DeprecationWarning: HTTPResponse.getheaders() is deprecated and will be removed in urllib3 v2.1.0. Instead access HTTPResponse.headers directly

[ericbn]

Hi 👋

Using hubspot-api-client 8.0.0 and urllib3 1.26.16, I get these warnings:

hubspot/crm/contacts/rest.py:41: DeprecationWarning: HTTPResponse.getheaders() is deprecated and will be removed in urllib3 v2.1.0. Instead access HTTPResponse.headers directly.
  return self.urllib3_response.getheaders()
hubspot/crm/contacts/rest.py:45: DeprecationWarning: HTTPResponse.getheader() is deprecated and will be removed in urllib3 v2.1.0. Instead use HTTPResponse.headers.get(name, default).
  return self.urllib3_response.getheader(name, default)

These warnings also come from:

hubspot/communication_preferences/rest.py:41
hubspot/communication_preferences/rest.py:45
hubspot/crm/associations/rest.py:45
hubspot/crm/deals/rest.py:45
hubspot/crm/objects/rest.py:45
hubspot/discovery/discovery_base.py:1

and so on...

See other deprecations with urllib3 2.0.0 here. And urllib3 2.1.0 is planned to be released in the summer of 2023.

Resolving these deprecation warnings will prepare hubspot-api-client to be ready for future versions of urllib3. A plan for package maintainers is described here.

I'll be happy to contribute with a PR. Regarding the maintenance of the project, I see most files have Generated by: https://openapi-generator.tech, but I don't see instructions on how to regenerate those files. To fix the issue mentioned here, should we regenerate the files with an updated OpenAPI Generator?

[ericbn]

Hi. FYI urllib3 version 2.1.0 was just released 4 days ago.

[alzheltkovskiy-hubspot]

Hey @ericbn. Could you check the latest version?

[ericbn]

Hi @alzheltkovskiy-hubspot. I still see getheaders being called at

hubspot-api-python/hubspot/crm/contacts/rest.py

Line 41 in 6572070

return self.urllib3_response.getheaders()

and at

hubspot-api-python/hubspot/crm/contacts/rest.py

Line 45 in 6572070

return self.urllib3_response.getheader(name, default)

, just to point out two examples.

This won’t be fixed until all HTTPResponse.getheaders calls are replaced by accessing HTTPResponse.headers directly, as mentioned in the issue description above.

[ericbn]

@alzheltkovskiy-hubspot to fix this issue, there was no need to require the requests package. The other way around, the code had to be updated as detailed in the ticket description. If you're going to add requests as a dependency (to fix another issue, not sure which one), I strongly suggest at least requests>=2.29.0.

EDIT: I didn't mean to propose that support for urllib3 v1.26.x to be dropped and for you to only start requiring v2.x going forward. There's a way to support both urllib3 v1.26.x and v2.x which is mentioned in the ticket description. The link was this one here.

Also, the migration of the code to support urllib3 v2.x, which is also mentioned in the link above was not done, so likely the current code is be broken when used with urllib3 v2.1.0 for example. The whole idea is to update the code, and keep supporting at least urllib3>=1.26,<3.

[alzheltkovskiy-hubspot]

@ericbn. Since the SDK is generated automatically, we cannot make manual changes. The old syntax is used due to the version of the generator we are currently utilizing. Once we transition to a more recent version of the generator, this issue will be resolved. However, until then, the old syntax will continue to be used. We are actively working on the transition, but it is not a quick process.

[winniehell]

@alzheltkovskiy-hubspot is there a publicly visible resource for the current progress of the transition?

[winniehell]

this has become an implicit security issue because urllib3 < 2.5.0 is vulnerable to CVE-2025-50181

[Schnouki]

And urllib3 < 2.6.0 is vulnerable to CVE-2025-66418 and CVE-2025-66471, which are both high-severity security issues.

urllib3 2.6.1 restores these methods for libraries like this one that still didn't update, but that's not ideal. (urllib3/urllib3#3731)