- 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>
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