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-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org