[Issue 4096] New - Using Hudson through a stunnel redirects to http- instead of https-URLs
https://hudson.dev.java.net/issues/show_bug.cgi?id=4096 Issue #|4096
Summary|Using Hudson through a stunnel redirects to http- inst
|ead of https-URLs
------- Additional comments from [hidden email] Fri Jul 24 12:59:09 +0000 2009 -------
I have configured an stunnel for accessing our intranet's Hudson instance form
the internet. This so far works fine but not for submit posts or links which are
answered with redirections (302). In that case the redirection URL always refers
to http instead of the referer's https, e.g. on login:
So it seems that all redirection answers simply do not respect the referer's
protocol, which effectively disables using Hudson transparently through a stunnel.
I digged a bit deeper, downloaded the sources for the winstone-0.9.10-hudson-10
and hudson-1.316 maven projects and added debug output to Winstone's
So I learned that the corresponding request scheme (req.getScheme() in
WinstoneResponse#sendRedirect) is "http", as well as the protocol of the request
URL (req.getRequestURL()). In contrast to that, the request header contains a
referer property (req.getHeader("Referer")) with "https" protocol.
Then I tried to find out, why the request URL has "http" as protocol and came
across winstone.HttpListener. In winstone.HttpListener#allocateRequestResponse
(called from the in the request handler thread) a new request is created and
setup. Then winstone.HttpListener#parseURI is called for that request which then
calls winstone.HttpListener#parseSocketInfo. Here now the request's scheme is
set to the connector's scheme (winstone.HttpListener#getConnectorScheme) which
is hardcoded to "http".
In my eyes, this is the culprit and determining the request's protocol should be
done in a more clever way. I do not mean to return anything else than "http" in
winstone.HttpListener#getConnectorScheme but simply to do something more clever
than req.setScheme(getConnectorScheme()) in
winstone.HttpListener#parseSocketInfo or winstone.HttpListener#parseHeaders.
As a workaround I now I use a patched version of winstone.jar (in a patched
hudson.war) which prefers the referer's protocol from the "Referer" header in
To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]