Re: http/1.1 requirements

Robert Collins wrote:

> I'm not sure that it shouldn't. The Client will be treating them as equal
> right? so the client may receive %7e and then send a HEAD for ~ in the next
> user session. What gets me is the explicit 3.2.3 text more than the concepts
> behind it. Is there someone on the RFC team we can ask for clarification?

Most clients does not transform the URL. If you in the URL window types
~hno, then ~hno is sent to the server, and if you type %7Ehno then
%7Ehno is sent. But this might vary with client type and version.

I am less sure how they react wrt the browser cache, but that is of a
less concern for the proxy.

Note: I don't know of any user client which uses HEAD. I have only seen
robots like wget and various search engines use HEAD.

> The issue that could arise is on revalidation. We can't send the
> "normalised" uri, we have to send the one the client gave us, but we can't
> add Etags for validation if the client request URI<>the cached URI.

I prefer to make it even stricter. If the client requests a different
encoding of the URI then forward this even if there is a normalized
version cached. If both are cacheable then cache and revalidate then
independently of each other.

> Why don't we do that then? It was one of the things nagging at me and I'm
> happy with that aproach - invalidate anything with the same canonical URI,
> but only deliver literal matching URI's.

Problem is to know that there is multiple objects with the same
canonical but differen literal URIs in the cache.

The least we can do is to also invalidate the canonical URI when we have
to invalidate a URI on some other form. Unless the store is restructured
to support multiple entities in one key I see no practical way of
invalidating all possible literal URIs for a given URI.

/Henrik
Received on Wed Oct 25 2000 - 14:53:24 MDT