Re: i28 proposed replacement text

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