W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: Set-Cookie vs list header parsing (i129)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 20 Aug 2008 15:34:16 +0200
Message-ID: <48AC1D58.2050604@gmx.de>
To: Dan Winship <dan.winship@gmail.com>
CC: ietf-http-wg@w3.org

Dan Winship wrote:
> Julian Reschke wrote:
>> To be complete we would also need to cite the original spec
>> (<http://www.netscape.com/newsref/std/cookie_spec.html>, 404s...). We
>> already have three cookie-related references; enough is enough, isn't it?
> 
> Well, but that one is more worth citing than some of the others, since
> it's pretty much what people actually implement in practice.

It's indirectly referenced through RFC2965, which now has an erratum 
pointing out the backup URL (thanks, Daniel) -- see 
<http://www.rfc-editor.org/errata_search.php?rfc=2965>.

>> The currently proposed text is at:
>> <http://www3.tools.ietf.org/wg/httpbis/trac/attachment/ticket/129/i129.diff>
> 
> AFAIK, the problem is only with "Set-Cookie", not "Cookie". (There's no
> need to send multiple Cookie headers; the spec says you're supposed to
> include all of the cookies, semicolon-delimited, in a single Cookie header.)

OK, see 
<http://www3.tools.ietf.org/wg/httpbis/trac/attachment/ticket/129/i129.3.diff>.

>> Brian also proposed to make this REQUIRED behavior.
> 
> FWIW, 3 out of the big 4 browsers also don't correctly parse multiple
> WWW-Authenticate headers that have been merged into one (even though
> 2617 explicitly points out this possibility). So it might be best to
> just say that intermediaries SHOULD NOT merge headers, except in cases
> where they know it's safe.

Time for test cases and bug reports, I think.

BR, Julian
Received on Wednesday, 20 August 2008 13:35:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:54 GMT