thanks remy for the information that helps. What if I decide to buffer
the response myself in a response wrapper? Does catalina try to call
clearBuffer, reset, resetBuffer, flush or flushBuffer in the event a
request is passed to my errorpage? Also, does the status code change
and the exception set in the request object with
request.setAttribute("Throwable") if html has already been sent to the
browser?
In cases where the exception occurs before any content is sent to the
browser, it all works fine. I need to ensure exceptions display my
custom errorpage, but I'd rather not set the page buffer to an
arbitrarily large 64K or 100K.
peter lin
Remy Maucherat wrote:
>
> peter lin wrote:
>
> > On a related note to flushing. I've discovered a bug, but don't want to
> > file one until I know for sure it's not a duplicate of the other flush
> > bugs already in bugzilla.
> >
> > The bug is the following:
> >
> > if a page throws an exception and an errorPage directive is set, the
> > resulting error page will print out anything left over from the parent
> > page and the errorpage. That means .... and everything preceding
> > the exception is written to the browser. One way around this I found was
> > to set the buffer to a large size, like buffer="64K".
> >
> > To reproduce the bug:
> >
> > create a page with some html (has to be more than the default buffer
> > size), towards the bottom throw an exception.
> > create a custom error page.
> > using a browser load the page and the resulting out put should contain
> > html from both pages.
> >
> > This bug can be reproduced with autFlush set to true and false. If
> > people are busy, I'm willing to spend a couple hours going through the
> > code to find a fix and submit a patch. If it's not a bug, any pointers
> > would be appreciated.
>
> If the buffer size is exceeded, then some data (the top of your page)
> will get sent to the client.
> After that, when the exception occurs, there's no way to get the data
> back (obviously).
>
> The servlet container error handling will not do anything in that case
> (error pages and status reports will not be processed), while Jasper
> also attempts to include the error page if forwarding to it failed. IMO,
> that's not that great an idea because it creates messy output, and the
> inclusion shouldn't happen (the error should be logged and ignored).
> It's been like that for a while, AFAIK.
>
> Rémy
>
> --
> To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
