On 3 June 2014 22:49, Martin Thomson <martin.thomson@gmail.com> wrote: > > But I would also point out that the proposal I made above does support > > arbitrary sized headers. > > Not quite. Arbitrary sized blocks, but not individual fields. Long > URLs and cookies are a part of the landscape unfortunately. Well it should be pretty simple to either modify hpack to support field aggregation or come up with a field naming convention to support aggregation of fields from different sets. My proposal would then still allow arbitrarily large meta data sets and fields - it would just keep them out of the transport meta data channel which intermediaries and servers have to handle specially. Yes there are current examples of some fields approaching 64KB (thanks Mike), but their existence is not an argument to make the transport meta channel unlimited. Those near 64KB use-cases are examples of exactly the kind of usage creep that will consume more and more resources from the intermediaries and servers unless we put a stop to it and offer them a more suitable channel for this application meta data. 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 Tuesday, 3 June 2014 21:13:43 UTC