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

Hi Matthew-

On 27 March 2014 05:45, Matthew Kerwin wrote:
> ... It's entirely up to my server configuration to decide whether to
> serve up the contents of index.html, or index.html_gz, or index.txt,
> or any other random *representation* of that resource.  Importantly,
> each of these representations is a distinct entity, with its own
> entity-specific metadata (Content-Type, Content-Encoding,
> Content-Length, Last-Modified, ETag, etc.)...

What if a client requests directly /index.html_gz, do you still send that as "Content-Encoding: gzip\r\nContent-Type: text/html" or just "Content-Type: application/x-gzip"?

What about a resource e.g. /search.php that has dynamic results and the response body is gzip compressed to save bandwidth? Are you saying each unique result is a distinct entity and so that too should be "Content-Encoding: gzip\r\nContent-Type: text/html" or is this a case where it really should be called "Transport-Encoding: gzip\r\nContent-Type: text/html"?

> It also allows entity-specific operations like range requests.

What if user directly requests a range of /huge.resource (e.g a huge non-compressed entity), but you want to save bandwidth on the transfer with compression? Based on the requirements of RFC2616, I assert you can't compress without using "Transport-Encoding: gzip".

> -p2 <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26>
> doesn't even have a section 14.  You seem to be referencing RFC 2616,
> which AFAIK isn't split into parts.

Got it. Thanks. I'll fix that.

> I propose not confusing hop-by-hop transport with end-to-end content.
> We already have an end-to-end compression mechanism, which works for
> the most part. I just don't like it because people have gotten
> confused by it. That doesn't mean that it *can't* be used correctly,
> or that it doesn't have any value.

Can you give some examples of what you consider the confusion?

> Even were gzip transport a MUST-level requirement for HTTP/2, there
> would still be 2->1.1 gateways that are forced to strip the transport
> compression because the machinery on the 1.1 side doesn't send TE
> headers. Therefore I argue that we should definitely NOT get rid of
> Content-Encoding: gzip. What I propose is that we recommend support
> for TE:gzip, and hope that the 1.X parts of the web fade away enough
> that nobody cares about them not having compressed data everywhere.
> Hence "best practice guideline, not an interoperability requirement."

In our original proposal we had guidelines for what intermediaries have to do for the 2->1.1 gateways if the 1.1 side doesn't send a "TE: gzip" header. I'm not sure why that wouldn't work with a MUST-level requirement for HTTP/2.

I'm also not sure exactly what part of our proposal you are referring to that should be a best practice guideline (also not exactly sure how you put a "best practice" guideline in an RFC - is there a guideline on how to write such a guideline).
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 Thursday, 27 March 2014 20:56:43 UTC