This week's book giveaway is in the General Computing forum. We're giving away four copies of Arduino in Action and have Martin Evans, Joshua Noble, and Jordan Hochenbaum 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.
0
