tjg184 / urlrewritefilter

Automatically exported from code.google.com/p/urlrewritefilter
Other
0 stars 0 forks source link

last="true" not behaving as expected #165

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Install urlrewritefilter according to the 3 steps in the homepage.
2. Add the following rules at the top of urlrewrite.xml:
    <rule>
        <from>^([^.]*)$</from>
        <to last="true">$1.jsp</to>
    </rule>

    <rule>
        <from>^.*\.jsp$</from>
        <to type="redirect" last="true">/whyamihere</to>
    </rule>
3. browse to /hi

The expected output is to see /hi.jsp (or an error page if it is not found). 
Instead, the browser is redirected to /whyamihere, i.e. the 'last' attribute on 
the first rule is not working as expected or as documented, and the second rule 
is still being matched.

Enabling the debug logs shows that after the first rule is matched, all the 
rules are being run from scratch on the rewritten url. Of course, if the rules 
aren't mutually exclusive as in this example, i.e. if the first rule regex 
would still match after it rewrites the url, this enters an infinite loop and 
ends with a StackOverflowException.

Removing the dispatcher elements from the filter-mapping configuration for the 
filter fixes the problem and makes 'last' really stop processing of additional 
rules after the first match.

I don't know if this is a bug in implementation or desired behavior, but seeing 
that this is the behavior out of the box (following the homepage installation 
steps), at the very least the documentation for 'last' is wrong and misleading 
and should mention this unexpected behavior and how to work around it.

Original issue reported on code.google.com by amichair on 3 Jul 2014 at 12:22