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

20: Re: Strange cross-caching of users (response to 1)

Posted by Tom Jackson on 12/12/02 06:38 PM

So ad_proc and ad_register_filter are defined at that point? I'm not sure, but I would try to run you filter as a regular ns_register_filter to you know exactly when it is run (ahead of the request processor filter).

But I'm just being paranoid. Put in an ns_log and verify when, if, where the filter gets run just to make sure.

21: Re: Strange cross-caching of users (response to 20)

Posted by Bart Teeuwisse on 12/12/02 06:47 PM

Tom,

you are paranoid ;)! Yes, both ad_ procs are defined at that point. Like I said, I'm running this script at a (staging) site. The advantage of ad_register_filter is that you can see the registered filters from the monitoring package.

/Bart

22: Re: Strange cross-caching of users (response to 21)

Posted by Tilmann Singer on 12/12/02 08:26 PM

First of all - thanks for investigating in this! I think this is a long needed and missing functionality in OpenACS, and should definitely be enabled by default. I have told users to "hit Reload, no not Reload, CTRL-Reload, yes you have to hold down the CTRL key and click on the Reload button" ... a few times, and that is annoying.

I think though that the right place to put this is the request processor, because only there you are sure what kind of file a URL really maps to. With abstract URLs you can't tell only by the URL all of the times, e.g. when '/some-file' maps to '/some-file.html'. Also there might be an index.vuh that handles requests for *.html files (not sure if that's really possible), which shouldn't be cached, although the URL ends on 'html'.

If you agree but don't have the time to rewrite your proc then I could give it a try (not immediately though).

Also I think it could be done more efficient with 'string match' instead of regexp, something that should be considered when adding code that is executed upon every request.