RE: Servlet Mapping Bug?
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:[EMAIL PROTECTED]] 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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Servlet Mapping Bug?
Holger, Thanks for the tip. I think you're right. I just noticed that it is behaving diferently to how it was with warp and webapp. Cheers, Andy -Original Message- From: Stratmann, Holger [mailto:[EMAIL PROTECTED]] Sent: 15 January 2003 15:56 To: 'Tomcat Users List' Cc: '[EMAIL PROTECTED]' Subject: AW: Servlet Mapping Bug? ie put the full URI in the url-pattern, not just the path relative to the Tomcat application root. Have you configured the Tomcat application root? I don't mean in Apache, I mean in server.xml? For each context you configure, you can also specify the URL-prefix. default: !-- Tomcat Root Context -- !-- Context path= docBase=ROOT debug=0/ -- !-- Tomcat Examples Context -- Context path=/examples docBase=examples debug=0 . etc. Maybe you could solve your problem by just configuring path=/control here... (I don't think it's a bug?) -Ursprüngliche Nachricht- Von: Andy Eastham [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 15. Januar 2003 16:17 An: Tomcat Users List Betreff: RE: Servlet Mapping Bug? 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:[EMAIL PROTECTED]] 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
RE: Servlet Mapping Bug?
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 +, 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:[EMAIL PROTECTED]] 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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
