[Web-SIG] Collating follow-up on the future of WSGI

[Graham Dumpleton]

> On 20 Jan 2016, at 11:24 PM, André Malo <nd at perlig.de> wrote:
> 
> * Graham Dumpleton wrote:
> 
>>> On 20 Jan 2016, at 10:25 PM, André Malo <nd at 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 time.

Graham