[Web-SIG] Move to bless Graham's WSGI 1.1 as official spec

Sun Nov 29 05:28:26 CET 2009

2009/11/29 Graham Dumpleton <graham.dumpleton at gmail.com>:
> After reading my prior blog posts where I explained my reasoning
> behind the changes, I will acknowledge that I haven't explained some
> stuff very well and people are failing to understand or getting wrong
> idea about why something is being suggested.
>
> I still believe there are though underlying problems there in the WSGI
> specification and right now, more by luck than design is various stuff
> working. In some cases such as readline(), the majority of WSGI
> applications/frameworks are in violation of the WSGI 1.0 specification
> due to their reliance on cgi.FieldStorage which makes calls to
> readline() with an argument.
>
> Either way, since there seemed to be objections at some level on every
> point, and since I really really have no enthusiasm for this stuff any
> more or of fighting for any change, I retract my personal interest in
> having any of the amendments as part of a WSGI 1.1 specification and
> will remove all that detail from mod_wsgi documentation. I will
> instead replace it with a separate page describing mod_wsgi compliance
> with WSGI 1.0 specification and highlighting those specific features
> which are in common, or not so common use, via mod_wsgi and which
> actually mean that people are writing applications incompatible with
> the WSGI 1.0 specification.
>
> To ensure compliance I could well raise Python exceptions for any use
> which isn't WSGI 1.0 compliant, but I have already learnt from where I
> tried get people to write portable WSGI applications by giving errors
> on certain use of stdin and stdout, that it is a pointless battle. All
> it got was a long list of users who believe mod_wsgi is broken even
> though if they read the actual documentation they would find it was
> their own software which was suspect or at least wasn't portable to
> all WSGI hosting mechanisms. This would only get worse if exceptions
> were raised for use of readline() with an argument and use of read()
> with no argument or argument of -1. Short story is that there are a
> fair few people who are just lazy, they will always write stuff the
> way the want to and not how it should be written. They will always
> blame other peoples code for being wrong before acknowledging they
> themselves are wrong.
>
> The only answer I therefore need out of WEB-SIG is whether the
> qualifications about how Python 3.X is to be supported are going to be
> an amendment to WSGI 1.0 or as a separate WSGI 1.1 update and whether
> if the latter whether the WSGI 1.1 tag will also have meaning for
> Python 2.X.
>
> I need an answer to this so I know whether to withdraw mod_wsgi 3.0
> from download and replace it with a mod_wsgi 4.0 which changes the
> wsgi.version tuple being passed, for both Python 2.X and Python 3.X,
> from (1, 1) back to original (1, 0), given that some opinion seems to
> be that any interface changes can only really be performed as part of
> WSGI 2.0 and so I would be wrong in using (1, 1).
>
> If don't see an answer, then guess I will just have to revert it back
> to (1, 0) to be safe and to avoid any accusations that am highjacking
> the process.
>
> An answer sooner rather than later would be appreciated on the
> wsgi.version issue.

Answering my own question, it is actually obvious that it has to be
called (1, 0). This is because wsgiref in Python 3.X already calls it
(1, 0) and don't have much choice to be in agreement with that.

I will therefore replace mod_wsgi 3.0 with a 4.0 release that reverts
it to (1, 0) from (1, 1) and all the other stuff about amendments can
be ignored.

Graham

> 2009/11/28 Graham Dumpleton <graham.dumpleton at gmail.com>:
>> Please ensure you have also all read:
>>
>> http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html
>>
>> I will post again later in detail when have some time to explain a few
>> more points not mentioned in that post and where people aren't quite
>> understanding the reasoning for doing things.
>>
>> One very quick comment about read().
>>
>> Allowing read() with no argument is no different to a user saying
>> read(environ['CONTENT_LENGTH']). Because a WSGI adapter/middleware is
>> going to have to track bytes read to ensure can return an empty string
>> as end sentinel, it will know length remaining and would internally
>> for read() with no argument do read(remaining_bytes). As such no real
>> differences in inefficiencies as far as memory use goes for
>> implementing read() because of need to implement end sentinel.
>>
>> Also, you have concerns about read() with no argument, but frankly
>> readline() with no argument, which is already required, is much worse
>> because you cant really track bytes read and just read to end of
>> input. This is because they only want to read to end of line and so
>> reading all input is going to blow out memory use unreasonably as you
>> speculate for read(). As such, a readline() implementation is likely
>> to read in blocks and internally buffer where read() doesn't
>> necessarily have to.
>>
>> It may also be pertinent to read:
>>
>> http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html
>>
>> as from memory it talks about issues with not paying attention to
>> Content-Length on output filtering middleware as well.
>>
>> As I said, will reply later when have some time to focus. Right now I
>> have a 2 year old to keep amused.
>>
>> Graham
>>
>> 2009/11/27 James Y Knight <foom at fuhm.net>:
>>> I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the official definition of WSGI 1.1, which describes how to implement WSGI adapters for both Python 2.x and 3.x. It may not be perfect, but, it's been implemented twice, and seems ot have no fatal flaws (it doesn't do any lossy transforms, so any issues are irritations at worst). The basis for this definition is also described in the "WSGI 1.0 Ammendments" [2] page.
>>>
>>> The definitions as they stand are clear enough to understand and implement, but not currently in spec-worthy language. (e.g. it says "should" and "may" in a colloquial fashion, but actually means MUST in some places and SHOULD in others, as defined by RFC 2119)
>>>
>>> Thus, I'd like to suggest that Graham (if he's willing?) should reformat the "Definition"/"Ammendments" as an actual diff against the current PEP 333. Then, I will recommend adopting that document as an actual standard WSGI 1.1, to replace PEP 333.
>>>
>>> This discussion has gone on long enough, and it doesn't really matter as much to have the perfect API, as it does to have a standard.
>>>
>>> James
>>>
>>> [1] http://code.google.com/p/modwsgi/wiki/SupportForPython3X
>>> [2] http://www.wsgi.org/wsgi/Amendments_1.0
>>>
>>> _______________________________________________
>>> Web-SIG mailing list
>>> Web-SIG at python.org
>>> Web SIG: http://www.python.org/sigs/web-sig
>>> Unsubscribe: http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com
>>>
>>
>