[ 
https://issues.apache.org/jira/browse/WW-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-3309.
-------------------------------

    Resolution: Fixed

Done

> XWork FileManager does not adequately decode URLs
> -------------------------------------------------
>
>                 Key: WW-3309
>                 URL: https://issues.apache.org/jira/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
>            Assignee: Lukasz Lenart
>            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.

Reply via email to