W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: disabling header compression

From: Peter Lepeska <bizzbyster@gmail.com>
Date: Fri, 13 Dec 2013 10:50:02 -0500
Message-ID: <CANmPAYGhYoBWMrh_d++sMXxcjJ2s2oiDx0-pJxeMa5owi2AJ3Q@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
+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
>>> > > >
>>> > >
>>> >
>>> >
>>>
>>
Received on Friday, 13 December 2013 15:50:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC