On second thought (ie. having turned my brain on and thought
about the problem at hand for a minute or two) my response
above is totally missing the point. Caching has three aims -
reduce end-user latency, reduce server load and reduce
badwidth consumption. For sites which are high on text content
and low on "high byte count" content (as I assume most ACS
sites are) the third point is of minimal importance relative to the
first two, leaving latency and load as the relevant issues.
Running the queries nescessary to determine if a 304 Not
Modified response is appropriate is no easier or faster for the
server than running those queries and returning the page itself
(asuming time spent in the database is much greater than time
spent parsing the template), so you gain nothing other than
increased complexity by attempting to do this. It's much easier to
make a decision about how stale you're willing to allow pages
returned to the user to be and seting an appropriate Expires
header. The "304 Not Modified" approach could be made to work
by caching DB queries, but you'll still be returning data as stale
as the age of your query cache, which is just the same result as
setting an Expired header in the future but with more server work
(and minimally more bandwidth consumed) than letting the end-
user's web cache take care of it all.
On a related note, squid in the recommended configuration will
not cache any requests containing a "?" character (ie GET
requests), which counts out pretty much every interesting page
in an ACS based site. Assuming most other caches operate
similarly I'd expect this makes most pages we serve
uncacheable for most users no matter what we do, apart from
those behind overly aggressive caches such as those
discussed above.
