[Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

[Graham Dumpleton]

On 4 January 2011 11:43, Guido van Rossum <guido at python.org> wrote:
> On Mon, Jan 3, 2011 at 3:13 PM, Jacob Kaplan-Moss <jacob at jacobian.org> wrote:
>> On Sun, Jan 2, 2011 at 9:21 AM, Guido van Rossum <guido at 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