Re: disabling header compression

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 Thursday, 12 December 2013 23:12:30 UTC