W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: Issues-list item "CACHING-CGI"

From: Ari Luotonen <luotonen@netscape.com>
Date: Tue, 15 Apr 1997 18:41:08 -0700 (PDT)
Message-Id: <199704160141.SAA17231@step.mcom.com>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3062

> I propose adding this to the end of section 13.9:
> 	Note that some HTTP/1.0 cache operators have found that it is
> 	dangerous to cache responses to requests for URLs including the
> 	string "cgi-bin".  HTTP/1.1 caches should follow this practice
> 	for responses that do not include an explicit expiration time.
> 	HTTP/1.1 origin servers that want to allow caching of responses
> 	for URLs including "?" or "cgi-bin" SHOULD include an explicit
> 	expiration time.  Explicit expiration times may be specified
> 	using Expires, or the max-age directive of Cache-Control, or
> 	both.
> -Jeff
> P.S.: I base the first sentence in the note on the sample configuration
> file distributed with a recent version of the Squid cache software.
> If this is actually contrary to normal practice, someone should say so.

Actually, the simple #1 rule for caching/non-caching of all time is:

	NEVER cache an HTTP/1.0 response that does not carry a
	Last-modified: header.

This supercedes any heuristics based on URLs containing strings like
"cgi-bin", ".cgi" or "htbin".  It's also intuitive: if a response
doesn't content L-M it implies that it probably didn't exist in this
form before I asked for it, and probably won't exist in this form
after so it's not worth caching.

This rule is strictly obeyed by both CERN and Netscape Proxies.
Specific proxy applications that know their data source intimately may
break this rule.  This assumes that the freshness of documents is
guaranteed by configuration, not by the protocol.

I've always strongly encouraged that both Last-modified: and Expires:
be sent out from CGI's whose result is produced from data that has a
specific last modification time, and will have a certain specific
modification time in the future (e.g. a database that is synchronized
at every midnight, but during the 24 hour period in between the
response would be unchanged for the same request).

Ari Luotonen, Mail-Stop MV-061		Opinions my own, not Netscape's.
Netscape Communications Corp.		ari@netscape.com
501 East Middlefield Road		http://home.netscape.com/people/ari/
Mountain View, CA 94043, USA		Netscape Proxy Server Development
Received on Tuesday, 15 April 1997 18:44:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC