- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 22 Jun 2014 18:27:29 +1000
- To: K.Morgan@iaea.org
- Cc: phk@phk.freebsd.dk, squid3@treenet.co.nz, ietf-http-wg@w3.org
On 22 Jun 2014, at 1:58 am, K.Morgan@iaea.org wrote: > On 19 June 2014 06:49, 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). > > How could this work? Aren't headers allowed to cross frame boundaries? You can't switch from compressed to uncompressed in the middle of a header, no? A sender would have to compose their header frames appropriately; e.g., putting all of the small / repeating headers in the compressed frame, with remaining frames in the subsequent uncompressed frames. In a pathological case, it means that most or all of the headers would be uncompressed. Personally, I’m OK with that; it supports the weird cases, but doesn’t optimise for them. YMMV. -- Mark Nottingham http://www.mnot.net/
Received on Sunday, 22 June 2014 08:28:07 UTC