- From: Ari Luotonen <luotonen@netscape.com>
- Date: Thu, 1 Jun 1995 21:59:19 -0700 (PDT)
- To: www-talk@www10.w3.org
So I'm trying to educate here a little... The way I'd like to think about this "caching dilemma" is not in the light of if something is or isn't a CGI output, but simply, and I've said this over and over again, if the returned object has an Expires or Last-modified header, it implies that the document has a non-zero lifetime, and it might just make sense to cache it. If those are missing it implies that it was dynamically created, maybe through CGI, maybe through NSAPI functions, maybe by some custom server, I don't really care. What that means to me is that I can't safely cache it. It's not a good idea to cache 302 Moved temporarily responses, because the destination of the redirection may have been a result of the requesting User-agent, time, location, or other dynamic factors. It's ok to cache 301 Moved permanently. > The biggest problem appears to be when > someone has a non-CGI document that includes dynamic information into an > otherwise static HTML document (counters, etc) and the remote server > doesn't send any useful headers to the cache. If the cache server caches those docs it's acting wrong. If the response is HTTP/0.9 it obviously doesn't have Exp/L-M headers and the cache server should assume a dynamic document. > 3) If the CGI script is invoked as a result of the POST method in a FORM, > the output shouldn't be cached anyway. So maybe the moral of the story > is always use POST insituations like this... :-) POST is the way to do it. GET was mainly just used in the early stages of form development when POST wasn't available yet in the servers, but today POST should be used in almost all cases (ok, there are some situations when it's well justified to use GET). 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 Friday, 2 June 1995 01:03:31 UTC