request_history[...].text unusable when requests made with streaming body

[edwardpeek-crown-public]

According to https://requests-mock.readthedocs.io/en/latest/history.html entries in the request history have an attribute:

text: The data of the request converted into a unicode string.

When requests are made with a file-like object or iterable as the body this is not the case.

Example:

from io import BytesIO

import requests
import requests_mock

with requests_mock.mock() as m:
    m.get("http://test.com", text="resp")
    resp = requests.get("http://test.com", data=BytesIO(b"foo"))

    print(f"{m.last_request.text=}")  # m.last_request.text=<_io.BytesIO object at 0x7f4908ac8ea0>
    assert m.last_request.text == "foo"  # AssertionError

Preferably the stream should be read and buffered at the time the request is made, but this could be complex with:

• Chunked encoding
• Very large request bodies

Otherwise docs should note that .text is not supported for streaming requests.

[jamielennox]

Hmm, yea. I can see that's happening and it's not something i would have tested. In practice stream seems to be handled pretty seperately from a "normal" request in requests so i did the same. You can see in the code that this history is a _RequestObjectProxy and it's really just a way to make it easier to get data from a requests.Request.

You can use the stream function to get the stream object, but depending on what you do there it may or may not be useful.

My guiding principal on all these things is to do what requests does. So do you think this is just a missing field on the documentation or something where requests-mock should pull the stream through and cache the body? There's a potential issue of people putting large files through here that would end up in memory, but I'd have no way to know how common that is.

[edwardpeek-crown-public]

You can use the stream function to get the stream object, but depending on what you do there it may or may not be useful.

That's not so useful as clients eagerly closing resources or single-pass stream objects are unreadable by the time the mock object is inspectable.

There's a potential issue of people putting large files through here that would end up in memory, but I'd have no way to know how common that is.

My intuition would be that data going through unit tests would tend to be on the smaller side, but yeah that's speculation.

An option would be to have something like a buffer_streaming_data keyword arg to register_uri as an escape hatch (whether defaulted true or false), but it may not be worth the dev effort it given this seems to be an uncommon use case.