Bug 55176 - SSI regular expressions parsing fails
Summary: SSI regular expressions parsing fails
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.39
Hardware: All Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-01 17:08 UTC by David Reitter
Modified: 2013-07-01 21:48 UTC (History)
1 user (show)



Attachments
test cases 1, 2 and 3 (2.66 KB, application/octet-stream)
2013-07-01 17:08 UTC, David Reitter
Details
Another variant without =~ and without $1 (631 bytes, text/html)
2013-07-01 20:19 UTC, David Reitter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Reitter 2013-07-01 17:08:30 UTC
Created attachment 30513 [details]
test cases 1, 2 and 3

Regular Expressions in SSI fail to parse.

This uses SSI in 7.0.39 using SSIFilter.  The file is parsed, in principle, but whenever an IF expression with a certain regular expression is encountered, Tomcat seems to either show an exception (test case 2) stop processing the file and will not return any contents after that (for test case 3).

Certain very simple regular expressions such as /a/ do not show an error (test case 1).


Example:

My request is:

http://...:8080/tomcat7_ssi_bug/foo.html?year=234234

The relevant portion of the file is (test case 3):

<!--#if expr="${QUERY_STRING} = /year=(.*)/" -->
   
I have tried a number of variants, including $QUERY_STRING instead of ${...}.
I find no error about this in the logs.

I tried simpler regular expressions.  The following

<!--#if expr="${QUERY_STRING} = /year=/" -->

Leads to the error below:

java.lang.ClassCastException: org.apache.catalina.ssi.ExpressionParseTree$EqualNode cannot be cast to org.apache.catalina.ssi.ExpressionParseTree$StringNode
	org.apache.catalina.ssi.ExpressionParseTree$CompareNode.compareBranches(ExpressionParseTree.java:353)
	org.apache.catalina.ssi.ExpressionParseTree$EqualNode.evaluate(ExpressionParseTree.java:381)
	org.apache.catalina.ssi.ExpressionParseTree.evaluateTree(ExpressionParseTree.java:67)
	org.apache.catalina.ssi.SSIConditional.evaluateArguments(SSIConditional.java:124)
	org.apache.catalina.ssi.SSIConditional.process(SSIConditional.java:50)
	org.apache.catalina.ssi.SSIProcessor.process(SSIProcessor.java:160)
	org.apache.catalina.ssi.SSIFilter.doFilter(SSIFilter.java:144)


This occurs whenever the regular expression does not contain any parenthesis.  

Attached war file contains foo.html, showing test cases 1 and 2, and bar.html, showing test case 1 and 3.

By the way, these regular expressions work as intended in Apache (httpd) 2.

See also feature request #53387.  (The back reference in this example is not what causes the exception.)
Comment 1 Mark Thomas 2013-07-01 20:08:30 UTC
Couple of issues here.

1. '=~' is perl RE syntax. That isn't what httpd uses in this case and Tomcat is aiming to emulate httpd. The expected syntax is '='

2. You'll need the enhancement from bug 53387 to be implemented before your test will work.

I'm therefore going to resolve this as a duplicate of 53387.

*** This bug has been marked as a duplicate of bug 53387 ***
Comment 2 David Reitter 2013-07-01 20:19:56 UTC
Created attachment 30515 [details]
Another variant without =~ and without $1
Comment 3 David Reitter 2013-07-01 20:23:21 UTC
Point 1: =~ is used in only one place in the test cases, and it is not what is causing this.  See text of my bug report. Attaching foo2.html to demonstrate.

Point 2: $1 is not what is causing this.  See text of my bug report.  Attaching foo2.html to demonstrate.

foo2.html brings up the same two errors without use of =~ or $1.

Sorry if my earlier test case contained these extra features.
Comment 4 Mark Thomas 2013-07-01 20:27:51 UTC
Re-opening to look at the new test cases.
Comment 5 Mark Thomas 2013-07-01 21:22:41 UTC
Found the root cause. '=' inside a regular expression was not handled correctly. There are also a bunch of other characters that would have triggered similar failures.

This has been fixed in trunk and 7.0.x and will be included in 7.0.42 onwards.

Thanks for the test cases. I used a simplified version to create a couple of unit tests.
Comment 6 David Reitter 2013-07-01 21:48:02 UTC
Nice, thank you.  That was certainly quick.