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

Re: Large Frames, Continuations, Flow Control, and changing HPACK

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 09 Jul 2014 15:03:17 +1200
To: ietf-http-wg@w3.org
Message-ID: <38861a782377399561c6d827805d92bc@treenet.co.nz>
On 2014-07-09 13:39, Mark Nottingham wrote:
> Everyone,
> 
> I think we're getting very close to consensus on Greg (et al)'s
> proposal, so clarity here would be appreciated.
> 
> Please be specific about what you like about this proposal --
> 
> a) Getting rid of the reference set (Jeff's "1", maybe "4") is a good
> idea, and complementary to Greg (et al)'s proposal
> b) This complete set of changes is a preferable alternative to Greg
> (et al)'s proposal
> c) Don't know, need to talk more.
> 

a and c.

I believe the reference set benefits are long-term and we wont be able 
to know whether the complexity is worth it until much of the ecosystem 
has been updated to HTTP/2 and implemented with some fairly smart 
encoding algorithms.

The proposal from Greg (et al) makes the frame encoding/decoding much 
more atomic which in turn reduces the necessity of removing reference 
set. There may be an alternative we can find on top of Gregs proposal 
that leaves those long term benefits with less complexity than present 
right now.

Someone may also come up with a better way to reduce repeated headers, 
or enable HPACK algorithm upgrades within h2 framing.

Amos

PS. I understand from discussions here that HPACK draft contains several 
completely separate encoding schemes/profiles but as written it is 
unclear which encoding operations apply to each profile. Perphase some 
editorial clarification to point implementers at which particular 
sub-set(s) of encoding actions make up each profile would help with the 
arguments about HPACK complexity.


> Thanks,
> 
> On 9 Jul 2014, at 2:39 am, Jeff Pinner wrote:
> 
>> To be clear, the proposal is:
>> 
>> 1) Remove the reference set from HPACK (use "Linear-H")
>> 2) Increase the frame size to 16-bits
>> 3) Allow interleaving of HEADERS frames
>> 4) Remove the "\0" separator hack.
>> 
>> Coupling this with my earlier proposal to add a "SYN_STREAM" header
>> would also allow us to:
>> 
>> 5) Remove CONTINUATION frames entirely
>> 6) Move END_* flags to the last HEADERS frame
>> 7) Flow control HEADERS frames
>> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 9 July 2014 03:03:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:19 UTC