tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: SCRIPT_NAME and PATH_INFO with extension mapping
Date Mon, 01 Oct 2001 03:45:09 GMT
As much as my personal preference is the same as Jon and Costin, it seems
that section 11.1 rule #3 explicitly dis-allows extension mappings to have a
If the last segment in 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.
This is from the 2.3 Spec, since Jon is a 4.0 user.

----- Original Message -----
From: "Jon Stevens" <>
To: "tomcat-dev" <>
Sent: Sunday, September 30, 2001 3:49 PM
Subject: SCRIPT_NAME and PATH_INFO with extension mapping

> on 9/30/01 5:47 PM, "" <> wrote:
> > the conclusion was that the HTTP spec is wrong and we should
> > follow the Servlet spec.
> That is complete BS. The servlet spec shouldn't 'override' what is defined
> in the HTTP spec unless absolutely necessary. This is definitely not a
> necessary case, but instead an act of stupidity.
> > Workaround - declare each page with exact mappings in web.xml.
> Making me specify each and every page in my webapp in the web.xml is just
> plain BS.
> I bet that a URL like this works:
> I *know* that this URL works:
> Essentially, what you are doing by removing this capability is preventing
> the SCRIPT_NAME from having PATH_INFO and that is not right according to
> HTTP spec. I don't think that a Servlet container can override the
> of the HTTP spec and still claim HTTP compliance.
> -jon


This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 

View raw message