Forum

Re: https://www.hiawatha-webserver.org/forum/topic/1512

I know this topic has come up before, but I thought I might try and figure at least some of it out on my own. For Drupal there are a couple of different ways of detecting if the cache needs to be bypassed.

Nginx uses the following configuration:

## Let Ajax calls go through.
map $uri $no_cache_ajax {
    default 0;
    /system/ajax 1;
}

## Testing for the session cookie being present. If there is then no
## caching is to be done.
map $http_cookie $no_cache_cookie {
    default 0;
    ~SESS 1; # PHP session cookie
}

## Combine both results to get the cache bypassing mapping.
map $no_cache_ajax$no_cache_cookie $no_cache {
    default 1;
    00 0;
}

Looking at the URLToolkit options is looks like we should be able to leverage the Header and Match commands to achieve the above results. I have added another toolkit operation called "BypassCache" which sets a bypass cache flag in the session. Operations are stackable (flow is set to continue) so you can do multiple checks and still rewrite the URL.

Here is an example toolkit:

UrlToolkit {
        ToolkitID = nocache
        Match ^/nocache.php BypassCache
        Header Cookie ^SESS BypassCache
}

Initial testing looks promising. I was able to get expected results with some limited testing using the Match operation but I didn't see what I was expecting with the Header operation. I may have my syntax wrong though so I will do additional testing as time allow.

Hope someone finds this useful!

And here is a link to the code on PasteBin:

http://pastebin.com/tw5zpMiv

Just as a follow up, I have some concerns about how the process would work during an initial login. I believe once credentials are sent, the content is returned with the Cookie session.

If the URLToolkit is only performing its check when the browser POSTs its login info, then its probably missing that a cookie header has been set when the FastCGI server returns its response.

Need to dig into the code and figure that out.

Just found this:

https://www.hiawatha-webserver.org/forum/topic/1510

Which led to this:

https://www.nginx.com/blog/nginx-caching-guide/



So, uh, definitely a complex issue. I can completely understand why Hugo is reluctant to go down that road! I'll keep playing with it and give an update if I come up with a solid solution.

It's very hard for a webserver to determine whether it's safe to cache output or not. The only one who knows best is the application itself. That's why I chose to let an application point out what output can be cached via a special header.

Thanks for the reply Hugo. I'm going to change direction and look into creating a Drupal module that makes that determination and sends the X-Hiawatha-Cache header along with the content.

I'll probably peek at the Banshee framework code for some guidance.