On May 22, 2009, at 2:52 AM, Charles Brooking wrote:
> G'day,
>
>> OK, got it now, and can reproduce it. Hmm.... strictly speaking the
>> path if the servlet pattern is /foo/* and the full path is /context/
>> foo then the servlet should not match, plus there is inconsistent
>> behavior with the "/*" and /foo/*" patterns, sigh...
>
> Section SRV.11.2.2 of the Servlet 2.4 spec says that an incoming
> path /baz
> will match the pattern /baz/* (it's an example in the table).
>
OK!
> We have talked about using redirects - and this is what Tomcat and
> Glassfish do for the /contextPath case - but my experience with non-
> root
> resources in Jersey like @Path("/foo/{foo}/") indicate that a 200
> response
> is returned both with and without the trailing slash.
Yes, that is by design and conforming to the JAX-RS spec. You can
enable redirection by setting the
"com.sun.jersey.config.feature.Redirect" property to true:
https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/jersey/com/sun/jersey/api/core/ResourceConfig.html
#FEATURE_REDIRECT
> So if we want
> consistency with non-root resources in the Jersey servlet maybe we
> should
> return 200 instead of redirecting.
>
No, because for the case you describe above *matches* a resource for
two URIs one with and one without the slash.
In this edge case, we are managing at the level of servlet before we
know if there would be a match or not if the path ended in a '/'. So
IMHO the best approach is a 404 or a redirect, and access to the
redirected URI can return a 404 or a 200 depending on whether the
application supports that resource.
>> Could you log an issue to as a reminder to change this to
>> redirection?
>
> https://jersey.dev.java.net/issues/show_bug.cgi?id=297
>
Thanks,
Paul.