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

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?

> 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...

Good point, but I still like PHK's idea to use a length extension bit in the HEADER frames better.  Makes everything else a lot less messy.  You already require HEADER+CONTINUATION frames to be sent in one atomic chunk so having a single huge HEADER frame isn't any more of a HOL blocking issue than a sequence of HEADER+CONTINUATION frames of the same size.
This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Saturday, 21 June 2014 16:02:43 UTC