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

Re: disabling header compression

From: David Morris <dwm@xpasc.com>
Date: Thu, 12 Dec 2013 10:19:54 -0800 (PST)
cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <alpine.LRH.2.01.1312121015380.22063@egate.xpasc.com>

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 18:20:27 UTC

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