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
winstone.HttpListener#parseHeaders.

Frank-Michael