It's too bad that a company with such prominence as 37 Signals doesn't know more about why IE is doing exactly what it should be doing in this case and that Safari is actually a problem. If IE was stricter in a lot more cases, we'd have fewer "Well, it works in IE, it must be good" problems overall.

Caching issues aside, few people know that the protocol is actually optional and is inherited from the base url (just like the origin/server name portion is). So if your entire site can be served by HTTPS, you can still use relative paths anchored at different server names. On

   https://www.example.com/something

the following relative paths will also be requested via HTTPS:

   /somethingelse
   //www.example.com/media/styles.css
   //media.example.com/images/buybutton.gif

Wildcard certs come in handy here. Then it's up to your app code to make absolute _individual_ links and/or redirect (with or without https) when you want a page to be requested securely. Building URLs for internal resources is much more straight forward.

As for the referrer, let's just remember that if you're using a SSN as a primary key AND exposing that primary key in links, you've got more serious issues than "mixed content warning".

I actually sent a bug report one time to some search engine that they were building URLs wrong and not properly inheriting the protocol and they fixed it.