I'm not sure from the spec what the intended behavior here is, but the current implementation appears to behave a bit inconsistently. From a jsp at the top dir of my webapp, if I try to: a) <c:import url="WEB-INF/somefile" var="foo"/> or b) <c:import url="/WEB-INF/somefile" var="foo"/> foo does not get bound to anything. However, if i do: c) <c:import url="./WEB-INF/somefile" var="foo"/> Then things "work". From a user perspective you'd expect a) and c) to both be considered relative and either work or not work together, while b) is absolute and could be different. I would prefer that the contents of WEB-INF be visible in all cases, but I'm not sure I understand what the specs say on this. From examining org/apache/taglibs/standard/tag/common/core/ImportSupport.java it looks like targetUrl gets normalized to be absolute in acquireString by prefixing the servlet path, causing this. This problem is particular to the WEB-INF directory; all other directories have behaved fine.
Hi there. Thanks for the report. I agree that the behavior you describe is somewhat awkward, but this one's not ours. In the first two cases, we're acquiring a RequestDispatcher for "/WEB-INF/foo.txt"; in the final one, we're acquiring one literally for "/./WEB-INF/foo.txt", which I believe is acceptable to the JSTL spec. The problem is that the underlying container (Tomcat in my case, and probably in yours too if you experience the same behavior) treats these differently. I'm not 100% sure which is the bug; I believe it depends on how you read the Servlet spec, though others claim they're sure that RequestDispatcher *should* be able to retrieve content from within /WEB-INF. Either way, the inconsistency isn't ours; it's the underlying container's. Sorry. If this is a show-stopper for you, I suggest you submit a bug report to the Tomcat team, in terms of the behavior of ServletContext.getRequestDispatcher() (not in terms of <c:import>, with which they might not be familiar). I'd submit the bug report myself, but I'm swamped and don't have time to test on the various Tomcat versions at the moment. Please let me know if you have some additional reason, contrary to what I have suggested here, indicating this is indeed a JSTL bug. Thanks again for the report.
By the way, it could also just be a configuration issue: can your security manager be made less restrictive?
Ignore that last comment; it was for a different bug.