Bug 27704 - Result of request.getServletPath() wrong in case JSP inside jsp-property-group
Result of request.getServletPath() wrong in case JSP inside jsp-property-group
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Jasper
5.0.19
PC All
: P3 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-03-16 12:52 UTC by Ronald Wildenberg
Modified: 2005-03-20 17:06 UTC (History)
0 users



Attachments
Test case for the described behavior. (1.12 KB, application/java-archive)
2004-03-16 12:53 UTC, Ronald Wildenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ronald Wildenberg 2004-03-16 12:52:50 UTC
A JSP that maps to a url-pattern in a jsp-property-group does not return the
correct result on calling request.getServletPath(). Instead, this call will
always return the property group url pattern minus the trailing '/*'.

Example:
<url-pattern>/level1/*</url-pattern>

A JSP in the directory '/level1/level2/test.jsp' calls request.getServletPath().
The result is '/level1' i.o. '/level1/level2/test.jsp'. This may be related to
bug 27664.

I will attach a test.war file that demonstrates the described behavior.
Comment 1 Ronald Wildenberg 2004-03-16 12:53:51 UTC
Created attachment 10803 [details]
Test case for the described behavior.
Comment 2 Remy Maucherat 2004-03-16 12:58:11 UTC
Well, again, this is normal: the JSP servlet is mapped to the
jsp-property-group. Again, very little chance of being fixed for now ;)
Comment 3 Ronald Wildenberg 2004-03-16 13:10:22 UTC
Ok, this may be perfectly normal from a code perspective, but it is unexpected
behavior that has by now caused me to replace my Servlet2.4/JSP2.0 application
for a Servlet2.3/JSP1.2 application.

Of course everything will also work using the older specs but I'm looking
forward to these issues being fixed in a (hopefully not to remote) future version.

And thanks for not closing my bug this time so I'd have to reopen it again ;)
Comment 4 Remy Maucherat 2004-03-16 13:32:16 UTC
I completely disagree with your two bug reports. Either they are invalid or the
specification is broken. The main problem is this sentence: "If at least one
<jsp-propertygroup> contains the most specific matching URL pattern, the
resource is considered to be a JSP file". This is clearly extremely bad behavior
when using wildcard patterns.
I am going to veto any attempt to fix these last two "bugs" (with bug 27664)
until I am explained why the specification is not broken.
Comment 5 Ronald Wildenberg 2004-03-16 14:40:41 UTC
I do not understand the badness of this behavior. If a resource is matched by a
jsp-property-group, it should be considered a JSP file. If a resource has the
extension .jsp it should be considered a JSP file. What's the difference between
these two?

If you include directories with the resources that match a url-pattern, this
explains bug 27664: a directory is then served as a JSP file, which can not be
found, resulting in a 404.

However, JSP3.3 states: "A JSP property group is a collection of properties that
apply to a set of files that represent JSP pages." Directories are apparently
not included in this definition.

SRV9.10 states: "The purpose of this mechanism is to allow the deployer to
specify an ordered list of partial URIs for the container to use for appending
to URIs when there is a request for a URI that corresponds to a directory entry
in the WAR not mapped to a Web component." Requests for a directory should
result in an attempt to append welcome files to this directory.
Comment 6 Remy Maucherat 2004-03-16 14:48:15 UTC
The problem is that this jsp-property-group feature is that it conflicts with
servlet mapping rules, and forces the JSP implementation to be a mini servlet
container in itslef.
Comment 7 Ronald Wildenberg 2004-03-16 15:14:59 UTC
Ok, I agree with the fact that this will probably make a mini servlet container
of the JSP implementation and that this is undesired. But not fixing this also
means that Tomcat is not fully compliant with the spec. This may become a
problem when products that Tomcat is integrated into attempt to become J2EE 1.4
compatible.

You'll probably be happy to know this is the last thing I will say about this issue.
Comment 8 Remy Maucherat 2004-03-16 15:25:24 UTC
As I said, I contend that this was not what was intended by the spec authors.
Due to the "servlet mapping"-like effect of jsp-property-group, and yet the need
to have web server like features and a JSP container (I'm sure in 5 minutes
you'll be complaining that directory listings do not work), you need special JSP
specific processing in your servlet container (and this processing is relatively
complex).
To implement jsp-property-group properly, you probably would have to do some
mapping hacks, and assign some requests to the JSP servlet (after regular
mapping), which is relatively complex (jsp-property-group/url-mapping is not
trivial, and you have to do it during request dispatching as well), has a
performance cost (similar to filter mapping), and introduces obvious
dependencies with JSP.
That violates the original design idea of the independence of the servlet and
JSP specs.
Comment 9 Jan Luehe 2004-03-18 17:25:59 UTC
Reopening so that I can close it as FIXED.