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

On Wednesday,26 March 2014 12:06, Poul-Henning Kamp wrote:
> The logfile example I'm just going to ignore because it is bogus on so many planes that it's not even funny:

> The exact same problem exists with compressed logfiles when no HTTP is involved at alle.

> You must have overlooked the "real-world" I put in my question ?  :-)



We do something very similar in the "real world" with data acquisition systems. But we are using a HTTP/1.1 _compliant_ server - and so the only option for compressed range requests was to do gzip transfer encoding.



On Wednesday,26 March 2014 10:49, Poul-Henning Kamp wrote:
> That's news to me.  Range works fine with C-E in Varnish...



You tell me "real-world" examples of Varnish using Range with C-E gzip and there you'll have all the examples you need.



> If your goal is to make HTTP the protocol that can do *everything*, then you are going to get a protocol which is good for nothing.



Not our goal at all.  _We just want to make sure HTTP/2 doesn't lock out something you can already do with HTTP/1.1._  As the HTTP/2 spec is currently written, you can't do compressed range requests because gzip transfer encoding is disallowed. But at the same time, if we can help eliminate the misuse/abuse of C-E gzip, that would be great too.



*Don't forget that HTTP isn't just for browsing the web.* Sure there are other protocols out there (e.g. FTP, SMB, CIFS, ...), but they all have their own issues (overhead, security, etc.).  But HTTP is the most widely used protocol in the world and has so many nice features that it gets used for lots of other purposes besides browsing.



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 11:37:55 UTC