RE: Making Implicit C-E work.

On Thursday,15 May 2014 12:53, Mark Nottingham wrote:
> On 15 May 2014, at 11:48 am, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:

>> I am down with Matthew's suggestion here to lift the MUST. Though I note that there

>> are cases where this places an intermediary between a rock and a hard place in terms

>> of conflicting requirements. Maybe we can note that an intermediary /could/

>> decompress and leave the normative text out of it.

>

> That makes sense to me...



Let's be more clear.  That only makes sense _if_ you are assuming acceptance of Roberto's proposed "uncompressed-*" headers solution. Otherwise this doesn't solve any of the problems brought up by Matthew, Julian, myself and others with respect to etag, no-transform, metadata within the entity body, etc...





On Tuesday,29 April 2014 22:29, Roberto Peon Wrote:

> [SNIP]

> Servers seeing an implicit gzip a-e and sending a compressed entity MAY include an

> additional header field, ":uncompressed-etag" ...

> [SNIP]



I take issue with the MAY.  IMO, if the server wants to use implicit gzip it MUST include the "uncompressed-*" header fields, if such a header would have been sent with the corresponding entity with c-e: identity. Otherwise it forces the intermediary into a position where it has to either 1) decompress and break the metadata, or, 2) forward the response as-is and possibly cause inter-op issues (on second thought, maybe this a desirable feature for Roberto and others?).





Finally, I also would like to see text added to Roberto's proposal about how servers should deal with range requests with respect to implicit c-e gzip.  As I've pointed out many times, the range n-m of a c-e gzip entity is NOT equal to the range n-m of the entity's c-e identity encoding. Example text:



>>>

If a server elects to service a range request, it MUST NOT use implicit gzip content encoding.

<<<



As I pointed out earlier though, this opens up loop-holes for intermediaries to work around implicit gzip...



On Wednesday,14 May 2014 09:28, MORGAN, Keith Shearl wrote:

> 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.