Re: Cookie crumbling in -09

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)

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.

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

> I'd be interested in learning if multiple headers appeared ever in the wild.

Well, I don't know if browsers do this, I doubt it. I know at least one
component at a customer's which splits cookies over multiple lines to
avoid emitting more than 8kB per line. I would not be surprized if we
could find a few other ones.

That said, as soon as you propose to split the Cookie header values into
multiple header fields and to re-aggregate them afterwards, you're doing
exactly that.

If we want to be able to split values following semi-colons in HTTP/2
(usually they're just "attributes" of a value), we should probably invent
a specific encoding for this. Or instead, we should go further and define
how cookies should be converted to some HTTP/2-specific state management
and conversely.

Best regards,
Willy

Received on Monday, 18 November 2013 04:52:27 UTC