On 27 June 2014 00:56, Martin Thomson <martin.thomson@gmail.com> wrote: > The same applies here. We're chartered to define a protocol that can > carry HTTP. We already have evidence that >16K of headers is > sometimes used. And that is enough reason to provide support. > Period. > Martin, you have tried to make that argument before, but it failed to convince before and fails now. The charter says: There is emerging implementation experience and interest in a protocol that retains the semantics of HTTP without the legacy of HTTP/1.x message framing and syntax, which have been identified as hampering performance and encouraging misuse of the underlying transport. So if 64KB header fields may not be entirely misuse, they are certainly hampering performance and encouraging others to misuse headers. Further, HTTP semantics allows for a limit on header size. There have been technical proposal put here (ie jumbo frames) that would allow an arbitrary large header limit to be configured and accepted, just as it must be specifically configured in HTTP/1 implementations today. Basically it is a strawman to say that the arguments against continuations are == with those saying that we should not support large meta data. We are speaking against continuations and have proposed other mechanisms to support large headers. regards -- 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 Friday, 27 June 2014 07:07:01 UTC