Re: disabling header compression

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