Always get a CaseInsensitiveDict for headers.

[kootenpv]

If we look at how headers are merged from session and request, only if both are set the result will be a CaseInsensitiveDict. I propose to always use a case insensitive dict, even when one of the two is missing.

Expected Result

Always get a CaseInsensitiveDict for headers.

Actual Result

If only session.headers or request.headers are set, then headers are not case insensitive.

See also:

https://github.com/kennethreitz/requests/blob/master/requests/sessions.py#L55

I am not sure whether we should only do it isinstance(dict_class, CaseInsensitiveDict), or whether it would make sense to always convert to the dict_class.

[vinitwadgaonkar]

can i take up this issue @kootenpv

[kootenpv]

Sure

[sigmavirus24]

Actually don't. We deliberately allow any mapping type to allow for a variety of use-cases. A change here won't be accepted

[nateprewitt]

For posterity as I see this was linked in Typeshed, the premise here is wrong.

If we look at how headers are merged from session and request, only if both are set the result will be a CaseInsensitiveDict. I propose to always use a case insensitive dict, even when one of the two is missing.

If only session.headers or request.headers are set, then headers are not case insensitive.

The reporter was confusing the generalized behavior of merge_settings which handle many forms of input, and the case of headers. Session.headers will always be a CaseInsensitiveDict when initialized and that's what it's documented as being. Setting it to None has never been a documented or intended use case, that's undefined behavior at that point.

Whether request_settings is None is moot at that point, it will either return the Session's CaseInsensitiveDict, or create a new one [1] [2]. This was also true with the code in 2019. Requests accepts a MutableMapping through the requests.request APIs but it will always be resolved to CaseInsensitiveDict before being sent.