-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Juha,
On 12/10/12 4:14 PM, Juha Laiho wrote: > I encountered an odd situation with request dispatching. > > 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. Small nit: requests are not redirected when you call RequestDispatcher.forward(). > So, consider a web app with /WEB-INF/web.xml as: > > <?xml version="1.0" encoding="UTF-8"?> <web-app version="2.5" > xmlns="http://java.sun.com/xml/ns/javaee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd";> > <display-name>RedirT</display-name> <welcome-file-list> > <welcome-file>index.jsp</welcome-file> </welcome-file-list> > </web-app> > > > ... and /sub/index.jsp as: > > <%@page contentType="text/html" pageEncoding="UTF-8"%> <!DOCTYPE > html> <% RequestDispatcher rd = > application.getRequestDispatcher("/"); rd.forward(request, > response); %> I realize that this is probably a contrived example, but the above JSP technically produces output. That can interfere with any container's ability to forward a request to another resource. The response buffer is probably big enough to avoid any such problems, but I felt it was worth mentioning. > ... and /index.jsp as: > > <%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%> > <%@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. You need to fully-qualify the url you use in your <c:redirect> tag. Since you didn't start the URL with "/", you are getting this URL build: http://host/context/sub/index.jsp - "index.jsp" + "sub/page.jsp" = http://host/context/sub/sub/page.jsp > 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. URLs are typically based upon the currently-executing request. Performing a forward() does not change the context of the original request (for better or worse) and thus is the problem, here. You pretty much need to use fully-qualified URLs for *everything* /all the time/. Try: <c:redirect url="/sub/page.jsp"/> Note that the default "context" attribute for the <c:redirect> tag (I assume you are using JSTL) is the current webapp. So, starting your URL with "/" means that the URL will be relative to the current context (webapp), not relative to the current host. > 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. A redirect involves the client, and changes the URL context of the request, so it will work. > 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)? Yeah, I think this probably should not have worked in WebLogic, but it's possible that there is room for interpretation in the spec (it certainly wouldn't be the first time). > 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. I'll take a look. You definitely want to use URLs that start with "/" in all cases to prevent this kind of ambiguity. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDGZOUACgkQ9CaO5/Lv0PDLHQCeOcR41slZ3Td92W/KIkkvTD7q djEAoMN4lBVe0uLdz70tRcXhKRmQA0ue =Pm2d -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
