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,
----- Forwarded Message ----
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
--