RE: Cookie crumbling in -09

Except that there's nothing on the wire communicating which form was used; "restoring" doesn't seem possible without communicating that.  An implementation will probably always do one or the other.

-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu] 
Sent: Saturday, November 16, 2013 12:22 AM
To: Martin Thomson
Cc: HTTP Working Group
Subject: Re: Cookie crumbling in -09

On Sat, Nov 16, 2013 at 09:02:13AM +0100, Willy Tarreau wrote:
> Hi Martin,
> 
> On Fri, Nov 15, 2013 at 11:52:02AM -0800, Martin Thomson wrote:
> > I've just added some text to the editor's draft [1] around special 
> > handling of the cookie header field.  This will allow clients to 
> > squeeze out a little more compression efficiency.
> > 
> > After the gaffe earlier this week with -08, I wanted to publicize 
> > this a little.  This is the only substantial change between -07 and 
> > the imminent -09 in the main specification.
> > 
> > There are, of course, other compression-related changes coming in HPACK.
> > 
> > [1] 
> > https://github.com/http2/http2-spec/commit/b9a62379e29174bada803fb27
> > e2a6d36b69513f0
> 
> This part looks strange to me :
> 
>   If there are multiple Cookie header fields after decompression,
>   these MUST be concatenated into a single octet string using the
>   two octet delimiter of 0x3B, 0x20 (the ASCII string "; ").
> 
> Indeed, right now applications correctly handle cookie as a list of 
> values which can be aggregated using commas like any other header 
> field. Thus, why make a special case of this cookie header and force 
> implementations to parse requests to see if there are multiple 
> occurrences and merge them differently than what is done for other 
> header fields ? I'd rather suggest that if there are multiple Cookie 
> header fields after decompression, they MAY be concatenated into a 
> single octet string using commas just like any other header field 
> (0x2C 0x20).

Or maybe even better, we could probably say that the headers MAY preferentially be concatenated using 0x3B 0x20, though the default header field folding using 0x2C 0x20 is fine as well. At least we allow implementations to restore what they found on the input in the case the cookies were all on a single line emitted by a browser using semi-colons.

Willy

Received on Saturday, 16 November 2013 18:47:57 UTC