Re: disabling header compression

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

Received on Friday, 13 December 2013 15:49:47 UTC