You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Taneli Saastamoinen <ts...@cs.helsinki.fi> on 2004/08/14 20:19:14 UTC
"headers redirect" weirdness
Hi, we're having some problems with "headers redirect $some_url"
reporting "Cannot manipulate headers - already sent".
A word about our setup. The actual pages are page1.rvt, page2.rvt etc.
They contain a proc named main_content, which does some basic logic and
then puts's out all the actual html. Each page defines main_content in
its own way, then says "parse $path/header.rvt". header.rvt does some
logic with "source stuff.tcl", then puts's the page headers, then does
some more logic with "parse login_stuff.rvt", then calls main_content
when everything is ready.
Now this kind of setup used to work a few weeks or months ago. And it
still works, except that "headers redirect $any_url" doesn't work within
main_content any more. I'm not sure why. It complains about the headers
already being sent.
If I comment out the "parse login_stuff.rvt" in header.rvt, all the
redirects work perfectly. Then, when I uncomment it, the redirects don't
work. Even if I comment out _every single line_ of login_stuff.rvt, the
"parse login_stuff.rvt" is sufficient to magically make all subsequent
redirect attempts non-working.
So is this a problem with the parse command? What exactly causes the
headers to be sent? I found no helpful hints anywhere, and don't have
the time to source-dive too much right now.
As I said, this setup used to work before, and I have no idea why it
doesn't work now. I'd appreciate any clues. We're currently using an
ugly kludgy workaround, but would much prefer real redirects.
--
SMS: SATAN Causes High Memory Utilization in WUSER32
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: "headers redirect" weirdness
Posted by "David N. Welton" <da...@dedasys.com>.
Taneli Saastamoinen <ts...@cs.helsinki.fi> writes:
> ["David N. Welton" <da...@dedasys.com> Mon, Aug 16, 2004 at 05:15:24PM EEST]
> > Well, what changed? No one has done any commits lately, so it
> > leads me to think it may be on your end unless you recently
> > upgraded to a new version. So what might have been moved around
> > in your code that would cause a 'puts' to happen before the
> > 'headers redirect' line is hit?
> Umm... Okay, so here's the deal. Essentially nothing has changed,
> except that we have some more redirects in the code now. But, IIRC,
> we _had_ puts's in the code before "headers redirect"'s previously,
> and it _worked_. I take it that isn't actually supposed to work?
It does work, actually, but if something were to go wrong... that
might be one place to look at.
> Related to this, our design is currently somewhat suboptimal; we're
> working on it, and will soon have eliminated almost all puts's. So
> we're doing all the logic and any possible header redirects first,
> and "puts $actual_content" then. From what I gather, that should
> work _every time_.
> I couldn't find any accurate information anywhere as to what exactly
> causes the headers to be sent; if it is the case that a puts before
> a headers redirect _should_ cause everything to fail, but doesn't
> always, I think that should be mentioned in the
> documentation. (Actually, I think it should also be documented
> exactly which things cause, or _might_ cause, the headers to be
> sent. Is it only the puts, or is there something else?)
If you were looking at the docs for this information, where would you
expect to find it? I have just a bit in the internals section, but
that's not someplace the casual user is going to want to look.
The summary:
In order to use regular old 'puts', Rivet has a channel type of its
own for output which it sets as the default for stdout. It sets the
buffer size for this channel to 1000000, which is the largest allowed,
so that it ought to keep buffering until you flush it with the 'flush'
command.
So, unless you do a *huge* amount of output, or start using 'flush',
things ought to work.
> > If you can provide a really simple example that causes the problem, I
> > will look at it and see if I can reproduce it and then find the
> > problem.
> I'm kinda hoping this won't be necessary. In any case, I'm going on
> vacation right after typing this mail and don't have the time right
> now. :)
Ok, well, whenever you're ready!
--
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: "headers redirect" weirdness
Posted by Taneli Saastamoinen <ts...@cs.helsinki.fi>.
["David N. Welton" <da...@dedasys.com> Mon, Aug 16, 2004 at 05:15:24PM EEST]
> Well, what changed? No one has done any commits lately, so it leads
> me to think it may be on your end unless you recently upgraded to a
> new version. So what might have been moved around in your code that
> would cause a 'puts' to happen before the 'headers redirect' line is
> hit?
Umm... Okay, so here's the deal. Essentially nothing has changed, except
that we have some more redirects in the code now. But, IIRC, we _had_
puts's in the code before "headers redirect"'s previously, and it
_worked_. I take it that isn't actually supposed to work?
Related to this, our design is currently somewhat suboptimal; we're
working on it, and will soon have eliminated almost all puts's. So we're
doing all the logic and any possible header redirects first, and "puts
$actual_content" then. From what I gather, that should work _every time_.
I couldn't find any accurate information anywhere as to what exactly
causes the headers to be sent; if it is the case that a puts before a
headers redirect _should_ cause everything to fail, but doesn't always,
I think that should be mentioned in the documentation. (Actually, I
think it should also be documented exactly which things cause, or
_might_ cause, the headers to be sent. Is it only the puts, or is there
something else?)
> If you can provide a really simple example that causes the problem, I
> will look at it and see if I can reproduce it and then find the
> problem.
I'm kinda hoping this won't be necessary. In any case, I'm going on
vacation right after typing this mail and don't have the time right now.
:)
--
Peruna tarvitsee kasvinsuojelurekisterinumeron ja tulipoltteen
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
ncgi compatibility layer
Posted by "David N. Welton" <da...@dedasys.com>.
I added in the beginnings of an ncgi compatibility layer, in order to
be able to take more or less unmodified CGI style Tcl scripts and run
them under Rivet. It doesn't implement everything yet, but it was
enough to get 'yakuwiki' going (an open source wiki that runs
http://leenooks.com/1 ).
Ciao,
--
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: "headers redirect" weirdness
Posted by "David N. Welton" <da...@dedasys.com>.
Taneli Saastamoinen <ts...@cs.helsinki.fi> writes:
> Hi, we're having some problems with "headers redirect $some_url"
> reporting "Cannot manipulate headers - already sent".
> A word about our setup. The actual pages are page1.rvt, page2.rvt
> etc. They contain a proc named main_content, which does some basic
> logic and then puts's out all the actual html. Each page defines
> main_content in its own way, then says "parse
> $path/header.rvt". header.rvt does some logic with "source
> stuff.tcl", then puts's the page headers, then does some more logic
> with "parse login_stuff.rvt", then calls main_content when
> everything is ready.
> Now this kind of setup used to work a few weeks or months ago. And
> it still works, except that "headers redirect $any_url" doesn't work
> within main_content any more. I'm not sure why. It complains about
> the headers already being sent.
Well, what changed? No one has done any commits lately, so it leads
me to think it may be on your end unless you recently upgraded to a
new version. So what might have been moved around in your code that
would cause a 'puts' to happen before the 'headers redirect' line is
hit?
That's what you need to look for, because due to the way http is, you
have to send headers before you send the page.
> If I comment out the "parse login_stuff.rvt" in header.rvt, all the
> redirects work perfectly. Then, when I uncomment it, the redirects
> don't work. Even if I comment out _every single line_ of
> login_stuff.rvt, the "parse login_stuff.rvt" is sufficient to
> magically make all subsequent redirect attempts non-working.
Ok, this is interesting...
> So is this a problem with the parse command? What exactly causes the
> headers to be sent? I found no helpful hints anywhere, and don't
> have the time to source-dive too much right now.
> As I said, this setup used to work before, and I have no idea why it
> doesn't work now. I'd appreciate any clues. We're currently using an
> ugly kludgy workaround, but would much prefer real redirects.
If you can provide a really simple example that causes the problem, I
will look at it and see if I can reproduce it and then find the
problem.
--
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org