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 PATH_INFO. <spec-quote> 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. </spec-quote> This is from the 2.3 Spec, since Jon is a 4.0 user.
----- Original Message ----- From: "Jon Stevens" <[EMAIL PROTECTED]> To: "tomcat-dev" <[EMAIL PROTECTED]> Sent: Sunday, September 30, 2001 3:49 PM Subject: SCRIPT_NAME and PATH_INFO with extension mapping > on 9/30/01 5:47 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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: > > http://www.foo.com/MicrosoftIsBetterThanSun.asp/foo/bar > > I *know* that this URL works: > > http://www.foo.com/PHPIsBetterThanJSP.php/foo/bar > > 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 the > HTTP spec. I don't think that a Servlet container can override the behavior > 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) e-mail.
