On Tue, 17 Jul 2001, Sylvain Wallez wrote:
>
>
> Carsten Ziegeler a écrit :
> >
> > > Donald Ball wrote:
> > >
> > > On Thu, 12 Jul 2001, Carsten Ziegeler wrote:
> > >
> > > > With the current design of cocoon2 it is not possible to have always a
> > > > clean error page.
> > > > The problem is that the components, e.g. the content aggregation write
> > > > directly to the output stream. If some components have written something
> > > > and an error occurs it is forbidden by the servlet engine to do
> > > a redirect
> > > > and the output stream cannot be reset.
> > > >
> > > > I wanted to address this problem by the concept of an
> > > intermediate output
> > > > stream, but there is currently no consense found.
> > >
> > > consensus seemed to be that an intermediate output stream was fine as long
> > > as we could configure it on or off on a per-sitemap or per-pipeline basis.
> > > that was my impression anyway. does anyone disagree with this?
> > >
> > I do not totally disagree, but I don't like the configuration part of it.
> > When you design your site/create the sitemap you don't want to think
> > about how the pipelines should be handled: if the output stream
> > should be directly written or "cached" and then written.
> > And the other think is, if the stream is directly written to the
> > output stream, the error handling is not working properly as
> > the result can consist of the first part of the real response followed
> > by the error information. This is really bad.
> >
> > Carsten
> > > - donald
> > >
>
> [Sorry for this late answer, it's hard to follow the list these days]
>
> The servlet API provides some methods to check if the servlet engine's
> output buffer has been flushed to the client browser
> (ServletResponse.isCommited) and, if no, to reset this buffer
> (ServletResponse.reset).
>
> Before calling the error-handler, the sitemap could reset the response
> if possible. This would allow for a higher probability of having clean
> error pages displayed to the user.
>
> Does it make sense ?
It make sense to me. So, patch the error handler :)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
