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
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.
