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

Hi Matthew-

On Monday,24 March 2014 23:21, Matthew Kerwin wrote:
> I'm completely fine with continuing to mandate support for TE:chunked, however
> it seems like a regression to forbid other codings (such as compression) when they
> may have had support in HTTP/1.1. ...

Exactly our point. Except that instead of "may have had support", I would have said "do have support".

> On the other side, I'm not sold on a single "gzip" bit...

Agreed. Which is why we proposed gzip transfer encoding. But a single gzip bit would be better than nothing.

> For the record: I routinely configure Apache to serve offline-compressed versions of files [1], which I believe is the Right Way(tm) to do CE

Are you sure this is the right way? I guess it depends on what kind of offline-compressed files you are talking about. For sure yes for static .tar.gz archives, etc. But if you are talking about your example of index.html that automatically redirects to index.html_gz, 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).

> and I've written an API[2] that allows resources to be dynamically compressed, and
> it jumps through hoops to provide content-encoded gzip (i.e. the Wrong Way(tm))
> because no one seems to do TE and I didn't want my code to go to waste.

Agreed this is the wrong way.

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 16:49:10 UTC