Hi Matthew,
you're probably better off making the whole site secure. There are complications (which I'll describe below) with mixing a secure and insecure site together. In the past folks tried to keep a bunch of the site unsecure to save on processing (ie decrypting the pages) but the client is likely fast enough to decrypt the page without anyone noticing a speed drop off.
The complications (in no particular order) are;
a) the secure and insecure servers are fundamentally 2 different servers. So they have 2 different session queues. So for a user to move smoothly from one to the other would take a bit of code to copy his session across as well. (Not impossibly by far, just more code.) This may not be an issue if you basically get users to log in (go secure) before they start using the session queue to any great effect.
For example shopping site A wants to allow users to "add to cart" before logging in and before going secure. In this case there would need to be a mechanism to move their cart to the Secure server when they do go secure.
Contrast this to Shopping site B which requires users to log in (and hence go secure) before adding to card. In this case the lost session of the "not logged in browser" can be ignored without any problems.
b) browsers don't like moving from a secure, to insecure environment at the same site. You've probably seen warnings of this on other sites if they do this. So from an interface point of view you'll probably leave users who have "gone secure" as secure even if they revisit parts of the site that are "insecure".
c) your URL determines whether a page request is secure, on insecure. Therefore you should only _ask_ for secure pages using the HTTPS url. In other words, to make a simple "fix" to your problem, don't focus on "serving the page securely when it's asked for insecurely" but rather work on "asking for the page securely if it has to be delivered securely."
Cheers
Bruce
Topic: Mixed secure sever (Read 14508 times)