tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Eastham" <andy.east...@gliant.com>
Subject RE: Servlet Mapping Bug?
Date Wed, 15 Jan 2003 15:16:50 GMT
This is a bug, as I've now checked the Servlet Specification v2.3:

The key phrase is:
The path used for mapping to a servlet is the request URL from the request
object minus the context path.
ie for my /control/plots/x.jpg request, the context path is /control, so
only /plots/x.jpg should be used to map the servlet.

I guess this bug is probably in the Coyote Connector?

Andy

PS
Here's the full text of the relevant bit from the servlet spec:

SRV.11.1 Use of URL Paths
Upon receipt of a client request, the web container determines the web
application to which to forward it. The web application selected must have
the longest context path that matches the start of the request URL.

The matched part of the URL is the context path when mapping to servlets.
The web container next must locate the servlet to process the request using
the path mapping procedure described below:
The path used for mapping to a servlet is the request URL from the request
object minus the context path. The URL path mapping rules below are used in
order. The first successful match is used with no further matches attempted:

1. The container will try to find an exact match of the path of the request
to the path of the servlet. A successful match selects the servlet.

2. The container will recursively try to match the longest path-prefix: This
is done by stepping down the path tree a directory at a time, using the '/'
character as a path separator. The longest match determines the servlet
selected.

3. If the last segment in the URL path contains an extension (e.g. .jsp),
the servlet
container will try to match a servlet that handles requests for the
extension.
An extension is defined as the part of the last segment after the last '.'
character.

4. If neither of the previous three rules result in a servlet match, the
container will
attempt to serve content appropriate for the resource requested. If a
"default"
servlet is defined for the application, it will be used.
The container must use case-sensitive string comparisons for matching.

Note 1. Previous versions of this specification made use of these mapping
techniques a suggestion rather than a requirement, allowing servlet
containers to each have their different schemes for mapping client requests
to servlets.

> -----Original Message-----
> From: Andy Eastham [mailto:andy.eastham@gliant.com]
> Sent: 14 January 2003 22:46
> To: Tomcat Users List
> Subject: Servlet Mapping Bug?
>
>
> Hi,
>
> I've just upgraded from Tomcat 4.0.4b1 and apache 1.3 using warp to Tomcat
> 4.1.18 and Apache 2.0.43 using mod_jk2.
>
> I use a feature of servlet mapping in web.xml, where I map any
> request under
> a particular directory to a single servlet.  My application is mapped from
> Apache under the url "/control/" and I invoke myServlet with any
> request to
> the "plots" subdirectory.  In the old configuration, the relevant
> part of my
> web.xml looked like:
>
>     <servlet-mapping>
>         <servlet-name>
>             myServlet
>         </servlet-name>
>         <url-pattern>
>             /plots/*
>         </url-pattern>
>     </servlet-mapping>
>
> However, in my new setup, I have had to change this to make it work:
>
>     <servlet-mapping>
>         <servlet-name>
>             myServlet
>         </servlet-name>
>         <url-pattern>
>             /control/plots/*
>         </url-pattern>
>     </servlet-mapping>
>
> ie put the full URI in the url-pattern, not just the path relative to the
> Tomcat application root.
>
> This strikes me as less portable - if I change my url mapping from Apache,
> I'll have to edit my web.xml, which wouldn't have been necessary
> before.  Is
> this a bug, or has it really been changed to better comply with
> the Servlet
> spec?
>
> Best regards,
>
> Andy Eastham
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message