- From: Ari Luotonen <luotonen@netscape.com>
- Date: Thu, 18 May 1995 14:35:02 -0700 (PDT)
- To: "Daniel W. Connolly" <connolly@beach.w3.org>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Why not cache CGI-bin responses? Most of the time CGI responses are entirely dynamic, and not only return a different document each time they're called, but also have intended side effects. In the earliest stages the CERN server used to cache also CGI responses, but that was a mistake and I changed it so that only documents with either Expires: and/or Last-modified: header can be cached. This is the way both CERN and Netscape proxies do it, and anything smarter will cause problems. So, CGI scripts may explicitly allow caching by giving at least on of those headers, indicating a non-zero lifetime (L-M less than current time; Expires greater than current time). > I believe some proxies (and some clients) cache more aggressively than > this. For example, I heard that the hensa cache doesn't bother with > the If-Modified-Since request unless the cache entry is 12 hours or > 10% of the lifetime of the document (current time - last-modified). This is not entirely correct. HENSA doesn't cache CGI responses unless they have the Exp/L-M header, so this 12hr/10% rule applies to only static documents. In general, if you want to get massive savings from running the proxy, both in response time and bandwidth, you have to use such settings. In general, min{12hr,10%} is a very safe setting. Both CERN and NS proxies support this kind of configuration. As an example, there was a rather large Netscape Proxy beta tester site which saved 75% of its outbound bandwidth with our proxy, with a 6hr/10% setting. Yes, bandwidth requirement dropped to a quarter of what it would be without the proxy! Cheers, -- Ari Luotonen ari@netscape.com Netscape Communications Corp. http://home.netscape.com/people/ari/ 501 East Middlefield Road Mountain View, CA 94043, USA Netscape Server Development Team
Received on Thursday, 18 May 1995 16:59:39 UTC