abort_page bypasses AfterScript...

[Karl Lehenbauer <ka...@gmail.com>]

Hi Everyone...

We just noticed that AfterScript gets tagged onto the text of the webpage such that, if something in the page does an abort_page, there's no Rivet config script that's going to get a crack at the interpreter before it sits waiting for the next request to invoke it.

How abort_page works is its invokes a Tcl error with an errorCode of RIVET ABORTPAGE.  If the mod_rivet.c code that invokes Tcl_EvalObjEx then it bypasses the error handler and continues (Rivet_ExecuteAndCheck) with the flush and release.

It's also valid for the AfterScript itself to invoke abort_page, IMO.  We do that.

One possibility would be to invoke the AfterScript using Tcl_Eval in the abort_page path.  But that would break the AfterScript being able to invoke abort_page.  Also it would change the behavior every page that does an abort_page in a possibly bad way.  

No, I think AfterScript should stay the way it is.

If people agree that it should be possible to specify code in the configuration, an additional after script, that gets executed whether the page aborted or not.  Maybe it would be AbortScript (that's pretty simple).  But the code in the page shouldn't be able to do an explicit return and bypass this script either.  (I think a bare return in the page will bypass the AfterScript).  So it's a second After script, the after script of last resorts that's always guaranteed to execute whereas AfterScript is not.  ForceAfterScript?  AlwaysAfterScript?



---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org

Re: abort_page bypasses AfterScript...

[Massimo Manghi <ma...@unipr.it>]

I'm trying to envision what 'ForceAfterScript' would be meant for and 
the only purpose I can imagine is to catch resources that may have been 
left open or in a inconsistent state (e.g. a transaction rollback). 
After all it's like the last catch of an exception mechanism where 
abort_page plays the role of a 'throw'. If my vision is correct we may 
also extend the mechanism and introduce a state variable which might 
work as an 'exception object' to be used to hand down to 
'ForceAfterScript' (perhaps to be named 'RequestCatchScript') some other 
info. Something like

abort_page <error_code>

that might be fetched later on through a new command 'abort_condition' 
(a pure state variable could be enough but I don't like it because  it 
can be manipulated...)

  -- Massimo

P.S. I have reasons to believe there are problems with the email 
delivery from rivet-dev to my mailbox. At the moment please CC your 
answer to my personal address. Thanks.


On 02/06/2011 09:01 PM, Karl Lehenbauer wrote:
> Hi Everyone...
>
> We just noticed that AfterScript gets tagged onto the text of the webpage such that, if something in the page does an abort_page, there's no Rivet config script that's going to get a crack at the interpreter before it sits waiting for the next request to invoke it.
>
> How abort_page works is its invokes a Tcl error with an errorCode of RIVET ABORTPAGE.  If the mod_rivet.c code that invokes Tcl_EvalObjEx then it bypasses the error handler and continues (Rivet_ExecuteAndCheck) with the flush and release.
>
> It's also valid for the AfterScript itself to invoke abort_page, IMO.  We do that.
>
> One possibility would be to invoke the AfterScript using Tcl_Eval in the abort_page path.  But that would break the AfterScript being able to invoke abort_page.  Also it would change the behavior every page that does an abort_page in a possibly bad way.
>
> No, I think AfterScript should stay the way it is.
>
> If people agree that it should be possible to specify code in the configuration, an additional after script, that gets executed whether the page aborted or not.  Maybe it would be AbortScript (that's pretty simple).  But the code in the page shouldn't be able to do an explicit return and bypass this script either.  (I think a bare return in the page will bypass the AfterScript).  So it's a second After script, the after script of last resorts that's always guaranteed to execute whereas AfterScript is not.  ForceAfterScript?  AlwaysAfterScript?
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org