cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [C2] Handling Redirects
Date Fri, 15 Dec 2000 23:01:55 GMT
Joerg Henne wrote:
> Hi all,
> we have found using HTTP redirects from C2 to be a thorny issue. Using
> HttpServletResponse.sendRedirect() the redirect can be initiated, just like,
> for instance, the XSPResponseHelper does. However, sending a redirect is only
> possible until some output has been generated and flushed down the HTTP
> connection.

IMO XSP pages should not use redirect. I think it's wrong by design. You
should use a component that does not generate output at all (ie.
Matcher, Selector, Action).

> Considering C2's pipelined architecture, I conclude that sending redirects is
> only safe while, from the XSPGenerator's point of view, startDocument nas not
> been called. Now here's the problem: there is no way to force code from a
> logicsheet to be executed before contentHandler.startDocument() is called in
> the generated XSP class. To fix this problem, I suggest modifications along
> the lines of the patch you'll find below.
> Another (minor) problem with redirects is the fact, that there is no (clean)
> way for xsp code to stop the processing of the current document after a
> redirect has been sent. This causes unnecessary resource use.

Simply use a return.

> What the patch does:
> - xsp-logicsheets may now include the new tag <xsp:init> within the context of
> a logicsheet xsl:template-match. Code enclosed within these tags will be
> placed at the very top of the xsp generator class's generate() method.

We cannot introduce new XSP tags. The specification of the XSP language
is not longer an authority of Cocoon because other projects implement
XSP as well (ie. AxKit). New XSP elements must be discussed on the xsp
mailing list.

What you'd like to introduce is exacly separating the code that you will
put into the xsp:init section into an Action which signals the sitemap
to do the rdirect or process further on.

  <map:match pattern="myuri/*>
    <map:act type="should-we-redirect">
      <map:redirect-to uri="http://somewhere/else/{to-go}"/>
    <map:generate type="serverpage" src="pages/{1}"/>

> - it adds the exception type PageRedirectException which is a subclass of
> ProcessingException. PageRedirectExceptions can carry redirect target
> information.
> - it allows the generated xsp generator's generate() method to throw
> PageRedirectExceptions
> - it adds the handling of PageRedirectExceptions to
> ResourcePipeline.process(). A ProcessingException is thrown when a redirect is
> tried from within an environement that is not an HttpEnvironement.

I don't see why the ResourcePipeline object should handle page redirects
if the XSP page can't handle it. What is the benefit of that? Can you
further explain that?


View raw message