Redirecting to and from Secure and Non Secure pages not working in ie7

Hello everyone,
I am trying to redirect every page in a certain directory, “checkout” to https and every page not in this directory to just http

I put this .htaccess code in my root directory:


#Redirect to nonsecure pages
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule ^(.*)$ http://www.mysite.com/$1 [R=301,L]

The above code should make all pages redirect to http

Then I put the below .htaccess code in the directory “checkout”


RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} checkout
RewriteRule ^(.*)$ https://www.mysite.com/checkout/$1 [R=301,L]

Which redirects any pages in this directory to https

But…with ie7 the LOCK icon that a lot of webusers look for to see if a page is secure shows as the page is loading, but then disappears. Which to many web users it may seem like the page is insecure, even though the url starts with https

The problem comes from the htaccess file in the root directory, when I remove it ie handles the https just fine and the lock icon displays.

But when someone moves out of the secure directory to a non-secure page that warning pops up saying something like “this page contains both secure and nonsecure…”

So is there anyway to get the above code to work nicely with ie to get the lock to display, and also redirect any non-secure pages to http?

Thanks for any advice!

JS,

You’re welcome!

… and you’re NOT the first recipient of my rant against the inappropriate use of the :kaioken: EVERYTHING :kaioken: atom. I regularly “go off” about that when it’s obviously causing the problem. At least (I HOPE) I explained both WHY and HOW to fix the problem it introduced.

My tirades normally go on about how (.*) is a garbage collector … but that’s exactly what you wanted (to match everything OR nothing). Since it still caused a problem (being used twice without an escape hatch), that’s what I pontificated upon above. My normal rant is that you should be specifying exactly what you will accept in your match whether it’s to list the characters (e.g., [a-zA-Z]+), digits ([0-9]+) or some other characters OR to list the specific matches ( (test1|test2|test3) ) or … well, you get the idea.

Regards,

DK

js,

It’s the :kaioken: EVERYTHING :kaioken: atoms that you’re using! Thanks for the example of what NOT to use.

Okay, now that’s out of my system, it IS the (.) which is not being properly checked before the redirection in the first RewriteRule (block) that is the problem. All you need to do to avoid the problem with (.) is to use a RewriteCond to ensure that the %{REQUEST_URI} is !^checkout.

Piece of cake! Using (.*) is okay IF - and ONLY IF - you know how to prevent the thing going loopy. To do that, you MUST remember that mod_rewrite is NOT finished after it makes its first pass; it goes back and redirects until it finds no new matches. Think through your code as if you were the mod_rewrite module looking at {THE_REQUEST}.

Regards,

DK

Thanks for the explanation and the patience! Hopefully I can figure it out now :slight_smile:

JS,

The RewriteRule can ONLY attempt to match the %{REQUEST_URI} string. Nothing more, nothing less. To examine other strings, you must use the RewriteCond statement and specify what string then the regex you’re trying to match in that string.

What you have wrong here

RewriteCond %{HTTPS} on
[COLOR="Gray"]RewriteCond %{REQUEST_URI} !^checkout[/COLOR]
RewriteRule [COLOR="Red"]!^checkout[/COLOR] http://www.yasminagroensteinstudio.com%{REQUEST_URI} [R=301,L]

is the lack of regex to test against the %{REQUEST_URI} string. Okay, you do have that in the RewriteCond but it’s the FORMAT of the RewriteRule which you’re non-compliant with.

RewriteRule{space}{regex}{space}{redirection}{space}{flags}

Of course, the last space and flags are optional but NOT if you are going to properly terminate your mod_rewrite (block) statement, i.e., get in the habit of using the Last flag.

You are SOooooo close! Using the example code from my signature’s tutorial article, try:


RewriteEngine on

# redirect DIRECTORY requiring a secure server

RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^checkout https://www.example.com%{REQUEST_URI} [R=301,L]

# redirect pages not requiring a secure server

RewriteEngine on
RewriteCond %{SERVER_PORT} ^443$
RewriteRule !^checkout http://www.example.com%{REQUEST_URI} [R=301,L]

Please note that I’ve used the secure server’s port rather than the {HTTPS} variable because it does not exist (“on” or undefined) if not https. I’ve also assumed that you’re using Apache 2.x (so the start anchor, ^, does not have to become ^/ or ^/?).

Regards,

DK

js,

I make redirections on my sites to ensure security but my code to ensure secure server treatment is generally aimed at specific files within my file structure (and using relative links within those files - secure or not secure).

If the redirections are being redirected FROM the secure server treatment, then the mod_rewrite will have to be re-coded to avoid your js and css files (and images) - adding a simple RewriteCond is all that is needed.

Regards,

DK

That is the best reply I have ever gotten! Thanks for the feedback, and the exploding emoticons!

I think I need more help,

Here is what I have put together based on your feedback:


RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} !^checkout
RewriteRule http://www.yasminagroensteinstudio.com%{REQUEST_URI} [R=301,L]

With this code block placed in my root directory, the secure directory ‘checkout’ does display secure, but when I move out of the secure directory I still have https in the url.

So the above code isn’t really doing what I need it to. I am still pretty new at htaccess and would love some help to what I am doing wrong.

Thanks!

Okay I finally figured out what the problem really is.

I have a couple of Javascript include files, a css file and one image that point to directories outside of the checkout directory., even though the src=“https://www.mysite/js/file.js” i think the htacess file is rewriting this to be just http:// causing the checkout page to not be secure.

Any ideas on how to fix this? I call these same files from other non-secure pages too so just placing them in the secure directory isn’t all that helpful.

I think I might just use my old php redirect method of forcing https…