JSTL URLs, Imports & Redirects

Whether the ;jsessionid=... part appears depends on the container’s session tracking, not on the tag. On the first response to a client that has not yet returned the cookie, Tomcat cannot know that cookies work, so encodeURL adds the id. Once the browser sends the cookie back, the same page produces clean URLs. The page links.jsp makes the difference visible; the first request carries no cookie, the second one does:

Source: Jakarta Servlet 6.1 API — HttpServletResponse.encodeURL

Source: Jakarta Servlet 6.1 — 7.1 Session Tracking Mechanisms

Two consequences follow. A page that links every internal URL through c:url works with and without cookies, and one that writes /g5jstlurls/books by hand works only with cookies (and breaks if the application is deployed under another context path). And the session id in the path is a security problem of its own: the Servlet specification says URL rewriting "exposes session identifiers in logs, bookmarks, referer headers, cached HTML, and the URL bar" and "should not be used" where cookies are supported (7.1.3). The fix is to turn it off, not to stop using c:url: with <tracking-mode>COOKIE</tracking-mode> in the session-config of web.xml, the same page produced /g5jstlurlsd/books/1 and /g5jstlurlsd/books?q=Frank+Herbert&page=1 for a cookie-less client (observed on a further deployment of the same WAR with only that element added). c:url still adds the context path, which is its main value. The sessions section of Servlet Fundamentals discusses tracking modes, and the Struts and Spring tags that do the same job are in The Same Job in Spring, Struts and Thymeleaf.

Source: Jakarta Servlet 6.1 — 7.1.3 URL Rewriting

context names another web application on the same container, so that a link to it gets its context path rather than the current one. Both the context name and the URL must start with a slash; anything else is a JspTagException. A rewritten URL for another context carried no session id in the observed run, because Tomcat’s encodeURL only rewrites URLs of the same application.

Source: Jakarta Standard Tag Library 3.0 — 7.5 c:url (Description)

Non-ASCII characters are encoded with the character encoding of the response, not with a fixed UTF-8. Three variants of the same line, <c:param name="q" value="é"/>, in pages that differ only in their directives:

Source: Jakarta Standard Tag Library 3.0 — 7.7 c:param

The first result is the right one: the encoded bytes are those of the response encoding, and the servlet that receives the request must decode them with the same charset (the request-encoding section of the character encoding page covers setCharacterEncoding and the request-character-encoding element). The second is consistent but wrong for a UTF-8 application, since a servlet configured for UTF-8 reads %e9 as an invalid sequence. The third is the classic double encoding (%c3%83%c2%a9), caused by a missing pageEncoding, not by c:param. On Tomcat 11.0.26 the response encoding was UTF-8 even for a plain text/html page without a charset; do not rely on that, set pageEncoding and contentType (or the page-encoding property) explicitly. The details are in Character Encoding.

c:param only appends to the end of the URL string, and it knows nothing about a fragment or an existing query string. Observed:

Source: Jakarta Standard Tag Library 3.0 — 7.7 c:param

The first result is broken: the parameter ended up inside the fragment, so the browser never sends it. Add the fragment after the URL has been built (${url}#top, inside c:out when it goes in an attribute). The second works, but the new parameter came out in front of the existing one, so do not rely on the order, and prefer to give every parameter to c:param rather than mixing a hand-written query string with it. The c:param description in the tag documentation says it adds a parameter to "a containing 'import' tag’s URL"; it is valid in c:url and c:redirect as well, as the specification says.

The page import.jsp imports one small view, footer.jsp, a one-line fragment that prints the request attribute who, the parameters q and extra, and the context path, and then the echo servlet through an absolute URL, and a page of the second application:

Source: Jakarta Standard Tag Library 3.0 — 7.2 Importing Resources

Source: Jakarta Standard Tag Library 3.0 — 7.2.2 Exporting an object: String or Reader

Read the output as the contract of the three kinds:

var and varReader differ in what they cost and promise. The String is kept in the scope you ask for, can be reused and is not escaped when written with ${footer} in template text, so print it with c:out unless it is trusted markup (the escaped line above). The Reader avoids the buffering of the whole content (7.2.2: the benefit "is not guaranteed", it depends on the implementation) and exists only between the start and end tags; on Tomcat 11.0.26 it was a java.io.StringReader, so the content had been read anyway. A c:param inside a varReader import is rejected when the page is compiled:

Source: Jakarta Standard Tag Library 3.0 — 7.4 c:import (Description)

The reason is in the specification: the reader must be available at the start tag, so the URL cannot still be changing. Build the URL with c:url and its parameters first, and pass it to c:import (7.4).

An imported resource is text, so c:import must know its encoding. With charEncoding absent it uses the charset of the Content-Type response header of the resource, and if there is none (or it is unsupported) ISO-8859-1 (7.4, "Character Encoding"). The specification expects charEncoding to be needed "normally only" for non-HTTP absolute URLs, but any HTTP resource that sends UTF-8 without declaring it needs it as well. A servlet that writes café in UTF-8 under a plain Content-Type: text/plain:

Source: Jakarta Standard Tag Library 3.0 — 7.4 c:import (Character Encoding)

The cure is better done at the source: declare the charset in the Content-Type of everything the application serves (see the character encoding page).

A failing import throws; the specification lists the cases ("Null and Error Handling", 7.4). The page import-404.jsp imports six failing resources inside c:catch:

Source: Jakarta Standard Tag Library 3.0 — 7.4 c:import (Null and Error Handling)

Case 2 shows the status rule for an internal resource: a non-2xx status set by the imported page becomes a JspTagException with the status and path. Case 3 and 4 are the absolute-URL failures, wrapping FileNotFoundException (a 404) or an IOException. Case 6, a context that does not exist, was reported as a missing file ("JSP file …​ not found") rather than as a missing context; a context that exists but is not reachable gives a different message, see below. Because the message of case 3 contains the URL, never print an exception message to the visitor when the URL held anything secret.

context="/g5jstlurlsb" imports a page of another web application, through that application’s RequestDispatcher. Tomcat allows it only if the importing application’s Context has crossContext="true", which the scratch WAR sets in META-INF/context.xml; the includes page says that case was not exercised there, so here are both outcomes. The same import-foreign.jsp was deployed twice, once with the setting and once without:

Source: Apache Tomcat 11 — Context, crossContext

Source: Jakarta Standard Tag Library 3.0 — 7.4 c:import (Relative URL - foreign context)

The specification itself warns that foreign-context imports "may not work in all containers" and suggests an absolute URL as the portable alternative, at the price of a real HTTP round trip and none of the page’s environment (7.4). Cross-context dispatching weakens the isolation between applications, so enable it only for applications that trust each other. If the container sits behind a proxy and an absolute URL must leave through it, the JVM needs the networking properties (http.proxyHost, http.proxyPort and their https twins, 7.2.4), which apply to every URLConnection of the container, not only to this page.

Source: Jakarta Standard Tag Library 3.0 — 7.2.4 Networking Properties

Source: Java SE 21 — Networking Properties

c:import is the one action on this page that makes the server do something on behalf of a request. With a url taken from a parameter it is both server-side request forgery (CWE-918) and a file-disclosure hole, as the page import-file.jsp shows:

Source: CWE-918 — Server-Side Request Forgery

Source: OWASP — Server-Side Request Forgery Prevention Cheat Sheet

The first request returned the application’s own descriptor (a relative import is dispatched inside the container, so the rule that hides WEB-INF from browsers does not apply), the second read a local file through the file: scheme of URLConnection, and the third made the container call an internal service (the 401 is the target’s answer; with an unprotected internal host or a cloud metadata address the content would have been returned). The defence is the one given for jsp:include: never pass request data as url; map a short key to a fixed target in the controller or in an allowlist and import only that; if the URL must vary, build it with c:url from a fixed base and parameters. The example of an allowlist is in the security section of the includes page. Also remember that c:import of an external site puts its content on your origin: unescaped markup from another site becomes cross-site scripting (print it with c:out unless it is trusted), and its slowness becomes yours (a request thread waits on the remote server, with the JDK default of no timeouts). A view is the wrong place to call a remote service; call it from the controller or a service with a client that has timeouts, and give the view the result.

c:redirect with a url from a request parameter is an open redirect (CWE-601): the page is a trusted site that sends visitors to an address of the attacker’s choosing, which phishing links use.

Source: CWE-601 — URL Redirection to Untrusted Site

Source: OWASP — Unvalidated Redirects and Forwards Cheat Sheet

Any absolute URL is sent as it is. The context-path rule gives some protection to scheme-relative forms (the //evil.example/x row above was turned into a path of this application), but that is a side effect of the implementation, not a safeguard to rely on. Redirect to a path chosen by the application (a fixed target, or a key looked up in a map), and when a return address must come from the user, accept only a path that starts with a single /, contains no scheme, host or backslash, and resolves to a known page of the application.