W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: CONTINUATION was: #540: "jumbo" frames

From: Greg Wilkins <gregw@intalio.com>
Date: Fri, 27 Jun 2014 09:06:33 +0200
Message-ID: <CAH_y2NFHb3f4Zki+m=+GcgzD6WWGVgSXhJ98qTXJfDx02nrXyA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, Roberto Peon <grmocg@gmail.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.


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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC