This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
However, if I try to go to http://website:443 things don't work so well. The browser simply shows some garbage characters that I'm assuming are a part of an SSL handshake that will never complete. BTW, I know that what I'm asking about here is fundamentally wrong - I'm looking into it because of the way a poorly-designed applet (that I have no control over) is working.
Anyway, what I would *LIKE* to have happen is this:
In looking at the SSL spec, I don't see why this can't happen. The server (that's expecting https connections) should be able to figure out that something is wrong since the client is not sending a ClientHello message. When it determines this, it can simply reply using regular old HTTP and issue the redirect.
I have a feeling that my argument is somehow flawed, but can't figure out why. Anyone have any ideas? Anyone have any ideas on how to actually implement such a thing?
In principal you could implement HTTPS in this way, I suppose. It's a special non-standard case of error handling, though, so it might violate the protocol (which probably specifies precisely what should happen in case of a "broken" HTTPS stream).
As a possible workaround you could try to detect URLs like that with an Apache server and the mod_rewrite module. I'm not sure whether it's not too late by the time mod_rewrite sees the request, though.