After a couple of hours of hair pulling over a few lines of rewrite instructions for apache, my search for inaccurate regular expressions or logic ended with this bug report in the debian community. I’m sure this bug is addressed in some upstream distributions, and I’m also sure it’s not a critical issue, because there are other ways to accomplish the same task. Nonetheless, if you are using debian on your server, and seeing strange logical errors (probably infinite loops that shouldn’t exist, or failure to evaluate to true when you would expect), check to see if you are using the apache’s HTTPS variable.

If you are checking that HTTPS is off, your logic will be fine, as that is the default value for the variable (and the only value for the variable on some debian servers). However, if you are checking that HTTPS is on, your logic will fail, as the HTTPS variable is never set. I was rewriting to control shifting from SSL to non-SSL, and in some cases this caused infinite loops, in others, code simply failed to ever evaluate to true.

The solution is to use the SERVER_PORT variable instead. I have always considered this to be less appropriate, because if someone decides to listen for SSL over a non-standard port HTTPS still works but a SERVER_PORT=443 check will fail. Keeping in mind that your server may (although it’s unlikely) require a unique port, try changing your conditions as follows:

# RewriteCond %{HTTPS} off   ## Always true
# RewriteCond %{HTTPS} on   ## Never true
RewriteCond %{SERVER_PORT} ^443$   ## Evaluates as expected
RewriteCond %{SERVER_PORT} !^443$   ## Evaluates as expected