Re: disabling header compression

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.

On Fri, 13 Dec 2013, Patrick McManus wrote:

> this is all well trodden territory. HTTP/1 has taught us the folly of
> optional features. (gzip requests, trailers, etc..)
> 
> Figure out what is important, define it, and then use it widely. HTTP/2 has
> done a pretty decent job of that so far with really just one significant
> exception (and that has a decent reason (flow control)).
> 
> 
> 
> 
> On Fri, Dec 13, 2013 at 11:34 AM, Peter Lepeska <bizzbyster@gmail.com>wrote:
> 
> > If it's on by default and disabled by a flag in SETTINGS, then we'd
> > still get the benefit you describe except when we've explicitly
> > decided we didn't want it. I think removing options (making more
> > things mandatory) is a way to manage complexity. But HPACK actually
> > ADDs complexity to any implementation so it makes sense to make it
> > optional. Lastly, your example of 30 parallel requests is only true
> > for rendering web pages. If I'm using HTTP 2.x to send a large file,
> > or any one of a large number of other use cases, header compression
> > gives me no benefit.
> >
> > Peter
> >
> > On Fri, Dec 13, 2013 at 11:17 AM, Patrick McManus <pmcmanus@mozilla.com>
> > wrote:
> > > This becomes exactly like sending Content-Encoded: gzip on requests in
> > > http/1 if compression is optional. In other words - it would be horribly
> > > broken.
> > >
> > > game it out.. you increase adoption of servers that don't receive
> > > compression and you don't negotiate that separately with alpn. Now
> > clients
> > > send a burst of 30 parallel requests in the same cwnd on the first rtt
> > (the
> > > real value of the compression) and they all get reset and have to start
> > > over,, that's one wasted rtt.. and now the client has to send those same
> > > requests again, but uncompressed and across 3 rtts because they don't
> > fit in
> > > the cwnd anymore.
> > >
> > > That's +3 rtt. blech!
> > >
> > > I don't want to increase adoption of whatever that lazy protocol is
> > called
> > > because it sucks compared to http/2. :)
> > >
> > > I want http/2 to be able to always count on what makes spdy work well:
> > > multiplexing, compression, prioritization, and [though some will panic at
> > > its mere mention] better crypto. It requires some effort, stipulated.
> > >
> > > fwiw - CRIME forced me to effectively disable gzip upstream in
> > firefox-spdy
> > > (its gzip formatted, but all literals) and its easy to see the +~2RTT
> > > penalty in benchmarks. Give spdy a lot of credit here - it demonstrated
> > the
> > > value of header compression and that we don't want to do it with a stream
> > > compressor. Running code ftw.
> > >
> > > -P
> > >
> > >
> > > On Fri, Dec 13, 2013 at 10:50 AM, Peter Lepeska <bizzbyster@gmail.com>
> > > wrote:
> > >>
> > >> +1 to what David said. I especially agree with this "Removing the
> > >> implementation of the header compression will simplify the
> > >> minimal implementation of HTTP/2", which I think is very important to
> > >> increase adoption.
> > >>
> > >> Peter
> > >>
> > >> On Fri, Dec 13, 2013 at 10:49 AM, Peter Lepeska <bizzbyster@gmail.com>
> > >> wrote:
> > >> > +1
> > >> >
> > >> > On Thu, Dec 12, 2013 at 6:11 PM, David Morris <dwm@xpasc.com> wrote:
> > >> >>
> > >> >> Removing the implementation of the header compression will simplify
> > the
> > >> >> minimal implementation of HTTP/2. Requiring support of the static
> > table
> > >> >> increase complexity. Worse is the RST rain dance you describe as that
> > >> >> is essentially a hack adding complexity and increasing the
> > probablility
> > >> >> of failure.
> > >> >>
> > >> >> It at least partially makes any performance evaluations or other
> > >> >> testing
> > >> >> attempts burdened with the overhead of opting out and perhaps
> > >> >> introducing
> > >> >> additional failure points in the RST process. Certainly, if I as a
> > >> >> developer or system admin suspect an issue with header integrity, I
> > >> >> can't
> > >> >> perform true isolation by turning off compression.
> > >> >>
> > >> >>
> > >> >> On Thu, 12 Dec 2013, Roberto Peon wrote:
> > >> >>
> > >> >>> These things are all possible with ALPN.
> > >> >>> There has been a proposal w.r.t. setting the default compression
> > >> >>> context
> > >> >>> size to zero, but I don't think there was a lot of support for that.
> > >> >>> ... which, honestly, is reasonable if a shade disappointing: One can
> > >> >>> RST
> > >> >>> the streams one doesn't like and wait for one RT for the setting of
> > >> >>> the
> > >> >>> compression context size to occur at the remote end.
> > >> >>>
> > >> >>> Alternate compression schemes are also doable via ALPN.
> > >> >>>
> > >> >>> If you don't want to handle compression you:
> > >> >>> 1) Send a SETTINGS frame requesting that the receive side-context be
> > >> >>> sized
> > >> >>> to zero.
> > >> >>> 2) RST all streams that would store state in the compression context
> > >> >>> until
> > >> >>> you receive the acknowledgement that this has occurred from the
> > remote
> > >> >>> side.
> > >> >>> 3) Proceed normally to handle stuff with zero context size.
> > >> >>>
> > >> >>> While not optimal in the DoS case, it certainly would be difficult
> > to
> > >> >>> argue
> > >> >>> it doesn't work.
> > >> >>> In the non-DoS case, you end up wasting an RT and a few bytes. I'd
> > >> >>> imagine
> > >> >>> that much of the time when someone is interacting with such a
> > >> >>> low-footprint
> > >> >>> thing that either the additional RT of delay isn't a big deal.
> > >> >>>
> > >> >>> I don't think it is too much to ask people to handle the static
> > table
> > >> >>> (it
> > >> >>> really is just a lookup into an array at that point) or huffman
> > stuff.
> > >> >>> -=R
> > >> >>>
> > >> >>>
> > >> >>> On Thu, Dec 12, 2013 at 10:19 AM, David Morris <dwm@xpasc.com>
> > wrote:
> > >> >>>
> > >> >>> >
> > >> >>> > I agree ... being able to disable compression is an important
> > >> >>> > complexity reduction for low foot print clients and/or servers.
> > >> >>> >
> > >> >>> > I think it is also a very useful capability in support of general
> > >> >>> > testing and performance evaluation.
> > >> >>> >
> > >> >>> > I'd also like so see an explicit mechanism for specification of
> > >> >>> > an alternate compression algorithm .. I think it is way to early
> > >> >>> > to lock down a specific approach and it would be very powerful to
> > >> >>> > allow easy deployement of an alternative.
> > >> >>> >
> > >> >>> > On Thu, 12 Dec 2013, Peter Lepeska wrote:
> > >> >>> >
> > >> >>> > > Thanks for the quick replies.
> > >> >>> > >
> > >> >>> > > So just in summary, in the current spec compression is the
> > choice
> > >> >>> > > of
> > >> >>> > > the sender but receivers always must support decompression.
> > >> >>> > >
> > >> >>> > > It would be nice to have just a nice clean DISABLE_COMPRESSION
> > in
> > >> >>> > > the
> > >> >>> > > SETTINGS frame so that receivers do not need to support
> > >> >>> > > decompression.
> > >> >>> > > Has that been discussed? I know there is a concern of cluttering
> > >> >>> > > up
> > >> >>> > > SETTINGS, but this seems like an important option.
> > >> >>> > >
> > >> >>> > > Peter
> > >> >>> > >
> > >> >>> > > On Thu, Dec 12, 2013 at 12:20 PM, Michael Sweet <
> > msweet@apple.com>
> > >> >>> > wrote:
> > >> >>> > > > Peter,
> > >> >>> > > >
> > >> >>> > > > You can't disable it but you can always just send literal
> > >> >>> > > > values.  The
> > >> >>> > > > kicker, of course, is that you will still need to support
> > >> >>> > decompression...
> > >> >>> > > >
> > >> >>> > > >
> > >> >>> > > > On Dec 12, 2013, at 11:50 AM, Peter Lepeska
> > >> >>> > > > <bizzbyster@gmail.com>
> > >> >>> > wrote:
> > >> >>> > > >
> > >> >>> > > > Is it possible for a browser, proxy, or web server to disable
> > >> >>> > > > header
> > >> >>> > > > compression in HTTP2? If not, I'm sure there was discussion
> > >> >>> > > > around this
> > >> >>> > > > decision but my search of the archives has not come up with
> > >> >>> > > > anything.
> > >> >>> > > >
> > >> >>> > > > Thanks,
> > >> >>> > > >
> > >> >>> > > > Peter
> > >> >>> > > >
> > >> >>> > > >
> > >> >>> > > >
> > >> >>> > > > _________________________________________________________
> > >> >>> > > > Michael Sweet, Senior Printing System Engineer, PWG Chair
> > >> >>> > > >
> > >> >>> > >
> > >> >>> >
> > >> >>> >
> > >> >>>
> > >> >>
> > >>
> > >
> >
>

Received on Friday, 13 December 2013 17:44:45 UTC