cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] error-handling for "cocoon:" pipelines
Date Thu, 10 Apr 2003 20:06:31 GMT
on 4/10/03 5:09 PM Sylvain Wallez wrote:

> Folks,
> Currently <map:handle-errors> in a sitemap is ignored for internal (i.e. 
> "cocoon:") requests. However, this behaviour is somehow limiting and 
> Jürgen Seitz and Björn Lütkemeier (guess it's the correct lastname) have 
> expressed the need to have additional control on this.
> They gave only some abstract examples, but a concrete use case for this 
> is coplets : they are included through a "cocoon:" URI, and, despite of 
> that, it would be good if a coplet was able to produce a nice error 
> result instead of just propagating the exception to the upper-level 
> pipeline (the one that builds the portal page).
> There are two ways to consider this problem.
> 1/ Error handling is controlled by the called pipeline
> The contract of a pipeline may include the fact that it produces some 
> fallback content in case of error. In that case, the current behaviour 
> that ignores error handlers for internal requests is not good and we 
> need a way to specify it. This can go through a new "when" attribute on 
> <map:handle-errors> with the possible values "external", "internal", 
> "always", the default being "external" since it's the current behaviour.
> 2/ Error handling is controlled by the caller
> We can also consider that the caller knows what to do in case of failure 
> of the called pipeline, and then want to control this externally. Two 
> ways are envisioned for this :
> 2a/ Through the URI, using a new subprotocol : 
> "cocoon:handle-errors/blah". There's a potential conflict here with the 
> "cocoon:raw" protocol
> 2b/ Through a reserved request parameter : 
> "cocoon:/blah?cocoon-handle-errors=true". Care must be taken to forbid 
> this parameter for external requests to avoid security holes.
> I'm personally in favor of 1/ and do not know about 2/ : is it good for 
> error handling to be controlled externally ? 1/ and 2/ can also be both 
> allowed and priority given to the external setting. FS ?

If I had to choose between 1/ and 2/ I'd choose 1/

I also tend to think that if you need to pass parameters to the cocoon
protocol there is an imbalance somewhere else, but that's only a gut


View raw message