- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Mon, 12 May 2008 22:44:08 +0200
- To: Jamie Lokier <jamie@shareable.org>
- Cc: ietf-http-wg@w3.org
On mån, 2008-05-12 at 18:52 +0100, Jamie Lokier wrote: > Doing that is not a HTTP proxy per spec, but it done nonethless in > some configurations, and it is useful. And breaking the evolution of HTTP quite noticeably.. Try deploying a for example a WebDAV client behind such transforming proxy, or a client fetching ranges. > > > So that makes compression independent of transfer encoding. > > > > ? > > In practice. I disagree. There is a lot more to HTTP than plain browsing, and these proxies bending the HTTP often do so without knowing HTTP or the bad effects they cause, and the ones deploying it often considers HTTP "browsing only, nothing critical if it gets a bit messed up as long as browsing to the major sites works". > > Which is partly why specs clearly say that if Transfer-Encoding is used > > then Content-Length MUST be ignored, with the small exception for the > > now removed case of "Transfer-Encoding: identity". > > I was meaning Content-Length in conjunction with Content-Encoding, not > Transfer-Encoding. And where is the confusion there? Content-Length with Content-Encoding is the message length, nothing else. Anyone getting this wrong is seriously flawed. Content-Encoding is a property of the resource returned, not of how it's transferred. Content-Encoding does NOT change the message format, only the resource transferred. To the protocol very similar to Content-Language or Content-Type but on a different axis. Regards Henrik
Received on Monday, 12 May 2008 20:44:47 UTC