httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@avron.ICS.UCI.EDU>
Subject Re: mod_proxy changes
Date Tue, 28 May 1996 02:05:40 GMT
> This seems perverse ... if the canonicalization is valid for the cache, surely
> one must assume it is valid for the URI? [yeah, I know, I should be on HTTP-WG
> for this kind of argument ... but can I take the mail load?]
> That is, surely:
> cache(a) ~ cache(b) => a ~ b [Axiom 1 (required for correct function of cache)]
> cache(a) ~ cache(canon(a)) [Axiom 2 (stated above)]
> where ~ means "is equivalent to"
> so,
> canon(a) ~ a [by axioms 1 and 2].

Nice theory -- it just doesn't work in practice.  The problem is that
not all caches and origin servers share the same canonicalization algorithm.

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.

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.


View raw message