Details
-
Bug
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
http.base-3.0.0, http.base-3.0.2, http.jetty-3.1.0, http.jetty-3.1.2, http.bridge-3.0.0, http.bridge-3.0.2
-
None
Description
The HttpServletRequest.getRequestURI must return the URI without processing % escaping. Since version 3.1.0 this processing is done, so the returned value is incorrect. For exemple this can lead to error in Apache Shiro when it try to unescape % of an URI.
See the attached jar for a bundle that can be used to reproduce the problem:
- load the bundle
- with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
With HTTP Jetty < 3.1.0 it prints:
Request URI: /requesturibug/test%2Ftest%25test (org.apache.felix.http.base.internal.handler.ServletHandlerRequest) Wrapped URI: /requesturibug/test%2Ftest%25test (org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper) Wrapped URI: /requesturibug/test%2Ftest%25test (org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest) Wrapped URI: /requesturibug/test%2Ftest%25test (org.eclipse.jetty.server.Request)
=> request URI is ok
With HTTP Jetty 3.1.0 or 3.1.2 it prints:
Request URI: /requesturibug/test/test%test (org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper) Wrapped URI: /requesturibug/test%2Ftest%25test (org.eclipse.jetty.server.Request)
=> request URI is wrong while the underlying request URI returned by Jetty itself is correct.
When this request come the Shiro filter it will issue an exception because it will try to unescape "%te" which is not valid since "te" is not a number
Attachments
Attachments
Issue Links
- relates to
-
FELIX-4925 Request path is not decoded
- Closed