RE: Header Compression - streaming proposal

I've been pondering on this proposal for some time.

I think it has several impact on the header compression mechanism.

1. The decoder can be much simpler. In particular, it can help avoiding nasty bugs due to the working set shadowing the index table.

2. It makes the encoder more complex. It think that the current spec allows for an encoder doing only one pass on the headers to encode, with the removed headers encoded at the end.
This new proposal enforce doing at least two pass on the headers to encode.

3. For performances, I will believe only when I see some numbers ;-).
The count of indexed entries will usually cost 8 bits. But 1 bit will be reclaimed on each entry, allowing to encoding larger index values on the first byte of each entry. I'm inclined to think this will result in a net gain, but I don't know how much.
However, if we decide to include typed codec, the reclaimed bit could be used as part of the signaling of which codec was used, and could decrease the cost of this inclusion.

Hervé.

> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: mercredi 10 juillet 2013 18:48
> To: Gábor Molnár
> Cc: HTTP Working Group
> Subject: Re: Header Compression - streaming proposal
> 
> On 10 July 2013 00:53, Gábor Molnár <gabor.molnar@sch.bme.hu> wrote:
> > I opened an issue on GitHub for this proposal with minor modification
> > to the original text:
> > https://github.com/http2/compression-spec/issues/11

> >
> > If I get more feedback, I will be happy to draft a PR as well.
> 
> The only feedback I have is that you could reclaim a bit from each of the
> existing opcodes by doing this, which could produce a pretty big increase in
> performance.
> 
> Starting the header block with a count (the number of index entries, prefix
> size 0), could make this quite efficient.

Received on Thursday, 11 July 2013 16:26:43 UTC