Don’t worry, I got it. :) And, I agree. I didn’t realize parse was doing a
flush of the output. We should fix that.
I also agree that redirect should cause an abort (or something like it). I
already do that in my own code, as it makes no sense to redirect and then keep
processing. It could potentially cause some seriously confusing bugs. We could
be more elegant about it in the C code, but here’s a version of the proc I use
we could include:
proc ::rivet::redirect {url {permanent 0}} {
no_body ; ## don’t output anything on a redirect
headers set Location $url
headers numeric [expr {$permanent ? "301" : "302"}]
abort_page ; ## stop any further processing
}
Damon
> On Dec 15, 2014, at 11:43 AM, Massimo Manghi <[email protected]> wrote:
>
> I probably didn't express this point in an impeccable way. Let me rephrase it
>
> Even though Tcl_Flush (and implicitly the output method of Rivet channel)
> could be called when everything is done just before returning to Apache (true
> for most web pages), as a matter of fact parsing a subtemplate causes the
> same call to Tcl to occur and therefore becomes impossible in this case to
> change the headers. This is incoherent and fuzzy and should be fixed
>
> I hope the rest of my message is understandable.
>
> -- Massimo
>
>
> On 12/15/2014 04:13 PM, Massimo Manghi wrote:
>> I take it and I don't want you to leave the discussion ;)
>>
>> I've been repeating with Rani the same point every time he brought it
>> up: redirection should be done ASAP and before sending any data to the
>> stdout. I maintain that for any "sensible" page (most web pages size is
>> well < 1000000) data are sent when mod_rivet calls Tcl_Flush, therefore
>> redirection can occur before that point, but it's not true every case.
>> Rivet_ExecuteAndCheck calls Tcl_Flush which in turn causes Rivet
>> channel's output procedure to be called by Tcl. And this happens also
>> when the ::rivet::parse command is called (which calls
>> Rivet_ParseExecFile and then Rivet_ExecuteAndCheck)
>>
