httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: mod_proxy changes
Date Wed, 29 May 1996 10:31:23 GMT
Roy T. Fielding wrote:
> 
> >> Nice theory -- it just doesn't work in practice.  The problem is that
> >> not all caches and origin servers share the same canonicalization algorithm.
> > 
> > Why not? If the canonicalization is not determined how can its use be
> > sanctioned in a proxy?
> 
> Because it should be determined -- it just isn't in practice.

Shouldn't 1.1 take the opportunity to fix this?

> 
> >> A cache's storage handling algorithm is not part of the HTTP protocol
> >> (and thus not part of the normative requirements [when done correctly]),
> >> which is why internal canonicalization is allowed.  However, the cache
> >> (more accurately, a proxy) is not allowed to screw up the user's request
> >> by mis-canonicalizing the user's request-URI when it is forwarded, and
> >> thus the first response will be correct (in the user's view) even if the
> >> cache is incompetent.  In practice, it turns out that incorrect hits on
> >> correct responses are always preferable to incorrect responses due to
> >> broken requests, and thus the problem of a later request getting a
> >> cache hit after canonicalization (but not before canonicalization) becomes
> >> a non-problem.
> > 
> > I'm sorry, I got lost in the tangle there. Could you explain in words of one
> > syllable, please? With diagrams? ;-)
> 
> Not via e-mail -- that would need at least a pint's worth of explanation.

Hehe ... do you support UUBP (Unix to Unix Beer Protocol)? Being geographically
challenged its the only way I'm going to get a pint to you!

> 
> >> Of course, it is never a problem if the origin server avoids using
> >> non-reserved characters for reserved purposes (which is when canonicalization
> >> breaks), but then the protocol doesn't prevent people from being stupid.
> > 
> > Ermm .. doesn't that make the server broken? [And therefore not a cause for
> > concern within the scope of the spec].
> 
> Yes, but it makes the proxy look broken and the proxy gets blamed.
> It just works better if it is done as spec'd rather than assuming
> that it is safe to canonicalize.  In general, an IETF spec tries to
> specify those things that "just work better", in addition to the 
> minimal requirements.

If browsers where required to canonicalize, as I suggested earlier, then any
non-canonical request could be rejected by both proxies and servers - thus
clearly planting the blame on the browser in all cases. And, incidentally,
making the whole situation clearer. I understand the requirement for RFCs to
deal with practical issues, but it seems to me that the whole direction of
permitting dodgy canonicalization should be quashed at the earliest
opportunity; it can only cause more and more pain as HTTP increases in
complexity.

Of course, this rule could not be imposed on HTTP/1.0 browsers...

Cheers,

Ben.

> 
> ......Roy

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Mime
View raw message