https://issues.apache.org/bugzilla/show_bug.cgi?id=51952
--- Comment #11 from Christopher Schultz <ch...@christopherschultz.net> 2011-10-05 21:36:31 UTC --- (In reply to comment #6) > If you look at the JSP source in question, it simply calls sendRedirect() in a > scriptlet. The issue here is that the auto-generated JSP source, whitespace, > etc, will try to write more stuff after that call. > > It would probably be more correct to do: > response.sendRedirect(...); > return; > in the scriptlet -- which may avoid the issue. > > In any case this sort of attention to detail wasn't necessary prior to this > change, though, so there are bound to be existing JSP pages, servlets, etc, > where this sort of sloppiness exists. Thus I believe we should endeavor to be > forgiving to such cases. The same could be true for a JSP that calls sendRedirect and then continues to produce (lots of?) output. It seems reasonable for Tomcat to allow webapps to provide their own "redirect" response bodies, too. I'm starting to lean towards Mark's suggestion of having this be an application-wide setting (though being able to enable/disable it on a per-request basis might also be nice). > Also using an output stream rather than a writer won't solve the issue as I > believe the JSP page in question would then produce an exception *without* a > compression filter in place. I think I wasn't thinking clearly when I asked my original question about the wrapper being in place: the root cause is that the compression filter hasn't called response.getOutputStream before delegating the call down the filter chain. When sendRedirect() is called, getWriter is called which (IMHO) cause the opposite exception to be thrown: IllegalStateException: getOutputStream has already been called. There are places in (Tomcat's?) code where IllegalStateException is caught when calling getWriter (or getOutputStream) and then the code switches-over to use the other strategy to accommodate the current situation. Maybe Tomcat's sendRedirect code should be augmented to do such error recovery. Finally, I just have to say it: JSP can be abused in /so many/ ways, and performing a redirect from a JSP is one such example. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
