RE: #445: Transfer-codings - Alternate proposal

Hi Amos-



Thanks for your response. Since there is obviously little support for this proposal, we are putting our support behind Matthew's proposal.



However, I did want to respond to a couple of your comments, for completeness and because you bring up a few interesting points I hadn't thought of...





On Tuesday,08 April 2014 18:35, squid3@treenet.co.nz wrote:
>> ...  Essentially making Transfer-Encoding end-to-end. This is

>> a bit ugly though because it changes semantics and would likely cause

>> confusion. ...

>>

> Making TE end-to-end effectively makes it a redundant duplicate of CE.



I disagree.  There would still be a subtle, but important, difference between TE and CE.



Content-Encoding is applied *before* a range is extracted.

- from RFC2616 Section 14.35.1: "Byte range specifications in HTTP apply to the sequence of bytes in the entity-body ..."

- from RFC2616 Section 7.2.1: "entity-body := Content-Encoding( Content-Type( data ) )"



Transfer-Encoding is applied *after* a range is extracted.

- from RFC2616 Section 4.3: "message-body = entity-body | <entity-body encoded as per Transfer-Encoding>"



As a result, there is no way to extract a range of the Identity content coding of data (i.e. original form) and then compress the result without using TE.  Although TE is not widely adopted in 1.1, it is part of the spec and we use it heavily for this very purpose.  Since HTTP/2 got rid of TE/Transfer-Encoding, we can't do that anymore.  Hence our fight for some sort of encoding that can be applied after a range is extracted.





>> ...

>> - A variation on the above solution would be to introduce a new end-to-end coding called "Message-Encoding".  The key difference between "Content-Encoding" (C-E) and "Message-Encoding" (M-E) would be that C-E comes before the Range is applied and M-E comes after the Range is applied.

>> ...

> This seems to be missing the point about Range requests problem.

> Part of the bigger problem is that intermediary cachesneed to store the messages and expect to be able to server sub-ranges out of it to meet client requests. Whether they received a full object or not this is true.

> ...



It seems we have two different range problems (ours is explained above).  (Also, we do not use proxies, so my knowledge here is limited...) In this case I would say the intermediary would remove the message encoding before caching and serve sub-ranges from that - optionally re-compressing with message encoding for whatever sub-range is requested that the proxy can fulfil.





>>   - The only downside is that intermediaries couldn't add compression ...

>>

> I suspect nobody here is working on satellite link networks. Squid project is regularly getting requests/pressure

> from those groups to do things like force compression, improved caching, etc. anything that might reduce bandwidth

> and need to transfer full copies of objects.



Actually we do use satellite link networks.  We even still have to use modems to some countries.  So we can empathize with this exact problem.  (We just don't use intermediaries.)



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.