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

> On 08 Jul 2014, at 20:48, "Herve.Ruellan@crf.canon.fr" <Herve.Ruellan@crf.canon.fr> wrote:
> An alternative to the reference set would be to add an "indexed range" opcode, that would correspond to several contiguous header fields in the header table.
> It would be less efficient than the reference set, as it would need at least 1 or 2 bytes to represent a group of headers where the reference set used none, and would depend on the ordering of the headers in the header table.
> However, in specific scenarios such as those pointed at by Martin, a well thought filling of the header table should allow getting significant improvements.
>
> Hervé.

+1
I think this is a good idea.  (It has a lot of similarities to what I proposed here [1] as an alternative to HPACK.)

When I was writing my proposal I spent a lot of time thinking about compressing runs of keys/values rather than just a single key or value.  The trick is for the decompressor to have some insight (a priori or learned) about the "staticity" of keys and values.  I started doing some research on the http2_samples data set; I'll see if I can dig that up.

Question? Are duplicates allowed in the hpack header set? That would be important for creating different static groups (eg by mime type) where, for example the accept and accept-encoding headers vary by mime type, but user-agent doesn't.

eg consider the following (very) contrived pseudo header table

1 user-agent
2 Mozilla
3 accept
4 text/HTML
5 accept-encoding
6 gzip
7 user-agent
8 Mozilla
9 accept
10 image/JPEG
11 accept-encoding
12 identity

there is a lot of repeat in the table, but the next time I request an HTML page I just need to send a "indexed range" opcode with index 1 and count 6 (two bytes to encode I guess)
But the next time I request an image I just need to send a "indexed range" opcode with index 7 and count 6
Obviously indexing each entry separately would require more bytes on the wire


[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1040.html

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Tuesday, 8 July 2014 21:26:17 UTC