[Bugfix] Fix incorrectly overwriting Content-Type header when passing JSON body

[DeathHound6]

Checks for when to set the Content-Type header currently are using the wrong casing to check if the value has already been set before This is causing the header to be overwritten from what it may have already been set as

[nateprewitt]

Hi @DeathHound6,

It looks like you may not have tested this before creating a PR? In the future, please read our contribution guide and open an issue describing your problem.

Requests uses a custom CaseInsensitiveDict that handles this for headers. As noted in the docs, individual prepare_* methods must not be invoked from end user code. prepare will ensure headers are evaluated case-insensitive.

If you have more info with an actual repro, please open an issue with exact instructions. Thanks!

import requests

r = requests.Request(
   'POST',
   'https://httpbin.org/post',
   headers={'cOnTeNt-TyPe': "application/foo"},
   json={"a": "b"}
)

p = r.prepare()
print(p.headers["content-type"])
>>> "application/foo"

[DeathHound6]

Hi @nateprewitt

Apologies, I did not realise that a case-insensitive dict was being used here

I hadn't really dug too much into the source code of the library, but I do believe there is a bug present in this general area.

We were experiencing issues in work during the week regarding passing a JSON body in a patch request, where our API was returning a request validation error. Unfortunately our logs were not providing any more information than this. All of our patch endpoints require a certain value in our content-type header, which is not the normal application/json value.

I believed the library overwriting the header was the issue here as passing our json data through the json kwarg was raising this error, but passing through data kwarg wasn't.

I may take a more thorough look into the library's source code soon to try to resolve this.

Once again, apologies for my lack of testing. Thanks

[sigmavirus24]

Please read the documentation of that endpoint closely. We do not allow you to override the content type when passing to the json kwarg. That's why using data worked because that's what you must use in that case. It's not a bug by any stretch.