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.