Re: i28 proposed replacement text

Henrik Nordstrom wrote:
> 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.

If a WebDAV client says "Accept-Encoding: gzip" it will probably get
similar issues even with no proxy.

Many generic HTTP servers act as transformative "pseudo-proxies" to
their backend content - consider Apache with mod_gzip for example.
Therefore, WebDAV clients for general purpose use should not say
"Accept-Encoding: gzip" unless they handle the consequences, which
typically means transparently decompressing what's received.  They
don't have to, but user expectations won't be met when connecting to
some servers, and editing may fail.

Range requests: if the proxy is written properly it can work.

HTTP evolution: Proxies for general HTTP use, such as at ISPs and
gateways, should not be configured that way.

Only proxies for specific applications would enable transformations
like that (we hope).  An example is Apache with mod_gzip+mod_proxy
acting as a reverse proxy in a server farm (I don't know if that
really works).  That is why I call it a configuration issue.

> > > > 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".

This is more like "as long as using major browsers (site irrelevant)
works, or as long as using a client intended to generally work with
sites found on the net (because mod_gzip is popular enough that even
non-browser clients must work with it, or not use Accept-Encoding)."
It is indeed dirty, but not as specifically dirty as you make out.

It's also not common to do this in proxies, so don't worry about it.
What is common is automatic compression a la mod_gzip, in what is
technically not a HTTP proxy, but is still a generic relay between
HTTP client and HTTP services, and similar non-transparency issues do
apply there.

Besides, I bet a HTTP proxy which opportunistically applies
"Transfer-Encoding: gzip" encoding when permitted, and adds "TE: gzip"
to requests removing the encoding from forwarded responses, will cause
problems too - maybe even bigger ones - even though it's fully
compliant and transparent according to spec.

> > > 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.

I know.  But spec isn't everything.

The serious flaw is deployed.  I'm not surprised - it's a predictable
mistake given how HTTP systems are architected.  When writing code you
can't ignore the installed base of buggy agents if you want to
interoperate.  But as I've implied, that particular bug is found (as
far as I know) only in old agents which are dwindling in presence, so
you might choose to ignore it now, depending on how much you care
about reaching those remaining.

-- Jamie

Received on Monday, 12 May 2008 21:27:42 UTC