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

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

From: Cory Benfield <cory@lukasa.co.uk>
Date: Tue, 8 Jul 2014 17:33:12 +0100
Message-ID: <CAH_hAJEuagWOuBXtQeqz3uRQ=6q4jKYAz=4jZYFsEEydidEaZg@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 8 July 2014 16:55, Jeff Pinner <jpinner@twitter.com> wrote:
> I would like to propose that we remove the "reference set" from HPACK.
>

Here's my understanding of the current state of affairs. The following
are, as far as I know, undisputed facts:

1. The reference set is the only part of HPACK that prevents header
frames being interleaved.
2. The reference set is the reason we cannot emit header sets in an
ordered manner, and so are the only reason section 8.1.2.3 of the
HTTP/2 draft exists.
3. The reference set has been shown to provide negligible compression
improvement in _today's_ header fields.
4. No-one has yet provided data to show a realistic data set of header
fields that does show significant improvement with the reference set.

Anecdotally, we can add the following:

5. At least two HPACK implementers (myself and Kazu Yamamoto) have
identified the reference set as the most complicated part of the HPACK
specification.
6. New implementers have complained that HPACK is extremely
complicated to implement from scratch.

With this in mind I'm strongly leaning towards killing the reference
set. I'm a little reluctant to throw away the work I did (having
rewritten my HPACK implementation to fix subtle reference set bugs in
the past). However, it seems clear that we get some big advantages.
Other things worth noting:

- Doing this could allow us to say that the fields relevant to routing
a request MUST come first in the headers block. This will make PHK a
lot happier, as intermediaries can quickly take action and then simply
pass the remaining header data through the compressor to /dev/null
(thereby maintaining header table state). We'd need to work out the
'routing relevant' fields, but that is a reasonable WG action.
- This makes HPACK truly streamable again (emit headers as soon as you
have them).

Assuming no data comes up to invalidate my points 3 and 4, I'm in
favour of this idea. Roberto and Johnny are the only two on the list
I've seen object so far, and Johnny claimed to be getting data. I'd
like to see it.
Received on Tuesday, 8 July 2014 17:00:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC