Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 73691 invoked from network); 15 Jan 2003 15:16:54 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 15 Jan 2003 15:16:54 -0000 Received: (qmail 20483 invoked by uid 97); 15 Jan 2003 15:17:25 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 20428 invoked by uid 97); 15 Jan 2003 15:17:24 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 20376 invoked by uid 98); 15 Jan 2003 15:17:24 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) From: "Andy Eastham" To: "Tomcat Users List" Subject: RE: Servlet Mapping Bug? Date: Wed, 15 Jan 2003 15:16:50 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: > > > > myServlet > > > /plots/* > > > > However, in my new setup, I have had to change this to make it work: > > > > myServlet > > > /control/plots/* > > > > 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: > > For additional commands, e-mail: > > > -- To unsubscribe, e-mail: For additional commands, e-mail: