Bug 57105

Summary: <buffer> under <jsp-property-group> in web.xml only accept integer which doesn't follow spec and cause jsp compile fail
Product: Tomcat 8 Reporter: Tommy Xu <xuyijun>
Component: MetaAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P2    
Version: 8.0.14   
Target Milestone: ----   
Hardware: PC   
OS: Linux   

Description Tommy Xu 2014-10-17 09:10:24 UTC
For example, I expected the following should be fine:
<jsp-property-group>
  <buffer>32kb</buffer>
</jsp-property-group>

BUT actually, it will cause start app fail.

If I change it to:
<buffer>32000</buffer>

It is accepted. BUT, jsp compile will FAIL!
Comment 1 Konstantin Kolinko 2014-10-17 13:04:38 UTC
The allowed values are "none" and <number>"kb".
It is verified in org.apache.jasper.compiler.PageInfo.setBufferValue()

1. The buffer size can also be specified via buffer attribute on @page directive. The same code is used to verify both use cases. Thus no wonder that the check happens in JSP compiler.


2. I would say that the better place to do verification is XSD schema, jsp_2_3.xsd.

Unfortunately it is currently declared there just as type="javaee:string" with no further constraints.

I think that to make changes there, it has to be raised with the specification folks.

Note that validation of web.xml is only enabled if you are running in "strict compliance" mode by setting a system property or setting xmlValidation="true" on Context.
https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html#Specifications


3. I does not really feels as a job for JSP engine to verify web.xml, and Servlet engine has little interest in those effectively foreign settings.
Comment 2 Tommy Xu 2014-10-17 13:25:09 UTC
What I mean is when set 32kb in <buffer> in web.xml is ok, BUT when tomcat start, it will throw Exception, because in source code, it parse it by calling  Integer.valueOf(...) which is want to convert "32kb" into a integer.
 
Please consider it.
Comment 3 Mark Thomas 2014-10-21 20:34:55 UTC
Thanks for the report. This has been fixed in 8.0.x for 8.0.15 onwards and in 7.0.x for 7.0.57 onwards.