Re: disabling header compression

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