You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Konstantin Kolinko <kn...@gmail.com> on 2015/11/05 06:05:58 UTC
On escaping of EL in attributes (BZ 57136)
Hi!
I happened to stumble on the following entry in changelog for 6.0.19:
<fix>
Fix various edge-cases when parsing EL, particularly inside attribute
values. Note that the Expert Group has confirmed that JSP.1.6 takes
precedence over JSP.1.3.10. Therefore EL in attributes must be escaped
twice. (markt)
</fix>
Chapters mentioned here:
JSP.1.6 Quoting and Escape Conventions
JSP.1.3.10.1 EBNF Grammar for JSP Syntax
Related discussion:
"EL and TCK" on dev@, started 2008-09-18
http://tomcat.markmail.org/thread/2rq3vkvx76vmhq75
Related commits:
Tomcat 6:
http://svn.apache.org/viewvc?rev=708165&view=rev
http://svn.apache.org/viewvc?rev=708166&view=rev
Tomcat trunk:
http://svn.apache.org/viewvc?rev=702587&view=rev
So apparently the change in EL escaping in attributes that was done
while fixing BZ 57136 [1] has already been discussed and resolved in a
different way 7 years ago.
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=57136#c17
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: On escaping of EL in attributes (BZ 57136)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 11/6/15 7:32 AM, Mark Thomas wrote:
> On 06/11/2015 12:24, Christopher Schultz wrote:
>> On 11/6/15 7:12 AM, Mark Thomas wrote:
>
> <snip/>
>
>>> Things are sufficiently messy between the spec, the TCK, 'clarification'
>>> from Oracle and Tomcat's previous behaviour that I agree both forms need
>>> to be supported. The new quoteAttributeEL init param for the JSP servlet
>>> does exactly that.
>>
>> Perfect. I wasn't able to follow the various acrobatics that you
>> performed with the switches... it looks like you actually removed
>> options that would have supported this. What have I missed?
>
> The old STRICT_QUOTE_ESCAPING system property was converted to an init
> param for the JSP servlet with the system property defining the default
> for 8.0.x and trunk.
>
> I then removed the STRICT_QUOTE_ESCAPING system property entirely from
> trunk and deprecated it in 8.0.x. This was part of my general loathing
> of system properties for configuration that should be per Context/Host/etc.
>
> I then added the new JSP init param quoteAttributeEL to 8.0.x and trunk.
Great, thanks for clearing that up. It didn't click to me that you were
exchanging a system property (bad) for a configuration setting (good).
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: On escaping of EL in attributes (BZ 57136)
Posted by Mark Thomas <ma...@apache.org>.
On 06/11/2015 12:24, Christopher Schultz wrote:
> On 11/6/15 7:12 AM, Mark Thomas wrote:
<snip/>
>> Things are sufficiently messy between the spec, the TCK, 'clarification'
>> from Oracle and Tomcat's previous behaviour that I agree both forms need
>> to be supported. The new quoteAttributeEL init param for the JSP servlet
>> does exactly that.
>
> Perfect. I wasn't able to follow the various acrobatics that you
> performed with the switches... it looks like you actually removed
> options that would have supported this. What have I missed?
The old STRICT_QUOTE_ESCAPING system property was converted to an init
param for the JSP servlet with the system property defining the default
for 8.0.x and trunk.
I then removed the STRICT_QUOTE_ESCAPING system property entirely from
trunk and deprecated it in 8.0.x. This was part of my general loathing
of system properties for configuration that should be per Context/Host/etc.
I then added the new JSP init param quoteAttributeEL to 8.0.x and trunk.
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: On escaping of EL in attributes (BZ 57136)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 11/6/15 7:12 AM, Mark Thomas wrote:
> On 06/11/2015 11:47, Christopher Schultz wrote:
>> Mark,
>>
>> On 11/5/15 4:34 AM, Mark Thomas wrote:
>>> On 05/11/2015 08:48, Mark Thomas wrote:
>>>> On 05/11/2015 05:05, Konstantin Kolinko wrote:
>>>>> Hi!
>>>>>
>>>>> I happened to stumble on the following entry in changelog for 6.0.19:
>>>>>
>>>>> <fix>
>>>>> Fix various edge-cases when parsing EL, particularly inside attribute
>>>>> values. Note that the Expert Group has confirmed that JSP.1.6 takes
>>>>> precedence over JSP.1.3.10. Therefore EL in attributes must be escaped
>>>>> twice. (markt)
>>>>> </fix>
>>>>
>>>> Wow. I have absolutely no memory of that at all.
>>>>
>>>> Let me see if I can dig up the discussion that provided that confirmation.
>>>
>>> OK, found it. Having a precise date range to work with made it a lot
>>> easier. Apologies in advance as I have the feeling that this is e-mail
>>> is going to be on the long side.
>>>
>>> Back in 2009, I, acting on behalf of the Tomcat community, raised this
>>> via a challenge to the JSP 2.1 TCK using the following examples:
>>>
>>> <test:echo text="${"hello world"}" /> <-- The spec requires this
>>> <test:echo text="${\"hello world\"}" /> <-- The TCK expects this
>>>
>>> To put this in the current context, the fix for BZ 57136 implements the
>>> first form.
>>>
>>> Our TCK contact discussed it with the JSP lead and the conclusion was
>>> that the second form was the correct one. The reason given was that the
>>> second form is valid XML whereas the first form is not.
>>>
>>> I queried this on the grounds that the grammar is explicit that the
>>> second form is correct and that the spec also states that the grammar
>>> takes precedence.
>>>
>>> The response was that a request would be made to clarify the spec.
>>>
>>> No such clarification was made in JSP 2.2 or JSP 2.3.
>>>
>>> Which brings us to where we are today. The spec says one thing, I assume
>>> the TCK tests for something else (I don't have access to the later JSP
>>> TCK versions), we have a private clarification from 7 years ago that the
>>> spec is wrong and the two versions of the spec since then have not
>>> included any related correction.
>>>
>>> In the past we have used the following order of precedence when the
>>> specs have been unclear:
>>> - what the EG intended based on their discussions
>>> - what the TCK tests for
>>> - spec language
>>>
>>> However, this order has only been used where we required clarification
>>> rather than when there were inconsistencies. Also, more recently, I have
>>> seen the view expressed with the EGs that it doesn't matter what the EG
>>> discussed, the specification language always takes priority even if the
>>> language does not reflect what the EG intended.
>>>
>>> To summarise:
>>>
>>> In favour of form 1:
>>> - it is consistent with the spec
>>> - EGs have recently expressed the spec takes precedence
>>> - There have been two releases of the JSP spec since the issue was
>>> raised and the spec has not been updated
>>>
>>> In favour of form 2:
>>> - it is well-formed XML
>>> - it is what the TCK tested (tests?) for
>>> - the spec lead expressed the view this was the intended behaviour
>>> - Up until the BZ 57136 fix, Tomcat did it this way
>>
>> Neither of these are well-formed XML due to the presence of the embedded
>> quote characters in the attribute value. Or, are you talking about
>> attribute values *after* XML-un-escaping occurs (in which case they
>> would both be valid XML)? XML does not recognize the common \ character
>> as an escape.
>>
>> (This doesn't get us any closer to a decision, but it eliminates one of
>> the slight advantages to form 2.)
>
> Fair point. I was just repeating a response I got back from Oracle. I
> suspect the test case was slightly different.
I'm surprised Oracle claimed that was valid XML. :/
>>> At this point, I don't see a clear argument one way or the other.
>>>
>>> I've looked through the open JSP spec issues:
>>> https://java.net/jira/browse/JSP_SPEC_PUBLIC
>>>
>>> and I don't see anything for this. I do see a lot of very old issues
>>> that don't appear to have been looked at for some time.
>>>
>>> Given the lack of clarity of the which behaviour is correct, I think we
>>> have little choice but to make this optional and that we should get this
>>> done before the next 8.0.x release. I intend to start working on that in
>>> trunk today.
>>
>> Well, the TCK behavior simply must be implemented or we won't pass it.
>> Are we actually under any obligation to pass the TCK?
>
> No, because Oracle and the ASF have yet to agree a new license agreement
> for the TCK,
I just wasn't sure about whether we have to pass it in order to even
claim support for the various specs.
> If we did have the TCK we could challenge it again (on the grounds the
> spec was never updated so surely that must mean the spec is right and
> the TCK is wrong)
>
>> On the other hand, nobody ready the TCK... only the spec.
>
> Indeed.
Obviously, I meant "nobody READS", but it looks like you understood.
>> So most users will expect form 2.
>
> If they read the spec carefully enough (and to be fair it took me
> several days of reading and re-reading the relevant bits to get to the
> point I was happy that I understood what it meant) they should expect
> form 1.
I fat-fingered that. I'm typing without a left index finger this week,
and it's really interfering with my typing mojo.
>> So I guess we need to have a mode-switcher? It's
>> either that, or fail the TCK and/or anger some significant subset of users.
>
> Things are sufficiently messy between the spec, the TCK, 'clarification'
> from Oracle and Tomcat's previous behaviour that I agree both forms need
> to be supported. The new quoteAttributeEL init param for the JSP servlet
> does exactly that.
Perfect. I wasn't able to follow the various acrobatics that you
performed with the switches... it looks like you actually removed
options that would have supported this. What have I missed?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: On escaping of EL in attributes (BZ 57136)
Posted by Konstantin Kolinko <kn...@gmail.com>.
2015-11-09 17:35 GMT+03:00 Konstantin Kolinko <kn...@gmail.com>:
> 2015-11-06 15:12 GMT+03:00 Mark Thomas <ma...@apache.org>:
>> On 06/11/2015 11:47, Christopher Schultz wrote:
>>> On 11/5/15 4:34 AM, Mark Thomas wrote:
>>>> On 05/11/2015 08:48, Mark Thomas wrote:
>
> <...>
>
>>>> At this point, I don't see a clear argument one way or the other.
>>>>
>>>> I've looked through the open JSP spec issues:
>>>> https://java.net/jira/browse/JSP_SPEC_PUBLIC
>>>>
>>>> and I don't see anything for this. I do see a lot of very old issues
>>>> that don't appear to have been looked at for some time.
>>>>
>>>> Given the lack of clarity of the which behaviour is correct, I think we
>>>> have little choice but to make this optional and that we should get this
>>>> done before the next 8.0.x release. I intend to start working on that in
>>>> trunk today.
>>>
>
> <...>
>
>> If we did have the TCK we could challenge it again (on the grounds the
>> spec was never updated so surely that must mean the spec is right and
>> the TCK is wrong)
>>
>>> On the other hand, nobody ready the TCK... only the spec.
>>
>> Indeed.
>>
>>> So most users will expect form 2.
>>
>> If they read the spec carefully enough (and to be fair it took me
>> several days of reading and re-reading the relevant bits to get to the
>> point I was happy that I understood what it meant) they should expect
>> form 1.
>>
>
>
> If I were in the footwear of somebody who implements a web application
> that has to run on all web containers implementing the specification,
> my position will be:
>
> All I would care is that all web containers implement this part of
> specification in the same way. In this case I can "write once, run
> everywhere", which is usually expected of Java.
>
> If this is enforced not through the text of the document, but through
> the TCK, it is a pity (and a shame on spec leader), but it solves my
> problem.
>
>
> It is unlikely that some test were removed from TCK unless spec leader
> officially allows undefined behaviour across different
> implementations. As such, testing this example in an alternate
> implementation (e.g. RI) will make a guess on what behaviour is
> expected here. (Maybe somebody on users list would like to do
> testing).
>
>
> That aside,
> as I mention in BZ 57136, form 2 (double escaping) provides better
> historical compatibility with pre-EL use of tag libraries (JSTL 1.0 /
> JSP 1.2 version of EL).
>
> form 1 (single escaping) is easier to read and write and provides
> uniformity across using EL in template text and EL in tags.
>
>
> Syntax hiliting in Eclipse IDE (4.4.2 Luna SR2) breaks at current
> /tomcat-7.0.x/test/webapp-3.0/el-method.jsp (form 1). I have not yet
> upgraded to current Mars 4.5[.1] to test it there.
I attached sample web application to the issue,
https://bz.apache.org/bugzilla/show_bug.cgi?id=57136#c31
Testing with Glassfish 4.1.1, it also expects double escaping.
I am not a user of Glassfish, so I do not know yet what configuration
options are there if this feature is configurable.
===
My steps:
1. Follow https://glassfish.java.net/download.html and download
glassfish-4.1.1-web.zip
2. After unzipping GF, copy test.war into
glassfish4/glassfish/domains/domain1/autodeploy/
3. Start it
cd glassfish4/bin
asadmin start-domain
4. Open the page in browser
http://localhost:8080/test/
Page with double escaped variant works.
Page with no double escaping fails:
org.apache.jasper.JasperException: /test1.jsp(27,66) PWC6031:
Unterminated <c:if tag
(GRRR: It is not Apache Jasper. They were lazy to rename the package
and are abusing the trademarks...)
5. Stop it
cd glassfish4/bin
asadmin stop-domain
===
As such, I think the default value of "quoteAttributeEL" option in
Jasper shall be changed to "true". The same in JspC, where it would
need a "-no-quoteAttributeEL" command line option.
BTW, jasper-howto.xml already documents that the default is true,
which does not match the code.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: On escaping of EL in attributes (BZ 57136)
Posted by Konstantin Kolinko <kn...@gmail.com>.
2015-11-06 15:12 GMT+03:00 Mark Thomas <ma...@apache.org>:
> On 06/11/2015 11:47, Christopher Schultz wrote:
>> On 11/5/15 4:34 AM, Mark Thomas wrote:
>>> On 05/11/2015 08:48, Mark Thomas wrote:
<...>
>>> At this point, I don't see a clear argument one way or the other.
>>>
>>> I've looked through the open JSP spec issues:
>>> https://java.net/jira/browse/JSP_SPEC_PUBLIC
>>>
>>> and I don't see anything for this. I do see a lot of very old issues
>>> that don't appear to have been looked at for some time.
>>>
>>> Given the lack of clarity of the which behaviour is correct, I think we
>>> have little choice but to make this optional and that we should get this
>>> done before the next 8.0.x release. I intend to start working on that in
>>> trunk today.
>>
<...>
> If we did have the TCK we could challenge it again (on the grounds the
> spec was never updated so surely that must mean the spec is right and
> the TCK is wrong)
>
>> On the other hand, nobody ready the TCK... only the spec.
>
> Indeed.
>
>> So most users will expect form 2.
>
> If they read the spec carefully enough (and to be fair it took me
> several days of reading and re-reading the relevant bits to get to the
> point I was happy that I understood what it meant) they should expect
> form 1.
>
If I were in the footwear of somebody who implements a web application
that has to run on all web containers implementing the specification,
my position will be:
All I would care is that all web containers implement this part of
specification in the same way. In this case I can "write once, run
everywhere", which is usually expected of Java.
If this is enforced not through the text of the document, but through
the TCK, it is a pity (and a shame on spec leader), but it solves my
problem.
It is unlikely that some test were removed from TCK unless spec leader
officially allows undefined behaviour across different
implementations. As such, testing this example in an alternate
implementation (e.g. RI) will make a guess on what behaviour is
expected here. (Maybe somebody on users list would like to do
testing).
That aside,
as I mention in BZ 57136, form 2 (double escaping) provides better
historical compatibility with pre-EL use of tag libraries (JSTL 1.0 /
JSP 1.2 version of EL).
form 1 (single escaping) is easier to read and write and provides
uniformity across using EL in template text and EL in tags.
Syntax hiliting in Eclipse IDE (4.4.2 Luna SR2) breaks at current
/tomcat-7.0.x/test/webapp-3.0/el-method.jsp (form 1). I have not yet
upgraded to current Mars 4.5[.1] to test it there.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: On escaping of EL in attributes (BZ 57136)
Posted by Mark Thomas <ma...@apache.org>.
On 06/11/2015 11:47, Christopher Schultz wrote:
> Mark,
>
> On 11/5/15 4:34 AM, Mark Thomas wrote:
>> On 05/11/2015 08:48, Mark Thomas wrote:
>>> On 05/11/2015 05:05, Konstantin Kolinko wrote:
>>>> Hi!
>>>>
>>>> I happened to stumble on the following entry in changelog for 6.0.19:
>>>>
>>>> <fix>
>>>> Fix various edge-cases when parsing EL, particularly inside attribute
>>>> values. Note that the Expert Group has confirmed that JSP.1.6 takes
>>>> precedence over JSP.1.3.10. Therefore EL in attributes must be escaped
>>>> twice. (markt)
>>>> </fix>
>>>
>>> Wow. I have absolutely no memory of that at all.
>>>
>>> Let me see if I can dig up the discussion that provided that confirmation.
>>
>> OK, found it. Having a precise date range to work with made it a lot
>> easier. Apologies in advance as I have the feeling that this is e-mail
>> is going to be on the long side.
>>
>> Back in 2009, I, acting on behalf of the Tomcat community, raised this
>> via a challenge to the JSP 2.1 TCK using the following examples:
>>
>> <test:echo text="${"hello world"}" /> <-- The spec requires this
>> <test:echo text="${\"hello world\"}" /> <-- The TCK expects this
>>
>> To put this in the current context, the fix for BZ 57136 implements the
>> first form.
>>
>> Our TCK contact discussed it with the JSP lead and the conclusion was
>> that the second form was the correct one. The reason given was that the
>> second form is valid XML whereas the first form is not.
>>
>> I queried this on the grounds that the grammar is explicit that the
>> second form is correct and that the spec also states that the grammar
>> takes precedence.
>>
>> The response was that a request would be made to clarify the spec.
>>
>> No such clarification was made in JSP 2.2 or JSP 2.3.
>>
>> Which brings us to where we are today. The spec says one thing, I assume
>> the TCK tests for something else (I don't have access to the later JSP
>> TCK versions), we have a private clarification from 7 years ago that the
>> spec is wrong and the two versions of the spec since then have not
>> included any related correction.
>>
>> In the past we have used the following order of precedence when the
>> specs have been unclear:
>> - what the EG intended based on their discussions
>> - what the TCK tests for
>> - spec language
>>
>> However, this order has only been used where we required clarification
>> rather than when there were inconsistencies. Also, more recently, I have
>> seen the view expressed with the EGs that it doesn't matter what the EG
>> discussed, the specification language always takes priority even if the
>> language does not reflect what the EG intended.
>>
>> To summarise:
>>
>> In favour of form 1:
>> - it is consistent with the spec
>> - EGs have recently expressed the spec takes precedence
>> - There have been two releases of the JSP spec since the issue was
>> raised and the spec has not been updated
>>
>> In favour of form 2:
>> - it is well-formed XML
>> - it is what the TCK tested (tests?) for
>> - the spec lead expressed the view this was the intended behaviour
>> - Up until the BZ 57136 fix, Tomcat did it this way
>
> Neither of these are well-formed XML due to the presence of the embedded
> quote characters in the attribute value. Or, are you talking about
> attribute values *after* XML-un-escaping occurs (in which case they
> would both be valid XML)? XML does not recognize the common \ character
> as an escape.
>
> (This doesn't get us any closer to a decision, but it eliminates one of
> the slight advantages to form 2.)
Fair point. I was just repeating a response I got back from Oracle. I
suspect the test case was slightly different.
>> At this point, I don't see a clear argument one way or the other.
>>
>> I've looked through the open JSP spec issues:
>> https://java.net/jira/browse/JSP_SPEC_PUBLIC
>>
>> and I don't see anything for this. I do see a lot of very old issues
>> that don't appear to have been looked at for some time.
>>
>> Given the lack of clarity of the which behaviour is correct, I think we
>> have little choice but to make this optional and that we should get this
>> done before the next 8.0.x release. I intend to start working on that in
>> trunk today.
>
> Well, the TCK behavior simply must be implemented or we won't pass it.
> Are we actually under any obligation to pass the TCK?
No, because Oracle and the ASF have yet to agree a new license agreement
for the TCK,
If we did have the TCK we could challenge it again (on the grounds the
spec was never updated so surely that must mean the spec is right and
the TCK is wrong)
> On the other hand, nobody ready the TCK... only the spec.
Indeed.
> So most users will expect form 2.
If they read the spec carefully enough (and to be fair it took me
several days of reading and re-reading the relevant bits to get to the
point I was happy that I understood what it meant) they should expect
form 1.
> So I guess we need to have a mode-switcher? It's
> either that, or fail the TCK and/or anger some significant subset of users.
Things are sufficiently messy between the spec, the TCK, 'clarification'
from Oracle and Tomcat's previous behaviour that I agree both forms need
to be supported. The new quoteAttributeEL init param for the JSP servlet
does exactly that.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: On escaping of EL in attributes (BZ 57136)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 11/5/15 4:34 AM, Mark Thomas wrote:
> On 05/11/2015 08:48, Mark Thomas wrote:
>> On 05/11/2015 05:05, Konstantin Kolinko wrote:
>>> Hi!
>>>
>>> I happened to stumble on the following entry in changelog for 6.0.19:
>>>
>>> <fix>
>>> Fix various edge-cases when parsing EL, particularly inside attribute
>>> values. Note that the Expert Group has confirmed that JSP.1.6 takes
>>> precedence over JSP.1.3.10. Therefore EL in attributes must be escaped
>>> twice. (markt)
>>> </fix>
>>
>> Wow. I have absolutely no memory of that at all.
>>
>> Let me see if I can dig up the discussion that provided that confirmation.
>
> OK, found it. Having a precise date range to work with made it a lot
> easier. Apologies in advance as I have the feeling that this is e-mail
> is going to be on the long side.
>
> Back in 2009, I, acting on behalf of the Tomcat community, raised this
> via a challenge to the JSP 2.1 TCK using the following examples:
>
> <test:echo text="${"hello world"}" /> <-- The spec requires this
> <test:echo text="${\"hello world\"}" /> <-- The TCK expects this
>
> To put this in the current context, the fix for BZ 57136 implements the
> first form.
>
> Our TCK contact discussed it with the JSP lead and the conclusion was
> that the second form was the correct one. The reason given was that the
> second form is valid XML whereas the first form is not.
>
> I queried this on the grounds that the grammar is explicit that the
> second form is correct and that the spec also states that the grammar
> takes precedence.
>
> The response was that a request would be made to clarify the spec.
>
> No such clarification was made in JSP 2.2 or JSP 2.3.
>
> Which brings us to where we are today. The spec says one thing, I assume
> the TCK tests for something else (I don't have access to the later JSP
> TCK versions), we have a private clarification from 7 years ago that the
> spec is wrong and the two versions of the spec since then have not
> included any related correction.
>
> In the past we have used the following order of precedence when the
> specs have been unclear:
> - what the EG intended based on their discussions
> - what the TCK tests for
> - spec language
>
> However, this order has only been used where we required clarification
> rather than when there were inconsistencies. Also, more recently, I have
> seen the view expressed with the EGs that it doesn't matter what the EG
> discussed, the specification language always takes priority even if the
> language does not reflect what the EG intended.
>
> To summarise:
>
> In favour of form 1:
> - it is consistent with the spec
> - EGs have recently expressed the spec takes precedence
> - There have been two releases of the JSP spec since the issue was
> raised and the spec has not been updated
>
> In favour of form 2:
> - it is well-formed XML
> - it is what the TCK tested (tests?) for
> - the spec lead expressed the view this was the intended behaviour
> - Up until the BZ 57136 fix, Tomcat did it this way
Neither of these are well-formed XML due to the presence of the embedded
quote characters in the attribute value. Or, are you talking about
attribute values *after* XML-un-escaping occurs (in which case they
would both be valid XML)? XML does not recognize the common \ character
as an escape.
(This doesn't get us any closer to a decision, but it eliminates one of
the slight advantages to form 2.)
> At this point, I don't see a clear argument one way or the other.
>
> I've looked through the open JSP spec issues:
> https://java.net/jira/browse/JSP_SPEC_PUBLIC
>
> and I don't see anything for this. I do see a lot of very old issues
> that don't appear to have been looked at for some time.
>
> Given the lack of clarity of the which behaviour is correct, I think we
> have little choice but to make this optional and that we should get this
> done before the next 8.0.x release. I intend to start working on that in
> trunk today.
Well, the TCK behavior simply must be implemented or we won't pass it.
Are we actually under any obligation to pass the TCK?
On the other hand, nobody ready the TCK... only the spec. So most users
will expect form 2. So I guess we need to have a mode-switcher? It's
either that, or fail the TCK and/or anger some significant subset of users.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: On escaping of EL in attributes (BZ 57136)
Posted by Mark Thomas <ma...@apache.org>.
On 05/11/2015 08:48, Mark Thomas wrote:
> On 05/11/2015 05:05, Konstantin Kolinko wrote:
>> Hi!
>>
>> I happened to stumble on the following entry in changelog for 6.0.19:
>>
>> <fix>
>> Fix various edge-cases when parsing EL, particularly inside attribute
>> values. Note that the Expert Group has confirmed that JSP.1.6 takes
>> precedence over JSP.1.3.10. Therefore EL in attributes must be escaped
>> twice. (markt)
>> </fix>
>
> Wow. I have absolutely no memory of that at all.
>
> Let me see if I can dig up the discussion that provided that confirmation.
OK, found it. Having a precise date range to work with made it a lot
easier. Apologies in advance as I have the feeling that this is e-mail
is going to be on the long side.
Back in 2009, I, acting on behalf of the Tomcat community, raised this
via a challenge to the JSP 2.1 TCK using the following examples:
<test:echo text="${"hello world"}" /> <-- The spec requires this
<test:echo text="${\"hello world\"}" /> <-- The TCK expects this
To put this in the current context, the fix for BZ 57136 implements the
first form.
Our TCK contact discussed it with the JSP lead and the conclusion was
that the second form was the correct one. The reason given was that the
second form is valid XML whereas the first form is not.
I queried this on the grounds that the grammar is explicit that the
second form is correct and that the spec also states that the grammar
takes precedence.
The response was that a request would be made to clarify the spec.
No such clarification was made in JSP 2.2 or JSP 2.3.
Which brings us to where we are today. The spec says one thing, I assume
the TCK tests for something else (I don't have access to the later JSP
TCK versions), we have a private clarification from 7 years ago that the
spec is wrong and the two versions of the spec since then have not
included any related correction.
In the past we have used the following order of precedence when the
specs have been unclear:
- what the EG intended based on their discussions
- what the TCK tests for
- spec language
However, this order has only been used where we required clarification
rather than when there were inconsistencies. Also, more recently, I have
seen the view expressed with the EGs that it doesn't matter what the EG
discussed, the specification language always takes priority even if the
language does not reflect what the EG intended.
To summarise:
In favour of form 1:
- it is consistent with the spec
- EGs have recently expressed the spec takes precedence
- There have been two releases of the JSP spec since the issue was
raised and the spec has not been updated
In favour of form 2:
- it is well-formed XML
- it is what the TCK tested (tests?) for
- the spec lead expressed the view this was the intended behaviour
- Up until the BZ 57136 fix, Tomcat did it this way
At this point, I don't see a clear argument one way or the other.
I've looked through the open JSP spec issues:
https://java.net/jira/browse/JSP_SPEC_PUBLIC
and I don't see anything for this. I do see a lot of very old issues
that don't appear to have been looked at for some time.
Given the lack of clarity of the which behaviour is correct, I think we
have little choice but to make this optional and that we should get this
done before the next 8.0.x release. I intend to start working on that in
trunk today.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: On escaping of EL in attributes (BZ 57136)
Posted by Mark Thomas <ma...@apache.org>.
On 05/11/2015 05:05, Konstantin Kolinko wrote:
> Hi!
>
> I happened to stumble on the following entry in changelog for 6.0.19:
>
> <fix>
> Fix various edge-cases when parsing EL, particularly inside attribute
> values. Note that the Expert Group has confirmed that JSP.1.6 takes
> precedence over JSP.1.3.10. Therefore EL in attributes must be escaped
> twice. (markt)
> </fix>
Wow. I have absolutely no memory of that at all.
Let me see if I can dig up the discussion that provided that confirmation.
Mark
>
> Chapters mentioned here:
> JSP.1.6 Quoting and Escape Conventions
> JSP.1.3.10.1 EBNF Grammar for JSP Syntax
>
> Related discussion:
> "EL and TCK" on dev@, started 2008-09-18
> http://tomcat.markmail.org/thread/2rq3vkvx76vmhq75
>
> Related commits:
> Tomcat 6:
> http://svn.apache.org/viewvc?rev=708165&view=rev
> http://svn.apache.org/viewvc?rev=708166&view=rev
> Tomcat trunk:
> http://svn.apache.org/viewvc?rev=702587&view=rev
>
> So apparently the change in EL escaping in attributes that was done
> while fixing BZ 57136 [1] has already been discussed and resolved in a
> different way 7 years ago.
>
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=57136#c17
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org