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

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