Tapestry 5
  1. Tapestry 5
  2. TAP5-2015

Tomcat .war path is not decoded properly

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 5.3.6
    • Fix Version/s: 5.3.7, 5.4
    • Component/s: plastic
    • Labels:

      Description

      If an tapestry application is deployed to tomcat and the path to a webapp contains hash signs (#), org.apache.tapestry5.internal.plastic.PlasticInternalUtils.getStreamForPath tries to read files from a wrong directory: instead a hash sign, the path it tries to read contains the sequence %23.
      This results in a FileNotFoundException and causes the app to fail starting.

      getStreamForPath already replaces url encoded %20 space characters for tomcat, it should also replace hash signs - and maybe even more valid file name characters.

      Background: Tomcat 6 uses hash signs in war file names as replacement for slashes, so that the file name can be used to construct the webapp's url. The war is unpacked to a directory which name is the war's file name without the .war extension and therefore can contain hash signs. Tomcat 7 uses two hash signs for the same purpose.

        Issue Links

          Activity

          Show
          Kalle Korhonen added a comment - https://issues.apache.org/jira/browse/TAP5-1995

            People

            • Assignee:
              Kalle Korhonen
              Reporter:
              Kapep
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development