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

Re: Support for gzip at the server #424 (Consensus Call)

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Fri, 21 Mar 2014 16:24:36 -0500
Message-ID: <CACuKZqHUdei9LiKEfA=5hpEBAAzjd3gpVeiQ8wW7T_T+ri=24w@mail.gmail.com>
To: Roland Zink <roland@zinks.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Mar 21, 2014 at 3:37 AM, Roland Zink <roland@zinks.de> wrote:
> On 21.03.2014 00:58, Mark Nottingham wrote:
>>
>> In truth, I'm not entirely happy about the requirement for clients to
>> support compressed responses, but tolerate it both because we have broad
>> support for it, and its integration is relatively simple; it might require
>> intermediaries to selectively decompress for 1.1 clients, but that's pretty
>> straightforward.
>
> I have a concern about this in the presence of range requests / responses.
> Assuming there is a HTTP/1.1 to HTTP/2 gateway and a client supporting range
> requests but not gzip. The gateway can't decompress a potential range

The gateway cannot simply relay the Range request header to the origin
server. What the client means is a range over the uncompressed data;
what the server interprets is (most likely) a range over the
compressed data.

If the gateway does not keep the decompression state, it'll have to
request the whole compressed entity from the origin server.

> response when the start isn't included. What should the gateway do to a ETag
> header when it needs to decompress?

Maybe the gateway can do ETag transformation. If the origin response is

    Content-Encoding: gzip
    ETag: 123.gz

the gateway response can be

    (No Content-Encoding)
    ETag: 123.gz-gateway.ungzip

If the origin response is uncompressed

    (No Content-Encoding)
    ETag: 123

the gateway response should be

    (No Content-Encoding)
    ETag: 123-gateway

The gateway needs to undo the transformation on ETags in client requests.

Zhong Yu

>
> Roland
>
>
Received on Friday, 21 March 2014 21:25:03 UTC

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