- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Fri, 21 Mar 2014 16:24:36 -0500
- 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