Graham, I thought I'd reply, so that we'd get replies from everyone else to tell me I'm wrong.
All your points are good common-sense stuff. I think that all of your policies on stdin, stdout, and stderr are good, and are appropriate for a WSGI environment running inside an Apache server. Some small points. > ..... one could actually write to sys.stdout directly as > well since that is where the WSGI adapter writes it to anyway. I think it's a good idea to redirect stdout, and to document in your server/gateway documentation that you are doing so. I also think this is a server specific issue. > Anyway, it may seem good practice for a WSGI adapter to still prevent > use of sys.stdin unless configured explicitly to allow it and even > then it might only allow it if the server is running in a mode whereby > it would work. This should be a server-specific feature, that is documented. > Finally, sys.stderr also presents problems of its own. Although > wsgi.errors is provided with the request environment, this can't be > used at global scope within a module when importing and also shouldn't > be used beyond the life time of the specific request. Thus, there > isn't a way to log stuff outside of a request and ensure it gets to > the server log. One could try and mandate use of 'logging' module, but > this isn't available in old versions of Python. I don't think you need to worry about versions of python that don't have the logging module. Strictly speaking, WSGI requires python 2.2, because of iterators. So I think it's extremely unlikely that people will be running WSGI apps on pre-2.2 VMs. > What you need is for sys.stderr to be underlayed with thread > specific log objects each with its own buffering mechanism that > ensures that only complete lines of text get sent to the actual log > file. This is a server/gateway implementation detail. > Yes one could simply ignore the whole issue, but I feel that a good > quality WSGI adapter/server should address these issues and either > lock things down as appropriate to protect users from themselves or > ensure that using them results in a sensible outcome. Given how much talk there is of the WSGI "environment", I think it's good to raise these issues. Regards, Alan. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
