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
