Re: i28 proposed replacement text

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

Interesting.  I didn't realise those exist.  It's quite
understandable: cheap fast web browsing is important, and
Transfer-Encoding is widely supported enough agents to be used.

Other HTTP uses on those networks are relatively unimportant and will
have to workaround those transformations.  Fortunately it is quite
straightforward and the least of one's worries - there's far more
annoying HTTP-in-reality issues!

I rather like the idea of proxies which use delta compression between
each other.  Infinitely more effective.  But alas not zero-install for
the end users.

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

I agree, but I think the unfolding reality suggest ways the spec
doesn't match the ways people want to actually use HTTP.  We push
sound principles but we work with the ecosystem too.  Same reason
we're writing applications in HTML + Javascript even though it's messy
and slow.

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

>From Google, I have the impression the problem is more prevalant on
servers, if you're counting different programs (as opposed to number
of running instances).  But that it's also rare, occurring around the
time people weren't really using compression and just starting to
dabble in it.

-- Jamie

Received on Tuesday, 13 May 2008 14:50:44 UTC