From one perspective, ideally SSL would be split apart into encryption and trust, with the goal of letting you have encryption without trust. In theory you could achieve this with a different handling of https, but lately I have come to think that the user expectation problems of such a solution are insurmountable at this point; too many people just know what https in URLs means for its meaning to change (in a subtle way).

(My personal feeling is that it is pointless and even undesirable to go the other way and try to have trust without encryption.)

So, let's take as given an axiom: if it has https: visible in the URL it must have trust, not just encryption. Thus, however a split works, the SSL encryption must appear to use a http: URL as far as the user sees (and as far as Javascript sees). While SSL is client-initiated and thus servers could accept it on regular HTTP ports, the client browser can't just blindly try it with strange web servers, since it would be a protocol error (and make people unhappy when it showed up in their logs).

(The client browser cannot just quietly try making an https request instead of an http one, because even if it exists there's no certainty that a server's https website supports the same URLs with the same meanings as the http website does.)

If we're willing to accept that the first HTTP request to a web server won't be encrypted, we can have the server signal clients that it supports direct SSL on the normal HTTP port by adding an appropriate new HTTP header to its reply. Cooperative clients would then do SSL on subsequent connections. (Clients that want all real requests to a new web server to be encrypted if possible can try a small dummy request, perhaps 'HEAD /', before their first real request.)

One downside of this is that it would probably have terrible effects on the effectiveness of any intermediate caching proxies, especially transparent ones (at least until the proxies were updated to understand the scheme and either strip out the header or implement the scheme).

(Properly implemented it should not malfunction in the presence of an uncooperative proxy; the client browser would try once to do 'SSL over HTTP', fail, and fall back to ordinary HTTP.)