using req.environ[wsgi.input].read() makes tracd connection stall

[trac@…]

When I run tracd and attempt to access a URI whose handler uses Request.environ['wsgi.input'].read(), that connection hangs until I cancel it. Attached is a testcase plugin and output log.

[trac@…]

command line output + tracd log output

[trac@…]

testcase plugin source code; tested using r3640

[Matthew Good]

Replying to trac@lazymalevolence.com:

When I run tracd and attempt to access a URI whose handler uses Request.environ['wsgi.input'].read(), that connection hangs until I cancel it. Attached is a testcase plugin and output log.

During the initialization of the Request object all the content of wsgi.input is read, so there will be nothing left to read in the request handler. For help developing a plugin check on the MailingList, since reading from wsgi.input is not the right way to get the data you need.

[trac@…]

Replying to mgood:

Replying to trac@lazymalevolence.com:

When I run tracd and attempt to access a URI whose handler uses Request.environ['wsgi.input'].read(), that connection hangs until I cancel it. Attached is a testcase plugin and output log.

During the initialization of the Request object all the content of wsgi.input is read, so there will be nothing left to read in the request handler. For help developing a plugin check on the MailingList, since reading from wsgi.input is not the right way to get the data you need.

Firstly, based on reading the code in trac/web/api.py, it seems that the content of wsgi.input is read only if the Content-Type indicates that it is form data. I have been testing it when it is not either of those types. Secondly, I neglected to mention (i.e., forgot) that it works just fine when using a mod_python setup. In any case, the behavior of wsgi.input is inconsistent between web frontends, and this, at least, deserves to be looked at.

[Matthew Good]

Replying to trac@lazymalevolence.com:

Secondly, I neglected to mention (i.e., forgot) that it works just fine when using a mod_python setup. In any case, the behavior of wsgi.input is inconsistent between web frontends, and this, at least, deserves to be looked at.

Ah, yes I think that was necessary at least for the XML-RPC plugin to read the request body. Have you tried using req.read()? This will read from wsgi.input, but checks the "Content-Length" header for how many bytes to read.

[trac@…]

This is what happens when I change the last line in my testcase from req.write(req.environ['wsgi.input'].read()) to req.write(req.read()) and attempt to access /null/testcase in the same fashion (still r3640):

2006-08-25 14:19:56,800 Trac[main] ERROR: get_header() takes exactly 2 arguments (3 given)
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 335, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 220, in dispatch
    resp = chosen_handler.process_request(req)
  File "build/bdist.linux-i686/egg/wsgi_input_testcase/__init__.py", line 12, in process_request
    # ;-)
  File "/usr/lib/python2.4/site-packages/trac/web/api.py", line 411, in read
    size = int(self.get_header('Content-Length', -1))
TypeError: get_header() takes exactly 2 arguments (3 given)

I assume that when Request.read() was written, Request.get_header() had a method signature similar to dict().get().

[Matthew Good]

I'll look into this.

[trac@…]

fixes the call to get_header() in Request.read()

[Matthew Good]

Ok, thanks for the patch.

[Matthew Good]

Ok, a small variant on that patch has been committed in r3746 along with unit tests.