tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 53469] possible bug in Response.normalize(CharChunk cc)
Date Mon, 23 Jul 2012 06:32:21 GMT

--- Comment #10 from papegaaij <> ---
(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:
For additional commands, e-mail:

View raw message