That makes sense. I'll ask there. Thank you. Matt
On Thu, Dec 12, 2013 at 2:00 AM, Martin Grigorov <[email protected]>wrote: > Hi, > > I think you should ask in Tomcat mailing lists. > The related code in Wicket is: > > https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java?source=cc#L232 > > As you can see Wicket always passes relative url to the underlying > container. > The container makes it absolute, i.e. sets the scheme, host, port and full > path, and then sets the "Location" response header. > > > On Thu, Dec 12, 2013 at 6:05 AM, Matthew Welch <[email protected]> > wrote: > > > I'm sure I'm missing something simple as there are certainly many others > > using similar setups, but I cannot figure out what I'm doing wrong. > > > > We force all requests from the public internet to use HTTPS when > accessing > > our app.We terminate SSL at the load balancer and the request that > actually > > hits Apache and then Tomcat is straight HTTP. The load balancer adds the > > proper X-Forwarded-Proto headers to the requests heading back to the app > > server and Wicket and we've confirmed that these are being received. > We've > > setup the XForwardedRequestWrapperFactory in our web application init. We > > can even confirm that request.getScheme() is properly returning "https" > > inside our application. > > > > Where things break down is when Wicket issues a redirect, which of course > > it does all of the time as people navigate from page to page. For some > > reason, the issued redirects are always HTTP, instead of HTTPS. These > HTTP > > redirects themselves eventually get redirected back to HTTPS by our load > > balancer on their return trip from the client, but many of our customers > > are ultra security conscious and have firewalls in place that won't even > > allow those initial HTTP requests through, so we've got a problem. > > > > We've traced through the Tomcat code and the cause is > > in org.apache.catalina.connector.Response. This is the original response > > that was created when the container first began processing the request. > It > > carries a pointer to the "original" request as well and it uses this > > request with its getScheme(), getServerPort(), and getServerName() to > > generate the redirect that is eventually returned. It does not use the > > "wrapped" request that contains the values determined from processing the > > X-Forwarded headers. > > > > As I said, I'm sure this is working as intended and that we've just > missed > > something somewhere, but for the life of me, I can figure out what it is. > > > > Any ideas? We need Wicket/Tomcat to produce HTTPS redirects. > > > > Matt > > >
