I’m guessing the reason we don’t get an error is because of the [no_body] command in there, so the error isn’t getting output. I would suggest adding a [headers sent] command that simply returns whether the headers have gone out already, and then we use that in ::rivet::redirect to return an error.
The [headers] command has the correct behavior that errors out when the headers have already been sent, but we’ve now prevented the error from displaying to the user. Also, looking at the code, I think we have a discrepancy in the [headers] command. The docs imply that most of the arguments to the command are optional, but the code says otherwise. For example, the docs say: headers set ?headername? ?value? The ?’s imply that both headername and value are optional arguments. I read that to mean that [headers set] by itself will probably return a dict of headers (it doesn’t), and [headers set Some-Header] will return the current value of the Some-Header header (it doesn’t). Changing the docs is the quickest course of action. HOWEVER, it is a very Tcl’ish thing to do to have the kind of introspection that would be provided by making the headers command arguments actually be optional with the behavior I’ve described above. Anyone know what stupid-ass process I have to go through to get committer access with Apache? I haven’t been a committer in a long, long time, but I’ve been working pretty steadily in Rivet for a few years now, and there are nits I would love to fix. I hate that Massimo is the only guy who’s ever in the code. I should get my hands dirty. :) D > On Dec 17, 2014, at 10:08 AM, Massimo Manghi <[email protected]> wrote: > > There is an implication in using 'headers numeric 302' with the buffer > control handling. > > I don't see any need for reducing the channel buffer size (especially > since the rivet channel handling was modified in order to have a single > channel per thread) but I tested the case where the buffer size was > shrunk to a length short enough to cause several buffer outputs on a > single page. I put a conditional redirect near the end of the page and > triggered the redirection. The page don't divert (because headers had > been flushed already), it stops outputting data, but it doesn't fail either. > > What the behavior we expect in this case (it would imply we should call? > I would expect the page to fail or return a some special code in order > to give us a chance to abort redirection and maybe take some action. > > What do you think? > > -- Massimo > > > On 12/15/2014 11:00 PM, Damon Courtney wrote: >> I had thought about that. I would vote for something extensible like a dict >> with a required field. >> >> ## For a straight abort_page >> set d [dict create] >> dict set d error_code “abort” >> >> ## For a redirect >> set d [dict create] >> dict set d error_code “redirect” >> dict set d location [headers set Location] >> >> Or whatever. error_code being very Tcl’ish and the only required value. The >> others are dependent on the error_code value. It’s simple, and we can add >> other codes with other information later. >> >> D >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
