https://issues.apache.org/bugzilla/show_bug.cgi?id=56890
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #5 from Mark Thomas <ma...@apache.org> ---
(In reply to f.bantner from comment #3)
> I have no strong opinion on this. Just a few thoughts:
>
> 1. getResource() is fundamental different to getRealPath().
Yes and no. The purpose is very different but they both take a path relative to
the base of the servlet context.
> 2. There is nothing in the spec which tell that getRealPath() must start
> with a slash.
I think it is strongly implied but I agree it could be clearer.
> 3. The leading slash in the path of urls is kind of inexistent anyway.
Regardless, the servlet spec uses leading '/'
> 4. The main advantage of not answering to requests for path's without a
> leading slash would be imho that the developer (say me) who is already
> confused about the **** servlet api is remindet that this is an absolute
> path. On the other hand throwing an exception would be the right thing to
> take in this case.
The Javadoc for getRealPath() strongly suggests returning null rather than
throwing an exception.
> 5. The spec says: "This method returns null if the servlet container cannot
> translate the virtual path to a real path [...]". The key here is "cannot".
> How it stands right now it is a "doesn't want to". (The server could
> translate it if it wanted to)
At this point, I really do wish the spec was clearer. I'll raise a bug and see
if we can get this addressed for Servlet 3.2. When a later spec clarifies
something, Tomcat often back-ports the clarification to earlier versions.
I've re-read the Javadoc for getRealPath() several times. It could be read as
"Take the value of path, append it to 'http://<host>:<port>/<contextPath>' and
return the absolute path on the file system that that request would be mapped
to or null if that is not possible."
The 'interesting' part here is that path gets appended to something that does
not end in '/'. Taking your 5 examples from earlier, that gives us:
getRealPath("") -> http://<host>:<port>/<contextPath>
getRealPath(".") -> http://<host>:<port>/<contextPath>.
getRealPath("./") -> http://<host>:<port>/<contextPath>./
getRealPath("/") -> http://<host>:<port>/<contextPath>/
getRealPath("test") -> http://<host>:<port>/<contextPath>test
The first and fourth examples should be OK (assuming the web app is expanded).
The others will fail.
This is actually (more by luck than judegment) how Tomcat is behaving now. I'm
not entirely comfortable with this. I'd be happier with either a requirement
that the path must start with / (else an IAE is thrown) or a requirement the
'/' is prepended if not present.
> 6. To be consistent getRealPath( "" ) should return null, too.
It depends what you are being consistent with. See my response to point 5 that
demonstrates that the current behaviour is consistent with at least one point
of view.
> 7. Why fix what's not broken?
The resource handling was almost impossible to maintain. It was horribly
fragile and implementing what - then - was expected to be in Servlet 3.1 in
terms of overlays would have been a nightmare. The new resource handling is
much more robust and provides much more consistent behaviour. What we have here
is yet another grey area in the Servlet spec that needs some clarification.
> 8. Finally: For my part I replaced my "./" string (after some heavy
> searching for the problem) with "/" and everything worked again. (I won't
> change this back anyway). But this was the first time I had to fix something
> for Tomcat upgrades since Tomcat 5. And I liked that very much ;)
I'm fairly sure that however the Servlet EG clarifies this, that starting with
"./" will end up being invalid so I think you were going to have to change this
sooner or later. It is nice to know that for well written applicaitons that
follow the spec the upgrade process is as smooth as it is meant to be.
I'm going to leave this in the NEEDINFO state until we get some clarification
from the Servlet EG.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
