[Web-SIG] Fwd: Can writing to stderr be evil for web apps?
graham.dumpleton at gmail.com
Sun May 20 03:05:49 CEST 2012
On 19 May 2012 22:36, anatoly techtonik <techtonik at gmail.com> wrote:
> Martin expressed concerns that using logging module with stderr output
> can break web applications, such as PyPI. I couldn't find any proof or
> denials for this fact, and it became a showstopper for me for further
> contributions to PyPI, because clearly I can't write good code without
> the sense of confidence.
> Here is the commit in question:
> I was redirected here from python-dev. So can anybody tell where are
> those stdout/stderr fears coming from and how to dispell them?
> (include in WSGI notes)
Part of this is likely going to be due to my deliberate action in
early versions of mod_wsgi to prohibit reading from stdin and writing
to stdout. This was specifically done to highlight that portable WSGI
application shouldn't be working with stdin/stdout because in doing so
they would break under a CGI/WSGI bridge written to conform to the
example in the WSGI PEP.
People don't like to change though and so a lot of people would say
that mod_wsgi was broken and/or that one couldn't use stdout under
Apache even though there was a configuration option there to remove
the artificial limitation. Over time I saw this grow in to a bit of a
myth that one couldn't even use stderr and started to see stupid
things like people remapping both stdout and stderr to their own files
or even /dev/null.
Although this artificial limitation was removed some time ago with it
being optionally enabled if you want to test WSGI application
portability. Certain LTS Linux distros still ship ancient mod_wsgi
versions where the limitation is the default.
So I tried to enforce something to make people do the right thing, but
people prefer to write crap code I guess.
An old blog post where I bemoaned all this can be found at:
If the CGI/WSGI bridge example in the PEP had simple saved away
original stdin/stdout and replaced them with an empty StringIO and
stderr, this possibly would never have become the issue it was. My own
CGI/WSGI bridge does exactly that now so as to allow people writing
crap code to still run it on CGI/WSGI if they really need to:
More information about the Web-SIG