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

Re: intermediaries, implicit gzip, etags, no-transform

From: Michael Piatek <piatek@google.com>
Date: Fri, 20 Jun 2014 14:52:04 -0700
Message-ID: <CAOTbZVnaU+DK9DCHfomKmsi0g9iBqbVCq7jnra1DESdfoDft4A@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Yup, Content-Encoding is protected. (I'm looking at the list in 2616
sec 13.5.2). I see that the proxy is gzipping text no-transform
responses. Thanks.

Are you aware of any sites that break given this behavior? Often,
misconfigured origins simply mark all responses as no-transform, and
it would be unfortunate to lose the compression benefits of gzip given
that it's typically benign.

On Fri, Jun 20, 2014 at 2:14 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2014-06-20 22:53, Michael Piatek wrote:
>>
>> On Fri, Jun 20, 2014 at 1:41 PM, Julian Reschke <julian.reschke@gmx.de>
>> wrote:
>>
>>> In the meantime, can you define what you consider a "real" site?
>>
>>
>> A site that breaks when using the data compression proxy that is not
>> contrived to do so.
>>
>>>>> - setting "cache-control: no-transform" on the response, does not
>>>>> change
>>>>> this behavior, thus both seem to violate a "MUST NOT" requirement from
>>>>> <http://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.5.7.2>
>>
>>
>> Actually, an example URL would be helpful for this case as well. In my
>> testing, I observe the proxy respecting the no-transform directive;
>> i.e., response payloads carrying cache-control: no-transform are not
>> modified, nor are the protected headers.
>
>
> Is "Content-Encoding" in your set of "protected headers"?
>
> Best regards, Julian
>
Received on Friday, 20 June 2014 21:52:52 UTC

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