[
https://issues.apache.org/jira/browse/WICKET-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Donohoe updated WICKET-1627:
---------------------------------
Attachment: 1627and1624.patch
Here is the patch which address both 1624 and 1627.
I had to create a WicketURLEncoder and WicketURLDecoder to replace
java.net.URLEncoder and java.net.URLDecoder respectively.
I search in the wicket project and replaced the usages with this new class. I
also deprecated the RequestUtils decode/encode API.
See the RFC http://www.ietf.org/rfc/rfc2396.txt for details of what is and is
not allowed in URLs. The main issue boils down to the encoding of spaces with
'+' as is done by java.net.URLEncoder. While this is okay for query
parameters, it is not for the path portion of a URL. The server will not
decode +'s to spaces in a path component.
There are still some things that need to be addressed:
1) Hardcoding of "UTF-8" versus
Application.get().getRequestCycleSettings().getResponseRequestEncoding()
There are many places (notably RequestCycle and RequestUtils) that hardcode
UTF-8 when decoding and encoding values. Cleary this will cause an issue if
the application's request encoding is not UTF-8.
2) I think RequestCycle.urlFor has a bug in it. I noted this in the comments.
Essentially, values are beeing URL-encoded and put into PageParameters. This
likely leads to double-encoding if a mount strategy is used.
I would request that developers with more experience in the code base review my
changes and comment on #1 and #2 above.
> AbstractRequestTargetUrlCodingStrategy improper user of URLEncoder.encode
> -------------------------------------------------------------------------
>
> Key: WICKET-1627
> URL: https://issues.apache.org/jira/browse/WICKET-1627
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.1, 1.3.2, 1.3.3, 1.4-M1
> Environment: Tomcat or Jetty (probably others)
> Reporter: Doug Donohoe
> Fix For: 1.4-M2
>
> Attachments: 1627and1624.patch
>
>
> The use of URLEncoder.encode is incorrect in this scenario. The URLEncoder
> is meant for encoding query string values - not values that appear in the
> path portion of a URI.
> Because the AbstractRequestTargetUrlCodingStrategy is used by other classes
> to encode values that appear in the path, problems can occur when that path
> has spaces. For example, the parameter "message with spaces
> and+some+pluses" is encoded as follows in a URL:
> http://localhost:8080/bugs/home/message/message+with+spaces+and%2Bsome%2Bpluses/
> However, the resulting request.getServletPath() call returns this:
> /home/message/message+with+spaces+and+some+plusses=bug/
> Note that the + in the path are not turned back into spaces. This is the
> correct behavior and is seen in both Tomcat and Jetty.
> See the RFC (http://www.ietf.org/rfc/rfc2396.txt) for a full description of
> what should or should not be encoded.
> /**
> * Url encodes a string
> *
> * @param string
> * string to be encoded
> * @return encoded string
> */
> protected String urlEncode(String string)
> {
> try
> {
> return URLEncoder.encode(string,
> Application.get().getRequestCycleSettings()
> .getResponseRequestEncoding());
> }
> catch (UnsupportedEncodingException e)
> {
> log.error(e.getMessage(), e);
> return string;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
