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.
Received on Thursday, 24 July 2014 23:24:11 UTC