[
https://issues.apache.org/jira/browse/WICKET-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426290#comment-13426290
]
Trejkaz commented on WICKET-4625:
---------------------------------
I have been tracking down an issue in a filter of ours for a few days. I have
managed to track it down into Wicket's
ServletWebRequest.getContextRelativeUrl() even though I initially thought it
was Jetty's fault since the 404 error was being omitted from them.
Local variables:
contextPath = "/"
filterPrefix = ""
uri = "/sign_in"
result = "ign_in".
This doesn't seem to happen on normal requests for /sign_in but it happens when
I forward in a filter:
ServletContext rootContext =
servletRequest.getServletContext().getContext("/");
RequestDispatcher dispatcher = rootContext.getRequestDispatcher("/sign_in");
dispatcher.forward(servletRequest, servletResponse);
Is this really a bug in Wicket? The reason I wonder is that
HttpServletRequest.getContextPath() is documented as follows:
Returns the portion of the request URI that indicates the context of the
request. The context
path always comes first in a request URI. The path starts with a "/"
character but does not end
with a "/" character. For servlets in the default (root) context, this
method returns "".
The container does not decode this string.
>From this, it sounds like Jetty's implementation of this method is incorrect.
> ServletWebRequest#getContextRelativeUrl() sometimes chops off leading
> characters
> --------------------------------------------------------------------------------
>
> Key: WICKET-4625
> URL: https://issues.apache.org/jira/browse/WICKET-4625
> Project: Wicket
> Issue Type: Bug
> Affects Versions: 1.5.7
> Reporter: Darryl L. Miles
> Attachments:
> 0001-WICKET-4625-ServletWebRequest-getContextRelativeUrl-.patch
>
>
> This patch reduces the number of nonsense return value this method might
> produce. I have clarified the in JavaDoc the expected inputs to the method.
> It is still possible to still get a nonsense return values in some use cases,
> all scenarios are documented and tested in a new test case.
> This method presumes that the input "uri" on the 1st argument always has the
> ContextPath and then the FilterPrefix on the front of the URL.
> Some unit tests were actually checking the nonsense return values were being
> returned these have been updated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
