HTTP<->HTTPS redirects with boost

Infact, here is a slightly better config that also allows boost to work for https pages:

  # Serve these pages only over https, bypassing the static cache.
   # Later on, we will redirect all other pages back to http.
   location ~* ^/(en/)?(donate|civicrm.*)$ {
     if ( $scheme = 'http' ) {
       rewrite     ^(.*) https://$host$1 permanent;
     }
     try_files $uri @sslcache;
   }

Then, add a new location for @sslcache, and as before add the https->http redirect to @cache:

    ###
    ### boost compatible cache check - nginx 0.7.27 or newer required with try_files support
    ###
    location @sslcache {
        if ( $request_method !~ ^(?:GET|HEAD)$ ) {
             return 405;
        }
        if ( $http_cookie ~ "DRUPAL_UID" ) {
             return 405;
        }
        error_page 405 = @drupal;
        add_header Expires "Tue, 24 Jan 1984 08:00:00 GMT";
        add_header Cache-Control "must-revalidate, post-check=0, pre-check=0";
        add_header X-Header "Boost Citrus 1.9";
        charset utf-8;
        try_files /cache/normal/$host${uri}_$args.html @drupal;
    }

    ###
    ### boost compatible cache check - nginx 0.7.27 or newer required with try_files support
    ###
    location @cache {
        if ( $scheme = 'https' ) {
            rewrite ^(.*) http://$host$1 permanent; # redirect to http
        }
        if ( $request_method !~ ^(?:GET|HEAD)$ ) {
             return 405;
        }
        if ( $http_cookie ~ "DRUPAL_UID" ) {
             return 405;
        }
        error_page 405 = @drupal;
        add_header Expires "Tue, 24 Jan 1984 08:00:00 GMT";
        add_header Cache-Control "must-revalidate, post-check=0, pre-check=0";
        add_header X-Header "Boost Citrus 1.9";
        charset utf-8;
        try_files /cache/normal/$host${uri}_$args.html @drupal;
    }

It seems strange to me that this actually works, but, it does!

Your setup looks cleaner in some ways, but disables boost caching for ssl pages, which is very much undesired. The pages need to be encrypted, but not encrypted and slow!

I don't think its a good default setting. Boost has an option in its configuration page to disable the cache for ssl pages, as well as providing a way to exclude specific paths. If people want to exclude boost on specific paths or ssl pages they should be able to use boost's own configuration for this.

I was trying to find a way to do it in a generic way, but was unsuccessful. My thinking was doing something like this:

location @cache {
        if ($do_http_redirect = '1') {
            rewrite ^(.*) http://$host$1 permanent; # redirect to http
        }
        if ($do_https_redirect = '1') {
             rewrite ^(.*) https://$host$1 permanent; # redirect to http
        }
        if ( $request_method !~ ^(?:GET|HEAD)$ ) {
             return 405;
        }
        if ( $http_cookie ~ "DRUPAL_UID" ) {
             return 405;
        }
        error_page 405 = @drupal;
        add_header Expires "Tue, 24 Jan 1984 08:00:00 GMT";
        add_header Cache-Control "must-revalidate, post-check=0, pre-check=0";
        add_header X-Header "Boost Citrus 1.9";
        charset utf-8;
        try_files /cache/normal/$host${uri}_$args.html @drupal;
    }

The thinking was that this would allow people to set $do_http_redirect or $do_https_redirect elsewhere in their vhost config based on path matching or some other paramters, and depending on the value of this the redirect would be performed. Something like:

  # Serve these pages only over https, bypassing the static cache.
   # Later on, we will redirect all other pages back to http.
   location ~* ^/(en/)?(donate|civicrm.*)$ {
     if ( $scheme = 'http' ) {
       set $do_https_redirect '1';
     }
     try_files $uri @cache;
   }
   set $do_http_redirect '1';

I couldn't get it working like this though. The variables didn't seem to be carrying over to the @cache section properly. You would also need to set those vars to default to 0, probably using map in nginx.conf.

My setup in #1 actually works flawlessly (well, it's been in production for a couple of days and there have been no issues so far). The only difference I can see between that and yours in #6 is that you are using $http_x_forwarded_proto to check for https. My setup isn't using a ssl proxy. Is the ssl proxy setup something new in Barracuda-dev, or is this something specific to Octopus, which I'm not using either.

Interesting (about the ssl proxy). Never knew that. I wonder if a more prominent section in the documentation would help make people aware of this feature. Would you consider the addition of an @sslcache block in the default nginx includes, to make it possible for people to use boost caching with https?