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

On 2014-06-20 23:52, Martin Nilsson wrote:
> On Fri, 20 Jun 2014 22:23:05 +0200, Julian Reschke
> <julian.reschke@gmx.de> wrote:
>
>>
>> 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.
>
> That depends on where you draw the line for the UA box. If you split the
> browser into multiple processes, are they allowed to send different
> representation of the data between each other? What if you move some
> processes to different hosts?

What's relevant is what gets out of the UA, which includes code using 
XMLHttpRequest.

> It also depends on what your view is on the authority over data. Should
> the origin server overrule the user agents decision? If the user agent
> explicitly asked for compressed data, should the origin server be
> allowed to overrule that? Should no-transform defeat all network
> security appliances?

It's up to the origin server to decide whether it wants to support the 
requested content-coding. If it does not, *and* sends c-c no-transform, 
that's what it is.

And no, no-transform doesn't defeat network security appliances. Those 
appliance just can't transform *and* send a 2xx status.

Finally, let's not forget 
<http://greenbytes.de/tech/webdav/rfc7234.html#rfc.section.5.5.6>:

"5.5.6 Warning: 214 - "Transformation Applied"

This Warning code MUST be added by a proxy if it applies any 
transformation to the representation, such as changing the 
content-coding, media-type, or modifying the representation data, unless 
this Warning code already appears in the response."

Another thing I haven't seen in the HTTP responses I saw in Chrome and 
Opera.

>> 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.
>
> In the case of current Turbo it's not HTTP so the protocol requirement
> doesn't apply.

Are users who opt in to use of Opera Turbo aware that this can break 
existing protocol semantics?

Best regards, Julian

Received on Saturday, 21 June 2014 06:22:17 UTC