On 4 January 2011 11:43, Guido van Rossum <gu...@python.org> wrote: > On Mon, Jan 3, 2011 at 3:13 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: >> On Sun, Jan 2, 2011 at 9:21 AM, Guido van Rossum <gu...@python.org> wrote: >>> Although [PEP 3333] is still marked as draft, I personally think of it >>> as accepted; [...] >> >> What does it take to get PEP 3333 formally marked as accepted? Is >> there anything I can do to push that process forward? >> >> The lack of a WSGI answer on Py3 is the main thing that's keeping me, >> personally, from feeling excited about the platform. Once that's done >> I can feel comfortable coding to it -- and browbeating those who don't >> support it. >> >> I understand that PEP 444/Web3/WSGI 2/whatever might be a better >> answer, but it's clearly got some way to go. In the meantime, what's >> next to get PEP 3333 officially endorsed and accepted? > > I haven't heard anyone speak up against it, ever, since it was > submitted. If no-one speaks up in the next 24 hours consider it > accepted (and after that delay, anyone with SVN privileges can mark it > thus).
I note one issue which I have expressed concern over previously. In section 'Handling the Content-Length Header; it says: """ Under some circumstances, however, the server or gateway may be able to either generate a Content-Length header, or at least avoid the need to close the client connection. If the application does not call the write() callable, and returns an iterable whose len() is 1, then the server can automatically determine Content-Length by taking the length of the first bytestring yielded by the iterable. """ As documented in: http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html the automatic addition of a Content-Length response header where len(iterable) is 1, can cause wrong output for cases where WSGI application believes that it can itself decide not to return any actual content for a HEAD response, ignoring the fact that there could be output filters which rely on headers or content being exactly the same as for GET. Do we therefore still want to promote the idea that the optimisation is a good idea or even allowed? Next thing is the reference to Jython in section 'Supporting Older (<2.2) Versions of Python' which are quite out of date with respect to version of Python it supports. Should that be updated? Should that whole section be removed now? Finally, I'd still like to see the CGI gateway example be updated to properly protect stdin/stdout so that people using print() without redirecting it to stderr don't stuff themselves up. For example: # Keep a reference to the original stdin. We then replace # stdin with an empty stream. This is to protect against # code from accessing sys.stdin directly and consuming the # request content. stdin = sys.stdin sys.stdin = cStringIO.StringIO('') # Keep a reference to the original stdout. We then replace # stdout with stderr. This is to protect against code that # wants to use 'print' to output debugging. If stdout wasn't # protected, then anything output using 'print' would end up # being sent as part of the response itself and interfere # with the operation of the CGI protocol. stdout = sys.stdout sys.stdout = sys.stderr The adapter would then use stdin/stdout local variables and not sys.stdin/sys.stdout. The CGI adapter in wsgiref should also really be updated to do something similar. This would solve the portability problem where code is written for non CGI hosting environment and they leave 'print' statements in which breaks on CGI. Even if people who have copied the CGI gateway from PEP previously don't update their implementations, have at least set what is best practice for the future. BTW, I am not across how stdin/stdout works on Windows, but is there an issue with that CGI example working on Windows because of text stream vs byte stream issues and CRLF translation? Graham _______________________________________________ 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
