On 1/27/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
> >> I very much dislike changing the default behavior within a minor release
> >> or a milestone. But,
> if we can restrain the changes to the configuration, I suppose we could live
> with it.
>
> Ted, perhaps you need to think about this more :) Unless there are plans to
> come up with a
> different solution for 1.3/1.4, I don't want to put into Struts a solution
> that you're going to
> immediately rip out for a better approach. And I don't say that because I put
> time into the
> patch... ;-) but because it will create anguish for developers, and who wants
> to buy into a
> solution you're virtually about to toss away?
>
> If the set-property is the way to go, let's do it. And if you want it into
> the DTD instead, we can
> do that too. It's just modifying the DTD. +1/-1 for the DTD?
Its not the case of tossing a solution away - attributes named in the
DTD and <set-property> work in the same way. For example you could do
the following
<action ...>
<set-property property="validate" value="true"/>
</action>
instead of
<action validate="true" ...>
</action>
It just means that in 1.2 the DTD wouldn't support the "cancellable"
attribute and in 1.3 it would and there would only be an additional
change to 1.3 is to add the new attribute to the DTD - otherwise
everything works the same.
> >> In any case, we should not just ignore the cancel token. If the token is
> >> present, and
> Cancellable is not set, then we should log the error and throw an exception
> so that the developer
> knows the contract is not being observed (or that the website is being
> spoofed).
>
> IMO, bad idea. What if you don't want to handle the cancel at all? That's how
> this whole thread
> started. The notion of canceling is semantically nonsensical for most actions
> that back a GET
> request (view airline ticket, view any item, etc.) The problem is not that
> the token is an
> intrinsic evil, but that the token is not always necessary. So you pass in a
> token of the CANCEL
> button and you're not handling it -- big deal. Whose to say that's incorrect
> behavior? It's only
> incorrect if the action is supposed to handle it but is not, and you need a
> requirements document
> for that ;-)
I don't agree - if the request is passing in the CANCEL token and the
action hasn't been marked as handling cancel it means one of two
things:
1) Programmer error - they've added a cancel button, but not marked the action
2) Invalid Request - someones trying to spoof the cancel behaviour to
avoid validation.
Both of which are errors and IMO I agree with Ted - we should throw an
exception.
> It is my understanding that Exceptions are heavy-lifting, relatively
> speaking, compared to a
> normal non-exception execution path. Don't you think, devilishly speaking, it
> would be a great
> idea to write a loop that passes in the CANCEL token knowing the server will
> generate an exception
> every time? Unless I am overly scrupulous, I'd say that lays the foundation
> of a DoS attack,
> eating up alot of CPU to churn exceptions.
I don't think it makes much difference either way - any kind of loop
which repeatedly calls an action could be the foundation of a DoS
attack - whether the server throws an exception for this - or
successfully executes an action. In this scenario its bad news -
exception or not.
Niall
> Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
