Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Reading negative length in pywsgi wsgi.input never returns #1274
Python sometimes uses read length -1 for reading all (like in file i/o) and sometimes None (like in http)...
When reading a non chunked body in pywsgi from wsgi.input with negative length (or -1) it gets stuck in the read command, the chunked code path has a check for this:
Maybe it's worth adding it in regular read as well before:
Also a minor nitpick (although it seems other frameworks have this issue as well):
If application already sets a Transfer-Encoding: chunked in the headers in start_response, pywsgi will not check it, and add another one (if it deems to use it), resulting in a Transfer-Encoding: chunked, chunked (Might be the same for Content-Length). Maybe those headers should be removed if they are conflicting (when deciding which headers to send) ?
What I've run:
from gevent.pywsgi import WSGIServer def app(env, start_response): print env['wsgi.input'].read(-1) start_response('204 OK', ) return  WSGIServer(('', 1234), app).serve_forever()
Maybe? The specification only says that "A server should allow
A PR that moves the check from
I believe that means the application is buggy. The specification says " applications and middleware must not apply any kind of Transfer-Encoding to their output, such as chunking or gzipping; as "hop-by-hop" operations, these encodings are the province of the actual web server/gateway."
referenced this issue
Sep 12, 2018
Just a quick question before this issue is closed (unrelated, but I want to know if to open a new issue or it's a wontfix).
When trying to read from Input using env['wsgi.input'].read(size) where size is a number > 31bit (i.e. 2GB) or content_length is > 31bit this will trigger:
Shouldn't we be able to handle reading inputs larger than 2GB ? (The comment is wrong, it's 31bit, since the if cStringIO does not have the required data in buffer, it would try passing the read length to the original socket .recv command which can only do 2GB at a time).
In a single go? It's under-specified. gevent.pywsgi and wsgiref both have the OverflowError issue on CPython 2.7 only; it works on PyPy 2.7 and CPython 3. On CPython 2.7, gunicorn appears to allow it (though allocating a single 2GB string may in the end prove challenging), while waitress rejects it via a configurable policy.