[8307] in www-talk@info.cern.ch
Re: caching dilemma
daemon@ATHENA.MIT.EDU (Henrik Frystyk Nielsen)
Tue May 30 19:36:39 1995
Date: Tue, 30 May 1995 19:22:41 +0500
Errors-To: procmaster@www19.w3.org
Reply-To: frystyk@w3.org
From: frystyk@w3.org (Henrik Frystyk Nielsen)
To: Multiple recipients of list <www-talk@www10.w3.org>
Koen Holtman:
> The draft http spec already defines both a Redirect and a NowGoHere.
> The redirection code
>
> 301 Moved Permanently
>
> signifies permanent redirection; clients are encouraged to remember
> the it, and the code
>
> 302 Moved Temporarily
>
> signifies a redirection that may be dynamic. The draft spec implies
> that redirection information gotten in a 302 response may never be
> cached, though I wonder how many clients conform to this part.
The basic rule of which return codes to cache is that there should be
a clear advantage of doing so in saved network access. In this light,
even though most of the return codes infact can be cached, in most
cases, it doesn't make a lot of sense. Examples of this are "404 Not
Found", and "500 Internal" where basically only the connection is saved
(which then again might be a significant win)
Regarding "301 Permanently Moved" code then the best solution
is to actually modify the link in the document. Caching
the document doesn't make a lot of sense, but the information in the
Location/URI-header header sure does!
> I've been writing on a draft spec commentary which suggests that the
> expires header may be used to allow control cacheability of 302 (and
> 300) responses.
Expires headers on 302 codes sounds like a good idea - not on 300!
--
Henrik Frystyk frystyk@W3.org
World-Wide Web Consortium, Tel + 1 617 258 8143
MIT/LCS, NE43-356 Fax + 1 617 258 8682
77 Massachusetts Avenue
Cambridge MA 02154, USA
