httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject cache headers and output filters
Date Wed, 04 Dec 2002 19:19:07 GMT
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


Mime
View raw message