cachecontrol is incompatible with Requests 2.30.0

[pgjones]

See psf/requests#6437

[notenti]

What would make more sense here? Pinning requests so it's <2.30? Or updating the logic so strict isn't referenced?

[elijahr]

The comment on that issue suggests this is from urllib3 >= 2 being used: psf/requests#6437 (comment)

this appears to be an incompatibility in cachecontrol with the new release of urllib3 2.0. strict is no longer a supported argument on the HTTPResponse class. For the time being you'll likely need to pin to an older version of urllib3 or work with the cachecontrol team to update their usage.

Perhaps the fix would be to check urllib3's major version and expect a different HTTPResponse shape based on whether it is 1 or greater than 1.

[notenti]

Based on this diff it looks like strict isn't supported at all in python 3. Could we just do a plain ole getattr call to default to 0 if it's not present? Looks like that's what was happening upstream of this library anyways

[sww314]

I believe the issue is actually urllib > 2.
Here is the issue in the urllib3 repo. As a work around pinning urllib version works.

The suggested gettattr solution seems like a clean fix in cachcontrol.

urllib3/urllib3#3010

You can fix it by pinning:
urllib3==1.26.15 # https://pypi.org/project/urllib3/

[sethmlarson]

Maintainer of urllib3 here! I'd recommend the getattr approach regardless of what gets done in urllib3 in the short-term, long-term the property won't be available on HTTPResponse or HTTPConnection (and defaults to True in terms of behavior).

[jonbeacherdomuso]

This issue came up today for us; the workaround was to use requests 2.29.0

[Shahard2]

This issue came up today for us; the workaround was to use requests 2.29.0

It didn't help...
Any other solution?

[sww314]

We fixed by pinning urllib3:

urllib3==1.26.15 # https://pypi.org/project/urllib3/

The problem is not requests.

[rdbisme]

The lightest workaround is to set urllib3<2.

[Shahard2]

We fixed by pinning urllib3:

urllib3==1.26.15 # https://pypi.org/project/urllib3/

The problem is not requests.

didn't work..

[Shahard2]

The lightest workaround is to set urllib3<2.

Tried this one too... same error

[rdbisme]

The lightest workaround is to set urllib3<2.

Tried this one too... same error

I'm pretty sure this fixes the problem. I've deployed it on hundreds of projects using poetry that stopped working because of this.

Can you elaborate what's not working? More details will help understand. :)

[sww314]

@Shahard2 you have something else wrong then. Old urllib3 works fine.

[ionrock]

@sethmlarson Hey! Is it safe to just drop the strict completely?

[sww314]

Seems like Python std library dropped support way back in Python 3.4:

Changed in version 3.4: The strict parameter was removed. HTTP 0.9-style “Simple Responses” are no longer supported.

https://docs.python.org/3/library/http.client.html#http.client.HTTPSConnection:~:text=HAS_SNI%20is%20true).-,Changed%20in%20version%203.4%3A%20The%20strict%20parameter%20was%20removed.%20HTTP%200.9%2Dstyle%20%E2%80%9CSimple%20Responses%E2%80%9D%20are%20no%20longer%20supported.,-Changed%20in%20version

[sethmlarson]

@ionrock It's safe to drop for urllib3 2.0 or Python 3+. In Python 2 on urllib3 1.26.x there is still functionally a difference between strict=True/False.

Appreciate you jumping in to help here! Apologies for the suddenness of this issue surfacing, no one reported it during our prerelease period, unfortunately.

[dwhatley19]

The lightest workaround is to set urllib3<2.

Tried this one too... same error

I'm pretty sure this fixes the problem. I've deployed it on hundreds of projects using poetry that stopped working because of this.

Can you elaborate what's not working? More details will help understand. :)

@rdbisme Pinning the version isn't working for me either. Using poetry and GitHub Actions and here is the output I get when building:

Step 16/20 : RUN poetry config virtualenvs.create false && poetry install --no-root $POETRY_ARGS
 ---> Running in df80379cd35d
Skipping virtualenv creation, as specified in config file.
Installing dependencies from lock file

Package operations: 76 installs, 6 updates, 6 removals

  • Removing distlib (0.3.6)
  • Removing filelock (3.9.0)
  • Removing pexpect (4.8.0)
  • Removing platformdirs (3.1.0)
  • Removing ptyprocess (0.7.0)
  • Removing virtualenv (20.20.0)
  • Installing pyasn1 (0.4.8)

  AttributeError

  'HTTPResponse' object has no attribute 'strict'

  at /usr/local/lib/python3.10/site-packages/cachecontrol/serialize.py:54 in dumps
       50│                 ),
       51│                 u"status": response.status,
       52│                 u"version": response.version,
       53│                 u"reason": text_type(response.reason),
    →  54│                 u"strict": response.strict,
       55│                 u"decode_content": response.decode_content,
       56│             ***
       57│         ***
       58│ 

Could it be that GitHub Actions uses its own version of cachecontrol which ignores anything set in pyproject.toml?

[xytxytxyt]

depending on your poetry version, it might be the case that poetry itself depends on the affected versions of requests/urllib3, separately from your project

in my case, poetry installs itself into a venv, so i found the venv, activated it, downgraded requests and urllib3 via pip, deactivated, and poetry worked fine thereafter

[woodruffw]

Given GHSA-j8r2-6x86-q33q, a fix here is increasingly important: packages that can't upgrade because of CahceControl's incompatibility will remain vulnerable.

[sethmlarson]

@woodruffw Requests is still compatible with urllib3 1.26.x so people using cachecontrol can continue using urllib3 1.26.x until cachecontrol adds support for urllib3 2.x.

[frostming]

Hi, I have to move on to create a fork at https://github.com/frostming/cacheyou, with this issue addressed.

The long term plan is if this project can continue I will merge the changes back.

[jacobg]

It doesn't seem that a fork will help in the case where this library is used as a transitive dependency where all installed packages must be in a requirements.txt file (e.g., typical serverless/paas configuration).

[frostming]

It doesn't seem that a fork will help in the case where this library is used as a transitive dependency where all installed packages must be in a requirements.txt file (e.g., typical serverless/paas configuration).

agree, but it can mitigate the problem.

[garchaaman19]

We fixed by pinning urllib3:

urllib3==1.26.15 # https://pypi.org/project/urllib3/

The problem is not requests.

This worked for me.