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
Original issue reported on code.google.com by
amichair
on 3 Jul 2014 at 12:22