On 25 July 2014 01:39, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> This bit makes no sense for a HTTP/2 proxy, since it MAY split the
> just assembled cookie header again for transmission:
>
> 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 ";
> ").
>
This makes no sense for an origin server either.
The origin server has to parse the cookie field into individual fields
anyway, so asking for them to be combined, just to be split again waste CPU
and memory. Servers have to handle multiple cookie fields from h1
anyway - so Jetty will just not do this and nobody will be the wiser as the
same Cookies will be handed over to the application either way.
What benefit is being sought by requiring this merge?
If it is a significant benefit, can't we put the burden on the client to
not send multiple cookie headers rather than make the poor server have to
receive the multiple headers, merge them and then split them?
cheers
--
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.