Bug 56334 - Double Backslash Escaping in Attributes
Summary: Double Backslash Escaping in Attributes
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Jasper (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 56731 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-04-01 08:58 UTC by Markus
Modified: 2014-09-30 13:13 UTC (History)
1 user (show)



Attachments
WAR file to reproduce exception (360.69 KB, application/octet-stream)
2014-04-01 08:58 UTC, Markus
Details
2014-04-28_tc8_XmlEscapeNonELVisitor_tests.patch (3.00 KB, patch)
2014-04-28 19:19 UTC, Konstantin Kolinko
Details | Diff
test_56334_c15.jspx (517 bytes, text/plain)
2014-06-17 13:43 UTC, Konstantin Kolinko
Details
2014-06-17_tc8_56334_c15_v1.patch (3.80 KB, patch)
2014-06-18 11:16 UTC, Konstantin Kolinko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Markus 2014-04-01 08:58:31 UTC
Created attachment 31462 [details]
WAR file to reproduce exception

EL expressions in jspx-files are Java-String-backslash-decoded twice when they're part of static template text. They're even decoded twice when they're part of certain JSP-Tag attributes, but they're only decoded once during processing when part of a JSTL tag attribute:

<!-- Works as expected yielding \?resize as value of asd -->
<c:set var="asd" value="${'\\?resize'}" />

<!-- Won't work, but should -->
<set data-value="${'\\?resize'}" />

<!-- dito -->
<jsp:element name="${'\\?resize'}"></jsp:element>

<!-- Works, but yields actually invalid results -->
<set data-value="${'\\\\?resize'}" />

During JSP compiling the following exception is thrown (taken from Tomcat log):

Apr 01, 2014 10:51:31 AM org.apache.catalina.core.StandardWrapperValve invoke
Schwerwiegend: Servlet.service() for servlet [jsp] in context with path [/tomcat_test] threw exception [/index.jspx (line: 12, column: 37) "${'\\?resize'}" contains invalid expression(s): javax.el.ELException: Failed to parse the expression [${'\?resize'}]] with root cause
org.apache.jasper.JasperException: /index.jspx (line: 12, column: 37) "${'\\?resize'}" contains invalid expression(s): javax.el.ELException: Failed to parse the expression [${'\?resize'}]
	at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)
	at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:443)
	at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:199)
	at org.apache.jasper.compiler.Validator$ValidateVisitor.getJspAttribute(Validator.java:1399)
	at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:772)
	at org.apache.jasper.compiler.Node$UninterpretedTag.accept(Node.java:1251)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2427)
	at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:529)
	at org.apache.jasper.compiler.Node$JspRoot.accept(Node.java:564)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2427)
	at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2433)
	at org.apache.jasper.compiler.Node$Root.accept(Node.java:474)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
	at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1817)
	at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:217)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:373)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) [...]

As you can see the \\ get processed to \ between the output of the line information and the actual EL parsing.

In tomcat 7.0.27 the above examples work and produce the correct output.
Comment 1 Markus 2014-04-03 07:40:33 UTC
Tomcat 7.0.53 still throws an Exception, but now the \\-decoding seems to be performed in an earlier step (as you can see the double-\ has already been decoded in the first part of the exception message):

ervlet.service() for servlet [jsp] in context with path [/tomcat_test] threw exception [/index.jspx (line: 15, column: 37) "${'\?resize'}" contains invalid expression(s): javax.el.ELException: Failed to parse the expression [${'\?resize'}]] with root cause
org.apache.jasper.JasperException: /index.jspx (line: 15, column: 37) "${'\?resize'}" contains invalid expression(s): javax.el.ELException: Failed to parse the expression [${'\?resize'}]
	at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)
	at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:443)
	at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:199)
	at org.apache.jasper.compiler.Validator$ValidateVisitor.getJspAttribute(Validator.java:1411)
	at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:772)
	at org.apache.jasper.compiler.Node$UninterpretedTag.accept(Node.java:1251) [...]
Comment 2 Markus 2014-04-04 11:04:42 UTC
A binary search through recent 7.0.x Tomcat versions shows that this bug has been introduced with 7.0.52, i.e. 7.0.50 shows correct behaviour while .52 is broken.
Comment 3 Markus 2014-04-04 11:20:46 UTC
(In reply to Markus from comment #2)
> A binary search through recent 7.0.x Tomcat versions shows that this bug has
> been introduced with 7.0.52, i.e. 7.0.50 shows correct behaviour while .52
> is broken.

Off-by-one: 47 works, 50 is broken. Sorry.
Comment 4 Mark Thomas 2014-04-12 20:23:15 UTC
This has been fixed in 8.0.x for 8.0.6 onwards.

This has been fixed in 7.0.x for 7.0.54 onwards.

The fix has been proposed for 6.0.x.
Comment 5 Mark Thomas 2014-04-15 18:55:06 UTC
I'm looking at this again and I am not sure that all of the examples given in the original description are correct.

There are multiple factors at play here as the JSP spec has one rule for escaping and the EL spec has very different rules. I need to think carefully about exactly which spec applies at which point.

The short version is that there is going to be a further commit for this issue and the end result might not be exactly what you are expecting.
Comment 6 Markus 2014-04-16 08:19:23 UTC
The question is whether EL should be processed as-is or inside some "context". I always thought (and till 7.0.47 it seems to be the case) that EL parsing is "context free", regardless whether the expression is in

<c:set value="${'\\?'}" ... />

or in

<set attribute="${'\\?'}" />

("context free" not meaning Chomsky Hierarchy Context Free btw. but "without regarding the context outside the EL expression" ;)

I skimmed through the JSP 2.2 spec and while \ in JSP documents are indeed treated specially I'd say this only applies to \ *outside* of EL expressions.

Especially when reading section JSP.10.1.11:

"For each escaped \ preceeding an unescaped expression ${foo}, a ${'\\'} must be
generated in the XML view, and neighboring generated ${'\\'} expressions must
be combined"


I think this implies "treat \ inside EL the same way regardless of position" ("context free" in the notion above), because otherwise the spec would have to read something like "convert \ to ${'\\'} in case A and to ${'\\\\'} in case B".


In "The Java EE 6 Tutorial, Volume I" Chapter 6 section "Referring to Object Properties Using Value Expressions" http://docs.oracle.com/cd/E19226-01/820-7627/gjddd/#6nisfjmda the following literals are defined for EL (amongst others):

"String: with single and double quotes; " is escaped as \", ' is escaped as \', and \ is escaped as \\"


So the EL specification defines the escaping literals *inside* EL expressions and the JSP specification defines processing rules of \ *outside* EL expressions, and \ inside EL should not be pre-processed by some JSP specific logic. (I could be wrong, but that's how I'd sitck together those different pieces...)
Comment 7 Mark Thomas 2014-04-16 11:17:25 UTC
I think I agree with you completely.

I have just applied an additional commit to 8.0.x to handle the different escaping required inside and outside EL expressions. If you are able to test against a build of the latest 8.0.x that would be great.

I have a few things I need to clean up before I back-port it but that should happen later today.
Comment 8 Konstantin Kolinko 2014-04-16 11:22:42 UTC
(In reply to Markus from comment #0)
> 
> <!-- dito -->
> <jsp:element name="${'\\?resize'}"></jsp:element>
> 

For a record, the above example makes no sense to me, as you should not generate XML tags with such names.

[40]   	STag	   ::=   	'<' Name (S Attribute)* S? '>'

[5]   	Name	   ::=   	NameStartChar (NameChar)*

4]   	NameStartChar	   ::=   	":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]

[4a]   	NameChar	   ::=   	NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]

per http://www.w3.org/TR/REC-xml/
Comment 9 Markus 2014-04-16 11:25:41 UTC
(In reply to Konstantin Kolinko from comment #8)
> (In reply to Markus from comment #0)
> > 
> > <!-- dito -->
> > <jsp:element name="${'\\?resize'}"></jsp:element>
> > 
> 
> For a record, the above example makes no sense to me, as you should not
> generate XML tags with such names.

Yes, that's true - however it should not produce an exception during runtime either - the produced markup might be invalid, but the (process of) producing is not.
Comment 10 Mark Thomas 2014-04-24 08:38:19 UTC
This has been fixed in 6.0.x for 6.0.40 onwards.
Comment 11 Konstantin Kolinko 2014-04-28 19:19:25 UTC
Created attachment 31566 [details]
2014-04-28_tc8_XmlEscapeNonELVisitor_tests.patch

Additional tests and fix for Validator$ValidateVisitor$XmlEscapeNonELVisitor.

Without this fix the patched bug56334.jspx fails at run time:
[[[
org.apache.jasper.JasperException: /bug56334.jspx (line: 34, column: 45) "05b$${&amp;${1+1}" contains invalid expression(s): javax.el.ELException: Failed to parse the expression [05b$${&amp;${1+1}]
]]]

With this fix Java fails to compile the generated java file.
bug56334_jspx.java contains:
[[[
      out.write("<set data-value=\"05a\$\${&amp;\"/>");
      out.write("<set data-value=\"" + (java.lang.String) org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("05b\\$\\${&amp;${1+1}", java.lang.String.class, (javax.servlet.jsp.PageContext)_jspx_page_context, null) + "\"/>");
      out.write("<set data-value=\"" + (java.lang.String) org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("05c\\#\\#{&gt;${'hello'}&lt;", java.lang.String.class, (javax.servlet.jsp.PageContext)_jspx_page_context, null) + "\"/>");
]]]

In 05a the Java escaping is missing.
In 05b and 05c the Java escaping is OK.

Something else is missing.
Comment 12 Konstantin Kolinko 2014-04-28 19:30:54 UTC
(In reply to Konstantin Kolinko from comment #11)

2) With fix in Comment 11 it also breaks TestParser.testBug55198() test case.

It now generates HTML that contains (see bug55198.tagx)
onclick="window.alert(&#034;2bar2&lt;&amp;&gt;&#034;)"
onclick="window.alert(&\#034;3a&amp;b3&\#034;)"

Note the '\#'.
Comment 13 Konstantin Kolinko 2014-05-11 18:00:10 UTC
(In reply to Konstantin Kolinko from comment #12)

The additional issues have been fixed in Tomcat 7 and 8 and proposed for Tomcat 6.
The fixes will be in 7.0.54, 8.0.6.
Comment 14 Konstantin Kolinko 2014-05-11 19:54:46 UTC
Fixed in Tomcat 6. The fix will be in 6.0.40 onwards.
Comment 15 Markus 2014-06-17 13:24:39 UTC
While some \\ in EL-strings work now, some others are still broken (in 7.0.54).

For example, the following fragment works now:

<set data-value="${'\\?resize'}" />

This also works:

<set data-content="${fn:escapeXml('\\?resize=.+')}" />

But this throws an Exception during JSP compiling:

<set data-content="${fn:contains(some_value, '\\?resize=.+')}" />

Full stack trace:

org.apache.jasper.JasperException: /page.jspx (line: 14, column: 68) "${fn:contains(some_value, '\\?resize=.+')}" contains invalid expression(s): javax.el.ELException: Failed to parse the expression [${fn:contains(some_value, '\\?resize=.+')}]
	at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:443) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:199) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Validator$ValidateVisitor.getJspAttribute(Validator.java:1420) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:772) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$UninterpretedTag.accept(Node.java:1251) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2429) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:895) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1538) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2429) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:529) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$JspRoot.accept(Node.java:564) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2429) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2435) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$Root.accept(Node.java:474) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1841) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:217) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:353) ~[jasper.jar:7.0.54]
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) ~[jasper.jar:7.0.54]
	at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:657) ~[jasper.jar:7.0.54]
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) ~[jasper.jar:7.0.54]
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) ~[jasper.jar:7.0.54]
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) ~[jasper.jar:7.0.54]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) ~[servlet-api.jar:na]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) [catalina.jar:7.0.54]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [catalina.jar:7.0.54]
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748) ~[catalina.jar:7.0.54]
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:604) ~[catalina.jar:7.0.54]
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:543) ~[catalina.jar:7.0.54]
	at a.b.c.d.webdav.Request.include(Request.java:206) ~[na:3.6.235]
	at a.b.c.d.e.render.RenderingFile.generate(RenderingFile.java:494) ~[na:3.6.235]
	at a.b.c.d.e.render.RenderingFile.getContent(RenderingFile.java:139) ~[na:3.6.235]
	at a.b.c.d.e.render.RenderingFile.getContent(RenderingFile.java:103) ~[na:3.6.235]
	at a.b.c.d.file.FileWrapper.getContent(FileWrapper.java:173) ~[na:3.6.235]
	at a.b.c.d.file.FileWrapper.getContent(FileWrapper.java:173) ~[na:3.6.235]
	at a.b.c.d.file.FileWrapper.getContent(FileWrapper.java:173) ~[na:3.6.235]
	at a.b.c.d.webdav.method.GET.run(GET.java:152) ~[na:3.6.235]
	at a.b.c.d.webdav.method.AbstractMethodHandler.handleRequest(AbstractMethodHandler.java:52) ~[na:3.6.235]
	at a.b.c.d.engine.Manager.handleRequest(Manager.java:361) [na:3.6.235]
	at a.b.c.d.engine.Manager.doFilter(Manager.java:283) [na:3.6.235]
	at a.b.d.w.i.ManagerWrapper.doFilter(ManagerWrapper.java:64) [ManagerWrapper.class:na]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [catalina.jar:7.0.54]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [catalina.jar:7.0.54]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) [catalina.jar:7.0.54]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) [catalina.jar:7.0.54]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) [catalina.jar:7.0.54]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [catalina.jar:7.0.54]
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) [catalina.jar:7.0.54]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) [catalina.jar:7.0.54]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) [catalina.jar:7.0.54]
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) [tomcat-coyote.jar:7.0.54]
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) [tomcat-coyote.jar:7.0.54]
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314) [tomcat-coyote.jar:7.0.54]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [na:1.7.0_03]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [na:1.7.0_03]
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-coyote.jar:7.0.54]
	at java.lang.Thread.run(Thread.java:722) [na:1.7.0_03]

The really funny part here is that in Eclipse's Console view I am unable to copy+paste the Exception message (Eclipse Kepler, Win7), the copied area always stops right after the comma in "fn:contains(some_value,", so it looks like there's something weird going on. There seem to be two blanks at that location in console view at this location.

Analyzing this further proves that when this Exception is constructed (DefaultErrorHandler.java line 43), the string errMsg passed to this method contains a NUL-char (\u0000) at index 26 (right after the comma):

errMsg.getBytes() ->
    (byte[]) [34, 36, 123, 102, 110, 58, 99, 111, 110, 116, 97, 105, 110, 115, 40, 115, 111, 109, 101, 95, 118, 97, 108, 117, 101, 44, 0, 32, 39, 92, 92, 63, ...

This NUL is taken from the ELException that is catched and rethrown in Validator.java line 1420.

This Exception is thrown in ExpressionBuilder.java line 145, and the Exception details there are interesting: the EL parser fails at the NUL char in expr, and the Exception message there is:
org.apache.el.parser.ParseException: Encountered " <ILLEGAL_CHARACTER> " "" at line 1, column 26.
Was expecting one of:
    <INTEGER_LITERAL> ...

This NUL char ist NOT in 'value' in Validator$ValidateVisitor.visit() (Validator.java line 773), this means that it is added inside getJspAttribute(). Stepping through the code shows that this happens around line 1403 of the same file:
XmlEscapeNonELVisitor v = new XmlEscapeNonELVisitor(

pageInfo.isDeferredSyntaxAllowedAsLiteral());
el.visit(v);
value = v.getText();

So basically something inside XmlEscapeNonELVisitor is causing this error. And I think this happens in ELParser.java, 'quote' is initialized to 0 (the string literal starts with a blank, not with the ' in my example expression - it is not trimmed), and this char 0 is appended to 'output' in line 320.

Regards
Markus
Comment 16 Konstantin Kolinko 2014-06-17 13:43:27 UTC
Created attachment 31721 [details]
test_56334_c15.jspx

I have not dug into the NUL character issue yet.
A quick testing shows that the issue is reproducible with the current 7.0.x (@1603024).

I am attaching the JSP that I used to reproduce the issue from Comment 15.
Steps to reproduce:
1. Put test_56334_c15.jspx into /webapps/examples/
2. Go to http://localhost:8080/examples/test_56334_c15.jspx
3. Actual behaviour: Compilation failure, as reported in Comment 15.
Expected behaviour: Render the page.
Comment 17 Konstantin Kolinko 2014-06-18 09:56:12 UTC
(In reply to Markus from comment #15)
> But this throws an Exception during JSP compiling:
> 
> <set data-content="${fn:contains(some_value, '\\?resize=.+')}" />
> 

If I remove whitespace after ",", it works successfully. The following works:
<set data-content="${fn:contains(some_value,'\\?resize=.+')}" />
Comment 18 Markus 2014-06-18 10:10:28 UTC
Yes, I thought so after digging through the source code, but could not test this yesterday. Basically the quote character detection fails because teh first character ' ' is not recognized as one, leading quote being initalized to (char) 0; this is later on added to the resulting String.
Comment 19 Konstantin Kolinko 2014-06-18 11:16:22 UTC
Created attachment 31724 [details]
2014-06-17_tc8_56334_c15_v1.patch

v1 of patch for Comment 15, including test cases

The test case "07g" fails, it is commented out.

When there is a quoted string, a token for it is created by ELParser as

  return new QuotedString(getAndResetWhiteSpace(), buf.toString());

It is later converted into ELText object
ELexpr.add(new ELNode.ELText(curToken.toString()));

The leading whitespace in ELText messes up quotes detection in ELParser.escapeELText().
The test "07g" checks whether single quotes in the value are re-escaped correctly.
Comment 20 Mark Thomas 2014-06-18 21:04:29 UTC
#15 fixed in trunk for 8.0.9 and in 7.0.x for 7.0.55 and proposed for 6.0.x.
Comment 21 Konstantin Kolinko 2014-07-17 11:17:30 UTC
*** Bug 56731 has been marked as a duplicate of this bug. ***
Comment 22 Mark Thomas 2014-09-30 13:13:47 UTC
This has been fixed in 6.0.x for 6.0.42 onwards.