Uploaded image for project: 'Undertow'
  1. Undertow
  2. UNDERTOW-373

ServletContextImpl.getRealPath returns null when the file does not exist.

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Minor
    • 1.2.0.Beta9
    • 1.0.15.Final
    • None
    • None
    • Hide

      In any simple web app, call ServletContext.getRealPath("/non-existing-file.html"). The method will return null, even though it could have easily returned the path to where the file was expected to be.

      Show
      In any simple web app, call ServletContext.getRealPath("/non-existing-file.html") . The method will return null, even though it could have easily returned the path to where the file was expected to be.

    Description

      The summary line in the Javadoc comment for ServletContext.getRealPath(String) indicates that getRealPath "gets the real path corresponding to the given virtual path." Additional details given in the comment stipulate that the method can return null if the servlet container is "unable" to perform the translation.

      Unfortunately, the javadoc comment does not fully elaborate on the definition of "unable," nor does it describe all of the scenarios where the container must, may, or shant be "able." Because of this lack of clarity, the comment itself is probably not normative, and it might be necessary to consult the official J2EE spec for the final word.

      However, whenever specs are unclear or unopinionated, interpretive implementations often become de facto standards, and it is sometimes a good idea for new implementations to strive for compatibility with previous implementations.

      To be clear, the javadoc comment does not say that the path must exist in order for translation to be successful.

      Undertow 1.0.15's implementation of this method correctly converts the provided virtual path to a physical file system path. But then, just before returning the result, it checks to see whether the file (or folder) actually exists, and if it doesn't, it returns null instead.

      It's not clear that this behavior is justified or correct. A path does not cease to be a path simply because there is no directory entry matching it. A process might, for example, be interested in describing a path to which a new file might be written.

      Undertow's interpretation of this method causes some J2EE apps that used to run correctly on JBoss AS 7.1.1 to no longer run correctly on Wildfly 8.1. For example, apps that use filters to intercept first requests to particular paths, in order to generate the files just in time, may now fail when Undertow provides the servlet context, simply because they can no longer rely on getRealPath to determine the location of the file that needs to be written.

      Attachments

        Activity

          People

            sdouglas1@redhat.com Stuart Douglas
            osamesama2 Charlton Rose (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: