https://issues.apache.org/bugzilla/show_bug.cgi?id=53469
--- Comment #10 from papegaaij <emond.papega...@topicus.nl> --- (In reply to comment #9) > > Suppose you are at /a/b and you click a link to /a/b/c/d. This page contains > > a link to /1/2. Wicket renders all urls relative, so the link to /1/2 will > > be ../../../1/2 (it is relative to /a/b/c/d). This link will be passed to > > Response.encodeURL, which rewrites it to /a/../../../1/2, which obviously is > > wrong and fails. > > Huh? If you click a link to /a/b/c/d and the response contains a relative > link ../../../1/2 then the result should be /a/b/c/../../../1/2 == /1/2 > (i.e. relative to the current request). Why does Tomcat/Wicket think it > should be relative to the previous request for /a/b ? This has to do with the way Wicket renders links and handles requests. The link on /a/b, might look like ./b?2-1.ILinkListener-link. During processing of this link, user-code can send the user to /a/b/c/d. This causes the page for /a/b/c/d to be rendered as part of the request on /a/b?2-1.ILinkListener-link. The result of this request is a redirect to /a/b/c/d. The GET on this url simply fetches the rendered page from a buffer. -- 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
