Greetings. Maybe I should rephrase my question. I do know how and why the behaviour is as it is...
Rephrased question: In earlier versions of tomcat - if an exception was thrown and "bubbled" up before the response was committed, it was redirected to the error page. No problem. If the reponse had already flushed, then the tomcat internals would manually request the set error page, passing it the exception, and would append the output of the manual error page call to the reponse, then flush, then return. Is that correct? Is there a reason this is no longer being done? I will emulate it in my system (or at least investigate the viablility therof) if this was taken out for a particular reason. Thanks, Carl -----Original Message----- From: Steven J. Owens [mailto:[EMAIL PROTECTED] Sent: Thursday, November 11, 2004 12:07 PM To: Tomcat Users List Subject: Re: Buffering and redirection to the errorPage On Thu, Nov 11, 2004 at 11:28:21AM +1100, Derek Clarkson wrote: > This sounds like something I have encountered. The basic question is > that how do you redirect to an error page if youa re writing to the > output stream rather than going to another JSP, and have an exception > ? I thought I posted a reply to this earlier, but I don't see it in my inbox, so maybe I should repost. In a nutshell, this topic makes a lot more sense if you understand what an HTTP request and an HTTP response really look like. My number one recommendation to folks doing web applications is to get a packet sniffer, or a logging proxy, and take a look at what the browser and server are actually sending back and forth. Each HTTP request and response look a lot like an ordinary email: a series of header lines, a blank line, and a message body. The header lines are all name: value. In an HTTP response the body is the HTML of the page, or the binary data of an image. In some cases there is no body at all (a client-side redirect, for example). Any logical operation is handled with a header - setting a cookie, redirecting the browser, etc. Once the blank line separating the header from the body has been sent, you can't go back and send another header line. So you _must_ do any sort of redirect before the server starts to flush output back to the client. If you try to set a header after the server has already sent the blank lnie separating the headers from the body, you'll get a java.lang.IllegalStateException. One way to make this easier to do is to set your buffer larger, so the server will wait longer before flushing output to the browser. Another way is to use an MVC architecture. Have the submit from the browser go to a servlet that does any logical processing you need, but doesn't send any output back to the user. Instead, the controller servlet sets request attributes and user session attributes containing the results of the logic, then redirects the request off to the right view page. The view page looks for the request attributes and user session attributes and generates HTML tags for the display. The controller doesn't muck with display stuff, the view page doesn't muck with the headers. -- Steven J. Owens [EMAIL PROTECTED] "I'm going to make broad, sweeping generalizations and strong, declarative statements, because otherwise I'll be here all night and this document will be four times longer and much less fun to read. Take it all with a grain of salt." - http://darksleep.com/notablog --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
