- From: Jason Greene <jason.greene@redhat.com>
- Date: Wed, 6 Aug 2014 09:30:20 -0500
- To: Michael Sweet <msweet@apple.com>
- Cc: David Krauss <potswa@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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