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

Stateless Multiplexable Continuations #541

From: Jason Greene <jason.greene@redhat.com>
Date: Thu, 26 Jun 2014 12:40:58 -0500
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-Id: <380B70E6-7937-4539-9FBA-E2D32A1A950E@redhat.com>
To: Mark Nottingham <mnot@mnot.net>

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
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
Received on Thursday, 26 June 2014 17:42:44 UTC

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