W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Transfer-codings, mandatory content-coding support and intermediaries

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 18 Apr 2014 16:52:36 +1000
Message-Id: <B3B5859D-26AB-44D5-B7ED-DBFF85DE529B@mnot.net>
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.


Mark Nottingham   http://www.mnot.net/
Received on Friday, 18 April 2014 06:50:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC