- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Mon, 26 Aug 2013 19:32:45 +0300
- To: ietf-http-wg@w3.org
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
pruned.
* 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...
-Ilari
Received on Monday, 26 August 2013 16:33:13 UTC