Re: disabling header compression

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