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

Re: Issues-list item "CACHING-CGI"

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Tue, 29 Jul 1997 15:23:27 -0700
To: Jim Gettys <jg@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9707291539.aa17045@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3999
>Here's a revised version, to replace the second paragraph
>in section 13.9:
>	Some HTTP/1.0 cache operators have found that it is dangerous
>	to cache and reuse without revalidation responses to requests
>	for URLs that include any of the strings "cgi-bin", "htbin", or
>	"?", because applications have traditionally used these URLs in
>	conjunction with operations with significant side effects for
>	GET or HEAD methods.  However, if such a response includes an
>	explicit, future, expiration time, then this implies that the
>	response may be cached and reused without revalidation until it
>	expires.  If such a response includes a Last-Modified or Etag
>	header, this implies that the response may be reused after
>	revalidation (or without revalidation if explicitly fresh).
>	A cache MUST NOT assign a heuristic expiration time to a
>	response for a URL that includes the strings "htbin", "cgi-bin", or
>	"?" in its rel_path part.  If such a response does not 
>	carry an explicit expiration time, it must be treated as
>	if it expires immediately.

I'm pretty sure I said this before, but I don't know what list.
I am completely opposed to this change.  It is inaccurate to say that
caching and reusing such responses is "dangerous".  The *only* reason
*some* caches do not provide heuristic caching of such responses is
because the presence of query-based parameters make it unlikely to get
a second "hit" on the cache, and because the the absence of a Last-Modified
(and now Etag) makes it impossible to do an efficient update.  In any case,
this is an optimization which is dependent on the context and number of
users of the cache, and not a requirement of the protocol.

The protocol already provides mechanisms for marking a response as
non-cachable.  All other responses to a GET request are cachable.

Received on Tuesday, 29 July 1997 15:46:38 UTC

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