RE: Making Implicit C-E work.

On Wednesday,30 April 2014 12:27, Roberto Peon Wrote:

>

> On Wednesday,30 April 2014 11:35, Roland Zinks wrote:

>>

>> On Wednesday,30 April 2014 08:45, Roberto Peon Wrote:

>>> In fact what we're doing is offering two representations simultaneously.

>>

>> Don't think this will really work. Only one can delivered and translating between them (for example range) seems to be difficult.

>

> Why is range a problem? If a server wishes to service a range request, it need not compress the output.

> With the proposal, the server will be able to know if the client requested gzip explicitly or not and make

> the correct decision w.r.t. what to output. This is the same as it is today with HTTP/1.



Let's clarify that.  If a server wishes to service a range request it MUST NOT use implicit c-e gzip to compress the output.



range(gzip(content)) != range(identity(content))



This introduces loop-holes for all of those intermediaries you're trying to combat which strip a-e gzip.



For example, an intermediary could...

+ Strip a-e gzip and inject a range request for the entire content:

   "Accept-Encoding: identity"

   "Range: bytes=0-"

+ Or, if the server is too smart for that, strip a-e gzip and inject a multi-part range for the entire content:

   "Accept-Encoding: identity"

  "Range: bytes=0-0,1-"

+ Or, if the server is really smart, strip a-e gzip and split the request into two separate range requests for the entire content:

   "Accept-Encoding: identity"

   "Range: bytes=0-0"

   ...

   "Accept-Encoding: identity"

   "Range: bytes=1-"



Of course the server could simply disable Range requests (i.e. always send the full c-e gzip response - which is legal).  I would argue that this will also degrade the user experience as there are more and more users browsing on spotty networks (e.g. Safari doesn’t use range requests [1] and it drives me crazy every time I’m loading a page and there is a break in network connectivity on the subway, because then it has to start all over).



[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0112.html




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.