- From: Jason Greene <jason.greene@redhat.com>
- Date: Thu, 26 Jun 2014 12:40:58 -0500
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
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