struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lukasz Lenart (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (WW-3309) XWork FileManager does not adequately decode URLs
Date Tue, 16 Mar 2010 14:50:29 GMT

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

Lukasz Lenart reassigned WW-3309:
---------------------------------

    Assignee: Lukasz Lenart

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


Mime
View raw message