They cannot tell the difference according to anything you can find in
the current draft http spec. But there does exist a well-established,
though not well-known, convention.
The convention is that CGI script generated responses will never have
Last-modified headers in them.
Http servers attach Last-modified headers when sending normal document
contents, because they can easily get the last modified date by
looking at the file date. Servers cannot (automatically) generate a
Last-modified to go with script output, so they don't. Summarizing,
CGI scripts are not required by the spec to omit a last-modified
header, but in practice they all do.
Thus, the lack of Last-modified is a means of telling that a response
came from a script.
As far as I know, all popular proxy caches never cache responses that
lack both a Last-modified header and an Expires header. Thus, no
popular proxy will cache CGI script output, unless of course the CGI
script author adds one of these headers by hand.
Again, proxy caches are not required by the spec to look at
last-modified, but in practice they all do, as anything else causes
problems. Quoting an old (18 May 1995) message on the http-wg mailing
list:
Ari Luotonen:
|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).
As I said before, this convention is well-established, though not
well-known. It seems to have come about a result of `evolution', not
as the result of an intentional specification effort. I feel this
convention should be documented in the next draft http/1.0 spec
though, I will be putting out a proposal for this some time in the
near future.
Koen.