For various reasons, I am generating a URL for a context relative resource using <c:url> and storing the result in a variable. Then I'm using that value in a <c:import> in an attempt to include the content of the resource in the page. Example: <!-- Stores "/myContext/text.html" in the variable textURL --> <c:url value="/text.html" var="textURL" /> <!-- attempts to insert the contents of text.html in the page, but nothing happens --> <c:import url="${textURL}" /> I'm pretty sure the problem is that <c:url> generates a url with a leading slash followed by the context name, when <c:import> expects URLs that start with a slash to be relative to the current context. The spec says: "In such a situation, <c:url> may be used to build a URL with query string parameters. <c:import> will remove any session id information if necessary (see Section 7.5)." -From section 7.4 That seems to imply that values generated by <c:url> should be useable by <c:import>
As you've noticed, the output of <c:url> cannot be used with <c:import> when the value specified for <c:url> is a relative URL that starts with a '/'. That is because the context path is then prepended to the URL. And I agree with you that the following paragraph in the spec is misleading: Section 7.4: ... It is therefore impossible for nested <c:param> actions to modify the URL of the resource to be accessed, thus their illegality with syntax 2. In such a situation, <c:url> may be used to build a URL with query string parameters. <c:import> will remove any session id information if necessary (see Section 7.5). It should be clearly stated that using the output of <c:url> for <c:import> won't work for context relative URLs (that start with a '/'). I've taken note and this will be fixed in the next release of the spec.