Re: disabling header compression

On Thu, Dec 12, 2013 at 3: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 probability
> 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.
>

Optionality/negotiation also increases the likliehood of failure.
It does not reduce complexity, but rather moves it around.

There is always a tradeoff between optional features and reliability.

-=R


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