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

Re: Stateless Multiplexable Continuations #541

From: Jason Greene <jason.greene@redhat.com>
Date: Thu, 26 Jun 2014 12:48:47 -0500
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-Id: <BECD32B0-A9B8-4928-8A3F-C0957FB2626D@redhat.com>
To: Mark Nottingham <mnot@mnot.net>
On Jun 26, 2014, at 12:40 PM, Jason Greene <jason.greene@redhat.com> wrote:

> On Jun 18, 2014, at 11:49 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> On 18 Jun 2014, at 8:29 pm, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>>> I'm starting to really hate the entire HEADER+CONTINUATION kludge
>>> upon kludge upon kludge hackery.
>>> My preference would be to impose sanity by simply removing CONTINUATION
>>> and telling cookie monsters that if their HPACK compressed HTTP
>>> headers do not fit in 16k, they should consider a diet.
>> One thing that came up in a side conversation in NYC was the possibility of only HPACKing the HEADERS frame; subsequent CONTINUATION frames would be uncompressed (so they don't affect state, and could be flow controlled). 
>> I kinda like it, YMMV.
>> At any rate, a server (origin or proxy) is perfectly within its rights to 431 Request Header Fields Too Large any request that has a CONTINUATION, and then reset the stream. They'll learn pretty soon…
> Since it seems likely that the jumbo frames are going to be sidelined to an extension, I really think this proposal needs a second look. It has a lot of really nice benefits including:
> 1. Discouraging CONTINUATIONS (slightly harder to create and they take more space)
> 2. Better multiplexing (other streams are not penalized by a “rude” stream)
> 3. Ability to RST_STREAM vs GOAWAY + close
> 4. Complexity of processing a standalone HEADERS frame (the desired behavior) is reduced

^ Actually I misstated this, its slightly reduced when you are processing a HEADERS frame with following CONTINUATIONS, but this benefit is very minor so I probably shouldn’t have even mentioned it.

> 5. All of the benefits of the existing design are preserved, but with a cleaner solution
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Thursday, 26 June 2014 17:50:30 UTC

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