On 26 March 2014 05:54, Patrick McManus <pmcmanus@mozilla.com> wrote: > I'm unlikely to implement a gzip transfer encoding decoder any time soon. > The distinction between TE and CE is too confusing and I think we're better > off without the footgun and just using a single defacto CE mechanism > instead (with all its admitted warts). > The fact that one of these "warts" is that people think CE is a transport feature is one that I strongly believe we should not perpetuate. HTTP/2 is a brand new transport, surely it will only help to clarify the issue if we discuss, codify, and/or revise transfer codings, and completely doesn't mention content codings. People might see it and think "oh, TE is a transport thing, and CE isn't". Maybe. Incidentally, is not the current implementation of CE:gzip effectively a "gzip transfer encoding decoder" anyway? Surely that would be *easier* to scavenge than implementing a whole new binary, header table based, huffman coded, bells and whistles transport mechanism. Of course, I says it as shouldn't, since I don't know the Firefox codebase at all. > The mandatory implied Accept-Encoding codifies a well worn and useful > optimization.. Transfer-Encoding doesn't have the same track record to > justify adding it at the same level. > It's not at the same level; CE is above TE. Making claims in HTTP/2 about CE is too close to modifying existing protocol semantics for my liking, whereas TE is exactly the space in which we're working. And like I said, we're already completely rewriting the entire transport mechanism; adding compression is hardly out of place. Put glibly: a binary wire format for HTTP doesn't have *any* track record at all, but we're adding that. -- Matthew Kerwin http://matthew.kerwin.net.au/
Received on Tuesday, 25 March 2014 22:28:44 UTC