Copterfly / modwsgi

Automatically exported from code.google.com/p/modwsgi
0 stars 0 forks source link

Need to dictate how sys.stdin, sys.stdout and sys.stderr can be used. #10

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The WSGI specification doesn't really say in what way sys.stdin, sys.stdout
and sys.stderr can be used. For some environments which WSGI can be used
in, for example CGI, the sys.stdin and sys.stdout streams actually have
special significance as they are how data is read from and written back to
the server. In the interest of highlighting portability issues with WSGI
scripts, use of sys.stdin and sys.stdout should probably be precluded and
raise an error.

With sys.stderr, although anything sent here gets to the Apache error log
if flushed it doesn't get time stamped like if ap_log_error() is used. As
such a special sys.stderr should perhaps be provided which buffers output
until complete lines are received or output flushed explicitly and the
buffered output only then sent to the log but via ap_log_error(). Only
issue with this is that each thread would need to have its own buffer area
and would need to ensure somehow that buffer areas are cleaned up if
threads finish, or if thread linked to request, that it is flushed and
cleaned up at end of request.

For further discussion of this, see Python WEB-SIG posting at:

http://groups.google.com.au/group/python-web-sig/browse_thread/thread/512874b8ac
16626e?hl=en

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 21 Mar 2007 at 10:47

GoogleCodeExporter commented 9 years ago
Now restrict access to sys.stdin and sys.stdout as described. The restrictions 
can
however be lifted using the WSGIRestrictStdin and WSGIRestrictStdout directives,
setting the values of the flags to Off instead of the default of On. If 
restriction
on sys.stdout is removed, anything written to sys.stdout will be written to the
Apache error log. Also now use an error log object for sys.stderr. This is line
buffered and there is only one per interpreter. As a result, different threads 
using
it at the same time to write partial lines of data will result in data being 
mixed
together. The idea of trying to have one error log object per thread wasn't 
perused
as not worth the trouble.

Original comment by Graham.Dumpleton@gmail.com on 25 Mar 2007 at 8:35