servlet-spec
  1. servlet-spec
  2. SERVLET_SPEC-11

Clarification required for ServletContext.getRealPath and HttpServletRequest.getPathTranslated

    Details

    • Type: Bug Bug
    • Status: In Progress
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      There appear to be different interpretations of the required behaviour of ServletContext.getRealPath(java.lang.String path) and HttpServletRequest.getPathTranslated() if the virtual path can be mapped to a physical path but the physical path does not exist.

      My reading of the specification and the Javadoc is that the physical path does not have to exist, just that the mapping has to be possible. However, I can see how someone else could read the specification as requiring the physical path to exist and null to be returned if it does not.

      This should be clarified for Servlet 3.1 and ideally the clarification included in any subsequent maintenance releases of the earlier specification versions.

        Activity

        markt_asf created issue -
        Hide
        gregwilkins added a comment -

        I think the text should be changed to indicate that a path should be returned if it possibly could exist.

        Typically this would mean that if getRealPath("/") returns a non null path, then all calls to getRealPath should not be null.

        Show
        gregwilkins added a comment - I think the text should be changed to indicate that a path should be returned if it possibly could exist. Typically this would mean that if getRealPath("/") returns a non null path, then all calls to getRealPath should not be null.
        Rajiv Mordani made changes -
        Field Original Value New Value
        Assignee Rajiv Mordani [ mode ]
        Hide
        Rajiv Mordani added a comment -

        In section 3.6 of the spec we clearly say

        In situations where the servlet container cannot determine a valid file path for these methods, such as when the Web application is executed from an archive, on a remote file system not accessible locally, or in a database, these methods must return null. Resources inside the META-INF/resources directory of JAR file must be considered only if the container has unpacked them from their containing JAR file when a call to getRealPath() is made, and in this case MUST return the unpacked location.

        and the javadocs also says along the same lines. What do you think will make it clearer?

        Show
        Rajiv Mordani added a comment - In section 3.6 of the spec we clearly say In situations where the servlet container cannot determine a valid file path for these methods, such as when the Web application is executed from an archive, on a remote file system not accessible locally, or in a database, these methods must return null. Resources inside the META-INF/resources directory of JAR file must be considered only if the container has unpacked them from their containing JAR file when a call to getRealPath() is made, and in this case MUST return the unpacked location. and the javadocs also says along the same lines. What do you think will make it clearer?
        Rajiv Mordani made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        markt_asf added a comment -

        If memory serves me correctly this wasn't a WAR/database/virtual vs local filesystem issue. If was purely in the context of a local file system when everything is unpacked.

        Take, for example, a WAR with context path "/foo" unpacked on the local file system to "/usr/local/webapps/foo".

        Assume that there also exists the directory "/usr/local/webapps/foo/bar"

        When called from the "foo" web application, getRealPath("/bar") will return "/usr/local/webapps/foo/bar".

        The question is, what should getRealPath("/other") return?

        Should it:
        a) return "/usr/local/webapps/foo/other" since that what it maps too?
        b) return null since "/usr/local/webapps/foo/other" does not exist?

        This really boils down to what does the specification mean by valid in section 3.6? I think we need to make it clear that "valid" does not mean "must exist".

        I've dug through the archives and the Tomcat bug that prompted this request for clarification was this one: https://issues.apache.org/bugzilla/show_bug.cgi?id=51799

        Show
        markt_asf added a comment - If memory serves me correctly this wasn't a WAR/database/virtual vs local filesystem issue. If was purely in the context of a local file system when everything is unpacked. Take, for example, a WAR with context path "/foo" unpacked on the local file system to "/usr/local/webapps/foo". Assume that there also exists the directory "/usr/local/webapps/foo/bar" When called from the "foo" web application, getRealPath("/bar") will return "/usr/local/webapps/foo/bar". The question is, what should getRealPath("/other") return? Should it: a) return "/usr/local/webapps/foo/other" since that what it maps too? b) return null since "/usr/local/webapps/foo/other" does not exist? This really boils down to what does the specification mean by valid in section 3.6? I think we need to make it clear that "valid" does not mean "must exist". I've dug through the archives and the Tomcat bug that prompted this request for clarification was this one: https://issues.apache.org/bugzilla/show_bug.cgi?id=51799
        Hide
        Rajiv Mordani added a comment -

        The getRealPath should return the real paths for resources that are available. So to be specific - in the example above if "other" does not exist in the webapp then it should return null. Looking at the issue filed for tomcat, Remy seems to suggest that it return the path so it is possible to create a file / directory using it. We can discuss this in the EG.

        Show
        Rajiv Mordani added a comment - The getRealPath should return the real paths for resources that are available. So to be specific - in the example above if "other" does not exist in the webapp then it should return null. Looking at the issue filed for tomcat, Remy seems to suggest that it return the path so it is possible to create a file / directory using it. We can discuss this in the EG.
        Ed Burns made changes -
        Assignee Rajiv Mordani [ mode ]

          People

          • Assignee:
            Unassigned
            Reporter:
            markt_asf
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: