[Python-bugs-list] [ python-Bugs-432621 ] httplib: multiple Set-Cookie headers

noreply@sourceforge.net noreply@sourceforge.net
Sat, 14 Jul 2001 18:20:42 -0700


Bugs item #432621, was opened at 2001-06-12 19:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib: multiple Set-Cookie headers

Initial Comment:
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.


----------------------------------------------------------------------

Comment By: Andrew Gaul (gaul)
Date: 2001-07-14 18:20

Message:
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.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 23:01

Message:
Logged In: YES 
user_id=3066

Categorized as a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470