RE: current HTTP/2 spec prevents gzip of response to "Range" request

Hi Matthew-

Thank you for all of your feedback on our proposal...

On Tuesday,25 March 2014 23:25, Matthew Kerwin wrote:
>> ... ([HTTP-p2], Section 14.39) ...
> Do you mean HTTP-p1, Section 4.3 ?

Section 14.39 specifically talks about the TE header and specifies that chunked is always acceptable. We could reference both sections I guess.

>> Servers MUST not include the values "gzip" or "deflate" in a Content-Encoding header,
>> regardless of whether the requested content is already compressed, but SHOULD
>> include the appropriate mime type in the Content-Type header. Correspondingly,
>> clients SHOULD not include the values "gzip" or "deflate" in a Accept-Encoding header.
>Why? Is this an attempt to work around double-compression? It seems pretty heavy-handed.

If HTTP/2 were to mandate support for TE, as we proposed, then CE is no longer necessary (see next comment).

> Yes, I said I'd like to do away with CE, but it's widely used and very popular, we would
> need to come up with a legitimate replacement. I believe that mandating support for
> TE might provide a gradual path for replacement, especially if/when HTTP/1 fades away
> from the web (i.e. if every hop guarantees support for TE, I have one less need for CE).

The proposal was based on the idea of removing CE for gzip/deflate ala your idea to have
> foo.html.gz to be transferred as "Content-Type: application/x-gzip"
> instead of "Content-Type: text/html\r\nContent-Encoding: gzip".

We knew that wouldn't be a popular idea, but we had to start somewhere with our proposal.
Just mandating support for TE and keeping CE would likely mean TE will still never be widely adopted and CE would never fade away.
BTW, please feel free to modify our proposal with your suggestions.

> How about this example?
> * I have an Apache web server which serves two files: index.html and index.html_gz, the latter beings a gzip-compressed version of the first.
> * I have configured the Content-Type of the index.html_gz as "text/html", and the Content-Encoding as "gzip" [a].
> * I have configured my Apache server to detect Accept-Encoding:gzip on requests for the index.html file, and internally redirect those requests to index.html_gz
> * Apache then handles setting response headers such as Last-Modified, ETag, etc. based on the file stat, as it would any other file request.

(Repeating what I said earlier...) I would argue that this is actually a transport encoding because the client is supposed to remove the compression before presenting it to the user (see Roy's distinction between TE/CE in his e-mail dated Monday,24 March 2014 21:19) - you are just smartly saving server resources by not re-compressing the file every time a client requests it (IIS for example, also automatically does this for you).

> Because of the MUST NOT, I now cannot take advantage of my proactive compression
> in HTTP/2, and instead either 1) require the server to compress the response on-the-fly
> each time, or 2) lose the compression.

Not sure which MUST NOT you're referring to? But the idea for this exact scenario was to send the header "Transfer-Encoding: gzip" and then put the contents of index.html_gz directly in the response body.

> Also, because TE is hop-by-hop I risk some intermediary terminating the compression,
> possibly negatively impacting my site's responsiveness in a way that is outside my control;
> but CE is end-to-end, so intermediaries shouldn't be touching the compressed data
> (I say "shouldn't" but I know some still will).

This is a good point. I'm not sure what the right answer is.  What do you propose?
(The ideal solution, I think, would be an end-to-end content transfer encoding.)

> This paragraph should be a best practice guideline, if anything, not an interoperability requirement.
>> Clients, servers and intermediaries MAY elect to support other compression methods for transfer
>> encoding, in which case it MUST be explicitly requested by the client in the TE header.

What's the correct way to re-write it?

> Should probably mention the IANA HTTP Transfer Coding Registry here.

Again, what's the correct way to do that?

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 Wednesday, 26 March 2014 17:05:49 UTC