Re: Stateless Multiplexable Continuations #541

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