https://issues.apache.org/bugzilla/show_bug.cgi?id=53469
--- Comment #11 from Mark Thomas <ma...@apache.org> --- OK. I see what the problem is here. It isn't quite as clear cut as comment #8 suggests. To determine if the URL should be encoded, Tomcat attempts the following checks: a) is it not an intra-document reference b) is there a current session c) are cookies being used d) is URL re-writing permitted e) does the absolute URL match down to the context path The problem is with check e). Now Tomcat normalizes any absolute URLs (a perfectly valid thing to do) then absolute URLs that fail normalization now fail the encoding process. Note that prior to the addition of normalization, check e) always passed for any relative URL. That is a bug that has gone unnoticed for many years. (With the addition of mormalization, it is now fixed). Note also that while Tomcat normalizes the URL for check e) it uses the original URL to construct the returned value. The failed normalization is easily caught in Tomcat but it means that any URLs for which normalization fails will not have the session ID encoded in the URL. This then comes back to what Wicket is trying to do. From your description, during the generation of the response to /a/b Wicket is pre-generating the content for /a/b/c/d and /a/b/c/d may contain links with relative URLs. It is the encoding of these URLs that is failing since Tomcat believes there are relative to the current request/response for /a/b rather than /a/b/c/d. This does seem a little unusual and not something that was anticipated by either the Tomcat developers or the Servlet EG. I'm not sure how to handle this. The Servlet specification does not state that relative URLs passed to encodeURL must be treated as relative to the current request/response but equally, what else could they be relative to? It is more clear cut for sendRedirect since Tomcat is required to return the absolute (and now normalized) URL. I am tempted to say the Wicket should be wrapping the HttpServletRequest during the generation of /a/b/c/d to return the correct URL and wrapping the HttpServletResponse to link it to the wrapped request although I'm not sure how well that would go down with the Wicket developers. As a minimum, Tomcat needs to be patched to catch a normalization failure and simply not encode the URL in that case. Thoughts, feedback and corrections welcome. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
