You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Igor Vaynberg (JIRA)" <ji...@apache.org> on 2010/08/25 01:32:17 UTC
[jira] Resolved: (WICKET-1751) shouldn't return relative path such
as ../ or ./ in redirect response
[ https://issues.apache.org/jira/browse/WICKET-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-1751.
-----------------------------------
Assignee: Igor Vaynberg
Resolution: Invalid
it is the servlet container's job to rewrite relative urls used for redirection to absolute ones, see the javadoc of httpservletresponse#sendredirect()
> shouldn't return relative path such as ../ or ./ in redirect response
> ---------------------------------------------------------------------
>
> Key: WICKET-1751
> URL: https://issues.apache.org/jira/browse/WICKET-1751
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.3
> Reporter: Kent Tong
> Assignee: Igor Vaynberg
>
> Wicket uses ".." and "." when generating urls which are sent to the browser as redirects
> (eg, in WebRequestCodingStrategy.encode() and WebResponse.encodeURL()).
> However, such relative path components are only meaningful within a document and
> only when the browser is resolving URI references to absolute URIs. As what is in the
> redirect is a URI, not a URI reference and there is no enclosing document, so ".." and
> "." have no special meaning.
> The reason why it has worked so far is probably because common browsers are
> going beyond the spec to interpret ".." and ".". However, it fails miserably with clients
> like htmlunit.
> The solution is that Wicket should resolve the relative path components itself and
> return absolute URIs to the browser.
> Quote from RFC239:
> Within a relative-path reference, the complete path segments "." and
> ".." have special meanings: "the current hierarchy level" and "the
> level above this hierarchy level", respectively. Although this is
> very similar to their use within Unix-based filesystems to indicate
> directory levels, these path components are only considered special
> when resolving a relative-path reference to its absolute form
> (Section 5.2).
> Quote from RFC2616:
> 303 See Other
> The response to the request can be found under a different URI and
> SHOULD be retrieved using a GET method on that resource. This
> method exists primarily to allow the output of a POST-activated script
> to redirect the user agent to a selected resource. The new URI is not a
> substitute reference for the originally requested resource.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.