Nate Prewitt

urllib3 1.26.x is continuing to receive security updates for the near future. Pinning at the Requests level will block you from receiving security patches. The underlying issue is at the...

@mase-git There isn't anything to be solved in Requests or urllib3. Requests 2.31.0 works with both major versions of urllib3. If you're using dependencies that don't support the breaking changes...

Resolving along with #6432 and locking it to avoid losing context with further comments. Please read https://github.com/psf/requests/issues/6432#issuecomment-1676067621 if you still have questions after reading this thread. Of particular note here:...

Hi @mdmintz, this is intentional as discussed [here](https://github.com/psf/requests/pull/6430#issuecomment-1522542220). We'll move the pin once we get more data points on any issues in the major version bump. We have a responsibility...

Many, if not most, projects pull urllib3 into their closure through another dependency. Pinning transitive dependencies, while good practice through something like a lockfile, is not widely observed. We have...

Landon, that's ultimately a decision for users of Requests to decide. We're doing a very temporary overlap of this pin during launch to prevent legitimate bugs being pushed to millions...

As was originally stated, Requests 2.30.0 has been released within a week of the urllib3 launch. Users who wish to stay on urllib3 1.x should ensure they're pinned to `urllib

For anyone upgrading, we have yanked Requests 2.30.0 as urllib3 appears to be silently dropping data on compressed response bodies. We'll be tracking investigation in urllib3/urllib3#3009.

Take 2 🎬 We've unyanked 2.30.0 now that the regression in urllib3 has been resolved. I'll leave this open for tracking today in the event of other late arising issues.

@andrew-pickin-epi this is usually something we'd appreciate being raised sooner than later. Can you please open a separate issue with the failure and preferably links to the builds?