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

RE: comments about draft-ietf-httpbis-header-compression

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Tue, 6 Jan 2015 09:17:28 +0000
To: Mark Nottingham <mnot@mnot.net>, Jyrki Alakuijala <jyrki@google.com>
CC: Dave Garrett <davemgarrett@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <5e8c279a02f04273bea8dd86b3064314@Antiope.crf.canon.fr>
Yes, the http2 compressor in the compression test is much out-of-date :-(

Hervé.

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: samedi 3 janvier 2015 18:25
> To: Jyrki Alakuijala
> Cc: Dave Garrett; ietf-http-wg@w3.org
> Subject: Re: comments about draft-ietf-httpbis-header-compression
> 
> See:
>   https://github.com/http2/compression-test

> 
> This is what we used to help make the initial selection; I don’t believe that the
> compressor there has been updated to exactly match the spec; e.g., it doesn’t
> do huffman (Herve?).
> 
> Cheers,
> 
> 
> > On 1 Jan 2015, at 10:35 am, Jyrki Alakuijala <jyrki@google.com> wrote:
> >
> > If the goal is to just make an algorithm that can work with a static entropy
> code with a static dictionary and no LZ77 outside the static dictionary, the
> current format (deflate) needs no changes. Deflate supports all these concepts.
> You only need a new encoder -- although zlib with setting a dictionary and
> running it with quality == 1 is a pretty close match already, only the static
> entropy coding is missing then.
> >
> > Was HPACK ever benchmarked against using deflate in such configuration?
> Would you accept help in setting up such an experiment?
> >
> > Note, that with a static dictionary I mean that we would generate a single
> deflate dynamic dictionary from a header corpus and always encode all data
> with that -- I don't refer to the static Huffman mode in deflate.
> >
> >
> > On Wed, Dec 31, 2014 at 7:52 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > The goal of HPACK was never to produce ideal compression, just competent
> > compression not vulnerable to known issues. Some people do want to attempt
> to
> > use/create a far more efficient codec here, but it's now accepted to be
> outside of
> > the initial scope. What could be very well received is an HTTP/2 extension to
> > allow negotiation of alternate header compression methods. This would allow
> > actual experimentation in an effort to find the most ideal route(s).
> >
> >
> > Dave
> >
> 
> --
> Mark Nottingham   http://www.mnot.net/

> 
> 
> 

Received on Tuesday, 6 January 2015 09:18:03 UTC

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