Today I faced a weird problem with some stores using SEO URLs and also using shared SSL.
Background: shared SSLs are popular among hosting providers, where the users can use both http://www.mydomain/myfile.html AND https://ssl.myhosting.com/users/mydomain/myfile.html
This situation is quite useful for ecommerce sites, because you won’t have to purchase a SSL certificate (at least, not while you’re trying to setup your store) and still benefit from using encrypted transmission of data to/from your server.
osCommerce has the ability of jumping back and forth from both URL formats, e.g. in a moment you are in the home of the store, in http://www.mydomain.com/index.php and in the other, you click in my account and move to https://sss.myhosting.com/users/mydomain/account.php, all transparently to the user, besides the info in the address bar.
That’s good for users of the standard osCommerce script, but I’d say that many the stores use a contribution named SEO URLs, which rewrites the standard url of a product (example: product_info.php?product_id=XX) into a more readable format: my_products_title-p-XX.html), which helps a LOT in Search Engine Optimization (hence SEO URLs 
).
All the problem arises from two facts:
- SEO URLs relies upon using mod_rewrite in Apache servers, which need a statement in .htaccess like
“rewritebase /mystore/” to work, along with some rewrite rules.
- The RewriteBase statement is not conditional, i.e., it cannot be differently for SSL or nonssl addresses.
It’s not a really big deal, since all rewritten urls *should* be pointing to http addresses, and so any https addresses are not rewritten.
In other words: the links to products in your store are all pointing to http://www.mydomain.com/myproduct-p-xx.html and the a “rewrite base /” will suffice.
BUT, you cannot underestimate Murphy’s law. If a user sees https://sss.myhosting.com/users/mydomain/account.php, there’s a good chance that they can try to append the product’s URL in the address, just to check if they’re not being fouled into a phishing website. Something like:
https://sss.myhosting.com/users/mydomain/my_products_title-p-XX.html.
As the .htaccess file is set by the standard configuration, the above URL will return a 404 error, and your visitor may think it’s not the same website. So, what can we do?
I modified my .htaccess to create 2 sets of rewrite rules, one for http and other for https accesses, like these:
RewriteCond %{HTTP_HOST} ^ssl\.myhost\.com$ [NC]
RewriteRule ^(.*)-p-([0-9]+).html$ users/mydomain.com/product_info.php?products_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-c-([0-9_]+).html$ users/mydomain.com/index.php?cPath=$2&%{QUERY_STRING}
RewriteRule ^(.*)-m-([0-9]+).html$ users/mydomain.com/index.php?manufacturers_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-pi-([0-9]+).html$ users/mydomain.com/popup_image.php?pID=$2&%{QUERY_STRING}
RewriteRule ^(.*)-pr-([0-9]+).html$ users/mydomain.com/product_reviews.php?products_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-pri-([0-9]+).html$ users/mydomain.com/product_reviews_info.php?products_id=$2&%{QUERY_STRING} [L]
RewriteCond %{HTTP_HOST} ^www\.mydomain\.com$ [NC]
RewriteRule ^(.*)-p-([0-9]+).html$ product_info.php?products_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-c-([0-9_]+).html$ index.php?cPath=$2&%{QUERY_STRING}
RewriteRule ^(.*)-m-([0-9]+).html$ index.php?manufacturers_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-pi-([0-9]+).html$ popup_image.php?pID=$2&%{QUERY_STRING}
RewriteRule ^(.*)-pr-([0-9]+).html$ product_reviews.php?products_id=$2&%{QUERY_STRING}
RewriteRule ^(.*)-pri-([0-9]+).html$ product_reviews_info.php?products_id=$2&%{QUERY_STRING} [L]
What are we doing here?
Those RewriteCond statements will limit the scope of each rewriterule block, so that one will work for https and the other will be OK for http accesses. Pretty straightforward, huh?
