- From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
- Date: Tue, 8 Jul 2014 17:59:10 +0000
- To: Jeff Pinner <jpinner@twitter.com>, Martin Thomson <martin.thomson@gmail.com>
- CC: Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
> -----Original Message----- > From: Jeff Pinner [mailto:jpinner@twitter.com] > Sent: mardi 8 juillet 2014 19:47 > To: Martin Thomson > Cc: Cory Benfield; HTTP Working Group > Subject: Re: Large Frames, Continuations, Flow Control, and changing HPACK > > > For some sets of data. The samples we have are for browsing and only > > for very short sessions. For APIs, server-to-server, > > XmlHTTPRequest-heavy pages, and similar, my understanding is that a > > reference set would be a significant improvement. I believe that the > > reference set would have represented a significant improvement in the > > applications I was building when I was at Microsoft. Sadly, I can't > > run the numbers to support this claim. > > I am not suggesting we remove the header table, so you can still > encode header fields using the "indexed representation." Yes it is > less efficient than requiring 0 bytes, but in most cases you should be > abel to get away with encoding it in 1 or 2 bytes. 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é.
Received on Tuesday, 8 July 2014 17:59:44 UTC