RE: Transfer-codings, mandatory content-coding support and intermediaries

On 18 April 2014 23:49, msweet@apple.com wrote:
> ... *if* the goal is to provide semantic compatibility between 1.1 and 2.0 ...
> A 2.0 proxy talking to a 1.1 server can fairly easily convert a 2.0 request using a gzip bit

> into a 1.1 request using T-E: gzip (just concatenate the gzip streams from each DATA

> frame), but the reverse will require the proxy to decompress the T-E: gzip stream from the

> 1.1 server and then either provide an uncompressed response to the 2.0 client or

> re-compress each DATA frame.

Or the proxy could simply not declare support (i.e. not send a "TE: gzip" header to the server) and then compress the response frame-by-frame, but that also seems like a waste of bandwidth and an ugly hack.

Which begs the question, why not TE/Transfer-Encoding? It would obviously retain semantic compatibility.

I don't understand the need to eliminate all hop-to-hop headers (mentioned by Martin and others). Specifically, what problems are introduced by having T-E in the headers instead of a flag in the frame?

Also, I haven't seen comments yet as to whether or not text similar to the following would appease the security concerns (regardless of the method; T-E or frame-by-frame) ...

>>> Intermediaries MUST NOT add transfer coding(s).  Intermediaries MAY remove transfer coding(s) if necessary. Intermediaries MAY remove and re-apply transfer coding(s), but the transfer coding(s) MUST be re-applied in the same order as applied by the origin.  For example, an intermediary might elect to remove a gzip transfer coding for local storage in its cache in order to more easily extract a range of the content. In this case, when serving a range, the intermediary can choose to send the range with no transfer coding or with gzip transfer coding, but not with any other transfer coding(s).



This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Friday, 18 April 2014 22:35:11 UTC