W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

RE: Re-work of op-code patterns

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Tue, 28 Jan 2014 17:05:20 +0000
To: Martin Thomson <martin.thomson@gmail.com>, Jeff Pinner <jpinner@twitter.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E532CCE5C3@ADELE.crf.canon.fr>
I ran the number, but they were maybe hidden at the end of my proposal.
Here there are again, with more details:

Mnot test set:
		Req	Res	All
Current		24,62%	37,53%	29,62%
Proposal	24,66%	37,53%	29,64%

Hruellan test set:
		Req	Res	All
Current		17,89%	26,34%	21,65%
Proposal	17,96%	26,34%	21,68%

So there is a compaction loss, but it's mostly negligible.

It is also probably easier for handling padding inside HPACK.

Hervé.

> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: lundi 27 janvier 2014 18:39
> To: Jeff Pinner
> Cc: RUELLAN Herve; ietf-http-wg@w3.org
> Subject: Re: Re-work of op-code patterns
> 
> On 27 January 2014 08:43, Jeff Pinner <jpinner@twitter.com> wrote:
> > With the proposed change what would 0b1000000 signal?
> 
> An indexed header field, the first one.
> 
> > If we are going to add a new opcode, I'd prefer to see the literal header
> > encodes both start with the same symbol:
> 
> The problem with your proposal is that it takes a rare condition
> (Encoding context change) and assigns a shorter opcode to it.  The
> cost is that header indexes greater than 30 will take an extra byte.
> If you really want this, run the numbers and let us know what it
> costs.
Received on Tuesday, 28 January 2014 17:05:55 UTC

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