- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 18 Apr 2014 16:52:36 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
We've had a wide-ranging discussion of the issues brought about by HTTP/2 dropping the concept of transfer-coding, in conjunction with the imposition of mandatory gzip content-coding support by clients. At this point, it looks like the folks who have asked for TE support in HTTP/2 are willing to wait on incorporating such a feature into HTTP/2. Since we don't seem to have much consensus on any of the proposals to date, the status quo seems like a good path forward -- although I think we should discuss this in more depth in NYC. However, discussion has also uncovered some problematic aspects of requiring clients to support GZIP content-encoding in HTTP/2. Specifically, we're chartered to enable intermediaries to translate from 1.1 to 2 and back with reasonable fidelity. As has been noted, that's hard to do if a HTTP/1 client doesn't support gzip content-encoding; if the HTTP/2 origin assumes gzip support, the intermediary has to decompress it, and -- importantly -- assign a new entity tag to the response. That's pretty clearly a major reduction in functionality, and effectively removes what we used to call semantic transparency from all HTTP1.x->HTTP2 proxies. As discussed, there are other side effects of this approach as well. I've created <https://github.com/http2/http2-spec/issues/460> to track this issue. I don't think it affects the current implementation draft, but we do need to discuss it before (and likely at) the NYC interim. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Friday, 18 April 2014 06:50:42 UTC