You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Björn Lütkemeier <bl...@s-und-n.de> on 2003/04/29 08:42:42 UTC
Allow redirects inside error handling
Hi,
currently it is explicitly prohibited in Cocoon to use
<map:redirect-to>-tags within error handlers. Please see our proposal for
changing this a few days ago, for which we did not get any answer
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105110034516051&w=2).
If no one disagrees, we would like to start changing the treeprocessor, so
that redirects are allowed within error handlers due to the explained
reasons.
Kind regards,
Jürgen (juergen.seitz@basf-it-services.com) and Björn.
--------------------------------------------
S&N AG
Klingender Str. 5
D-33100 Paderborn
--------------------------------------------
internet: http://www.s-und-n.de
mail: bluetkemeier@s-und-n.de
phone: 05251 / 1581-35
--------------------------------------------
[OT] Re: Allow redirects inside error handling
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, April 29, 2003, at 02:30 PM, Berin Loritsch wrote:
> Carsten Ziegeler wrote:
>> Ok, you are perhaps right that redirects in error handlers are not the
>> way to go for designing web apps. But, if someone decides to do so,
>> why
>> should we create a barrior?
>
> If you had a friend with suicidal tendencies would you give them a
> loaded gun?
>
This makes me think of a statement by the guy who makes the diving
equipment I use:
“I have often compared rebreathers to guns. After all, either one will
kill you just as dead. A rebreather with automatic controls is like
walking around with a loaded gun with the safety on vs walking around
with a loaded gun that has no safety. In the first case you "think" it
is safe because of the "safety". And it is, as long as the "safety"
isn't broken and hasn't been switched off accidentally. But you just
may be safer in the second case because you know at all times that the
gun is apt to go off and you are much more likely to stay aware of the
danger and treat it with the respect it demands.”
Gordon Smith
User beware!
regards Jeremy
Re: Allow redirects inside error handling
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> Ok, you are perhaps right that redirects in error handlers are not the
> way to go for designing web apps. But, if someone decides to do so, why
> should we create a barrior?
If you had a friend with suicidal tendencies would you give them a
loaded gun?
> With the same arguments you could say we have to remove the redirect from
> the pipelines as well etc.
A sane person with proper training can go to a shooting range and use
the loaded gun without any worries. You are comparing apples and
oranges.
> If someone wants to use redirects in an error handler, he should be able
> to, but he must also live with the consequences and problems.
"I know you have talked about killing yourself before, but I can trust
you with this hand gun, right? If you pull the trigger, you just have
to live with the consequences."
It's a grim picture that shows how that logic can go too far. How
many steering wheels does a car need? Should you really be able to
change gears using the radio?
It's FS with dangerous side effects.
> And even without the explicit redirect-to, you can do a redirect using
> an action, or using a reader or generator with the same url.
Please tell me you are joking. Error handlers need to be restricted
on purpose.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
RE: Allow redirects inside error handling
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> I still think that this is bad, for the infinite error loop. And no, we
> should not make this possible, because errors can always occur in
> sitemaps, and infinite loops in a web server are really bad. Furthermore
> it also makes it easy to start using error handling for app flow , and
> it should *not* be it.
>
> As for the fact that redirects can be done in Actions, well, it should
> *not* be possible in handle-errors. It was a bug.
>
> Now that generators can be used, users can generate from another
> pipeline, and it's a forward, and include, not a redirect.
>
> Handle errors should not have a goto to external code. No gotos there,
> please.
>
> Why would you want a redirect now that generators are possible? I don't
> like redirects there, please remove this.
>
> I also think that redirects in Actions are equally bad, as only the
> sitemap and the flow should redirect, based on the results of the
> components. Redirects in code are a bad programming practice.
>
Ok, you are perhaps right that redirects in error handlers are not the
way to go for designing web apps. But, if someone decides to do so, why
should we create a barrior?
With the same arguments you could say we have to remove the redirect from
the pipelines as well etc.
If someone wants to use redirects in an error handler, he should be able
to, but he must also live with the consequences and problems.
And even without the explicit redirect-to, you can do a redirect using
an action, or using a reader or generator with the same url.
Carsten
Re: Allow redirects inside error handling
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> Björn Lütkemeier wrote:
>
>> Hi,
>>
>
>> As far as I see the problem with infinite loops does not only occur in
>> conjunction with error handling. Even with normal pipelines you are
>> able to
>> configure an infinite loop. Cocoon does not prevent you from doing so,
>> because as I said before it is your fault, not a bug in the system.
>> It is the same in Java: The Java language does not prevent you from
>> implementing infinite loops. When you do so, you made a mistake in your
>> program and have to fix it. Therefore I do not see any reason to allow
>> redirects anywhere in the sitemap, but forbid them in error handlers.
>> This
>> would be a bad restriction that is not necessary at all in my opinion.
>
>
>
> And when that user asks you why they can't see what's wrong in their
> application (because they will) but it goes into an infinite loop, you
> can explain that to them.
>
> Perhaps Cocoon should detect potential infinite loops as a feature.
Also keep in mind that Java has this interesting little exception called
StackOutOfBoundsException so that if your infinite loop spanned several
methods (which I recently ran into an application that did this), you
will get this exception so that you can break out of the loop. Think of
error handlers as the "catch" part of a try/catch/finally structure.
Almost all developers (even new ones) put very simple error hanlding
logic so you can correct it.
Putting too much in your catch block is bad programming IMNSHO.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
Re: Allow redirects inside error handling
Posted by Berin Loritsch <bl...@apache.org>.
Björn Lütkemeier wrote:
> Hi,
>
>
>>Perhaps Cocoon should detect potential infinite loops as a feature.
>>
>
>
> that would really be a very great feature solving the problem, any idea how
> to implement it ;-)
>
> But as I said: In my opinion it is not the task of the underlying system
> (Java, Cocoon or whatever) to prevent or detect infinite loops. It is and
> remains to be a mistake of the developer. But if he nonetheless likes to
> redirect in an error handler for whatever reason, he should be able to. At
> any other point of the sitemap he has this possibility, too.
This is where we disagree whole-heartedly.
Let me ask you, what do you do with exception handling?
You can't use code that can generate new exceptions unless you nest a
new try/catch block inside that.
Eventually you have to do one of two things: give up and die or handle
the exception as gracefully as possible.
Think of error handlers in the same way. The Java language, and many
other languages restrict what you can do in an exception/error handler.
Since you are so fond of using the language as an example of how to do
things, here is an example of where the language restricts what you
can do.
There needs to be some restrictions in your error handlers, and I will
restate that you should not allow anything that can generate an error
in an error handler, unless your user explicitly handles that error
as well.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
Re: Allow redirects inside error handling
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/30/03 1:08 AM Björn Lütkemeier wrote:
> Hi,
>
>
>>-----Original Message-----
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>Sent: Tuesday, April 29, 2003 6:38 PM
>>To: cocoon-dev@xml.apache.org
>>Subject: Re: Allow redirects inside error handling
>>
>>
>>
>>Björn Lütkemeier wrote, On 29/04/2003 16.42:
>>...
>>
>>>Sorry, but I did not find any convincing argument in the discussion why
>>>redirects should be impossible.
>>
>>Tell me why you need them, maybe I can understand.
>>
>>--
>>Nicola Ken Barozzi nicolaken@apache.org
>> - verba volant, scripta manent -
>> (discussions get forgotten, just code remains)
>>---------------------------------------------------------------------
>>
>
>
> It's quite simple to explain. We have a customer, that has to do the
> following within his web application:
>
> <map:pipeline>
> <map:match pattern="showForm">
> <!-- show a web form -->
> </map:match>
> <map:handle-errors>
> <map:select type="exception">
> <map:when test="x">
> <map:redirect-to uri="cocoon:/x-error"/>
> </map:when>
> <map:when test="y">
> <map:redirect-to uri="cocoon:/y-error"/>
> </map:when>
> </map:select>
> </map:handle-errors>
> </map:pipeline>
>
> <map:pipeline>
> <map:match pattern="formSubmitted">
> <!-- process form values -->
> </map:match>
> <map:handle-errors>
> <map:select type="exception">
> <map:when test="validationFailed">
> <map:redirect-to uri="cocoon:/showForm"/> <!-- redisplay form -->
> </map:when>
> <map:when test="x">
> <map:redirect-to uri="cocoon:/x-error"/>
> </map:when>
> <map:when test="z">
> <map:redirect-to uri="cocoon:/z-error"/>
> </map:when>
> </map:select>
> </map:handle-errors>
> </map:pipeline>
>
> <map:pipeline>
> <map:match pattern="x-error">
> ...
> </map:match>
> <map:match pattern="y-error">
> ...
> </map:match>
> <map:match pattern="z-error">
> ...
> </map:match>
> </map:pipeline>
What about map:resources?
--
Stefano.
Re: Allow redirects inside error handling
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
> Björn Lütkemeier wrote, On 30/04/2003 8.08:
>
>> Hi,
>>
>>> -----Original Message-----
>>> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>> Sent: Tuesday, April 29, 2003 6:38 PM
>>> To: cocoon-dev@xml.apache.org
>>> Subject: Re: Allow redirects inside error handling
>>>
>>> Björn Lütkemeier wrote, On 29/04/2003 16.42:
>>> ...
>>>
>>>> Sorry, but I did not find any convincing argument in the discussion
>>>> why
>>>> redirects should be impossible.
>>>
>>>
>>> Tell me why you need them, maybe I can understand.
>>
>>
>> It's quite simple to explain. We have a customer, that has to do the
>> following within his web application:
>>
>> <map:pipeline>
>
<snip/>
>>
>> </map:match>
>> </map:pipeline>
>
>
> Ok, this does the same without redirects *except* in the
>
> <map:when test="validationFailed">... <!-- redisplay form -->
>
> part. This is wrong, because handle-errors in *not* to be used for
> programming logic. This shows it clearly that we cannot allow
> redirects in there, because the first thing that happens is misuse.
>
> Sylvain, please revert the change.
I also consider using error-handler that way to be bad design : handling
invalid form submission is part of the nominal behaviour of the
application, and therefore should be handled in the sitemap (actually in
the form-validation action).
But I also consider Geoff's use case to be fully valid : if something
goes wrong, do the minimal that we can expect to work correctly which is
redirect to another server (e.g. an httpd) that will deliver the error page.
Furthermore, I never understood the link between allowing generators in
handle-errors and forbidding redirects, as having an implicit generator
doesn't prevent redirecting.
So I will call for a vote on this issue (see next post).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Allow redirects inside error handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Björn Lütkemeier wrote, On 30/04/2003 8.08:
> Hi,
>
>
>>-----Original Message-----
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>Sent: Tuesday, April 29, 2003 6:38 PM
>>To: cocoon-dev@xml.apache.org
>>Subject: Re: Allow redirects inside error handling
>>
>>
>>
>>Björn Lütkemeier wrote, On 29/04/2003 16.42:
>>...
>>
>>>Sorry, but I did not find any convincing argument in the discussion why
>>>redirects should be impossible.
>>
>>Tell me why you need them, maybe I can understand.
>>
>>--
>>Nicola Ken Barozzi nicolaken@apache.org
>> - verba volant, scripta manent -
>> (discussions get forgotten, just code remains)
>>---------------------------------------------------------------------
>>
>
>
> It's quite simple to explain. We have a customer, that has to do the
> following within his web application:
>
> <map:pipeline>
<> <map:match pattern="showForm">
> <!-- show a web form -->
> </map:match>
> <map:handle-errors>
> <map:select type="exception">
> <map:when test="x">
> <map:redirect-to uri="cocoon:/x-error"/>
> </map:when>
> <map:when test="y">
> <map:redirect-to uri="cocoon:/y-error"/>
> </map:when>
> </map:select>
> </map:handle-errors>
> </map:pipeline>
>
> <map:pipeline>
> <map:match pattern="formSubmitted">
> <!-- process form values -->
> </map:match>
> <map:handle-errors>
> <map:select type="exception">
> <map:when test="validationFailed">
> <map:redirect-to uri="cocoon:/showForm"/> <!-- redisplay form -->
> </map:when>
> <map:when test="x">
> <map:redirect-to uri="cocoon:/x-error"/>
> </map:when>
> <map:when test="z">
> <map:redirect-to uri="cocoon:/z-error"/>
> </map:when>
> </map:select>
> </map:handle-errors>
> </map:pipeline>
>
> <map:pipeline>
> <map:match pattern="x-error">
> ...
> </map:match>
> <map:match pattern="y-error">
> ...
> </map:match>
> <map:match pattern="z-error">
> ...
> </map:match>
> </map:pipeline>
Ok, this does the same without redirects *except* in the
<map:when test="validationFailed">... <!-- redisplay form -->
part. This is wrong, because handle-errors in *not* to be used for
programming logic. This shows it clearly that we cannot allow redirects
in there, because the first thing that happens is misuse.
Sylvain, please revert the change.
Here is the example.
<map:resources>
<map:resource name="x-error">
...
</map:resource>
<map:resource name="y-error">
...
</map:resource>
<map:resource name="z-error">
...
</map:resource>
</map:resources>
<map:pipelines>
<map:pipeline>
<map:match pattern="showForm">
<!-- show a web form -->
</map:match>
<map:handle-errors>
<map:select type="exception">
<map:when test="x">
<map:call resource="x-error"/>
</map:when>
<map:when test="y">
<map:call resource="y-error"/>
</map:when>
</map:select>
</map:handle-errors>
</map:pipeline>
<map:pipeline>
<map:match pattern="formSubmitted">
<!-- process form values -->
<!-- use an action that checks the
forms and also handles the
*programmatically defined* errors -->
</map:match>
<map:handle-errors>
<map:select type="exception">
<map:when test="x">
<map:call resource="x-error"/>
</map:when>
<map:when test="z">
<map:call resource="z-error"/>
</map:when>
</map:select>
</map:handle-errors>
</map:pipeline>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: Allow redirects inside error handling
Posted by Björn Lütkemeier <bl...@s-und-n.de>.
Hi,
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Tuesday, April 29, 2003 6:38 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Allow redirects inside error handling
>
>
>
> Björn Lütkemeier wrote, On 29/04/2003 16.42:
> ...
> > Sorry, but I did not find any convincing argument in the discussion why
> > redirects should be impossible.
>
> Tell me why you need them, maybe I can understand.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
It's quite simple to explain. We have a customer, that has to do the
following within his web application:
<map:pipeline>
<map:match pattern="showForm">
<!-- show a web form -->
</map:match>
<map:handle-errors>
<map:select type="exception">
<map:when test="x">
<map:redirect-to uri="cocoon:/x-error"/>
</map:when>
<map:when test="y">
<map:redirect-to uri="cocoon:/y-error"/>
</map:when>
</map:select>
</map:handle-errors>
</map:pipeline>
<map:pipeline>
<map:match pattern="formSubmitted">
<!-- process form values -->
</map:match>
<map:handle-errors>
<map:select type="exception">
<map:when test="validationFailed">
<map:redirect-to uri="cocoon:/showForm"/> <!-- redisplay form -->
</map:when>
<map:when test="x">
<map:redirect-to uri="cocoon:/x-error"/>
</map:when>
<map:when test="z">
<map:redirect-to uri="cocoon:/z-error"/>
</map:when>
</map:select>
</map:handle-errors>
</map:pipeline>
<map:pipeline>
<map:match pattern="x-error">
...
</map:match>
<map:match pattern="y-error">
...
</map:match>
<map:match pattern="z-error">
...
</map:match>
</map:pipeline>
Regards, Björn.
Re: Allow redirects inside error handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Björn Lütkemeier wrote, On 29/04/2003 16.42:
...
> Sorry, but I did not find any convincing argument in the discussion why
> redirects should be impossible.
Tell me why you need them, maybe I can understand.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: Allow redirects inside error handling
Posted by Björn Lütkemeier <bl...@s-und-n.de>.
Hi,
>
> Perhaps Cocoon should detect potential infinite loops as a feature.
>
that would really be a very great feature solving the problem, any idea how
to implement it ;-)
But as I said: In my opinion it is not the task of the underlying system
(Java, Cocoon or whatever) to prevent or detect infinite loops. It is and
remains to be a mistake of the developer. But if he nonetheless likes to
redirect in an error handler for whatever reason, he should be able to. At
any other point of the sitemap he has this possibility, too.
> Anything more is FS. By over-customizing the error handling logic you
> increase the chance of the error handling not reporting the right
> errors.
It has nothing to do with over-customizing. We simply say: Within an error
handler you are able to define any pipeline, except the single task of
redirects. That does not make sense! If you like to enforce developers not
to perform dynamic activity in error handlers you would have to start
forbidding SQLTransformer (since the user SHOULD not do database access),
but allow the RequestGenerator (since the information MAY be displayed on
the error page), but then it makes perhaps sense to also allow the
RequestParamAction, but forbid the DatabaseAddAction, whereas the
TraxTransformer is of cause allowed... What on earth would be the sense of
all this distictions?
Sorry, but I did not find any convincing argument in the discussion why
redirects should be impossible.
Björn
Re: Allow redirects inside error handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote, On 29/04/2003 16.11:
> By removing the redirect in the error handling you can't prevent
> infinite loops. Imagine the client requests "document", the
> corresponding pipeline produces an exception and the error handler
> is called. In the error handler I make a <map:generate
> src="cocoon:/document"/>
> And I have an infinite loop without a redirect.
As I said many times (yes I'm a PITA), generation in the handle-errors
should be allowed only without this possibility, and no redirects in
actions.
This was also why I wanted generatiors out of handle-errors, and the
condition was part of the deal of removing the veto.
If it's not done, I won't complain, since this is OS and if I really
want I can fix it myself. But this does not mean that it's not a bug.
> Can you prevent a user from doing so?
Yes. Make handle errors look at the stacktrace or something like that
and see if it was called already. If so, break the loop and return a
general error.
Anyway, having loops is not the only reason of not having redirects,
it's also that handle-errors is a dead end and should remain so, by
design, just like serializers exit a pipeline processing, by design.
You have not yet shown me though why redirects are needed ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Allow redirects inside error handling
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> By removing the redirect in the error handling you can't prevent
> infinite loops. Imagine the client requests "document", the
> corresponding pipeline produces an exception and the error handler
> is called. In the error handler I make a <map:generate
> src="cocoon:/document"/>
> And I have an infinite loop without a redirect.
> Can you prevent a user from doing so?
Then I would not allow that URI. Why would we want a self
referencing generator? Anything that creates an infinite
loop like that should set off alarm bells to someone.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
RE: Allow redirects inside error handling
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
By removing the redirect in the error handling you can't prevent
infinite loops. Imagine the client requests "document", the
corresponding pipeline produces an exception and the error handler
is called. In the error handler I make a <map:generate
src="cocoon:/document"/>
And I have an infinite loop without a redirect.
Can you prevent a user from doing so?
Carsten
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Tuesday, April 29, 2003 3:33 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Allow redirects inside error handling
>
>
> Björn Lütkemeier wrote:
> > Hi,
> >
>
> > As far as I see the problem with infinite loops does not only occur in
> > conjunction with error handling. Even with normal pipelines you
> are able to
> > configure an infinite loop. Cocoon does not prevent you from doing so,
> > because as I said before it is your fault, not a bug in the system.
> > It is the same in Java: The Java language does not prevent you from
> > implementing infinite loops. When you do so, you made a mistake in your
> > program and have to fix it. Therefore I do not see any reason to allow
> > redirects anywhere in the sitemap, but forbid them in error
> handlers. This
> > would be a bad restriction that is not necessary at all in my opinion.
>
>
> And when that user asks you why they can't see what's wrong in their
> application (because they will) but it goes into an infinite loop, you
> can explain that to them.
>
> Perhaps Cocoon should detect potential infinite loops as a feature.
>
>
> --
> "You know the world is going crazy when the best
> rapper is a white guy, the best golfer is a black guy,
> The Swiss hold the America's Cup, France is
> accusing the US of arrogance, and Germany doesn't want
> to go to war. And the 3 most powerful men in America
> are named 'Bush', 'Dick', and 'Colon' (sic)".
>
> -----Chris Rock
>
Re: Allow redirects inside error handling
Posted by Berin Loritsch <bl...@apache.org>.
Björn Lütkemeier wrote:
> Hi,
>
> As far as I see the problem with infinite loops does not only occur in
> conjunction with error handling. Even with normal pipelines you are able to
> configure an infinite loop. Cocoon does not prevent you from doing so,
> because as I said before it is your fault, not a bug in the system.
> It is the same in Java: The Java language does not prevent you from
> implementing infinite loops. When you do so, you made a mistake in your
> program and have to fix it. Therefore I do not see any reason to allow
> redirects anywhere in the sitemap, but forbid them in error handlers. This
> would be a bad restriction that is not necessary at all in my opinion.
And when that user asks you why they can't see what's wrong in their
application (because they will) but it goes into an infinite loop, you
can explain that to them.
Perhaps Cocoon should detect potential infinite loops as a feature.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
RE: Allow redirects inside error handling
Posted by Björn Lütkemeier <bl...@s-und-n.de>.
Hi,
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Tuesday, April 29, 2003 2:28 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Allow redirects inside error handling
>
> I still think that this is bad, for the infinite error loop. And no, we
> should not make this possible, because errors can always occur in
> sitemaps, and infinite loops in a web server are really bad. Furthermore
> it also makes it easy to start using error handling for app flow , and
> it should *not* be it.
>
> As for the fact that redirects can be done in Actions, well, it should
> *not* be possible in handle-errors. It was a bug.
>
> Now that generators can be used, users can generate from another
> pipeline, and it's a forward, and include, not a redirect.
>
> Handle errors should not have a goto to external code. No gotos there,
> please.
>
> Why would you want a redirect now that generators are possible? I don't
> like redirects there, please remove this.
>
> I also think that redirects in Actions are equally bad, as only the
> sitemap and the flow should redirect, based on the results of the
> components. Redirects in code are a bad programming practice.
>
As far as I see the problem with infinite loops does not only occur in
conjunction with error handling. Even with normal pipelines you are able to
configure an infinite loop. Cocoon does not prevent you from doing so,
because as I said before it is your fault, not a bug in the system.
It is the same in Java: The Java language does not prevent you from
implementing infinite loops. When you do so, you made a mistake in your
program and have to fix it. Therefore I do not see any reason to allow
redirects anywhere in the sitemap, but forbid them in error handlers. This
would be a bad restriction that is not necessary at all in my opinion.
Regards, Björn.
Re: Allow redirects inside error handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote, On 29/04/2003 10.29:
> Carsten Ziegeler wrote:
>
>> Björn Lütkemeier wrote:
>>
>>
>>> currently it is explicitly prohibited in Cocoon to use
>>> <map:redirect-to>-tags within error handlers. Please see our proposal
>>> for
>>> changing this a few days ago, for which we did not get any answer
>>> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105110034516051&w=2).
>>>
>>> If no one disagrees, we would like to start changing the
>>> treeprocessor, so
>>> that redirects are allowed within error handlers due to the explained
>>> reasons.
>>>
>> I would like to add that we allowed a redirect in an error handler
>> until recently; the ability was removed during the changes to allow
>> different error generators.
>
> This contraint was added to make Nicola Ken happy.
:-PPPPPPP
> I personally didn't
> have good feelings about it, but really wanted custom generators in
> error handling.
>
> So, since it seems to make more people unhappy : constraint removed !
I still think that this is bad, for the infinite error loop. And no, we
should not make this possible, because errors can always occur in
sitemaps, and infinite loops in a web server are really bad. Furthermore
it also makes it easy to start using error handling for app flow , and
it should *not* be it.
As for the fact that redirects can be done in Actions, well, it should
*not* be possible in handle-errors. It was a bug.
Now that generators can be used, users can generate from another
pipeline, and it's a forward, and include, not a redirect.
Handle errors should not have a goto to external code. No gotos there,
please.
Why would you want a redirect now that generators are possible? I don't
like redirects there, please remove this.
I also think that redirects in Actions are equally bad, as only the
sitemap and the flow should redirect, based on the results of the
components. Redirects in code are a bad programming practice.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: Allow redirects inside error handling
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Thanks Sylvain!
Carsten
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Sent: Tuesday, April 29, 2003 10:30 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Allow redirects inside error handling
>
>
> Carsten Ziegeler wrote:
>
> >Björn Lütkemeier wrote:
> >
> >
> >>currently it is explicitly prohibited in Cocoon to use
> >><map:redirect-to>-tags within error handlers. Please see our
> proposal for
> >>changing this a few days ago, for which we did not get any answer
> >>(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105110034516051&w=2).
> >>
> >>If no one disagrees, we would like to start changing the
> treeprocessor, so
> >>that redirects are allowed within error handlers due to the explained
> >>reasons.
> >>
> >>
> >I would like to add that we allowed a redirect in an error handler
> >until recently; the ability was removed during the changes to allow
> >different error generators.
> >
> >
>
> This contraint was added to make Nicola Ken happy. I personally didn't
> have good feelings about it, but really wanted custom generators in
> error handling.
>
> So, since it seems to make more people unhappy : constraint removed !
>
> Cheers,
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
Re: Allow redirects inside error handling
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Björn Lütkemeier wrote:
>
>
>>currently it is explicitly prohibited in Cocoon to use
>><map:redirect-to>-tags within error handlers. Please see our proposal for
>>changing this a few days ago, for which we did not get any answer
>>(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105110034516051&w=2).
>>
>>If no one disagrees, we would like to start changing the treeprocessor, so
>>that redirects are allowed within error handlers due to the explained
>>reasons.
>>
>>
>I would like to add that we allowed a redirect in an error handler
>until recently; the ability was removed during the changes to allow
>different error generators.
>
>
This contraint was added to make Nicola Ken happy. I personally didn't
have good feelings about it, but really wanted custom generators in
error handling.
So, since it seems to make more people unhappy : constraint removed !
Cheers,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Allow redirects inside error handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Geoff Howard wrote, On 29/04/2003 19.13:
> At 10:13 AM 4/29/2003, NKB wrote:
>
> <snip/>
>
>> > Therefore I do not see any reason to allow
>> > redirects anywhere in the sitemap, but forbid them in error handlers.
>>
>> Show me why you really need them, when you can do the same in the
>> Generator.
>
>
> How about when you want to redirect to a static error page on a separate
> server? I know I _can_ use cocoon to get the static page over http but
> is it really that necessary to _make_ people do that?
Why would you want to redirect error pages to another server?
Anyway, this does not impact on the handle-errors==dead-end rule, as it
redirects elswhere... hmmm...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Allow redirects inside error handling
Posted by Geoff Howard <co...@leverageweb.com>.
At 10:13 AM 4/29/2003, NKB wrote:
<snip/>
> > Therefore I do not see any reason to allow
> > redirects anywhere in the sitemap, but forbid them in error handlers.
>
>Show me why you really need them, when you can do the same in the Generator.
How about when you want to redirect to a static error page on a separate
server? I know I _can_ use cocoon to get the static page over http but is
it really that necessary to _make_ people do that?
Geoff
Re: Allow redirects inside error handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote, On 29/04/2003 15.21:
...
> An error handler should do one thing: handle errors.
>
> It should not be complicated, or too dynamic. If there is a 404 error,
> the user of the site needs to know one thing: the link was bad (they
> don't need a stack trace proving it).
>
> Is it good to customize the error pages? Yes. Error pages that look
> like they are part of the site are important. Error pages that help
> the user get back on track (i.e. provide a link to a search function,
> a sitemap, and/or the main page) are necessary.
>
> When I see things that try to allow dynamic activity for error handling,
> it makes me wince. There should be no actions, no redirects, no
> database access. At the most, a simple generator/transformer/serializer
> chain. That's it.
Actions are needed to make the developer access the error data
programmatically and
> Anything more is FS. By over-customizing the error handling logic you
> increase the chance of the error handling not reporting the right
> errors.
Well said. This is exactly my thinking.
Björn Lütkemeier wrote, On 29/04/2003 14.47:
> As far as I see the problem with infinite loops does not only occur in
> conjunction with error handling. Even with normal pipelines you are
> able to
> configure an infinite loop.
Error handling is *not* like normal sitemap logic. If it was so, we
would have done <map:onerror redirect-to""/>. Instead we did another
section. handle-errors should glob everything and be the *last* part of
the chain.
> The Java language does not prevent you from
> implementing infinite loops.
So? This is for websites. Assembler can give you gotos... so?
> Therefore I do not see any reason to allow
> redirects anywhere in the sitemap, but forbid them in error handlers.
Show me why you really need them, when you can do the same in the Generator.
Carsten Ziegeler wrote, On 29/04/2003 14.43:
> Ok, you are perhaps right that redirects in error handlers are not the
> way to go for designing web apps. But, if someone decides to do so,
> why should we create a barrior?
FS
Cocoon is not Perl (yet ;-)
> With the same arguments you could say we have to remove the redirect
> from the pipelines as well etc.
I would like so, yes. And in fact were they not deprecated?
Besides, all logic of redirects should now go in the flowmap.
> If someone wants to use redirects in an error handler, he should be
> able to, but he must also live with the consequences and problems.
Why should he be able to? Can't he do a cocoon:// in the generator?
You see, it's very different. If you do it in the Generator, you are
*including* outer comment in the handle errors. If you redirect, you get
*out* of handle errors. From handle-errors, nobody should get out. ;->
> And even without the explicit redirect-to, you can do a redirect using
> an action, or using a reader or generator with the same url.
Exactly what I asked Sylvain to prevent. In my removal of the veto, it
was included that Actions there should not be able to redirect there.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Allow redirects inside error handling
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Björn Lütkemeier wrote:
>
>>currently it is explicitly prohibited in Cocoon to use
>><map:redirect-to>-tags within error handlers. Please see our proposal for
>>changing this a few days ago, for which we did not get any answer
>>(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105110034516051&w=2).
>>
>>If no one disagrees, we would like to start changing the treeprocessor, so
>>that redirects are allowed within error handlers due to the explained
>>reasons.
>>
>
> I would like to add that we allowed a redirect in an error handler
> until recently; the ability was removed during the changes to allow
> different error generators.
An error handler should do one thing: handle errors.
It should not be complicated, or too dynamic. If there is a 404 error,
the user of the site needs to know one thing: the link was bad (they
don't need a stack trace proving it).
Is it good to customize the error pages? Yes. Error pages that look
like they are part of the site are important. Error pages that help
the user get back on track (i.e. provide a link to a search function,
a sitemap, and/or the main page) are necessary.
When I see things that try to allow dynamic activity for error handling,
it makes me wince. There should be no actions, no redirects, no
database access. At the most, a simple generator/transformer/serializer
chain. That's it.
Anything more is FS. By over-customizing the error handling logic you
increase the chance of the error handling not reporting the right
errors.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
Re: Allow redirects inside error handling
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
>Björn Lütkemeier wrote:
>
>
>>currently it is explicitly prohibited in Cocoon to use
>><map:redirect-to>-tags within error handlers. Please see our proposal for
>>changing this a few days ago, for which we did not get any answer
>>(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105110034516051&w=2).
>>
>>If no one disagrees, we would like to start changing the treeprocessor, so
>>that redirects are allowed within error handlers due to the explained
>>reasons.
>>
>>
>>
>I would like to add that we allowed a redirect in an error handler
>until recently; the ability was removed during the changes to allow
>different error generators.
>
>
I don't have issues with this addition. Or, to be precise, with adding
this feature back.
Vadim
RE: Allow redirects inside error handling
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Björn Lütkemeier wrote:
>
> currently it is explicitly prohibited in Cocoon to use
> <map:redirect-to>-tags within error handlers. Please see our proposal for
> changing this a few days ago, for which we did not get any answer
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105110034516051&w=2).
>
> If no one disagrees, we would like to start changing the treeprocessor, so
> that redirects are allowed within error handlers due to the explained
> reasons.
>
I would like to add that we allowed a redirect in an error handler
until recently; the ability was removed during the changes to allow
different error generators.
Carsten