Phillip J. Eby ha scritto:
> At 08:24 PM 10/3/2007 +0200, Manlio Perillo wrote:
>> WSGI already
>> states that the WSGI gateway should not buffer the data).
>
> It does not state that at all. It states that a gateway *must not delay
> the transmission of any block*. That requirement is not a "should" but
> a "must", and it does not directly state anything about buffering, one
> way or the other.
>
> It *does*, however, imply that buffering is only acceptable if the
> buffer is being asynchronously emptied, via another thread or the OS
> emptying its own OS-level buffers. (e.g. if you're using synchronous
> sockets)
>
Ok.
>
>> Note that in Nginx, unlike Apache, an output buffer can process a
>> partial buffer, so, for a WSGI application like:
>>
>> start_response('200 OK', [...])
>>
>> yield 'xxx'
>> yield 'yyy'
>> yield 'zzz'
>>
>>
>> the 'xxx' string is sent to the next output buffer, and, finally it is
>> sent to the client.
>>
>> Now can happens that the socket is not ready to send further data, so
>> the application must be paused until the socket is ready.
>>
>> When the socket is ready, the next buffer can be sent to the next outpup
>> buffer, and so on.
>
> In the above code, when "yield 'yyy'" is invoked, one of two conditions
> must apply. Either:
>
> 1. the 'xxx' has been sent to the OS, OR
> 2. it is still being sent in the background by another thread
>
> If it is possible to execute the "yield 'yyy'" line without one of these
> conditions applying, the gateway is *not* WSGI compliant.
>
I'm not sure, but I think that the 'xxx' can be still in one of the
output filter buffers (like gzip), unless we explicitly require it to be
flushed.
Nginx does not use threads.
By the way: I think that the environ dictionary should contain a new
wsgi.asynchronous value, that should evaluate true if the WSGI gateway
is asynchronous.
This may be necessary, because a WSGI application should know that it
can be suspended, even if it not requested it.
>
Regards Manlio Perillo
_______________________________________________
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
