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

Re: HPACK substitution & header table pruning

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Mon, 26 Aug 2013 19:32:45 +0300
To: ietf-http-wg@w3.org
Message-ID: <20130826163245.GA16850@LK-Perkele-VII>
On Mon, Aug 26, 2013 at 10:44:20AM -0400, Jesse Wilson wrote:
> I'm attempting to implement HTTP/2.0 for
> OkHttp<http://square.github.io/okhttp/>,
> Square's HTTP client for Android and Java.
> I'd like to clarify how header table pruning works with
> replacement-by-index.

Some other corner cases of HPACK / interaction with HTTP2:

- Literal Header with Substitution Indexing with indexed name pointing
  to entry which will be pruned.

  E.g. 01 01 <value>  When that operation causes the first entry to be

  * I presume the name is saved before pruning.

- What does 8+ in diagrams mean? 8-bit prefix? 0-bit prefix?

  * I presume 0-bit prefix, since one such field is mentioned to be 0-bit
  prefix in text.

- Parameter negotiation (yes I realize it is not part of spec):

  Does encoder have a way to bid down the context size?

  There seems to be some mechanism for bid-down for renegotiation,
  but initial negotiation seems to be fuzzier.

  Because of memory limitations for encoder, implementation
  limitations for encoder or unreasonable context size...

  * E.g. encoder using 16-bit offsets, only allowing up to 65535
    byte contexts...
  * E.g. remote peer signaling 4GB compression window...

Received on Monday, 26 August 2013 16:33:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC