7

I need to redirect all incoming HTTP traffic to HTTPS on my elastic load balancer.

I tired using Apache mod_rewrite:

 RewriteEngine On
 RewriteCond %{HTTP:X-Forwarded-Proto} !https
 RewriteRule !/status https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

Taking advantage of the X-Forwarded-Proto header added by the load balancer, this rule should instruct the users browser to request the HTTPS version of the same URL.

So far It doesn't work (no redirection happens).

What am I doing wrong?

Is there a better way to do this?

EDIT:

This eventually worked:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^/(.*)$ https://%{SERVER_NAME}/$1 [R=301,L]
Improve this question
0

3 Answers 3

Reset to default
5

So I assume you have the ELB set to accept traffic on both HTTP/80 and HTTPS/443, but port-forward all to HTTP.

If you want to use your method (which is clever), are you sure what you get isn't %{X-Forwarded-Proto} -- the HTTP: prefix looks odd to me. Other than that, this looks right to me.

If this is in a virtual host or the main server config and it's still not working, you can add 

RewriteLog rewrite-log
RewriteLogLevel 3

then look in the file rewrite-log to see what's actually going on. This file can be incredibly verbose, start with lower levels. Logging cannot be initiated from .htaccess files.

(I would suggest you make the flags on the RewriteRule [R=301,L] which will cause the server to send back a 301 response, which tells search engines to consider the redirect permanent, and update its links accordingly.)

Improve this answer
4
  • Thanks for the answer, It looks like the [R=301,L] was part of the solution.
    – panos2point0
    Nov 30, 2012 at 11:39
  • 2
    Glad you found something that worked, but the flags [L,R] should be fine other than the naked R returns an http 302 status. The order of flags shouldn't matter. More likely it's something about the change in the RewriteRule which is different in 2 ways 1) it will not rewrite http requests to /status any more, and 2) it uses a capture group and back-reference ((.*) then $1) instead of the %{REQUEST_URI} variable. It might be helpful to others to see if the flags really were the cause, or perhaps it was something else.
    – Tom Harrison Jr
    Nov 30, 2012 at 13:19
  • 1
    I think I have narrowed it down to the use of != instead of !
    – panos2point0
    Nov 30, 2012 at 13:41
  • HTTP:X-Forwarded-Proto and X-Forwarded-Proto both worked for me.
    – jaredsten
    Jul 15, 2014 at 0:31
1

Just wanted to add my experience as I struggled for hours before realizing that my heartbeat file had an unescaped dot in it (/alive.html). Duh.

The second problem was that the main domain was not redirecting, but files were. So http://domain.com/hello.html was redirecting to https://domain.com/hello.html, but http://domain.com was not.

Here's what I put in my .htaccess file that worked for me:

RewriteEngine On
# SSL connection forced
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{REQUEST_URI} !^/alive\.html$
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
Improve this answer
1

In my case the problem turned out to be that the !https condition was breaking the health check.

changing the condition to ^http$ made it work

RewriteCond %{HTTP:X-Forwarded-Proto} ^http$

found that here: https://forums.aws.amazon.com/thread.jspa?messageID=641930

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .