http => https => http with .htaccess

[servaris]

Hi,

I am trying to get .htaccess to force redirection to a *file* with https. And then, any links in the nav bar to go back to http without having to edit the nav bar constantly.

Currently in .htaccess the following is present:

Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_FILENAME} /contact.php
RewriteRule ^(.*)$ https://www.domain.ca/$1 [R,L]
RewriteRule ^/(.*):NOSSL$ http://www.domain.ca/$1 [R,L]

The http => https works just fine. Problem is from https to http that doesn't get changed.

The file contact.php is in the same dir as the other files (root dir). Can someone please tell me what is wrong with the current .htaccess as shown above.

Thanks!

[jdMorgan]

Nothing major is wrong, except that half of it is missing. With a few additional minor corrections, I'd suggest something like:

Options +FollowSymlinks
RewriteEngine on
RewriteBase /
#
# Externally redirect http secure-page requests to https
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^contact\.php$ https://www.domain.ca/contact.php [R=301,L]
#
# Externally redirect https requests for all non-secure
# objects to http, except for shared included objects
RewriteCond %{SERVER_PORT} =443
RewriteCond $1 !(^contact\.php|\.(gif|jpe?g|png|ico|css|js))$
RewriteRule ^(.*)$ http://www.domain.ca/$1 [R=301,L]

This code redirects http requests for "contact/php" to https.
It also redirects https requests for anything *except* contact.php back to http, unless the request is for a "shared object" such as an image, a favicon, a css stylesheet, or an external JavaScript file -- any included objects which will be shared between secure and non-secure pages.

You may need to modify this list of excluded objects, but the purpose is to avoid "Mixed secure/insecure object" warnings in the browser by *not* redirecting objects included using page- or server-relative links on your pages. Only object-types loaded by and shared between http and https need to be listed. You may make the exclusion list as specific as you like, and specify only the exact URL-paths to be shared, but of course doing so may increase future maintenance of the rule.

You may wish to do this exclusion by filetype (as I show here), or based on directory-paths or some other criteria that is "visible" in the requested URL.

Jim

[servaris]

Hi JdMorgan,

I put the code it as you have it. Just changing domain.ca to real one. Same thing though. Once a click to contact.php is made, using nav bar link back to any page is still https. The only way its working in the desired fashion is to specifically list in the menu every link as [domain.ca...]

Here is the current .htaccess

Options +FollowSymlinks
RewriteEngine on
RewriteBase /
#RewriteCond %{SERVER_PORT} 80
#RewriteCond %{REQUEST_FILENAME} /contact.php
#RewriteRule ^(.*)$ [domain.ca...] [R,L]
#RewriteRule ^/(.*):NOSSL$ [domain.ca...] [R,L]

# Externally redirect http secure-page requests to https
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^contact\.php$ [domain.ca...] [R=301,L]
#
# Externally redirect https requests for all non-secure
# objects to http, except for shared included objects
RewriteCond %{SERVER_PORT} =443
RewriteCond $1 !(^contact\.php|\.(gif|jpe?g|png|ico|css|js))$
RewriteRule ^(.*)$ [domain.ca...] [R=301,L]

[servaris]

Hi jdMorgan,

Forgot to to mention that I killed current browser and tried with another browser to be sure no cache was doing this.

[servaris]

Is there something special in the <VirtualHost> for httpd-ssl.conf that is causing .htaccess to be ignored?

the DirectoryRoot points to www/data/domain.ca/ and contact.php is sitting right there with the rest of the .php files.

[jdMorgan]

If the SSL <VirtualHost> points to a different DocumentRoot filespace than the non-SSL, then the .htaccess file in the non-SSL filespace won't be executed for SSL requests.

If the SSL <VirtualHost>t contains "AllowOverride None", then the Options directive in the .htaccess file in the "http filespace" won't be allowed, and mod_rewrite should fail with a 500-Server Error.

Further, if you have access to the server config files, then you should seriously consider doing all of these redirects in a server config file -- It is much more efficient than using .htaccess.

Instead of switching browsers (which won't always work), simply delete your browser cache (or set its size or its "cache time" to zero. If you do disable it, though, don't forget to re-enable it after testing, or you will likely get very slow general web-surfing...

Jim

[servaris]

Hi jdMorgan,

No, the ssl.conf DocumentRoot for this virtualhost points to exactly same place as does vhosts.conf. There is no AllowOverride anything in vhost of ssl.conf

Can you put DocumentRoot /usr/local/www/data/domain.ca/contact.php and it will work rather than pointing to a dir ?

[jdMorgan]

The code I posted was meant as a complete relacement for what you had, although I do not know the meaning of the ":NOSSL" string appended to your pattern (and apparently to your URLs as well), and my code will not handle that -- nor do I recommend it.

If you still have trouble, you should look at all of the config files...

No you can't specify a file as <DocumentRoot>. It is, by definition, a directory-path.

Jim

[servaris]

This is now the only content in .htaccess The other stuff you talk about was commented out.

Options +FollowSymlinks
RewriteEngine on
RewriteBase /

# Externally redirect http secure-page requests to https
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^contact\.php$ [domin.ca...] [R=301,L]
#
# Externally redirect https requests for all non-secure
# objects to http, except for shared included objects
RewriteCond %{SERVER_PORT} =443
RewriteCond $1 !(^contact\.php|\.(gif|jpe?g|png|ico|css|js))$
RewriteRule ^(.*)$ [domain.ca...] [R=301,L]

[servaris]

Ok, flushed cache, rc.d/apache graceful; went back to site, when going from contact.php to any other domain.ca/file_name.php (and in the p7 menu, the link is something like <a href="/product.php">Product1</a>

So it keeps the https.

Are you suggesting that contact has to be in its own dir as in, data/domain.ca/secure/contact.php rather than data/domain.ca/contact.php ?

[jdMorgan]

Well, the product-page links should be <a href="http://domain.ca/product.php> unless you want to confuse search engines, cause your visitors to suffer a redirect delay, mess up your stats (doubled page requests), and see errors in Webmaster Tools reports, but that point notwithstanding, it's clear that the https-to-http redirect is not being invoked, because if it was, it would 'conceal' this linking error from casual view.

No, contact.php need not be in its own directory -- not sure where that idea came from...

Without admin access to your server, I can't tell you why the https-to-http redirect code isn't executed, so I'm afraid you're just going to have to dig into this in any way that you can... The clue-train to follow is that in the context of an https request, this .htaccess file must be in the filepath between DocumentRoot and the requested resource (inclusive), it must be processed, and mod_rewrite must be enabled. Anything that disables .htaccess file or mod_rewrite processing, or that 'diverts the request away' before mod_rewrite can act on it (e.g. mod_alias, mod_proxy, mod_negotiation) would be a likely suspect. That's about all I can do for you from here...

Jim

[servaris]

I have access/root to the servers. Seems you're saying the links on the https contact.php page explicitly have to say [domain.ca...] and *not* just /file_name.php or else all links just stay as https. Is this correct?

[g1smd]

A partial URL found in a link on an HTTPS page will be resolved as being the same protocol and same hostname as the page upon which the link was found - unless you specifically specify a different protocol (http vs. https) and different hostname (www vs. non-www). It is the browser that resolves relative URLs, relative to the current page.

[servaris]

Hi g1smd,

I was hoping there was some sort of magic that could be implemented in a .htaccess file in root dir of a site that would allow any (wanted) links within a https page to go to just regular http.

Thanks!

[jdMorgan]

There is no magic of any kind in the world of computers or the internet. Of course, the code above will redirect requests to the correct protocol if those requests are made using the wrong protocol (once you figure out why it isn't being invoked at all, that is). But relying on external redirects to compensate for linking errors is one of the things we (simplistically) term "SEO suicide" around here.

I call these "linking errors" because that is what the search engines will call them. You will see reports showing up in your Google Webmaster tools saying something to the effect of "Link to the final correct URL, and don't make us a follow a redirect to get there." Requiring your users to suffer the delay of a 301 redirect on every request --a fact which is visible to search engines-- will be adjudged to be a sign of "poor technical quality" on your site, and will --to some degree-- count against your site's rankings.

Understand that an external redirect sends a response to the client (e.g. browser or search robot) that says, "The resource you requested has moved, please ask for it again at this new URL." This terminates the current HTTP transaction, and the client (at its option) must issue a new HTTP request for the resource, this time using the new URL supplied in the redirect response.

This doubles the number of requests to your server for that resource, slows down the 'user experience,' and makes a mess of your 'site stats' because the number of 'hits' is doubled with half of them resulting in 301 redirects. Relying on the 301s therefore indicates to search engines that you care about none of this, and they'll treat your site accordingly.

There is no maqic. There are no shortcuts. Run a tight ship.

Jim

[servaris]

Hi jdMorgan,

So please, let me get this right once and for all. If (as in our case) one has just one page that should go to https, the navigation menu should have the entire URL with the preceding https. And secondly, in a separate nav bar file used only on the page that is the one using https protocol, all links going to non https page *must* be explicitly stated as [blah.com...]

The above then does not cause the 301 and the web site with 1 https page and other pages being non https are then as you call, in a tight ship.

If by chance there were other pages being offered that were to be https, one would simply have /dir/file_name.php without requiring the entire URL with https since the page displayed is already https.

Is this correct or not?

[jdMorgan]

On all SSL pages, all links to all non-SSL pages must be explicit and include the http protocol and canonical hostname.
On all non-SSL pages, all links to all SSL pages must be explicit and include the https protocol and canonical hostname.

The 301-redirect code discussed above then functions only to catch errors made by other Webmasters, forum and blog posters, and therefore, search engines when linking to your site.

That plus full canonicalization of all other inbound linking errors, such as non-canonical hostnames, FQDN hostnames (trailing period on "example.com." for example), appended port numbers (example.com:80 for example), index-page filepath in URL (instead of just example.com/), common forum auto-linking errors (trailing punctuation on the URL or malformed HTML mark-up around the URL, for example), capitalization errors, and bogus or incorrect query string parameters are part of running a tight ship.

The bottom line is that one and only one unique URL should be associated with any given piece of content on your site. This is the canonical (usual, correct, and proper) URL. Any variation whatsoever in the URL string should result in a 301 redirect to the canonical URL.

Discussion of all of these canonicalization functions and more are available in previous threads posted here in this forum, our Apache Forum Library, and (mainly) in our Google forum (as SEO subjects) and these threads are findable with a site search of WebmasterWorld using terms and phrases such as "canonical hostname", "canonicalise domain" (UK spelling), "domain canonicalization", "duplicate content", "dupe content penalty" (or "duplicate pages", or "URLs"), and "tight ship". Enjoy... :)

All of this may seem daunting at first, but once a ship is tight, it is much easier to keep it that way. For one thing, it's not always leaking (i.e. sinking in the search results) and distracting you from keeping everything else tidy as an integral part of your day-to-day process. It also closes the door to common malicious linking exploits used to attempt to scuttle your site.

Jim

[servaris]

Hi jdMorgan,

Thank you for telling me. It is now perfectly clear what has to be done and what might have to be done later if more pages are created for two different sites.

I couldn't agree with you more on the aspects of a properly crafted tight ship.

Thank you again!