[added documentation for HTTP caching dan**20031219080657] { hunk ./NEWS 9 +* Some notes on HTTP caching added to documentation + hunk ./TODO 45 +** HTTP caching + +Documentation should explain use of Vary + addfile ./doc/caching.html hunk ./doc/caching.html 1 - +Araneida - Caching + +Araneida - Caching + + +

Caching

+ +

Proper use of HTTP caching can make your application run faster and +use less bandwidth - especially when using Apache mod_proxy - and is +also friendlier to the rest of the Internet. Improper use of cachinbg +can lead to stale pages or to visitiors getting content intended for +other people. + +

Araneida's REQUEST-SEND-HEADERS allows all HTTP response headers to +be sent, giving you full control over caching. You are advised to +read RFC 2616 for the detail, but here are a few tips: + +

Aet a Last-Modified time, if at all possible. With a +correct :Last-Modified argument and :CONDITIONAL T to request-send-headers, +Araneida will send appropriate "304 Not modified" responses on your behalf. + +
Caches use the Expires header to determine when a cached response +is stale (meaning that it should be revalidated with the origin +server), not necessarily when it should be flushed from the cache +altogether. If mod_proxy receives a request for which is has a fresh +response, it will send that response without even consulting Araneida. +If it has a stale response it will query Araneida first, using a +conditional GET to which araneida may respond with a 304. So even if +you can't predict the future well enough to set long expiry times, you +can still derive some benefit from caching at least in the case where +it is cheaper to determine whether a resource has changed than it is +to generate the resource afresh. + +
If you don't set Expires, mod_proxy (and other caches) will +attempt to guess a suitable staleness time based on the Last-Modified +header. In mod_proxy this is controlled using +CacheLastModifiedFactor. I'd suggest that in a dynamic web +application it's probably easiest to set this to 0 so that the cache +defaults to revalidating every time, and send explicit Expires headers +when you know that a request won't always need this conservative +treatment (e.g. on static files). + +
Note that you can specialise request-send-headers on your static +file handlers to implement your expiry policy. For example + +
```
+(defclass cached-file-handler (static-file-handler) ())
+(defmethod request-send-headers ((h cached-file-handler) &rest)
+  (apply #'call-next-method :expires (+ (get-universal-time) 86400) rest))
+
```
+ +
If using mod_proxy, add "LogLevel debug" in the apache httpd.conf +and watch the error log. It will tell you a lot about the caching +decisions that Apache is making: even more, if you read it with +reference to the Apache source code. Note that as well as per-request +debugging this will also give you some more messages that indicate +actual errors (e.g. when apache doesn't have permission to write to +its cache directory) + +
Restarting Apache will not clear its cache, but it appears to be +safe to wipe it out with rm whenever necessary. + +

hunk ./doc/handlers.html 80 -if the response has been sent before. If it sends a 304, it will then +if the response has been sent already. If it sends a 304, it will then hunk ./doc/handlers.html 83 -UNWIND-PROTECT. +UNWIND-PROTECT. See the documentation on HTTP +caching for more detail. hunk ./doc/listeners.html 45 -can safely be displayed to the browser without bypassing the proxy. +can safely be displayed to the browser and will not cause subsequent +requests to bypass the proxy. hunk ./doc/listeners.html 52 +

Apache mod_proxy can also cache your responses when so configured. +See the documentation on HTTP caching for details. hunk ./doc/reference.html 15 +

HTTP caching + }