[RFE] multiple headers with the same name without combining

Hi

As some parts of Swazoo might get rewritten I take the chance and as
for a new feature ;-)

Currently Swazoo much like Kom treats the headers of an HTTP response
as a key value dictionary. There can only be one header with a given
name. If there are multiple headers with the same name, they are
combined. This works fine in theory but fails in practice. For example
combining cookies won't work because the cookie itself contains a
comma. If you set multiple cookies in one response most browsers will
see only the first one.

Cheers
Philippe

A couple of questions:

Which section of the HTTP RFC covers the point you are making?

Do you have an SUnit test that demonstrates the problem?

On 05/04/2008, Philippe Marschall <[hidden email]> wrote:

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

2008/4/5, Bruce Badger <[hidden email]>:
> A couple of questions:
>
>  Which section of the HTTP RFC covers the point you are making?

HTTP 1.1 [1]
4.2 Message Headers says
...
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma.
...

Now someone at Netscape apparently did not read the spec because the
Netscape cookie spec [2] says:

The date string is formatted as:
Wdy, DD-Mon-YYYY HH:MM:SS GMT

Notice the comma after the week day, that's the same as comma used for
header combining. As a result many browsers see only the first
"combined cookie" [3]. There are actually two RFCs [4] [5] that
address this issue. However browser support is severely lacking.

>  Do you have an SUnit test that demonstrates the problem?

Nope, I could write tests for the Swazoo side but that would be pretty
pointless because the bugs are in the browser.

 [1] http://tools.ietf.org/html/rfc2616
 [2] http://wp.netscape.com/newsref/std/cookie_spec.html
 [3] http://www.mnot.net/blog/2006/10/27/cookie_fun
 [4] http://tools.ietf.org/html/rfc2109
 [5] http://tools.ietf.org/html/rfc2965

Cheers
Philippe

Sorry, perhaps I'm missing the point you are making.

Are you saying that we are currently doing what the RFC says, but that
we should change that to something else?

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

2008/4/6, Bruce Badger <[hidden email]>:
> Sorry, perhaps I'm missing the point you are making.
>
>  Are you saying that we are currently doing what the RFC says,

Yes

> but that
>  we should change that to something else?

HTTPSetCookieField should no longer be written as a single header in
the case of multiple cookies. Instead it should be written as a one
header line per cookie.

To repeat the example of the cited sources, if we currently set two
cookies with Swazoo the resulting http response header looks like
this.

Set-Cookie: NS_1=a; expires=Wednesday, 01-Jan-10 0:0:00 GMT, NS_2=b;
expires=Wednesday, 01-Jan-10 00:00:00 GMT

But IE and FireFox will only see the first cookie. Instead if we set
one header for each cookie:

Set-Cookie: NS_1=a; expires=Wednesday, 01-Jan-10 0:0:00 GMT
Set-Cookie: NS_2=b; expires=Wednesday, 01-Jan-10 00:00:00 GM

Then FireFox and IE will see it. This behavior is in line with the
HTTP and all Cookie specs. And more important, it works in the real
world.

Cheers
Philippe

In general, software should be strict in what it emits and flexible in
what it accepts.  What you are suggesting is that we be kind of
flexible in what we emit too in order to work around perhaps
inconsistent bugs in other peoples software which, one would hope, the
authors would get around to fixing themselves at some point.   And
indeed the Mozilla people ask that any cookie problems be logged and
reported:

http://www.mozilla.org/projects/netlib/cookies/cookie-log.html

Also, I see in both RFC 2109 and it's successor RFC 2965: "Note that
an intervening gateway could fold multiple such headers into a single
header", so even if we did split the headers (just for cookies?) then
it may have no effect if people see the origin server through such a
gateway.  And that's something we can't control so at best such a
'fix' would be hit and miss in the real world.

Of course you can hack your local version of the http server to act in
any way you wish, but I think that the common code should reflect the
spec.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/