> On 20 Jan 2016, at 11:24 PM, André Malo <n...@perlig.de> wrote:
> * Graham Dumpleton wrote:
>>> On 20 Jan 2016, at 10:25 PM, André Malo <n...@perlig.de> wrote:
>>> Regarding chunked requests - in my own WSGI implementation I went the
>>> most pragmatic way and simply provided a CONTENT_LENGTH of -1 for unknown
>>> request sizes (it maps very well to file.read(size)). Something like this
>>> would be my suggestion for a future WSGI spec.
>> I am assuming here you mean that -1 means return whatever you have
>> available, or block until you have something.
>> Problem with that is that some implementations will use -1 as a default
>> value to mean no argument supplied and so read all input.
> That was actually the idea. It has the same semantics (as in 
> file.read(int(environ['CONTENT_LENGTH'])). Since -1 is not covered by RFC 
> 3875, it should not break much as well (*cough*).
>> So that could well conflict with some implementations.
>> Also, if it is going to block, how is it really different to reading with a
>> block size.
> It's not. It's a signal, that the gateway has no idea about the size of the 
> request body and you (as the application) should not make any assumptions. 
> You wouldn't read(-1) a file of unknown size either.

Okay. Didn’t read properly everything you said. I thought you were trying to 
give read() with -1 a special meaning only. Not that you are also suggesting 
CONTENT_LENGTH in WSGI environ would be -1.

I can’t remember the details but I recollect when this was discussed once 
before that setting CONTENT_LENGTH to -1 was determined as not being a good 
idea. Would need to go back through the archives to find the reasons brought up.

Anyway, it becomes unnecessary if you simply change things such that you should 
read, in chunks as necessary, until get back an empty byte string. You don’t 
need a special CONTENT_LENGTH value to indicate unknown length at that point.

If you want to deal with partial reads of unknown length, still better to have 
ASYNC as then you can avoiding blocking and be doing something else at same 

Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to