On 21/06/2019 11:04, Tommy Pham wrote: <snip/>
> Thank you for the clarification and the heads up. I greatly appreciate it. > I've been thinking about different methods of approach and I think this is > better than servletPath + pathInfo: > > return getServletContext() == null ? null : getServletContext(). > getRealPath(getRequestURI().substring(getContextPath().length())); > > due to less conditional checks yielding better execution time and since I > can't see any condition that either requestURI or contextPath could be null: getRequestURI() is not normalized and is still encoded. You need decoded values for getRealPath(). getServletPath() and getPathInfo() are both normalized and decoded. The null checks are going to be a lot cheaper than the decoding. That said, it would be unusual for that timing difference to be significant. Most web applications seem to spend a lot of time doing "stuff". Also keep in mind that these can be security sensitive operations. If you aren't careful you'll open up directory traversal vulnerabilities. <snip/> You want to use nanoTime to get a better idea of timings and you should repeat that operation many times. I usually start with 100,000 iterations and then adjust up/down until I have something that takes ~10s and then take the average. > As for the new method of getRealPath(), how does the web container knows > which is the correct one? getRealPath() takes whatever path is provided and returns whatever file, if any, is at that location relative to the web application root. In the case of the method I was proposing for ServletRequest it would do something like: getServletContext().getRealPath(getServletPath() + getPathInfo() == null ? "" : getPathInfo()) Keep in mind that not all web applications are deployed on a file system. If the web application is deployed as a WAR you'll get null back. Mark > Does it then check if the file actually exists > for both getRealPath() and getPathTranslated() and compare? Going forward > to have progress of my project, I'll have write to my own servlet to handle > static content instead of forwarding to TC's default servlet. On the > bright side, I think I can have stricter enforcement ie: "/css/*.css" > > Thanks, > Tommy --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
