Issue432621
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-06-13 02:20 by anonymous, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Messages (9) | |||
---|---|---|---|
msg5034 - (view) | Author: Nobody/Anonymous (nobody) | Date: 2001-06-13 02:20 | |
httplib does not support multiple headers of the same name, because the headers are stored in a dictionary. This causes a problem because an HTTP response can contain multiple "Set-Cookie". It is stated in RFC2109 - HTTP State Management Mechanism that "An origin server may include multiple Set-Cookie headers in a response. " With the current python implementation, only the last "Set-Cookie" header is included in the headers dictionary, effectively meaning that the other cookies were lost. |
|||
msg5035 - (view) | Author: Fred Drake (fdrake) | Date: 2001-07-04 06:01 | |
Logged In: YES user_id=3066 Categorized as a feature request. |
|||
msg5036 - (view) | Author: Andrew Gaul (gaul) | Date: 2001-07-15 01:20 | |
Logged In: YES user_id=139865 I'm willing to fix this, but I could use some clarification of the relevant RFCs (822 and 2045). Do either of these allow multiple headers with the same field names? I get the impression from looking around in Google that reusing a field is discouraged, but necessary for things like HTTP's Set-Cookie header. If one or both of the standards allow the above, I'll add an optional argument (defaulting to the current behaviour) that controls the handling of duplicate field names. If the flag is passed, any field name having more than one value will return the duplicate values in a list. For example: foo: yes bar: false bar: true will be returned as {foo: yes, bar: [false, true]} as opposed to the old return value {foo: yes, bar: true} HTTPResponse will always use this new behaviour, which may break some programs that rely on the old behaviour. Does anyone have comments before I code up this solution? While I am concerned about breaking compatibility, it seems like a correctness issue that headers aren't handled properly. |
|||
msg5037 - (view) | Author: Steve Holden (holdenweb) * | Date: 2001-07-17 11:49 | |
Logged In: YES user_id=88157 RFC 822-compliant mail messages frequently contain several "Received-By:" headers. I cannot remember anything in the standard which speaks to the general case. There may well be headers whose semantics require enforcement of the "There can be only one" variety, but equally some others must be treated the same as "Received-By:". In so far as RFC 2616 [HTTP/1.1] says "Unrecognized header fields SHOULD be ignored by the recipient and MUST be forwarded by transparent proxies." (section 7.1: Entity header fields) this is an argument for being able to handle many unknown headers of the same type in the general case. For correct processing it is therefore necessary to hold headers as lists, or in some other way which allows multiple headers of the same type. Fortunately there appears to be no need to emit headers in the same order they were seen in the original to preserve meaning. |
|||
msg5038 - (view) | Author: Barry A. Warsaw (barry) * | Date: 2001-08-30 21:10 | |
Logged In: YES user_id=12800 Please use RFC 2822 instead of 822 as the former has replaced the latter. RFC 2822 describes the number of times standard headers must or can appear in a mail message. AFAIK, rfc822.py does no such enforcement (and there are good reasons to have both strict and lenient modes). My own mimelib (soon to be renamed and installed in the standard library) accepts duplicates by keeping headers in a list instead of a dictionary and searching the list linearly for hits. The speed advantages of a dictionary are probably minimal for typical mail messages, so a linear search, which preserves insertion order and duplicate order, is fine in practice. mimelib does not, but should have both a strict and lenient mode where duplicates breaking the standard are either allowed or flagged as errors. |
|||
msg5039 - (view) | Author: Greg Stein (gstein) * | Date: 2001-08-31 02:52 | |
Logged In: YES user_id=6501 Use response.msg.getallmatchingheaders() as a workaround. That said: the default operation of HTTPResponse.getheader () should use the same, since HTTP headers can (by definition) use multiple headers. And HTTP defines a way to join those headers into one. The solution here is to not return a list of header values (thus, breaking backwards compat), but to join them per the specification (with a ","). I'm reclassifying this as an Accepted bug due to fix in Python 2.2. |
|||
msg5040 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-08-31 03:37 | |
Logged In: YES user_id=6380 Greg: this is a new use of "Accepted" for me. We've only used "Accepted" for accepted *patches*. Bugs to be fixed simply remain open until they are fixed; I'm not sure I see the value of changing the status. Were you innovating here, or is this common usage in other projects? |
|||
msg5041 - (view) | Author: Greg Stein (gstein) * | Date: 2001-08-31 04:23 | |
Logged In: YES user_id=6501 I've been using it for Expat, but that still isn't authoritative :-) Basically, I'm trying to suggest that the bug has been "accepted as a real bug" and will be addressed. Sort of a "started", if you will, rather than leaving it in the indeterminate Open/None status/resolution. When it gets fixed, the resolution will be "Fixed" I kind of see it as a way to let the submitter know that their bug has been considered and acknowledged and will be fixed. |
|||
msg5042 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2002-07-07 16:52 | |
Logged In: YES user_id=31392 Fixed in rev 1.57 of httplib.py |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:07 | admin | set | github: 34621 |
2001-06-13 02:20:07 | anonymous | create |