On 4 January 2011 16:39, Guido van Rossum <guido@pyth...> wrote:
> On Mon, Jan 3, 2011 at 7:39 PM, Graham Dumpleton
> <graham.dumpleton@gmai...> wrote:
>> 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.
> That is copied exactly from PEP 333, i.e. WSGI 1.0. I didn't mean to
> solicit objections to parts of PEP 3333 that are the same as PEP 333;
> PEP 3333 is intended only to specify how WSGI 1.0 compliance is
> supposed to work in Python 3. Some clarifications to the original WSGI
> 1.0 wordings were actually added to PEP 333 around the same time that
> PEP 3333 was spun off; AFAIK the changes to PEP 333 were
> noncontroversial and merely clarifications of how WSGI already works.
> I don't think you can change the above bit of specification (no matter
> how bad it is) and still call the resulting spec WSGI 1.0(.x) -- we
> don't want to rule out WSGI 1.0 compliance of apps or frameworks that
> would be considered compliant under the original 1.0 spec.
I don't believe this really causes a compliance issue as it is a
requirement on the WSGI server, not the WSGI application and doesn't
cause any existing WSGI applications to break.
It also says 'can' and not 'must' so technically WSGI servers are not
currently obligated to do it as I read it and certainly mod_wsgi
doesn't do it any more because it was causing problems for people.
But then, since it does say 'can' and not 'must' any WSGI server
implementers who know better can just ignore it anyway if it if left
in, and it can be dealt with in any new major revision.