Thanks. I typically let my webserver handle SSL whenever I can since it's much easier that way; especially since I know how to handle http->https urlrewrites that way already; and, plenty of examples on the web for IIS. The reasons for adding stunnel into the mix in this scenerio completely outweight not having it at all. I couldn't find any examples anywhere showing how to handle a simple http to https URL redirect if stunnel is involved; not even in javascript. Hopefully someone here has the expertise to offer a solution at least in html.
On 30.10.2012 20:39, MKANET wrote
> Thanks for the quick reply! So... what http code do I use to break
> out the infinite loop so it loads only once?
I'm afraid I can't answer that one, as you're using IIS and I'm Unices centered.
FWIW, in situations where the port-80 service does *nothing but* hand out redirects to port 443, I typically let the full-blown webserver handle the HTTPS (whether natively or behind an SSL wrapper) and use a boilerplate PERL script (alas, not readily usable on Windows) for the redirecting. I've seen too many kinds of webserver doing redirections to autodetermined URLs that happen to miss some vital part of the originally requested URL, including some that *cause* the browser to drop from HTTPS back to HTTP in the first place. :-S
Regards,
Thanks for the quick reply! So... what http code do I use to break out the infinite loop so it loads only once?
I think the other 2 circumstances may have something similar happening to them (which are forwarded using the web server instead). If I use the webserver to rewrite the URL, the web browser tries to do something (I can't tell what), then returns the error below:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
> Normally, I could do this a few different ways (provided my webserver
> had ssl added to it natively in a normal way) 1. webserver URL Rewrite
> plugin 2. webserver redirect plugin
> 3:
>
> For whatever reason, I'm having all sorts of weird issues when
> trying the three methods above if I use stunnel for ssl instead of
> using the webserver's builtin ssl.
Please note that traffic coming out of the stunnel looks - and actually
*is* - just as port-80-ish to the actual webserver as native HTTP requests do, so unless you take special measures to break the loop, the webserver will try to (re-)redirect *that, too*.
Regards,
J. Bern
--