[jira] Commented: (WICKET-1303) Slash separated URL's cannot have URL parameters with value containing forward slash '/'

["Andreas Sahlbach (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669431#action_12669431 ] 

Andreas Sahlbach commented on WICKET-1303:
------------------------------------------

It's not "some serverlet container", it's Apache as well as Tomcat. And it's done on purpose for security reasons and because of this it is unlikely that they will change their behavior in the future. 

In fact IMHO it's not important if it's a bug or not. Just check out the consequences for wicket users if wicket does not change it's encoding. In this case every single wicket user has to check all of his forms. If it's possible that a user enters / or \ in one of the fields, the wicket developer cannot use the affected URL Encoders. 
The only other possibility would be that he double encodes his fields like the bug reporter did. 

Do you really think a framework should make life so hard for developers? Wouldn't it be nice if our framework-of-choice would solve this issue once and for everyone?

There is RFC and there is real life. I strongly encourage to handle this in wicket.

> Slash separated URL's cannot have URL parameters with value containing forward slash '/'
> ----------------------------------------------------------------------------------------
>
>                 Key: WICKET-1303
>                 URL: https://issues.apache.org/jira/browse/WICKET-1303
>             Project: Wicket
>          Issue Type: Wish
>          Components: wicket
>    Affects Versions: 1.3.0-final
>         Environment: Tomcat 6.0.14, Firefox 2.0.0.11, Windows XP SP2
>            Reporter: Mika Salminen
>            Priority: Minor
>
> There seems to be an issue with URL parameters encoded into path in form "/page/param1/val1" with handling parameter values with forward slash ('/'). The slash is correctly URL-encoded to entity '%2F' so that for example parameter key/value pair 'foo' => 'b/a/r' is encoded into url like: '/page/foo/b%2Fa%2Fr'. The problem is that Tomcat returns error or empty page with this url.
> I tested and researched a little bit and found out that this is Tomcat related issue. In versions >= 6.0.10 Tomcat does not allow entities '%2F' and '%5C in path by default so it responds with error (or empty page) when it encounters one of them in URL's path part. More information can be found on http://tomcat.apache.org/security-6.html, under header "Fixed in Apache Tomcat 6.0.10". I tried according to the document to turn system property org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true, to allow encoded slashes in path, and got the request with '%2F'  in path through.
> I think that PageParameters in wicket should be easy to use, so that user does not have to worry about the contents of the parameter, so something should be done to this issue.
> I managed to get around this issue by double encoding the parameter values with URLEncoder. I encoded the PageParameter map parameter values with URLEncoder and replaced all occurences of '%' in resulting text with '=' before passing it forward. So only entity that is left to be encoded by the framework (AbstractRequestTargetUrlCodingStrategy) is '=' which becomes "%3D" so "foo" => "b/a/r" becomes encoded in URL like: "/page/foo/b%3D2Fa%3D2Fr". Decoding of URL is done by opposite operation sequence: framework decodes the parameter for me to form b=2Fa=2Fr and after that I replace  '=' with '%' and the replaced string is further decoded with URLDecoder. Not very beautiful solution but seems to work as a quick fix and leaves non-special characters unaffected. As a little downside two extra characters are needed to encode every special character.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.