[issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg
Robin Schoonover added the comment: I'm not sure I follow, as it has little to say on whether the application's expected behavior here, and only a recommendation that the server allow it. But, it also defers to the Python Standard Library, which does have an opinion. I feel that (in hindsight) the exact behavior of each method should have been specified in full. *However*, even if I differ on the reading of the spec, on general principle (and this has changed since I first wrote the issue) I agree that the application should not be omitting it anyway, because reading the entire response at once without checking the content length is dangerous. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18610 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21890] wsgiref.simple_server doesn't accept empty bytes before start_response is called
Robin Schoonover added the comment:
Fair enough, I misled myself.
However, and I feel like I'm getting really picky here, but it still doesn't
fulfill the paragraph I quoted:
def application(environ, start_response):
start_response('200 OK',
[('Content-type', 'text/plain')])
yield b''
try:
# produce an exception tuple, so we can re-call s_r
raise RuntimeError
except RuntimeError:
# Headers shouldn't have been sent, but they were
# so this will throw:
start_response('200 OK',
[('Content-type', 'text/plain')],
sys.exc_info())
yield b'error data or whatever'
But if async support a foregone conclusion anyway, is it worth bothering
complying with that odd requirement?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21890
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21890] wsgiref.simple_server sends headers on empty bytes
Robin Schoonover added the comment: I agree, the current patch is too permissive. Both a server I wrote a while ago, and most other complaint servers deal with the problem the exact same way as that patch, and that extra permissiveness led to my misinterpretation when analyzing why I had made that original change. In any case, I've attached an updated patch. -- resolution: not a bug - status: closed - open title: wsgiref.simple_server doesn't accept empty bytes before start_response is called - wsgiref.simple_server sends headers on empty bytes Added file: http://bugs.python.org/file35835/wsgiref-empty-byte-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21890 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21890] wsgiref.simple_server sends headers on empty bytes
Changes by Robin Schoonover ro...@cornhooves.org: Added file: http://bugs.python.org/file35836/wsgiref-empty-byte-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21890 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21890] wsgiref.simple_server doesn't accept empty bytes before start_response is called
Changes by Robin Schoonover ro...@cornhooves.org: -- keywords: +patch Added file: http://bugs.python.org/file35810/wsgiref-empty-byte.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21890 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21890] wsgiref.simple_server doesn't accept empty bytes before start_response is called
New submission from Robin Schoonover: Consider this paragraph of PEP, referring to headers obtained via start_response, emphasis mine: Instead, it must store them for the server or gateway to transmit only after the first iteration of the application return value that yields a *non-empty bytestring*, or upon the application's first invocation of the write() callable. This means that an WSGI app such as this should be valid, because the yielded bytes pre-start_response are empty: def application(environ, start_response): yield b'' start_response(200 OK, [(Content-Type, text/plain)]) yield b'Hello, World.\n' However, in wsgiref's simple server, this fails: Traceback (most recent call last): File /usr/local/lib/python3.4/wsgiref/handlers.py, line 180, in finish_response self.write(data) File /usr/local/lib/python3.4/wsgiref/handlers.py, line 269, in write raise AssertionError(write() before start_response()) AssertionError: write() before start_response() -- components: Library (Lib) messages: 222005 nosy: pje, rschoon priority: normal severity: normal status: open title: wsgiref.simple_server doesn't accept empty bytes before start_response is called type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21890 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg
Changes by Robin Schoonover ro...@cornhooves.org: -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18610 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21878] wsgi.simple_server's wsgi.input readline waits forever for non-multipart/form-data
New submission from Robin Schoonover:
In the reference WSGI server in wsgiref.simple_server, wsgi.input's readline()
hangs if the request body does not actually contain any
newlines.
Consider the following (slightly silly) example:
from wsgiref.simple_server import make_server
def app(environ, start_response):
result = environ['wsgi.input'].readline()
# not reached...
start_response(200 OK, [(Content-Type, text/plain)])
return []
httpd = make_server('', 8000, app)
httpd.serve_forever()
And the following also silly request (the data kwarg makes it a
POST request):
from urllib.request import urlopen
req = urlopen(http://localhost:8000/;, data=b'some bytes')
print(req)
Normally this isn't a problem, as the reference server isn't intended
for production, and typically the only reason .readline() would be
used is with a request body formatted as multipart/form-data, which
uses ample newlines, including with the content boundaries. However,
for other types of request bodies (such as application/x-www-form-urlencoded)
newlines often wouldn't appear, and using .readline() would wait forever for
new input.
--
components: Library (Lib)
messages: 221774
nosy: rschoon
priority: normal
severity: normal
status: open
title: wsgi.simple_server's wsgi.input readline waits forever for
non-multipart/form-data
type: behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21878
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21878] wsgi.simple_server's wsgi.input read/readline waits forever in certain circumstances
Robin Schoonover added the comment: Issue also occurs if .read() is used with no size. -- title: wsgi.simple_server's wsgi.input readline waits forever for non-multipart/form-data - wsgi.simple_server's wsgi.input read/readline waits forever in certain circumstances ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21878 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18610] wsgiref.validator expects wsgi.input read to give exactly one arg
New submission from Robin Schoonover: wsgiref.validator requires wsgi.input's read to always give EXACTLY one argument. This is incorrect. It's own documentation says: * That wsgi.input is used properly: - .read() is called with zero or one argument PEP says: A server should allow read() to be called without an argument, and return the remainder of the client's input stream. -- components: Library (Lib) files: wsgiref.patch keywords: patch messages: 194027 nosy: Robin.Schoonover priority: normal severity: normal status: open title: wsgiref.validator expects wsgi.input read to give exactly one arg type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file31106/wsgiref.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg
Changes by Robin Schoonover ro...@cornhooves.org: -- title: wsgiref.validator expects wsgi.input read to give exactly one arg - wsgiref.validate expects wsgi.input read to give exactly one arg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8323] multiprocessing.Queue ignores pickle restrictions in .put()
New submission from Robin Schoonover e...@cornhooves.org: The multiprocessing module's version of the Queue class, which causes objects to be pickled for process to process transfer, ignores pickle restrictions when objects are added to the queue. Example code (buffer isn't pickleable): from multiprocessing import Queue q = Queue() q.put(buffer(this is a buffer)) print(q.get()) It results in an exception, which is expected, but the exception is confusing, after the problem has already occurred, and if I were actually using multiple processes, not in the process that tried to send an unsendable object: Traceback (most recent call last): File mppkbuffer.py, line 5, in module print(q.get()) File /usr/lib/python2.6/multiprocessing/queues.py, line 91, in get res = self._recv() TypeError: buffer() takes at least 1 argument (0 given) Expected result would be a thrown exception when we attempt to put the object into the queue using .put(), NOT when we attempt pull it out of the queue using .get(), when it gets unpickled. Basically, while pickle fails when it tries to dump, Queue succeeds the dump (somehow) and fails to load. I have tested with python 2.6.4 and 2.7a4. 3.1 doesn't appear to have this bug (but it does have a different one which I will report later). -- components: Library (Lib) messages: 102423 nosy: rschoon severity: normal status: open title: multiprocessing.Queue ignores pickle restrictions in .put() type: behavior versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8323 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8323] multiprocessing.Queue ignores pickle restrictions in .put()
Robin Schoonover e...@cornhooves.org added the comment: Since these sort of buffer objects don't exist in 3.x (so far as I know), I came up with a different way to test in 3.x (basically, trying to pickle bound or unbound methods). It turns out that using this method to test it in 2.6 seems to fail where it should (in .put()), so if there's some sort of object that isn't pickleable in the same way as buffer that exists in 3.x, it should be tested to see if this specific problem is actually confined to 2.6 or not. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8323 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Changes by Robin Schoonover e...@cornhooves.org: -- nosy: +rschoon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
