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

On 2014-06-20 22:15, Martin Nilsson wrote:
> On Fri, 20 Jun 2014 17:12:20 +0200, Julian Reschke
> <julian.reschke@gmx.de> wrote:
>
>> Hi there,
>>
>> so I played around with Google's Data Compression proxy and Opera's
>> Turbo today, and found:
>>
>> - both implicitly use content-coding gzip, but do not touch the Etag,
>> potentially breaking HTTP semantics
>>
>> - GDCP adds a custom header field describing the original content
>> length (which of course has not been registered)
>>
>> - 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>
>>
>
> Both GDC and Turbo communicates between endpoints of known
> implementations. MUST and MUST NOTs are really only relevant seen from
> the outside, i.e. beyond the proxy. The exception would be
> intermediaries looking at this traffic, which both protocols assumes
> there are none of.

If the origin server say "no-transform", and the UA receives a 
transformed payload, that's non-conforming. I don't believe there's any 
wiggle room here.

> The cache-control: no-transform is really only set on ad images, so it
> is the semantic equivalent to the high priority flag on emails.

The spec is agnostic about what kind of payloads it's used on. It might 
be true that *in practice* it's mostly used for these, but that doesn't 
change the protocol requirement to leave the payload alone when it's set.

> The actual implementation of Turbo varies quite a lot between versions btw.

I tried with whatever the current Opera desktop version uses when I 
select the "Turbo option".

Best regards, Julian

Received on Friday, 20 June 2014 20:23:44 UTC