On 12/12/2012 08:10, Rajiv Mordani wrote:
> All,
> The issue http://java.net/jira/browse/SERVLET_SPEC-11 talks about
> ServletContext.getRealPath and HttpServletRequest.getPathTranslated().
> In particular what should the behavior be for a resource not speicifed.
> In my opinion, based on the spec if a resource does not exist then the
> methods should return null.
My reading of the specification differs. I don't see any language in
section 3.6 that requires the path to map to a file that exists. All the
examples in that last paragraph are cases where the concept of a local
file system does not exist.
I also checked the Javadoc. Again, I didn't see any obvious language
that clarifies this one way or the other. This is as far as I got when I
raised this issue.
This time I went a little further. I looked harder at
HttpServletRequest.getPathTranslated() since that states "Same as the
value of the CGI variable PATH_TRANSLATED". A little googling lead me to
RFC 3875. While that is not a formal standard, it does define 'current
practice' which is as good as you are ever going to get for CGI.
Section 4.1.6 of RFC 3875 addresses PATH_TRANSLATED. At the top of page
15 about half way through section 4.1.6 there is the following text:
"The value is derived in this way irrespective of whether it maps to a
valid repository location."
Therefore, given that stated requirement in the Javadoc that the
behaviour is the same as that for CGI, I believe the specification
should be clarified to make clear that, in Greg's words "...a path
should be returned if it possibly could exist." to save others having to
dig through RFC 3875 to figure out the expected behaviour.
> If we change this behavior then this has the
> potential of breaking backwards compatibility.
There is only a backwards compatibility issue if the implementation has
not noticed the implications of RFC 3875 in which case I would argue
that is a bug in that implementation.
> I would like to keep the
> return null semantics but would like to hear what others think.
There are no return null semantics to keep as the Servlet specification
does define the required behaviour (which is to not return null), just
in a very roundabout way.
Mark