[jwarkentin]

> mixing of HTTP/HTTPS content

This is ALWAYS a bad idea. A few points:

- The only purpose of HTTPS and encrypting communications in general is to prevent MITM attacks.

- If your server is even willing to serve unencrypted requests it exposes your users to sslstrip attacks (http://www.thoughtcrime.org/software/sslstrip/). In reality you still should serve HTTP requests but only to force a redirect to HTTPS. In addition you should use the 'Strict-Transport-Security' header. It's the ONLY way to prevent future sslstrip attacks.

- Even worse, if you don't set the 'secure' flag on session cookies at a minimum (thus forcing logged in users to HTTPS only) you expose your users to session hijacking without even putting up a fight.

- If you aren't going to bother with forcing HTTPS all the time then there's not much point as you've opened up your users to simple sslstrip attacks followed by session hijacking or even worse, script injection or redirects.

One fundamental concept many people seem to forget as well is that the dangers of not encrypting communications extends beyond snooping. Attackers can actually modify the data stream to inject and/or replace content or even redirect users entirely.

Also, even if you only serve secure content yourself but you include insecure content on your page it exposes security vulnerabilities. Let's say you include unencrypted images on your site and you have users that are using a client with an image rendering engine vulnerability that allows remote code execution (this has happened in about every browser). All a MITM has to do is replace the requested image with different content that exploits the vulnerability. Now imagine if you included unencrypted JavaScript that actually does execute on your site (like from a CDN). The possibilities are endless.