[Issue 4096] New - Using Hudson through a stunnel redirects to http- instead of https-URLs

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[Issue 4096] New - Using Hudson through a stunnel redirects to http- instead of https-URLs

                 Issue #|4096
                 Summary|Using Hudson through a stunnel redirects to http- inst
                        |ead of https-URLs
       Status whiteboard|
              Issue type|DEFECT
             Assigned to|issues@hudson
             Reported by|fmmoser

------- 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:

> https://www.mysite.com:8080/j_acegi_security_check
> POST /j_acegi_security_check HTTP/1.1
> Host: www.mysite.com:8080
> User-Agent: Mozilla/5.0 ...
> Accept: text/html,...
> Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: https://www.mysite.com:8080/login?from=%2F
> Cookie: ...
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 227
> j_username=user&j_password=pwd&from=...&Submit=Anmelden
> HTTP/1.x 302 Found
> Server: Winstone Servlet Engine v0.9.10
> Location: http://www.mysite.com:8080/
> Content-Length: 0
> Connection: Keep-Alive
> Date: Tue, 21 Jul 2009 09:38:03 GMT
> X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
> ----------------------------------------------------------

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
winstone.WinstoneResponse#sendRedirect method.

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]