You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Sylvain Laurent <sy...@m4x.org> on 2010/10/18 23:04:29 UTC
welcome files, servlet mappings and jsps (was [VOTE] Release Apache Tomcat 7.0.4)
Actually Glassfish does not differentiate between implicit and explicit mappings. There's just a test on the servlet-name : When determining the wrapper to use for a welcome file, if the physical file is not found, it checks for servlet mappings. If there's such a match, it also checks that the servlet name is different from "jsp" (overridable by a System property).
their source is here : https://grizzly.dev.java.net/source/browse/grizzly/trunk/code/modules/utils/src/main/java/com/sun/grizzly/util/http/mapper/Mapper.java?view=markup
I believe we could do the same hack in tomcat 7. The spec might not be very clear but that behavior avoids big surprises for current applications...
Sylvain
On 18 oct. 2010, at 02:35, Mark Thomas wrote:
> On 17/10/2010 22:58, Caldarale, Charles R wrote:
>>> From: Mark Thomas [mailto:markt@apache.org]
>>> Subject: Re: [VOTE] Release Apache Tomcat 7.0.4
>>
>>> There are no matches for the static files so all is
>>> OK for the first sentence. However there is a match
>>> (to *.jsp) the second time through so Tomcat passes
>>> "/catalog/products/default.jsp" to the JSP servlet
>>> which returns a 404.
>>
>> This might be the crux of the matter: section 12.2.1 of the spec states that "*.jsp" is an /implicit/ mapping (unless overridden by the webapp), and the second matching protocol in 10.10 seems to be referring to /explicit/ mappings (my interpretation, not definitive in the spec). Tomcat does not differentiate between implicit and explicit mappings, whereas the other containers seem to do so.
>
> Implicit seems to be a term used in section exclusively 12.2.1 (OK apart
> from a single mention in 12.1). It isn't used elsewhere in the Servlet
> spec so it isn't at all clear what - if any - special treatment implicit
> mappings are meant to have.
>
> 12.2.1 doesn't mention *.jspx which doesn't give me a great deal of
> confidence in the completeness or correctness of that section.
>
> Something else that requires some clarity for Servlet 3.1. I'll add it
> to my list.
>
> My previous suggestion regarding a new config option would at least
> allow users to control this behaviour until we get some clarity in the spec.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> 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
Re: welcome files, servlet mappings and jsps (was [VOTE] Release
Apache Tomcat 7.0.4)
Posted by Mark Thomas <ma...@apache.org>.
On 18/10/2010 16:04, Sylvain Laurent wrote:
> Actually Glassfish does not differentiate between implicit and explicit mappings. There's just a test on the servlet-name : When determining the wrapper to use for a welcome file, if the physical file is not found, it checks for servlet mappings. If there's such a match, it also checks that the servlet name is different from "jsp" (overridable by a System property).
>
> their source is here : https://grizzly.dev.java.net/source/browse/grizzly/trunk/code/modules/utils/src/main/java/com/sun/grizzly/util/http/mapper/Mapper.java?view=markup
>
> I believe we could do the same hack in tomcat 7. The spec might not be very clear but that behavior avoids big surprises for current applications...
Something along those lines is certainly going to be the way we need to
handle this until the EG updates the spec to say what they meant it to
say rather than what it currently says.
Options look like:
1. system property / context option to enable/disable this behaviour for
JSP servlet
2. system property / context option to enable/disable this behaviour for
all wildcard mapped servlets
3. system property / context option to enable/disable this behaviour for
a user defined set of servlets
My preferences (without looking at the code) is for 3 is that doable
without an undue amount of complexity. Then 2. Then 1.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org