W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Cookie crumbling in -09

From: Willy Tarreau <w@1wt.eu>
Date: Mon, 18 Nov 2013 09:56:33 +0100
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20131118085633.GA19538@1wt.eu>
On Mon, Nov 18, 2013 at 09:30:10AM +0100, Julian Reschke wrote:
> On 2013-11-18 05:52, Willy Tarreau wrote:
> >Hi Martin,
> >
> >On Sun, Nov 17, 2013 at 04:44:19PM -0800, Martin Thomson wrote:
> >>On 16 November 2013 00:02, Willy Tarreau <w@1wt.eu> wrote:
> >>>Indeed, right now applications correctly handle cookie as a list
> >>>of values which can be aggregated using commas like any other header
> >>>field.
> >>
> >>All the discussions thus far, plus a reasonably careful reading of RFC
> >>6265 leads me to conclude that this is not the case.  In particular,
> >>http://tools.ietf.org/html/rfc6265#section-5.4 is quite clear:
> >>
> >>    When the user agent generates an HTTP request, the user agent MUST
> >>    NOT attach more than one Cookie header field.
> >
> >Indeed, I'm noticing this change in this version. Both 2109 and 2965 used
> >to define it this way using ';' or ',' as delimiters :
> >
> >   cookie          =  "Cookie:" cookie-version 1*((";" | ",") cookie-value)
> 
> But that's not the "list" rule that 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-25.html#rfc.section.3.2.2.p.2> 
> refers to.

Good catch, I didn't notice the "cookie-version" part that's mentionned
as mandatory here while almost nobody sends it (one more reason for 6265
to rely on use cases BTW).

> >I have no idea why Adam proposed this change in a way incompatible with
> >what was done for 15 years. Also I know a number of places where reverse
> >proxies add Cookie headers before passing the request to the server
> >(generally with user information or geoloc info). It's been said for a
> >while that only the Set-Cookie header could not be folded (because of the
> >date containing a comma) while the Cookie header can.
> 
> As far as I remember, this didn't come up while the httpstate WG worked 
> on the new cookie spec.

I participated a little bit near the end when I noticed there was some
ongoing work on this and didn't notice the disparition of the comma, it
was so obvious to me that cookies "remained" defined as a list...

> >>Given the grammar, which doesn't use the list construction or a comma,
> >>merging with commas would seem to be invalid.
> >
> >It used to be before 6265 at least.
> 
> Nope, see above.

It's a bit more complicated in fact. What happens is that folding cookie
header fields using commas used to work with previous parsers because
they used to support both the semi-colon and the comma and didn't care
about the $Version which was not part of the initial spec from Netscape.
Now since the original spec did not propose the comma as a delimiter, it
is indeed possible that some implementations prior to 2109 do not even
support it. That might be the reason the comma was finally removed from
6265. Definitely a sad situation.

So that probably goes in the direction of dealing specifically with
semi-colon delimited values in HTTP/2 without considering that, as a
special case, we split the Cookie header in multiple occurrences on
one side to fold it on the other side.

Ideally some cleaner state management would significantly help so that
this Cookie/Set-Cookie hell only affects 1.1-2.0 gateways and not at all
any end-to-end 2.0 communication.

Best regards,
Willy
Received on Monday, 18 November 2013 08:56:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC