W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: disabling header compression

From: Patrick McManus <mcmanus@ducksong.com>
Date: Fri, 13 Dec 2013 13:23:22 -0500
Message-ID: <CAOdDvNprOzxYd5Gf1q5QG0ALhf=A3+Xxtdy_tNJcB30n+gK3TA@mail.gmail.com>
To: Chris Burdess <dog@gnu.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
there is no negotiation before sending inside http/2. So the receiver must
be able to decode compressed headers in some form in order for the protocol
to work well. (resetting those streams and sending them again slowly does
not qualify as working well). Right now that base format is hpack.

We could add some kind of switch-alogirthms negotiation via settings that
could change things later on the fly.. (ironic given the motivation in this
thread is simplicity). Though I think just revving the protocol with *PN
makes a lot more sense.

On Fri, Dec 13, 2013 at 1:04 PM, Chris Burdess <dog@gnu.org> wrote:

> On 13/12/13 17:44, David Morris wrote:
> > I don't agree with the conclusion you reach from the HTTP/1 space.
> >
> > HTTP/1 has been all over the map because there were multiple ways
> > to do the same thing (compression). The lesson I get is that we
> > need clear unambigous specifcation of the options that are defined.
> >
> > Our design intent needs to remain replacing all possible requirement
> > for continuing use of HTTP/1.x. Mandatory support for header compression
> > will reduce adoption for the large space of devices which won't perceive
> > any significant value because of their particular use cases.
> >
> > Being able to turn off header compression will make failure analysis
> > triage easier, and it will allow for more comprehensive performance
> > comparision.
> >
> > My second point is that it should be easy to substitute an alternative
> > algorithm. We need to measure and compare alternatives.
> >
> > I believe header compression is a very good idea, I'm not convinced that
> > the current algorithm is the best we can do.
> Not compressing headers is simply a value of zero in the
> compressing-headers space. We cannot know that there will not be a
> better header compression algorithm developed tomorrow, and we shouldn't
> prevent such an algorithm from becoming a de facto standard. If you
> grant that header compression may take more than one form, it seems
> logical to allow no compression also since there may be use cases that
> support it.
Received on Friday, 13 December 2013 18:23:49 UTC

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