[Web-SIG] serving (potentially large) files through wsgi?

[Brian Smith]

Graham Dumpleton wrote:
> > > However there are some problems.
> > > The log object has a fixed error level (NGX_LOG_ERR);
> > > this means that every message logged using this object
> > > will have this error level, even if I do, as example:
> > > log.info('just an info message')
> >
> > I'm missing the relationship between this and python's 
> > logging package. 
> 
> As I believe I have said before, I disagree with how you are 
> trying to make logging module output simply go to sys.stderr. 
> If you want to preserve the concept of logging levels, then 
> expose the internal web server logging function, including it 
> accepting its concept of log level, and write a log handler 
> for the logging module that uses it instead.

<snip>

> So, there is no reason to force fit log levels into 
> wsgi.errors or sys.stderr somehow.

> > > A better solution could be the integration with the 
> > > logging module.

> Thus, I don't see this an issue, you just make it 
> transparently map as best you can in your nginx specific log 
> handler for the logging module.

<snip>

The WSGI specification doesn't say anything about what the WSGI gateway
will do regarding the python logging module. It only talks about
wsgi.errors. My initial understanding of this was that my WSGI
application is supposed to ensure that all its loggers write their
output to wsgi.errors. But, if I did this, there is no opportunity for
the WSGI gateway to translate the logging package's logging levels into
the host environment's logging levels, since the level information is
lost when the logged information passes through wsgi.errors.
Furthermore, doing so turned out to be impossible anyway, since I can't
reliably redirect the output of every logger used by every third-party
package and every built-in package.

It would make more sense for the WSGI specification to explicitly say
that WSGI gateways are responsible for setting the default logging
output location. Every WSGI gateway has to do this anyway to handle
non-WSGI-aware modules that use the python logging module. The
specification should then also explicitly say that WSGI applications
should not redirect logging output to wsgi.errors or anywhere else. In
fact, if that was done, there would be no reason to have wsgi.errors in
the first place. 

See also:
http://mail.python.org/pipermail/web-sig/2007-November/002948.html

- Brian