requests with multiparts using data and files doesn't have content-type in data part

When issuing a requests.post request("POST"...) with data and files, the content-type for the data doesn't get set.

Environment
Windows 11
Python 3.10.7

Trying to debug why a Postman request was working but Python wasn't, I captured the request data (using requestcatcher.com) and below are the two parts of the requests that should be the same:

Postman:
----------------------------166390214727573301705303
Content-Disposition: form-data; name="documents_input"
Content-Type: application/json

{"requests":[{"request_id":"f631ffc.....
----------------------------166390214727573301705303
Content-Disposition: form-data; name="files"; filename="removed.pdf"
Content-Type: application/pdf

Python:
--285101b8d40c60d675e8f54e937ceb3e
Content-Disposition: form-data; name="documents_input"

{"requests":[{"request_id":"f631ffc....
--285101b8d40c60d675e8f54e937ceb3e
Content-Disposition: form-data; name="files"; filename="removed.pdf"
Content-Type: application/pdf

As you can see, the content type displays correctly in Postman but via Python requests it does on the PDF but not the data=jsonDate


The, hacky, work-a-round for this was to shove the json data alongside the files= component:
multipart_data = {
"documents_input": (None, documentInputPayload, "application/json"),
"files": files["files"]
}

response = requests.post(url, headers = headers, files = multipart_data)

This work-a-round works as expected and gives same output as Postman.

Apologies if this bug has already been raised or if it's not deemed a bug, although documentation on how to work-a-round this is sparse and it was trial and error.

Thanks

This isn't a bug and what you found works is what is already documented.

You're asking for a documentation change but haven't explained what you searched for that leads you to believe there is no documentation or that is reproducible for us to determine if this is functionality (documented for something close to a decade that many have used without complaint about the discoverability) that is hard to find in the documentation today.

If we don't know what you searched for, we can't possibly improve the documentation so that someone else searching for the same thing could discover this more quickly. 

This is causing issues for me with the Django server. Without specifying the content-type for the data part, it treats the data as a file instead of JSON. It would be beneficial to have the ability to specify that.

> This is causing issues for me with the Django server. Without specifying the content-type for the data part, it treats the data as a file instead of JSON. It would be beneficial to have the ability to specify that.

This is in no way requests fault. Before we start setting headers randomly, depending on what data you provided, you can just set those headers yourself.

From my point of view, requests is doing **exactly** as its supposed to. Any change in this behavior would also break countless libraries and applications.

To be very clear,

1. I should hvae closed this last month when I replied
2. Using `data` with an opaque string (or bytes) does not tell us what the type should be, so expecting us to read your mind is unreasonable
3. If you have specific field names you wish to use, and content-types with opaque data, you must use `files={...}` with the tuple syntax documented to do exactly that.
4. `json=` and `files=` do not work together and that is documented, and potentially if I remember correctly (I'm on my phone) an exception