Setting up Pressflow and Varnish to work with HTTP and HTTPS

Using Varnish and Pressflow together is an effective way to maximize the potential of your hosting environment, and can yield extraordinary results. The problem is, if you're not intimately familiar with Varnish, or the Linux command-line, getting it into a functional state can be something of a challenge. Out of the box, it is adequate at caching content for anonymous users, but that's where the fun ends.

On a recently completed (large) Pressflow project, we had to make some decisions about server architecture. Varnish, under heavy load, can suck down memory pretty quickly, so we opted to use two servers. The first one housed Varnish and Memcache, while the second one acted as the application environment (LAMP with APC).

After some basic tweaking, we got things running properly. Varnish was caching as expected, and things were moving along relatively well. We completed load-testing, and were very happy with the results. Then, a few weeks before launch, it was determined (by the client) that the site was to be for registered users only, and that there would be a recurring annual fee to remain a member, due to the premium content.

This obviously changed things a bit. If all users of the site needed to be authenticated, we'd have to modify the Varnish configuration to allow for this. There was a larger problem, though, that had not been anticipated. Varnish is an HTTP accelerator. Notice that I didn't say HTTP/HTTPS accelerator. It doesn't know what to do with HTTPS traffic, due to the encryption. We'd have to find a way to pass HTTPS traffic through Varnish in a meaningful way, or bypass it entirely. In addition to this, we needed to create a number of rewrite rules to redirect the user from HTTP > HTTPS on login, registration, and checkout pages (and vice versa).

Some quick Googling finds the Varnish FAQ, which recommends using an HTTPS accelerator like Pound or Stunnel. We decided to move forward with Pound, which was as easy as running the following commands from Server 1:

… and then, the basic configuration to get Pound working:

*note* If you have .key/.crt files (likely), you'll need to convert them into a single .pem key for Pound to work properly. This guide should help with that.

Running this configuration allowed both instances (HTTP/HTTPS) of the site to run independently of one another. For example, navigating to http://mysite.com/path would load the non-secure version of the site, and navigating to https://mysite.com/path would load the secure version.

Since Pound sends traffic to Varnish on port 80, Drupal's normal method of detecting HTTPS (Server variable - $_SERVER['HTTPS') doesn't work. Therefore, we can modify the value for a server variable that already exists, from the Pound configuration:

… and add exclusion rules to Varnish to tell it to not cache the pages mentioned above:

Now, you would think that since Varnish is passing the requests for these pages back to Apache in their entirety, we could just add some rewrite rules to .htaccess that use the X-Forwarded-Proto variable as a condition. In our testing, this didn't work, so we added a little logic to the Pressflow settings.php file to handle the work that conditionally enables the HTTPS variable in the presence of HTTP_X_FORWARDED_PROTO:

Now we can add rewrite rules to the Pressflow .htaccess file...

An alternative to modifying the settings.php and .htaccess files is to simply add some code at the top of your page.tpl.php file...

and voila! Navigating to user/login, user/register or cart/checkout forces a rewrite of the URL to HTTPS, and navigating away from those pages returns the user to HTTP.