Open Collective
Open Collective
v2.0 Roadmap is Live!
Published on September 21, 2020 by Seth Michael Larson

Read the complete v2.0 Roadmap!

🚀 Functional API Compatibility

We’re maintaining 99% functional API compatibility to make the migration an easy choice for most users. Migration from v1.x to v2.x should be the simplest major version upgrade you’ve ever completed.

Most changes are either to default configurations, supported Python versions, and internal implementation details. So unless you’re in a specific situation you should notice no changes! 🎉

v1.26.x Security and Bug Fixes

Thanks to support from Tidelift we’re able to continue supporting v1.26.x releases with both security and bug fixes for the forseable future 💖

If your organization relies on urllib3 and is interested in continuing support you can learn more about the Tidelift Subscription for Enterprise.

🔐 Modern Security by Default

HTTPS requires TLS 1.2+

Greater than 95% of websites support TLS 1.2 or above. At this point we’re comfortable switching the default minimum TLS version to be 1.2 to ensure high security for users without breaking services.

Dropping TLS 1.0 and 1.1 by default means you won’t be vulnerable to TLS downgrade attacks if a vulnerability in TLS 1.0 or 1.1 were discovered in the future. Extra security for free! By dropping TLS 1.0 and TLS 1.1 we also tighten the list of ciphers we need to support to ensure high security for data traveling over the wire.

If you still need to use TLS 1.0 or 1.1 in your application you can still upgrade to v2.0, you’ll only need to set ssl_version to the proper values to continue using legacy TLS versions.

Stop Verifying CommonName in Certificates

Dropping support the long deprecated commonName field on certificates in favor of only verifying subjectAltName to put us in line with browsers and other HTTP client libraries and to improve security for our users.

Certificate Verification via SSLContext

By default certificate verification is handled by urllib3 to support legacy Python versions, but now we can rely on Python’s certificate verification instead! This should result in a speedup for verifying certificates and means that any improvements made to certificate verification in Python or OpenSSL will be immediately available.

✨ Optimized for Python 3.6+

In v2.0 we’ll be specifically be targeting CPython 3.6+ and PyPy 7.0+ (compatible with CPython 3.6) and dropping support Python versions 2.7 and 3.5.

By dropping end-of-life Python versions we’re able to optimize the codebase for Python 3.6+ by using new features to improve performance and reduce the amount of code that needs to be executed in order to support legacy versions.

🔮 Tracing

Currently with urllib3 it’s tough to get low-level insights into what how your HTTP client is performing and what your connection information looks like. In v2.0 we’ll be adding tracing and telemetry information to HTTP response objects including:

  • Connection ID
  • IP Address resolved by DNS
  • Request Method, Target, and Headers
  • TLS Version and Cipher
  • Certificate Fingerprint, subjectAltName, and Validity Information
  • Timings for DNS, Request Data, First Byte in Response

📜 Type-Hinted APIs

You’ll finally be able to run Mypy or other type-checkers on code using urllib3. This also means that for IDEs that support type hints you’ll receive better suggestions from auto-complete. No more confusing with **kwargs!

We’ll also add API interfaces to ensure that when you’re sub-classing an interface you’re only using supported public APIs to ensure compatibility and minimize breakages down the road.

🎁 …and many more features!

  • Top-level urllib3.request() API
  • Open Possibility to Alternate HTTP Implementations
  • Translated Guides
  • Support Zstandard Compression
  • Streaming multipart/form-encoded Request Data
  • More Powerful and Configurable Retry Logic