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

Re: HPACK opcode bit patterns

From: Jason Greene <jason.greene@redhat.com>
Date: Wed, 6 Aug 2014 09:30:20 -0500
Cc: David Krauss <potswa@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <549CFAFA-EF58-4AE6-90E8-17AB93C64D2E@redhat.com>
To: Michael Sweet <msweet@apple.com>

On Aug 6, 2014, at 7:12 AM, Michael Sweet <msweet@apple.com> wrote:

> David,
> On Aug 6, 2014, at 6:58 AM, David Krauss <potswa@gmail.com> wrote:
>> ...
>> Also, an implementation can treat “without indexing” as “never indexed” and use a common code path, since the encodings are identical modulo a don’t-care bit. Wouldn’t be surprised if that was deliberate.
> That's the approach I am taking, and frankly I wouldn't cry if we just did away with the semantic difference and just had "never indexed".  While I don't think the extra bit will make a huge difference in compression ratio, it would simplify all implementations and it puts the onus of efficient encoding on the sender (vs. intermediaries like proxies).

If a proxy coalesces connections its encoding context can be radically different than the clients. A field sent by one client might already be in the state table from another client, and so an optimal hpack encoder would notice that and reuse that index, even if it was sent without indexing (no reason not to). So its important for a proxy to know the difference between a client which was simply optimizing its encoding context, and a header that should never be indexed.

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Wednesday, 6 August 2014 14:30:52 UTC

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