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

So the gateway should create an ETag of its own, make it a weak etag or 
remove it? When the server doesn't know about it then the gateway 
probably need to translate the etag between the client and server legs. 
What happens if the client switch to a different gateway or talks 
directly to the server.

Regards, Roland


On 21.03.2014 21:21, Julian Reschke wrote:
> On 2014-03-21 20:12, Martin Thomson wrote:
>> On 21 March 2014 01:37, Roland Zink <roland@zinks.de> wrote:
>>> 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
>>> response when the start isn't included. What should the gateway do 
>>> to a ETag
>>> header when it needs to decompress?
>>
>> Sounds like a perfect case to apply 415 to.  ETag would (I imagine) be
>> the same regardless of whether gzip is applied.
>
> The Etag will need to be different, as it is a different entity.
>
> Best regards, Julian
>

Received on Friday, 21 March 2014 21:26:31 UTC