Repository navigation
deprecate content_type argument #675
Description
Should we consider deprecating the content_type argument?
It appears redundant in conjunction with the headers argument. Common tools like cURL and libraries such as requests do not provide a specific way to set the data type; it is typically managed through headers. Therefore, I propose that we consider deprecating the content_type argument to streamline the function signature and simplify the codebase. Instead, we could encourage users to utilize the headers parameter for specifying the content type. This would enhance clarity and maintain consistency with prevailing practices.
@markstory
thoughts?
Reacted by Pável Kalmykov Razgovórov and Henry Walshaw
Activity
ThiefMaster commentedon Oct 12, 2023
Please don't. It's nice 'syntactic sugar' for what's probably most common header. It also makes moving from httpretty much more straightforward.
ptalbert commentedon Jul 11, 2024
At least for the responses recorder having the separate content-type causes some difficulty.
The recorder does not set the 'content-type' parameter when it saves a real http payload as a Response. This means Response.init sets the 'content-type' attribute value to 'text/plain' in every case. The recorder actually strips out the content-type http header (among others) and when the Response is written to the out.yaml file the Response.content-type is all you get and that is of course always 'text/plain'.
So when you load the output file into the responses registry the mocked Response does not necessarily have the same content-type header value as the original and some libraries process responses differently depending on the content-type header value. As an example: https://github.com/python-gitlab/python-gitlab/blob/main/gitlab/client.py#L832
I've mad a stab at sorting this out for the recorder in #728 but it definitely made me wonder why it was done this way in the first place. It seems like at least the Response init should set its 'content-type' attribute from the input headers if it is there and only fallback to setting it to 'text/plain' when no value is given. But there is surely some historical context I am missing.