W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: Support for gzip at the server #424

From: 陈智昌 <willchan@chromium.org>
Date: Fri, 14 Mar 2014 15:22:01 -0700
Message-ID: <CAA4WUYh9-qDzASQ_fT_hi+Y8FUsrkakCNHwm1UJXQkfh3EGP8w@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Correct. But IIUC, the problem is the client doesn't know if there's a 1.0
intermediary or backend in the path, or if the 2.0 gateway is willing to
buffer (sounds crazy, but just for completeness I mentioned it). So the
client can't assume gzip support at the peer, even though we suspect most
would support it. Since we can't assume by default, I was thinking maybe we
can assume by having the server/proxy explicitly declare support.


On Fri, Mar 14, 2014 at 3:14 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 15/03/2014 11:04 a.m., William Chan (陈智昌) wrote:
> > It's unfortunate, but I agree that given the interop issues, I don't
> think
> > we can require this.
> >
> > I haven't thought about it deeply, but perhaps we can opt-in using the
> > SETTINGS and HTTP2-Settings headers. Explicit server declaration of
> > support. I haven't gamed it out completely in my head yet as to whether
> or
> > not that would create other obstacles and whether or not it's better than
> > application specific knowledge (e.g. JS shipped from server to client).
>
> The issue is mainly (only?) in 2.0->1.0 gateways, and only in that one
> direction. Solving it in the 2.0<->2.0 or 1.x->2.0 cases does not seem
> to be any benefit.
>
> Amos
>
>
>
Received on Friday, 14 March 2014 22:22:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC