You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Ryan Fields (JIRA)" <ji...@apache.org> on 2009/10/30 19:31:50 UTC
[jira] Created: (WW-3309) XWork FileManager does not adequately
decode URLs
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.
[jira] Commented: (WW-3309) XWork FileManager does not adequately
decode URLs
Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (WW-3309) XWork FileManager does not adequately
decode URLs
Posted by "Ryan Fields (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46997#action_46997 ]
Ryan Fields commented on WW-3309:
---------------------------------
I agree. FileUtils is a better solution.
Seeing as how I need this fix for a current project, I'm going to grab the 2.1.8 source and try building it with the FileUtils fix. If it works as desired, I'll need to learn what the process is for contributing to Struts 2 and see about submitting a patch. :)
> 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.
[jira] Updated: (WW-3309) XWork FileManager does not adequately
decode URLs
Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Musachy Barroso updated WW-3309:
--------------------------------
Fix Version/s: 2.2.0
> 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.
[jira] Commented: (WW-3309) XWork FileManager does not adequately
decode URLs
Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46996#action_46996 ]
Musachy Barroso commented on WW-3309:
-------------------------------------
I have done some research on this before and URLDecoder doesn't cover all, the cases either (meaning it's output is not good to be used in File's constructor). The best thing to do is use Commons io FileUtils: http://commons.apache.org/io/api-release/org/apache/commons/io/FileUtils.html#toFile%28java.net.URL%29
> 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.