In some situations, it's necessary to disable both Boost cache, and Speed Booster (fastcgi cache) on the fly, for specific page requests. This is especially important if you intend to perform https <-> http redirection either through code in override.global.inc or using the Securepages module, both of which operate at the application level. If pages are cached by either Boost o Speed Booster, then the application never gets hit, and therefore https<->http redirection never takes place. Therefore to ensure redirection always takes place on these pages both Boost and Speed Booster must be disabled on the fly.

How does one disable both Boot and Speed Booster on the fly, for specific URL's within global.inc?

Comments

omega8cc’s picture

omega8cc commented

To always disable Speed Booster cache on some URI defined in the /data/conf/override.global.inc file, use: header('X-Accel-Expires: 1'); or even: header('X-Accel-Expires: 0');

To never cache some URIs with both Boost and Speed Booster, redirect it to the same URL with ?nocache=1 added (but avoid redirect loop, so do that the smart way) or always add there a cookie with name OctopusNoCacheID and some short TTL. This method may not work as expected if you allow bots/spiders on those URIs, since bots will get redirect loop, as they are by default sent to args-free URLs and they may be able to create at least Boost cache entry. But if I remember correctly, Boost allows you to define not cached paths. Also, why to use Boost? Use only Speed Booster the smart way and you can very easily control what is cached and what not, on the fly, so any redirects you need, will just work. Just send X-Accel-Expires: 0 header when needed.

mrfelton’s picture

mrfelton commented

Thanks. Couple of questions:

1. Does Speed Booster cache both http and https versions of a request as 2 distinct urls?

2. Does setting header('X-Accel-Expires: 0'); really completely bypass the cache for a page request? We have tried to set that header before, and have found that it doesn't actually seem to disable the cache.

omega8cc’s picture

omega8cc commented
Component: Documentation » Code
Category: support » feature

In fact, we could even introduce another check on the Nginx level (and you can do that even now using Nginx include file - not sure, however) to disable both Boost and Speed Booster. Two steps:

1. In the /data/conf/override.global.inc file add a logic which sends extra header when URI matches the no-cache pattern, like header('X-MyHeader: Magic');.

2. In the custom Nginx include add this check:

  if ( $sent_http_x_myheader = "Magic" ) {
    set $nocache_details "Skip"; // This will skip Speed Booster cache
    return 405; // This will skip Boost cache
  }
  error_page 405 = @drupal;
omega8cc’s picture

omega8cc commented

1. Yes, but only if there is a HTTP_X_FORWARDED_PROTO header, because it is included in the cache key, if exist.

2. Yes, header('X-Accel-Expires: 0'); does skip the Speed Booster cache or more precisely - it prevents creating the cache entry, so it may not work when added after the cache entry has been created and didn't expire yet.

mrfelton’s picture

mrfelton commented

I think there are a couple of things here.

As an example, take the case where Aegir's native SSL support is in use. In this case HTTP_X_FORWARDED_PROTO is not set and therefore the URI has just one Speed Booster cache entry for both http and https requests. A user requests a URI over https. It is served and then cached by Speed Booster. Now, the user requests the same URI over http. A cache already exists, and so this is served. There may have been code in global.inc to stop cache generation of the http version of the page and redirect this URL from http to https, like in http://drupalcode.org/project/barracuda.git/blob/refs/heads/master:/aegi.... But HTTP_X_FORWARDED_PROTO was not set, there was already a cached version of the page, and so that is what will get served. So https<->http redirection through global.inc is broken in the case where Aegir's SSL feature is being used.

Also, you said that setting X-Accel-Expires=0 doesn't disable the cache. It prevents a Speed Booster cache entry from being created. But if a cache entry already exists then this will be served. Essentially, this currently only works if SSL is determined by HTTP_X_FORWARDED_PROTO because that is the only way that http and https versions of a page can have separate caches, but in the case of Aegir's SSL support, it is HTTPS that is set, not HTTP_X_FORWARDED_PROTO.

Perhaps the part of the Speed Boost cache key that indicates the protocol should be based on a combination of HTTP_X_FORWARDED_PROTO and HTTPS, and possibly HTTP_X_LOCAL_PROXY too? That might help to make the caching compatible with Aegir's SSL support.

Another problem is with Boost. Boost takes no notice of the X-Accel-Expires header. If a cached page exists on disk it will be served. Only way to prevent this is to set nocache=1. That is fine for one-off requests, but I dont think that redirecting to a url with nocache=1 appended as part of http->https redirection is a nice way to handle disabling of the Boost cache. A custom header would be better, like you outlined in #3.

Why use Boost when Nginx can do the same or better caching? One reason for using Boost is that it provides a site's content editors a very easy way to flush out the cache for an individual page through a block that can be placed in the footer. This block shows them very clearly if a page was cached, when it is due to expire, and gives them a button to clear it. Does Purge/Expire provide that? I haven't got those two working at all yet, so wouldn't know, but my guess is that they do not since the cache information is stored in Nginx and not in Drupal's database where it can easily be queried.

omega8cc’s picture

omega8cc commented

Support for HTTPS header has been added: http://drupalcode.org/project/barracuda.git/commit/ddf291f

omega8cc’s picture

omega8cc commented
Status: Active » Fixed

We have added support for optional extra X-Force-NoCache header: http://drupalcode.org/project/barracuda.git/commit/a69dc0d

However, because of this egg/chicken syndrome with Boost, if Boost will create cache file, there is no way to get around this on the PHP level if there is nothing in the visitor's browser which could skip Boost cache - like already mentioned OctopusNoCacheID cookie or extra ?nocache=1 added to the URL.

You would need to use nocache exceptions configured in Boost (but it is available in the D6 version probably?)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.