[Web-SIG] WSGI and start_response

[Graham Dumpleton]

On 13 April 2010 21:46, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> On Tue, Apr 13, 2010 at 13:39, Graham Dumpleton
> <graham.dumpleton at gmail.com> wrote:
>> WSGI 2.0 isn't about Python 3.X, it is about removing start_response().
>
> Okay, so it is orthogonal, right?
>
>> Python 3.X support can be catered for by clarifications in the WSGI
>> 1.0 specification and to a degree how Python 3.X is implemented is
>> dictated by existing practice in the form of what wsgiref implemented
>> in Python 3.1. The Apache/mod_wsgi implementation has had Python 3.X
>> support for over a year using the same interpretation. I believe
>> latest CherryPy WSGI server code is also providing Python 3.X support.
>>
>> Apache/mod_wsgi tried to push the issue of a new
>> definition/specification to cater for Python 3.X by actually
>> identifying itself as WSGI 1.1. The attempts at ratifying that didn't
>> happen however, but then no one has turned around either to complain
>> about Apache/mod_wsgi identifying itself as WSGI 1.1 and so it has
>> been left that way and not reverted to WSGI 1.0.
>>
>> So, in effect existing practice has determined how WSGI on Python 3.X
>> should be implemented and given how long this has been going on,
>> nothing is likely to change that now. You can however see a summary of
>> how it is being interpreted at:
>>
>>  http://code.google.com/p/modwsgi/wiki/SupportForPython3X
>
> So that page has 8 points required for 3.x, which apparently wsgiref
> and CherryPy also adhere to?
>
> And you have 5 simplifications that, as far as we know, have only been
> been implemented in mod_wsgi?

They are not simplications. They are clarifications or just describing
existing practice. They are not necessarily mod_wsgi specific.

(1) Implemented by everyone already otherwise cgi.FieldStorage doesn't work.

(2) Implemented by the more reputable WSGI servers such as CherryPy
and Paste WSGI servers. Not implemented by wsgiref. An implementation
that doesn't implement it and which doesn't discard request content
yet supports HTTP 1.1 request pipelining is arguably broken. A
correctly implemented WSGI middleware already has to cope with an
empty string as end sentinel anyway to detect premature end of input.

(3) Only implemented by Apache/mod_wsgi that I know of for sure.
Although it makes it work like a proper file like object as
specification suggests wsgi.input is, would raise potential issues
with WSGI middleware which depend on it then not being able to be used
with WSGI 1.0 and so intent was that it not be made a requirement.

(4) This is a statement about WSGI middleware, not the WSGI server. A
WSGI middleware that doesn't do it is arguably broken and can generate
incorrect data. Thus is a clarification of obligations only.

(5) A WSGI server shouldn't do this now as doing so is technically a
voilation of HTTP. Thus is a clarification of obligations only.

You can find more detail on these at:

  http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html

Graham