Re: disabling header compression

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