[
https://issues.apache.org/jira/browse/WICKET-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669452#action_12669452
]
Andreas Sahlbach commented on WICKET-1303:
------------------------------------------
I am currently contracted by Volkswagen. Do you know how hard it would be for
me to ask the network division of VW to configure the tomcat and all three
apaches along their proxy chain from their DMZ up to my application so that
wicket works? Hehe, if I even mention that this change will weaken the security
of the servers or if they would find out by themselves, this would be an
totally impossible task. They would simply order me to change the framework.
I totally agree that this is not a bug according to the RFC. But it is
currently very inconvenient to use IMHO.
You are right, forms are not directly affected, it's just a common case I
think. In my case it was an "enter new article with description" form and a
"create-new-article" with article id and article description. I think it's a
pretty often used case that the form calls a page with the values of the form
as parameters. And this will not work in these cases. Unfortunately it's a
runtime user error. It looks like it works perfectly but will fail sometimes in
productive environment. Yuk...
> 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.
