Your last is correct - what you want to do is on any page that is on https, alter all links that go back to general shopping to be the full URI to non-https. If your checkout template is a single file (which it should be) this is an easy deal. I don't think taking away links to simplify your problem as a developer is a good idea as far as the customer is concerned.
What is not elegant about that? You have the pages that need to be secure secure, and the ones that are not are not and load faster. To browse over to checkout and just leave the customer on https is well, sloppy. :-)
There is one hiccup you need to consider. If you are using cookies to keep track of cart contents, when you move to https, you need a method of passing some unique identifier and reset a new cookie. Then when you move back to the non-https, you need to do the same thing in reverse. A cookie can only be read from the domain it was originally set on, and when moving back and forth the browser sees them as two separate domains and cookies. It's not that big a deal to do though.
By not elegant, I mean that in my included header and footer files it will no longer be as simple as having references like /images/box.gif. I will have to check the $_SERVER value (in PHP) and then all my links will have to be $protocol/$domain/images/box.gif even if $protocol and $domain are empty.
Hope I've explained that clearly!
The cookie stuff is already working, so that's fine.
Option 2 is better for a few reasons.
1) Duplicate content served over https
2) Distractions in the buying process are bad. Once you started checkout (shipping info) your goal is to get a verified payment. If you want to upsale do it at the view cart step or after they add something to the cart which should all be on the http side anyway.
Option 1 is better. The shopper may receive a "the URL you are being redirected to is not secure" message when you try to switch back to HTTP. Also, the "drain on resources" caused by SSL is minimal.
|The shopper may receive a "the URL you are being redirected to is not secure" message |
This is only true if the immediate action is on a secure server and the server directs to or includes insecure items. That is, if you submit a form then redirect to a non secure page, you will get this message. It will never occur from any link to a non-secure page from a secure page.
Forcing your visitors to browse over https which is often less than half normal speed is pretty annoying.
I think I'm inclined to agree with sandyeggo. I might be missing out on a few extra additions to the shopping cart, but maybe I shouldn't really have any distracting exit points once they've clicked that checkout button. It's hard enough to get them that far after all.
|I think I'm inclined to agree with sandyeggo. I might be missing out on a few extra additions to the shopping cart, but maybe I shouldn't really have any distracting exit points once they've clicked that checkout button. It's hard enough to get them that far after all. |
Me too! You've worked hard to get them to click that Checkout button, once they are in, don't let them out! ;)
I've actually ended a few checkout sessions because I was getting carried away with all the "others also bought" distractions. I was there for one thing and ended up with about six things and I finally came to my senses. ;)
Hard code those links all the way. The last thing you want is the bot picking up a whole set of links with https because of relative path references while on https. It happens every day and we see many wondering why their home pages are indexed under https.