Re: i28 proposed replacement text

On mån, 2008-05-12 at 22:27 +0100, Jamie Lokier wrote:

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

And yet there is plenty doing this, especially in bandwidth scarse parts
of the world, by looping all their traffic via a gzip proxy in a well
connected co-location, and some major proxy vendors advertising it as a
feature..

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

I know, as can be seen in my discussions with the Apache team..

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

Not sure on that. There isn't many implementing TE: gzip today.

> I know.  But spec isn't everything.

Not short-term no, but when working with a timespan of several years
it's important.

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

Personally I have very little respect for old broken user agents. Those
generally have major gaping security flaws as well and really SHOULD get
upgraded.

I care more about broken servers.

Regards
Henrik

Received on Monday, 12 May 2008 23:04:24 UTC