W3C home > Mailing lists > Public > www-talk@w3.org > May to June 1995

Re: caching dilemma

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Tue, 30 May 1995 19:05:53 +0500
Message-Id: <9505302305.AA03709@www20>
To: www-talk@www10.w3.org, koen@win.tue.nl

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
Received on Tuesday, 30 May 1995 19:06:07 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:17 UTC