[Edit] - Thanks for the comments. I've tried to shape my question accordingly and I've added some additional information based on the suggestions offered.
I have a JSF web application running on JBoss AS7 that I front with Apache on SSL (port 443). Apache and JBoss are running on the same machine and communicate "in the clear" over HTTP with reverse proxy forwarding rules. With this setup, I have observed that clicking on any link created via the JSF tag <h:commandLink>
(i.e. without <f:ajax>
and where there is always a genuine backing bean action method that, after performing some business logic, returns an outcome with the ?faces-redirect=true
suffix) will see the page redirect fail because the https
scheme is dropped and replaced with http
.
If I replace all instances of <h:commandLink>
with <h:commandLink><f:ajax/></h:commandLink>
, this redirection problem goes away - i.e. the https
scheme is preserved in the resulting redirected URL.
Could anyone explain to me what I'm observing and what the "under-the-hood" difference between the non-ajax form submit and ajax submit might be in this case?
Additional Information:
My Apache reverse proxy rules:
ProxyRequests Off
ProxyPreserveHost On
<Proxy *>
Order Allow,Deny
Allow from all
</Proxy>
ProxyPass / http://localhost:8080/ timeout=1800
ProxyPassReverse / http://localhost:8080/
The web console in Firefox shows the difference between the ajax form submit and non-ajax form submit HTTP requests as:
Ajax submit via <h:commandLink><f:ajax/></h:commandLink>
I see a GET request to the expected page on https
(I can't yet post screen shots)
Non-ajax submit via <h:commandLink/>
The non-ajax version first POSTs back to the same page (which is expected) on https
with a 302 status code 'Moved Temporarily' and then redirects to the target page from the action method on http
.
Location in HTTP header for POST before failed GET redirect on http
Here's a screen shot. The location value for the POST shows as the URL of the GET request, on http
and not https
:
I guess I've gotten slightly "under-the-hood" at this point. Since the <f:ajax>
approach achieves the desired result, I am happy leaving this alone. It seems there are at least a few other JSF posts related to this same sort of thing (here's the single URL I'm allowed to post):
JSF redirects from HTTPS to HTTP
Maybe the ajax-based approach is required to preserve the scheme in the URL originating from the client?
Thanks,
-Andy