The welcome files section of the 2.4 spec is hopelessly broken. IMHO,
Tomcat's implementation is as good as can be implemented. While it wouldn't
be that hard to append the welcome-file to the requestURI, that would mean
that it would be impossible for the servlet to ever get the requestURI that
the UA sent. This is much worse than matching the pedantic formula (not to
mention breaking the spec for getRequestURI :).
----- Original Message -----
From: "Morten S. Mortensen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 19, 2004 6:57 AM
Subject: Q: Mismatch request-URI vs. servlet-path in TC 5.0.XX
Hi all,
Can it really be, that the newer TC 5.0.25 and 5.0.27 breaks the formula
-
requestURI = contextPath + servletPath + pathInfo
(Servlet 2.4 specification, page 38)
?
My TC sets some really weird request-info like .e.g on a request upon
the URL "http://localhost:8080/Oginok_Prime/"; I get the request-values -
*** requestURI: /Oginok_Prime/
*** servletPath: /index.html
*** pathInfo: null
Obviously, the request-URI does *not* contain the servlet-path.
Request upon the URL "http://localhost:8080/Oginok_Prime/"; should
however result in a HTTP-redirect to the browser at the URL
"http://localhost:8080/Oginok_Prime/index.html";, but this is a different
request, which the engine somehow mixes with the current request.
To the best of my knowledge, this stuff functions correctly within the
TC 4.1.XX-series.
Am I the only one seeing this?
Reguards,
Morten Sabroe Mortensen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
