decompression at 2 -> 1.1 gateway breaks ranges

>From Section 9.3: "Intermediaries that perform translation from HTTP/2 to HTTP/1.1 MUST decompress payloads unless the request includes an Accept-Encoding value that includes 'gzip'." [1]



Issue: Decompression by a 2 <-> 1.1 intermediary breaks ranges



Consider the following scenario...



+ A HTTP/1.1 client requests a static resource X (without an Accept-Encoding header i.e. implicitly only accepts Identity)



+ The request is routed through a 1.1 <-> 2 intermediary.



+ A HTTP/2 server responds with "Content-Encoding: gzip" for the static resource X (because in HTTP/2 C-E gzip is implicitly assumed acceptable and the server has no way to know the request came from a 1.1 client)



+ Per the requirement in Section 9.3 (quoted above), the 1.1 <-> 2 intermediary begins to decompress X before forwarding the response back to the client (and presumably strip the C-E header)



+ During the transfer of the response, the connection is dropped/cancelled



+ The client now has a part of resource X (with the Identity representation)



+ The client requests the remainder of resource X with a range request (as we showed in [2], almost all browsers will try a range request if it has the Identity representation of a content)



+ The server receives the request and serves the range from the gzip content encoded representation of X (again, because gzip is implicitly accepted in HTTP/2)



+ The 1.1 <-> 2 intermediary again tries to decompress the response, but fails because it is impossible to decompress part of a gzip (unless the portion starts from the beginning)



+ ...



Others have indirectly mentioned this problem before, but nobody seems to be listening...

- Roland said: "Existing HTTP/1.1 clients may not support C-E gzip and the gateway can't do the decompression without affecting HTTP/1.1 functionality like range requests." [3]

- Roy said (emphasis added): "Content Encoding is metadata about the representation.  If the protocol modifies a value for CE, then it breaks anything that relies on the payload being delivered without transformation (e.g., ranges and signature metadata)." [4]

- Roy also said (emphasis added): "Dynamic CE is deployed, but is known to break content signatures, ranges, and caches, and is incapable of supporting selectively compressed transfer from client to server." [5]



On a related note: decompressing from /2 -> /1.1 violates a requirement [HTTP-p1]

>From [HTTP-p1], Section 5.7.2: "A proxy MUST NOT transform the payload (Section 3.3 of [Part2]) of a message that contains a no-transform cache-control directive (Section 5.2 of [Part6])." [6]





[1] http://http2.github.io/http2-spec/#Compression

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

[3] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1225.html

[4] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1189.html

[5] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1203.html

[6] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-5.7.2



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.