re-posting: web.py, incomplete

[_wolf]

hi all,

this is a re-posting of my question i asked a month or so ago. i
installed web.py, flups, and cheetah. when i copy'n'paste the sample
app from then http://webpy.org homepage ::

import web

urls = (
'/(.*)', 'hello'
)

class hello:
def GET(self, name):
i = web.input(times=1)
if not name: name = 'world'
for c in xrange(int(i.times)): print 'Hello,', name+'!'
# point (1)

if __name__ == "__main__": web.run(urls)

it does seem to work *but* when i call it with sth like

http://localhost/cgi-bin/webpyexample.py/oops?times=25

then the output is ::

Hello, oops!
Hello, oops!
<20 lines omitted/>
Hello, oops!
Hel

it is only after i insert, at point (1) as shown in the listing, ::

print ( ( ' ' * 100 ) + '\n' ) * 10

---print ten lines with a hundred space characters each---that
i do get to see all twenty-five helloes. so, this is likely a
character buffering problem. as far as i can see, it is a consistent
amount of the last 32 characters that is missing from the page
source. ok i thought so let's just output those 32 characters, ::

print ' ' * 32

but *this* will result in a last output line that is 8 characters
long, so someone swallows 24 characters. does look like
a buffer of fixed length.

i'd like to bust that ghost.

_wolf

 

[Magnus Lycka]

then the output is ::

Hello, oops!
Hello, oops!
<20 lines omitted/>
Hello, oops!
Hel

Are you running Python unbuffered? I.e. python -u

 

[_wolf]

it does look like it, no? but i don't---at least i think i don't. in my
httpd conf it says
``AddHandler cgi-script .py``, and at the top of my script,
``#!/usr/local/bin/python``. standard, no ``-u`` here.

 

[Dennis Lee Bieber]

it does look like it, no? but i don't---at least i think i don't. in my
httpd conf it says
``AddHandler cgi-script .py``, and at the top of my script,
``#!/usr/local/bin/python``. standard, no ``-u`` here.

That may be part of the problem -- partial buffer not being
written...

Have you tried a flush operation on stdout?
--

 

[Magnus Lycka]

No, it looks the other way around: You have buffered output,
and parts of your stdout never gets flushed. -u is not a
problem, it's the normal fix for this.

That may be part of the problem -- partial buffer not being
written...

Have you tried a flush operation on stdout?

Just change the first line to ``#!/usr/local/bin/python -u``.
You don't want buffered output in CGI apps.

 

[_wolf]

ok, that does it! th@nks a lot!

sorry first of all for my adding to the confusion when i jumped to
comment on that ``-u`` option thing---of course, **no -u option** means
**buffered**, positively, so there is buffering and buffering problems,
**with -u option** there is **no buffer**, so also no buffering
problems at that point. these add-option-to-switch-off things do get
confusing sometimes.

ok, so the ``#!/usr/local/bin/python -u`` does work. as noted on
http://www.imladris.com/Scripts/PythonForWindows.html: "Trying to run
python cgi scripts in the (default) buffered mode will either result in
a complete lack of return value from your cgi script (manifesting as a
blank html page) or a "premature end of script headers" error." funny
you don't get to see a lot of ``-u`` shebang lines these days tho. as
the document goes on to explain, there is a way to put ::

SetEnv PYTHONUNBUFFERED 1

into your apache ``httpd.conf``. this works for me! great!

now, thinking about this problem it strikes me it has never bitten me
before, where it should have. is there something special about the way
web.py cgi apps work that make this thing pop up? also, in theory,
since apache itself (as of v1.3) does no buffering of cgi output, then
when apache calls a cgi process, and that process happily buffers at
its own descretion, and then finalizes and terminates, then should the
remaining buffer not be output and sent to apache---as happens with a
script run from the command line? you do get to see all the output in
that case, at long last upon process termination, right? i'm wondering.

_wolf