Greg,
(I'm cc'ing Greg directly also since I am not a jetty mailing list member, and don't know if this will get to Greg otherwise).
It seems to me that this is not actually so clear-cut. The filter in question is not mapped to the request via a
<servlet-name>xxxx</servlet-name>
in the <filter-mapping> element, but rather a
<url-pattern>/*</url-pattern>
url mapping. As such, when the filter is executed, as I understand it, it's not even a servlet filter, it's just a general filter on the request.
As far as I can make it out, both Jetty _and_ WebSphere are wrong. The method definition is:
"Servlet Path: The path section that directly corresponds to the mapping
which activated this request. This path starts with a’/’ character except in the
case where the request is matched with the ‘/*’ pattern, in which case it is an
empty string."
well the mapping that caused the filter to fire in this case is definitely '/*', so I think the method should be returning an empty string. Instead, Jetty (and I think TomCat) return
/j_acegi_security_check
and WebSphere returns
/
How is either of the above correct?
Regards, Colin
Greg Wilkins wrote:
Ben,
The spec says:
"A string containing only the / character indicates the "default" servlet
of the application. In this case the servlet path is the request URI minus
the context path and the path info is null."
"Servlet Path: The path section that directly corresponds to the mapping which
activated this request. This path starts with a / character except in the case
where the request is matched with the /* pattern, in which case it is an empty string. "
"PathInfo: The part of the request path that is not part of the Context Path or the
Servlet Path. It is either null if there is no extra path, or is a string with a leading / .
So looking at your results, Jetty is giving you results as if the mapping was /j_acegi_security_check
I can't think of a legal mapping that would result in the WebSphere result of
servlet path=/.
If the mapping was /j_acei_securitycheck, then a sp of / is just wrong.
If the mapping was /* then servletpath must be the empty string and the path info must start with a /
If the mapping was / then the servletpath should be the whole request URI and the path info must be null
So websphere is just plain wrong on this one !
cheers
Ben Alex wrote:
Hi everyone
The Acegi Security System for Spring (http://acegisecurity.sourceforge.net)
uses HttpServletRequest getters in a filter. I do all the development of the
project using Jetty, but we've had a report of problems with WebSphere
5.1.1. I'm writing to the Jetty list in the hope of gaining some
clarification as to the correct behaviour of different HttpServletRequest
getters.
Here are our filter logging directives:
logger.debug("REQ url: " + httpRequest.getRequestURL()); logger.debug("REQ servlet path: " + httpRequest.getServletPath()); logger.debug("REQ context path: " + httpRequest.getContextPath()); logger.debug("REQ path info: " + httpRequest.getPathInfo()); logger.debug("REQ path translated " + httpRequest.getPathTranslated()); logger.debug("REQ request url: " + httpRequest.getRequestURL());
Using Jetty 4.2.17 it returns:
REQ url: http://localhost:8080/contacts/j_acegi_security_check REQ servlet path: /j_acegi_security_check REQ context path: /contacts REQ path info: null REQ path translated null REQ request url: http://localhost:8080/contacts/j_acegi_security_check
Using WebSphere 5.1.1 (on a different machine) it returns:
REQ url: http://localhost:9080/Permit/j_acegi_security_check REQ servlet path: / REQ context path: /Permit REQ path info: j_acegi_security_check REQ path translated
/home/mark/Repositories/permit/PermitWeb/WebContent/j_acegi_security_check REQ request url: http://localhost:9080/Permit/j_acegi_security_check
So, is getServletPath() and getPathInfo() correct for Jetty or WebSphere?
We're trying to detect the getServletPath() output as per Jetty (ie
/j_acegi_security_check) so we know our filter should do something.
Any advice appreciated.
Ben
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
