UrlRewriteFilter Direct to https

Question

I am using UrlRewriteFilter to redirect to SSL. I am running Glassfishv2.

My rule looks something like this now. It's in my urlrewrite.xml in WEB-INF of my war folder. Is there any other glassfish setting that needs to be set?

<rule>
        <condition name="host" operator="notequal">https://abc.def.com&lt;/condition&gt;
     <condition name="host" operator="notequal">^$</condition>
     <from>^/(.*)</from>
     <to type="permanent-redirect" last="true">https://abc.def.com/ghi/$1&lt;/to&gt;
    </rule>

But FF keeps saying that the URL redirect rule is in a way that it will never complete. I am not exactly sure whats happening here. any ideas?

Answer 1

I suspect the problem is that the value of the host header (which you're comparing against) does not contain the scheme used to access the resource, where your comparison value does. This means that the condition is always true, because the host never equals what you're comparing it to, leading to an infinite redirect loop.

Looking at the documentation for UrlRewriteFilter, you should be able to do something like this to get what you want:

<rule>
    <condition type="scheme" operator="notequal">https</condition>
    <condition name="host" operator="equal">abc.def.com</condition>
    <from>^/(.*)</from>
    <to type="permanent-redirect" last="true">https://abc.def.com/ghi/$1&lt;/to&gt;
</rule>

Answer 2

The value of the hostname specified in the url rewriting rule cannot include the scheme. UrlRewriteFilter internally uses the Servlet API methods to determine the hostname, via request.getServerName(); this method call never returns the scheme, so you're better of performing the scheme validation separately (as Tim has implied).

If you notice the other methods available, scheme validation has to be done separately, since the scheme is made available only via the request.getScheme() method in the API, which is exposed separately via UrlRewriteFilter.

The real reason on why FF reports the error in redirection is probably due to multiple 302s being sent back to the client, for the original request (and the subsequent requests made by the client). You might want to monitor the HTTP traffic to determine if there is a rule that is present when the HTTPS redirection fails, on the actual cause of the behavior in your application.

EDIT:

If possible, you can investigate the use of the CONFIDENTIAL transport guarantee element in web.xml to ensure that the servlet container forces all HTTP requests to be made over SSL.