You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Andy Eastham <an...@gliant.com> on 2003/01/14 23:45:40 UTC

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Servlet Mapping Bug?

Posted by Jacob Kjome <ho...@visi.com>.
Are you sure this is happening when you go directly to Tomcat rather than 
through Apache?  All my mappings in web.xml make no mention of the context 
name and work just fine.

Try you app at:

http://localhost:8080/control/

Then try it at:

http://localhost/control/

If it works in the former case but not in the latter, then the bug is with 
your mod_jk config or the Coyote JK/JK2 connector, not with Tomcat in general.

Jake

At 03:16 PM 1/15/2003 +0000, you wrote:
>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:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Servlet Mapping Bug?

Posted by Andy Eastham <an...@gliant.com>.
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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>