[Bug 56890] getRealPath returns null
https://bz.apache.org/bugzilla/show_bug.cgi?id=56890 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Mark Thomas --- Fixed in: - 10.0.x for 10.0.0-M11 onwards - 9.0.x for 9.0.41 onwards - 8.5.x for 8.5.61 onwards 7.0.x was not affected. -- 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
[Bug 56890] getRealPath returns null
https://bz.apache.org/bugzilla/show_bug.cgi?id=56890 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #9 from Mark Thomas --- One of the benefits of moving to Eclipse is that is that progress on issues like this is no longer dependent on a single spec lead who may have other priorities. The consensus is that the following will be added for Servlet 5.1 onwards: The path should begin with a "/" and is interpreted as relative to the current context root. If the path does not begin with a "/", the container will behave as if the method was called with "/" appended to the beginning of the provided path. I'll update Tomcat to the new behaviour shortly. -- 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
[Bug 56890] getRealPath returns null
https://bz.apache.org/bugzilla/show_bug.cgi?id=56890 --- Comment #8 from Mark Thomas --- Updating the location again: https://github.com/eclipse-ee4j/servlet-api/issues/105 -- 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
[Bug 56890] getRealPath returns null
https://bz.apache.org/bugzilla/show_bug.cgi?id=56890 Mark Thomas changed: What|Removed |Added CC|e.barg0...@icloud.com | Status|NEW |NEEDINFO -- 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
[Bug 56890] getRealPath returns null
https://bz.apache.org/bugzilla/show_bug.cgi?id=56890 Ebarg changed: What|Removed |Added CC||e.barg0...@icloud.com Status|NEEDINFO|NEW -- 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
[Bug 56890] getRealPath returns null
https://bz.apache.org/bugzilla/show_bug.cgi?id=56890 --- Comment #7 from Mark Thomas --- Updated location for the Servlet-spec issue. https://github.com/javaee/servlet-spec/issues/105 -- 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
[Bug 56890] getRealPath returns null
https://issues.apache.org/bugzilla/show_bug.cgi?id=56890 James Velasco changed: What|Removed |Added Hardware|PC |All OS|Linux |All -- 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
[Bug 56890] getRealPath returns null
https://issues.apache.org/bugzilla/show_bug.cgi?id=56890 --- Comment #6 from Mark Thomas --- https://java.net/jira/browse/SERVLET_SPEC-105 -- 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
[Bug 56890] getRealPath returns null
https://issues.apache.org/bugzilla/show_bug.cgi?id=56890 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #5 from Mark Thomas --- (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://:/' 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://:/ getRealPath(".")-> http://:/. getRealPath("./") -> http://:/./ getRealPath("/")-> http://:// getRealPath("test") -> http://:/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
[Bug 56890] getRealPath returns null
https://issues.apache.org/bugzilla/show_bug.cgi?id=56890 --- Comment #4 from Remy Maucherat --- +1 for invalid. -- 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
[Bug 56890] getRealPath returns null
https://issues.apache.org/bugzilla/show_bug.cgi?id=56890 --- Comment #3 from f.bant...@axon-e.de --- I have no strong opinion on this. Just a few thoughts: 1. getResource() is fundamental different to getRealPath(). Above all getResource( "/in_war/something" ) would return data whereas getRealPath( "/in_war/something" ) would return null. 2. There is nothing in the spec which tell that getRealPath() must start with a slash. At least not as far as I can see. (IMHO the spec for the whole servlet api is fubar anyway...) So the new behavior is not more strict but just different. 3. The leading slash in the path of urls is kind of inexistent anyway. (In complete urls there is no "leading slash". Just a separator between the host and the path) 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. 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) 6. To be consistent getRealPath( "" ) should return null, too. 7. Why fix what's not broken? 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 ;) Best Regards Scheintod -- 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
[Bug 56890] getRealPath returns null
https://issues.apache.org/bugzilla/show_bug.cgi?id=56890 --- Comment #2 from Mark Thomas --- I'm leaning towards resolving this as invalid. While the spec and the Javadoc could be clearer, it seems pretty obvious that a 'virtual path' is 'servletPath + pathInfo' along the lines of section 3.5 of the Servlet spec. Therefore, requiring that the virtual path is either empty or starts with '/' seems reasonable. It is not unusual for one major verison of Tomcat to interpret a specification more strictly than the previous major version. Such changes are to be expected across major versions and certainly do not qualify as bugs. If these changes are causing problems, then they can be added to the migration guide. An argument could be made that the virtual path, if it doesn't start with '/', should be taken as being relative to the ServletContext root - i.e. append '/' and then process it. I'm not convinced that that argument is valid since there is nothing I see in the specs or the Javadoc to support it. -- 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
[Bug 56890] getRealPath returns null
https://issues.apache.org/bugzilla/show_bug.cgi?id=56890 --- Comment #1 from Konstantin Kolinko --- Resource paths are expected to start with a "/" (per javadoc of ServletContext.getResource()). [1] The behaviour in Tomcat 8 is caused by a more strict underlying Resources implementation. That said, - I would expect "strict compliance" option (or more specifically GET_RESOURCE_REQUIRE_SLASH option) to control this behaviour both in this and in older versions. Apparently it is not so. [2] - I wonder whether passing "" instead of "/" to getRealPath("") is valid. [1] http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getResource%28java.lang.String%29 [2] http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification -- 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