I'm forwarding this message from Damon because I can't get it through
the moderation mechanism. I get weird error messages in return claiming
my approval message is too big. I'm going to open a jira issue on this
but I wish the infrastructure was equipped with something more "modern"
for mailing list processing.
-- Massimo
-------- Original Message --------
Subject: Re: [Bug 55583] Rivet traceback on "headers redirect" command
Date: Tue, 8 Oct 2013 19:53:58 -0500
From: Damon Courtney <da...@tclhome.com>
To: Massimo Manghi <mxman...@apache.org>
CC: rivet-dev@tcl.apache.org
The original intent was that once you've said you're going to redirect
to another page, you should simply stop processing. So the command
would return a RETURN code telling Tcl to return from the current function.
I don't think it ever really worked the way it was intended (at least
not in my experience), and it seems as though the Tcl guys probably
fixed something that shouldn't actually have been allowed. Or maybe
someone messed up. :)
Either way, I always end up wrapping [headers redirect] in a proc that
then does an abort_page call after it to get the result that should
really occur.
On Oct 8, 2013, at 7:22 PM, Massimo Manghi <mxman...@apache.org> wrote:
Resending to the list this comment posted on bugzilla as the list
processor won't let me approve it because the message gets tagged as
SPAM (??) perhaps because of the attached patch
I don't know if this has side effects (I still have to run the test
suite) but apparently this trivial patch fixes the problem (Rivet
2.1.3, Apache 2.2.25, Tcl 8.6.1). The problem is with the Tcl code
returned by command 'headers redirect ...' which is TCL_RETURN. I
don't understand what happened under the hood of Tcl, but probably
there is some interaction with the NRE that didn't occur in Tcl 8.6.0
(8.5 still has the recursive engine)
It seems to me that if TCL_RETURN could work out an equivalent TCL_OK
in most cases, but Tcl 8.6.1 must have changed something. I wonder if
this was a mistake or intentional of the person who originally coded
this command.
here is the patch (easy)
Index: src/rivetcmds/rivetCore.c
===================================================================
--- src/rivetcmds/rivetCore.c (revision 1530074) +++
src/rivetcmds/rivetCore.c (working copy) @@ -340,7 +340,7 @@
apr_table_set(globals->r->headers_out, "Location",
Tcl_GetStringFromObj (objv[2], (int *)NULL)); TclWeb_SetStatus(301,
globals->req); - return TCL_RETURN; + return TCL_OK; }
else if (!strcmp("set", opt)) /* ### set ### */ {
-- Massimo
On 09/25/2013 12:17 AM, bugzi...@apache.org wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55583
--- Comment #6 from Massimo Manghi <mxman...@apache.org> ---
Confirmed: I was able to reproduce the traceback with Tcl 8.6.1
*and* Apache 2.2.25 (Debian/linux unstable). Changing one of these
to 8.6.0 or 2.2.22 doesn't produce the bug.
I removed the numeric header command from the error handler and the
bug doesn't show up again. Time to investigate what 'headers
numeric' is actually doing, but I can't get on it immediately
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org