Re: disabling header compression

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