[Web-SIG] serving (potentially large) files through wsgi?
brian at briansmith.org
Fri Dec 21 17:58:16 CET 2007
Manlio Perillo wrote:
> Graham Dumpleton ha scritto:
> > On 21/12/2007, Brian Smith <brian at briansmith.org> wrote:
> >> 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.
> > At least in the context of Apache, wsgi.errors is
> > different to sys.stderr or a global logging module
> > output target. This is because wsgi.errors is linked
> > to the actual request and so any output can be
> > correctly redirected to a per virtual host error log.
(Apache) mod_wsgi uses threads, right? You could keep a map (thread ->
output stream), possibly using thread-local variables, to keep track of
where to redirect stderr and logging output.
> This is the same for Nginx.
> sys.stderr is linked to the nginx main cycle logging,
> wsgi.errors to the request logging.
In Nginx, there is only one thread, right? So, it should be a simple
matter for the Nginx web_wsgi to keep track of the proper log file to
redirects stderr and logging output to.
Whether or not the specification requires you to do this, you really
should be doing this anyway, because there are a lot of applications
that using the long-standard python logging package (including many
modules that are not WSGI-specific), and dumping all that output into
the wrong location when you have enough information to get it right
doesn't make any sense.
More information about the Web-SIG