hi all...
I've been looking at how output filters and caching headers
interact (in mod_perl land, but the principles are the same). anyway,
I had a real-life scenario where I thought the API wasn't all that
intuitive and wanted to maybe get some feedback or clarification.
currently default_handler calls ap_update_mtime,
ap_set_last_modified, and ap_set_etag. now, say I have an output
filter that modifies the content from default_handler....
Last-Modified is likely wrong, since said filter has variables that
alter the content (like the mtime of the filter code, and various
httpd.conf attributes).
so, ok, similar to the Content-Length dilemma, the filter is
responsble for adjusting the headers appropriatly. so, it calls
set_last_modified, too. however, it can't do this willy-nilly - it
probably needs to inspect the outgoing headers and only call
set_last_modified if Last-Modified exists (since the response could be
from a CGI script, and injecting Last-Modified where one didn't
already exist could have consequences).
what seems awkward to me here is that the filter has too much to
do, and mainly because default_handler is assuming too much - it's
updating r->mtime _and_ assuming that everyone else has updated mtime
too, so it's ok to populate the headers with the "real" value. this
is fine in 1.3, but seems really limiting in the new 2.0 filter world.
it all seems doubly awkward since update_mtime already has the
built-in capability of deciding which time is most relevant - later
filters can't rely on this functionality (alone) when it seems to be
exactly what they would want.
what seems more reasonable (to me, anyway :) is moving the call to
set_last_modified to it's own filter (similar to Content-Length).
this way, all response handlers and filters could simply call
update_mtime themselves, update_mtime could do the work of determining
which time is most relevant, then the (new) cache-header filter could
do the actual job of setting Last-Modified to the proper value.
if you buy that :) then ETag should probably function in the same
way. with an output filter acting on a static file, ETag is almost
certainly wrong, and any updates the filter would make to r->mtime
occur too late to be recognized by default_handler's call to
ap_set_etag. oh, and now that all the caching headers are set
properly, why not use that same filter to decide whether the request
meets_conditions and offload that responsibility from response
handlers as well? :)
anyway, I'm either wildly off base or bringing up stuff that
everyone has already discussed, but I didn't see it glaring at me in
the archives...
--Geoff
