tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juha Laiho <>
Subject Request dispatching oddity
Date Mon, 10 Dec 2012 21:14:03 GMT

I encountered an odd situation with request dispatching.

Java platform: Oracle 1.7 (7u9)
Tomcat platform: 7.0.32, 7.0.33
Operating systems: Linux, Windows (likely irrelevant)
Browser: Firefox 17

In short, if the same request is first redirected using servlet API
RequestDispatcher.forward(), and then via JSTL c:redirect using a
relative target, the end result seems incorrect.

So, consider a web app with /WEB-INF/web.xml as:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns=""

... and /sub/index.jsp as:

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
RequestDispatcher rd = application.getRequestDispatcher("/");
rd.forward(request, response);

... and /index.jsp as:

<%@taglib prefix="c" uri=""%>
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<c:redirect url="sub/page.jsp"/>

(sub/page.jsp contents omitted as irrelevant for now)

Then, consider a request to http://server/context/sub/index.jsp .
Looking at the above, I would expect:
- the request to be first processed by /sub/index.jsp (this happens)
- next by /index.jsp (this happens, too)
- ending with showing http://server/context/sub/page.jsp (this doesn't happen!)

Instead, the error is "The requested resource
(/RedirT/sub/sub/page.jsp) is not available.".
Note the "sub" path component being listed twice.

So, it is as if the first redirect (using the RequestDispatcher
manually, in /sub/index.jsp) fails to reset
the "current" location for the requested component from /sub to /, and
then subsequently, the c:redirect
in /index.jsp adds another "sub" to the request path.

If, on the other hand, the latter redirect is done with an address
bound to context root (i.e. /sub/page.jsp,
instead of sub/page.jsp), the request ends up in the expected place.
Also, if the first redirect is done with
<c:redirect> rather than the RequestDispatcher, the request ends up in
the expected place.

This structure looks admittedly odd, but part of that came from
producing this SSCCE; the original context
was that the initial RequestDispatcher.forward() was located inside a
filter class (but similarly, forwarded
a request targeted to a resource in a subdirectory to /index.jsp,
which in turn contains the c:redirect to
another resource within the same subdirectory. I encountered this when
moving an application from
a WebLogic 9.2 server (where this structure had worked without issues)
to a Tomcat server (where this
"not found" error appeared.

Any comments? Did I come across a but in Tomcat, or a "lucky bug" in
the application (i.e. something
that worked by luck in the previous container)? While I can (and did)
change the application so that the
c:redirect in /index.jsp now uses a context-absolute addressing, I'd
be interested in hearing the actual
verdict. I tried to read the servlet specification, but could not find
an exact description covering this case.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message