another simple rewrite question

[finlander]

I'm looking for the .htaccess rewrite code that will allow some seemingly simple functions. I understand the basic Apache rewrite, but have not been able to get the https rewrite that simply tacks on 'www' for a page that is normally secure.

So, for the really basic stuff, of course, I want this:

'domain.com' redirects to
'http://www.domain.com'

and

'domain.com/index.php?main_page=faq' redirects to
'http://www.domain.com/index.php?main_page=faq'

but then I also want this for secure pages:

'domain.com/index.php?main_page=login' redirects to
'https://www.domain.com/index.php?main_page=login'

It's easy to see this in action at a website such as sears.com. If you remove the beginning part of the URL, the non-secure pages will add on 'http://www' to a raw non-secure URL and the secure pages will add on 'https://www' to a raw secure URL. Is this a simple thing to do? Oh, forgot to mention, yes of course the secure pages are already set up with SSL and are already served secure when arriving at them through a site link. I'm just trying to figure out how to force rewrite the URLs, correctly, when the front part of the URL is removed.

[finlander]

here is the only other clue I can think of:

Before we fixed our multiple NOT issue, there was total functionality, but it seems that there should not have been total functionality, because Rule2 would have resolving to change login page to http, since, for example, the word account (before we fixed the NOTs) not being in the string satisfied Cond3, so there either should have been a conflict, or login page should have changed to http, since Rule2 is last in line. Since neither was happening before we fixed the NOTs, I wonder if that's a clue..

[finlander]

Maybe it's just a cardinal sin to the browser for a Cond to check for secure request and have the answer be true. Maybe the browser then thinks that, even though it's a secure request, there is a chance the page shouldn't be secure, so the browser refuses to display the padlock. Funny thing about that explanation, though, is that even though the Rule is evaluated, it's not invoked because the conditions aren't met, so the browser acts on its hunch only after evaluating but not invoking the Rule?

[finlander]

g1smd, I may have an idea about the problem. I read on a MS forum that the Last flag has no effect on redirects, it only stops processing on rewrites, so our ordinary https login request, that needs nothing, gets evaluated in Rule2, and even though conditions are not met for Rule2 to be invoked, the https 'on' Cond of Rule2 being true may be enough of an expected thing that the browser is told to display the page as non-padlock http. ?

[finlander]

maybe it's as simple as this:

The second rule is half-true for a secure page, and the outcome of the second rule would http, so even though the outcome is not invoked, the fact it nearly gets invoked is enough of a red flag about security, so the browser is told to withhold the padlock, even though the URL retains https. That make sense?

[finlander]

I think I finally understand.

There are common page elements (images maybe or buttons?) on secure pages that get redirected to http because they do not contain words, such as login or account, in their query_strings. So, the page is served partially unsecure, so the padlock (in IE) disappears and in FF a warning appears on the padlock. So, using NOT-certain-words in query_string is not a good way of saying 'send all OTHER pages to http if they happen to request as https. By the way g1smd, it appears that ! in front of a paranthetical group of items, each separated by pipe, really does mean 'not ALL(ANY) of these things' rather than 'not this OR not that OR not the other' so that's cool -- don't have to make a long list to say NOT ALL of these things.

[g1smd]

Ah, I assumed that you already had the internal linking nailed, as I mentioned that problem in post #4236048.

You do need the [L] flag on every RewriteRule when using this with Apache.

[finlander]

The [L] flag may not work on redirecting, but may only work on rewriting. I read something about that on a MS forum. I tried a method of using the [L] flag on the first rule (to stop processing) with the redirects that we developed earlier, so that a subsequent rule would not fire, but the [L] seemed to be ignored and the subsequent rule fired when it didn't need to, causing redirect to http (apparently just for page elements on the secure on the secure page). Thus, the padlock was lost even though the URL still said https, because the redirect occurred for page elements.

It seems that, no matter how I code it, when redirect of page elements of the secure page get ran through the second rule, the padlock is going to naturally be lost, because even though the secure page still has https in browser URL, there are page elements that get directed to http, causing page delivery to be partially unencrypted.

All the refs to images ARE only only relational, not full URL references, so maybe there are scripts in the secure page(s) that are full URL rather than relational. Yeah, the inadvertent but seemingly unavoidable redirection of them to http could explain mixed encryption happening and thus loss of padlock.

I may keep working on it .. I dunno .. It's got me pretty baffled at this point. Maybe I should try to just put secure rules in a .htaccess in the directories for just the secure pages .. I don't know if the shopping cart php allows for that .. and then put non-secure rules in the site-wide htaccess to control all non-secure pages.

There probably is a whole different of way that major e-commerce sites control for the behavior. If I go to someplace like sears.com, every different behavior fix that we have worked on gets handled, but the padlock is not ever lost on secure pages. Could be a completely different way of handling it?

[edited by: finlander at 3:55 am (utc) on Nov 30, 2010]

[finlander]

The [L] flag may not work on redirecting, but may only work on rewriting. I read something about that on a MS forum. I tried a method of using the [L] flag on the first rule (to stop processing) with the redirects that we developed earlier, so that a subsequent rule would not fire, but the [L] seemed to be ignored and the subsequent rule fired when it didn't need to, causing redirect to http (apparently just for page elements on the secure on the secure page). Thus, the padlock was lost even though the URL still said https, because the redirect occurred for page elements.

It seems that, no matter how I code it, when redirect of page elements of the secure page get ran through the second rule, the padlock is going to naturally be lost, because even though the secure page still has https in browser URL, there are page elements that get directed to http, causing page delivery to be partially unencrypted.

All the refs to images ARE only only relational, not full URL references, so maybe there are scripts in the secure page(s) that are full URL rather than relational. Yeah, the inadvertent but seemingly unavoidable redirection of them to http could explain mixed encryption happening and thus loss of padlock.

I may keep working on it .. I dunno .. It's got me pretty baffled at this point. Maybe I should try to just put secure rules in a .htaccess in the directories for just the secure pages .. I don't know if the shopping cart php allows for that .. and then put non-secure rules in the site-wide htaccess to control all non-secure pages.

There probably is a whole different of way that major e-commerce sites control for the behavior. If I go to someplace like sears.com, every different behavior fix that we have worked on gets handled, but the padlock is not ever lost on secure pages. Could be a completely different way of handling it?

[edited by: finlander at 3:55 am (utc) on Nov 30, 2010]

[finlander]

The [L] flag may not work on redirecting, but may only work on rewriting. I read something about that on a MS forum. I tried a method of using the [L] flag on the first rule (to stop processing) with the redirects that we developed earlier, so that a subsequent rule would not fire, but the [L] seemed to be ignored and the subsequent rule fired when it didn't need to, causing redirect to http (apparently just for page elements on the secure on the secure page). Thus, the padlock was lost even though the URL still said https, because the redirect occurred for page elements.

It seems that, no matter how I code it, when redirect of page elements of the secure page get ran through the second rule, the padlock is going to naturally be lost, because even though the secure page still has https in browser URL, there are page elements that get directed to http, causing page delivery to be partially unencrypted.

All the refs to images ARE only only relational, not full URL references, so maybe there are scripts in the secure page(s) that are full URL rather than relational. Yeah, the inadvertent but seemingly unavoidable redirection of them to http could explain mixed encryption happening and thus loss of padlock.

I may keep working on it .. I dunno .. It's got me pretty baffled at this point. Maybe I should try to just put secure rules in a .htaccess in the directories for just the secure pages .. I don't know if the shopping cart php allows for that .. and then put non-secure rules in the site-wide htaccess to control all non-secure pages.

There probably is a whole different of way that major e-commerce sites control for the behavior. If I go to someplace like sears.com, every different behavior fix that we have worked on gets handled, but the padlock is not ever lost on secure pages. Could be a completely different way of handling it?

[edited by: finlander at 3:56 am (utc) on Nov 30, 2010]

[finlander]

g1smd, could you delete these two duplicate posts? my browser hung and it got submitted three times. thanks..