[
https://issues.apache.org/struts/browse/WW-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46998#action_46998
]
Musachy Barroso commented on WW-3309:
-------------------------------------
you can just attach a patch here. the tricky part is that this code is in
xwork, which does not depend on commons io, to add a dependency it needs to be
jarjar into xwork. To fix it, you can just add a dependency to xwork and use
fileutils and build it. I will try ti fix it in xwork next week.
> XWork FileManager does not adequately decode URLs
> -------------------------------------------------
>
> Key: WW-3309
> URL: https://issues.apache.org/struts/browse/WW-3309
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter
> Affects Versions: 2.1.8
> Environment: Linux/Windows running Tomcat 6.0.18/6.0.20
> Reporter: Ryan Fields
> Priority: Minor
> Fix For: 2.2.0
>
>
> The JarEntryRevision inner class of XWork's FileManager class lazily decodes
> URLs by calling replace to change instances of %20 into spaces.
> Unfortunately, file URLs can and occasionally do contain other % encoded
> characters. In order for the referenced file to be opened, these % encoded
> characters must be transformed into their decoded equivalents.
> This bug is directly relevant to Tomcat 6, which uses a naming convention of
> context#subpath.war in its autodeployer to facilitate deployment of a web
> application into a context like /context/subpath. Tomcat deploys a war named
> in this manner to webapp/context#subpath, meaning that all absolute file
> references will contain a #. Because # (along with all other encoded
> characters except for space) do not get URL decoded by JarEntryRevision's
> build method, it is impossible to deploy a Struts 2 application named using
> this convention into Tomcat 6.
> I would think that this could be fixed by running the string representation
> of the URL through java.net.URLDecoder's decode method before handing it to
> the File constructor. The only snag is that decode expects a character
> encoding to be passed to it, and I'm not quite sure how to assume the correct
> encoding in a cross-platform manner. It might be feasible to assume UTF-8
> for all URLs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
