Question

I’m trying to prevent certain pages on my site from being accessed through HTTPS, and (for whatever reason) I want to do it through PHP and not through a .htaccess.

Here’s the code I’m using:

if ( isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on' ) {
    header("HTTP/1.1 301 Moved Permanently");
    header("Location: http://mydomain.com");
}

But for some odd reason, I’m stuck in an infinite loop, and can’t get it to work. When I check the response headers in firebug, I see that the location header is set to https://mydomain.com instead of http://mydomain.com, which is causing the infinite loop.

EDIT: Accessing http://mydomain.com directly does work.

Also note: this works if I send’em to a different page, but not if I send them to the same page. So if I run the above code in mydomain.com/somePage.php, and then try accessing it through https://mydomain.com/somePage.php, it’ll properly redirect to (non-SSL-ed) homepage. Only when I redirect them to the same page with a different protocol does it ignore the protocol.

What am I doing wrong?

Answer 1

It turns out there was nothing wrong with my code. The server was just setup in a way that was messing with my headers. I’m using engineHosting.com, and I have to say: they were very helpful. After a lot of back & forth with them, here’s what they sent me:

We were able to get to the bottom of this and may have it (sic) fixed the issue but the fix in and of itself my cause other issues. Let me explain.

Our architecture is not typical of most web hosts. Your account is actually hosted by twin firewalls, twin intrusion prevention systems, twin load balancers also performing the role of SSL hardware-based acceleration, fronting two apache web nodes, and a massive mysql server backend.

The problem was with how we were doing the SSL acceleration inside the load balancers. We have had a number of clients that wanted to detect when a user was accessing a page that was only meant to be used with https, but never the reverse of wanting to detect when a user was on a page that should be redirected to regular http. Because of this, we had an option enabled on our load balancers called "http wan optimized compression SSL Sites Only" which also rewrites an outbound location header to be https when the requesting url was already https enabled. This is useful when you may have a lot of links to assets on the same URL served dynamically but accidentally wrote the link as http. So this is actually a feature, not a bug (and yes I too dislike that phrase).

To work around your particular use case, we changed the SSL profile for your domain to be "http compression for normal/non-ssl" virtual server setups. You have likely not run into this issue using single server web solutions in the past. The unfortunate consequence of operating in this mode is that the other use case of doing 30x redirects at the server level for redirecting users from http to https may have issues depending on how the redirects are implemented. To be safe, you should validate the methods you will be using in your live site and let me know if you run into any problems.