httpserver.requests[-1].json raises ClientDisconnected

[a-gerhard]

I am using the following code in my test:

httpserver.serve_content('SUCCESS')
function_that_does_a_post_request()
received_request = httpserver.requests[-1]
assert received_request.json == {'mock': 'data'}

during the last instruction, I get the following exception:

../venv/lib/python3.9/site-packages/werkzeug/wrappers/request.py:561: in json
    return self.get_json()
../venv/lib/python3.9/site-packages/werkzeug/wrappers/request.py:611: in get_json
    data = self.get_data(cache=cache)
../venv/lib/python3.9/site-packages/werkzeug/wrappers/request.py:423: in get_data
    rv = self.stream.read()
../venv/lib/python3.9/site-packages/werkzeug/wsgi.py:829: in readall
    data = self.read(1024 * 64)
../venv/lib/python3.9/site-packages/werkzeug/wsgi.py:796: in readinto
    self.on_disconnect(error=e)

../venv/lib/python3.9/site-packages/werkzeug/wsgi.py:751: ClientDisconnected

werkzeug.exceptions.ClientDisconnected: 400 Bad Request: The browser (or proxy) sent a request that this server could not understand.

Now for the weird part: I set the PyCharm debugger to have a break point at the instruction that stores the request in httpserver. Inside the debugger, I was able to read the json as expected. Continuing from there into my test, the exception did not occur and it was possible to read the json as normal.

My suspicion is that the request's payload isn't read from the network interface unless needed (I don't really know the libraries that well here). This makes sense as most requests don't need to be stored like httpserver does. So when we try to read the payload after the connection object is long gone, this leads to that error.

A quick fix would be to manually call request.json inside the previously linked function.

[diazona]

Thanks for the detailed report and the suggestion!

I think calling request.json() wouldn't necessarily work in general because not every request body is going to be valid JSON, right? But I assume there should be some equivalent that reads the raw data, and that should probably do the trick. (I don't know the Request API offhand 😅) I'll figure out the details when I get a chance - maybe over the weekend - or if you happen to find a good fix before I do, I'm always happy to accept a PR.

[a-gerhard]

After a quick look I figured out two things:

• The request.data property is the more generic one you may want to use here
• Internally, it uses the get_data() method on the object, which does have caching functionality implemented, so it seems to confirm my suspicion

I'll create a pull request.