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

Re: Stuck in a train -- reading HTTP/2 draft.

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 22 Jun 2014 18:27:29 +1000
Cc: phk@phk.freebsd.dk, squid3@treenet.co.nz, ietf-http-wg@w3.org
Message-Id: <FCDD1917-6D8B-45EE-98BA-FE890534DA10@mnot.net>
To: K.Morgan@iaea.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

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