Henrik> The basic rule of which return codes to cache is that
Henrik> there should be a clear advantage of doing so in saved
Henrik> network access. In this light, even though most of the
Henrik> return codes infact can be cached, in most cases, it
Henrik> doesn't make a lot of sense. Examples of this are "404 Not
Henrik> Found", and "500 Internal" where basically only the
Henrik> connection is saved (which then again might be a
Henrik> significant win)
Henrik> Regarding "301 Permanently Moved" code then the best
Henrik> solution is to actually modify the link in the
Henrik> document. Caching the document doesn't make a lot of
Henrik> sense, but the information in the Location/URI-header
Henrik> header sure does!
I think we need a return code that is somewhere in between these two
codes. Let me reiterate my application and you can see what I mean. I
envision a system where pages are replicated across many
servers. Clients should be redirected to the nearest server containing
a replica of the pages that client is interested in. Under this scheme
the client does not know ahead of time where the replicas are; the
server however does. The redirection should be cached across sessions,
but the document link should not be changed necessarily, since the
redirection will vary depending on the location of the client. A
client in Australia for example will most likely be redirected to a
server in Australia, but you don't want to change the link in the
document to point to the Australia replica.
This is not quite the same as a "permanent" change; more like a
"suggested redirection". In such a case there must also be a way of
forcing the server to provide the document -- otherwise in certain
situations you can enter a race condition of endless redirection.
The justification for this scheme can be found at
http://www.das.harvard.edu/research/vino/push.cache/
James.