Home
The Toolkit for Online Communities
17701 Community Members, 1 member online, 3957 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : Strange cross-caching of users : One Message

Forum OpenACS Q&A: Re: Strange cross-caching of users

Collapse
Posted by Tilmann Singer on
Robert: What component of an OpenACS installation is outputting Last-Modified headers? And which one would be able to deal with If-Modified-Since? I don't see this happening at all right now. Or are you suggesting to add this instead of the Cache-Control stuff for static content?

Regarding adding .pdf, .wav, .doc: When the request processor decides if to add the cache control headers, it's not necessary to keep a list of file extensions at all, the rp would decide based on wether it is serving an actual file from the file system or calling one of the handlers, e.g. the one for tcl/adp pairs.

I agree that it should be possible for individual sciripts to override the cache handling of the rp, for example if a custom last-modified handling was to be implemented in cr_write_content it should be able to call something like "ad_conn -set rp_output_cache_control_headers_p 0" to inform the request processor that it should not add the headers.

Collapse
Posted by Robert Locke on
Hi Tillman,

I'm not sure, but it's definitely happening. Here's an example from fetching our beloved logo on the openacs.org site:

$ telnet openacs.org 80
HEAD /templates/slices/openacs.gif HTTP/1.0

HTTP/1.0 200 OK
...snip...
Last-Modified: Tue, 29 Oct 2002 16:41:11 GMT
...snip...

Notice the Last-Modified header.

Then, if I follow it up with an If-Modified-Since and:

$ telnet openacs.org 80
GET /templates/slices/openacs.gif HTTP/1.0
If-Modified-Since: Tue, 29 Oct 2002 16:41:11 GMT

HTTP/1.0 304 Not Modified

This correct behavior is not just limited to URLs which map directly to a file in the file system. cr_write_content, which calls ns_returnfile for static content stored in the file system, seems to also honor the Last-Modified/If-Modified-Since directives, which is a good thing.

And I'm not suggesting to add this *instead* of Cache-Control stuff, since it's already there. I'm suggesting that some people may want to remove all Cache-Control stuff for static content and instead rely on the Last-Modified/If-Modified-Since "protocol", which guarantees freshness along with some measure of efficiency.

Perhaps reasonable default behavior might be:

  • At the end of the request, check if there is Last-Modified header. (From what I can tell, this would imply the URL maps to an actual file or is static content being delivered by, say, cr_write_content as described above. It could also have been dynamically added by a script.)
  • If one exists, then optionally add a configurable caching directive (30 minutes, 1 hour, whatever), if there are no caching directives already present.
  • Otherwise, add the "no cache" stuff, if there are no caching directives already present.
  • Hope that makes sense...

Collapse
Posted by Tilmann Singer on
Robert, that's great!

From searching a bit in the aolserver code I would say those headers are generated in aolserver whenever ns_returnfile is called. Since the request processor calls that for static files we get this functionality for free, and it also means we don't need to check for the existance of those headers but just refrain from adding any cache control headers when ns_returnfile is being called.

I would therefor suggest to add some code to the request processor that adds the cache control headers in all other cases, overideable by an acs-kernel parameter and on a per-request basis by setting an ad_conn flag as mentioned above.

I don't think that there is much use for a 30min/1 hour/whatever cache directive - typical dynamic pages need to be regenerated on every request and should thus not be cached at all - at least those that display login information on each page, like openacs.org does.

It would be great if the Last-Modified/If-Modified-Since behaviour could be added  to cr_write_content later. Being able to avoid the no-cache headers on a per-request basis makes sure that this is possible.