Version 0.28.0

[lovelydinosaur]

Hey team. 👋🏼

Alrighty we've got ourselves a release here. I think this strikes the right balance between pushing forwards towards an improved and simplified 1.0 release while minimising disruption in getting there.

---

0.28.0 (15th November, 2024)

The 0.28 release includes a limited set of backwards incompatible changes.

Backwards incompatible changes:

SSL configuration has been significantly simplified.

• The verify argument no longer accepts string arguments.
• The cert argument has now been removed.
• The SSL_CERT_FILE and SSL_CERT_DIR environment variables are no longer automatically used.

For users of the standard verify=True or verify=False cases this should require no changes.

For information on configuring more complex SSL cases, please see the SSL documentation.

The following changes are also included:

• The undocumented URL.raw property has now been deprecated, and will raise warnings.
• The deprecated proxies argument has now been removed.
• The deprecated app argument has now been removed.
• Ensure JSON request bodies are compact. (Ensure JSON representation is compact. #3363)
• Review URL percent escape sets, based on WHATWG spec. (Review URL percent escaping sets, from whatwg. #3371, Review urlescape percent-safe set, and use + behavior for form spaces. #3373)
• Ensure certifi and httpcore are only imported if required. (made dependencies on certifi and httpcore only load when required #3377)
• Treat socks5h as a valid proxy scheme. (add socks5h proxy support #3178)
• Cleanup Request() method signature in line with client.request() and httpx.request(). (Cleanup Request method parameter. #3378)

[agrueneberg]

@tomchristie How would I supply a custom root certificate if a dependency is using httpx but does not allow a custom context to be passed? So far we have used SSL_CERT_FILE in those situations.

[lovelydinosaur]

@agrueneberg Thanks. You would need the dependency to support passing an ssl context through, if you wanted to use a custom context...

Can you describe your setup just a little more?

[lovelydinosaur]

@agrueneberg Thanks. You would need the dependency to support passing an ssl context through, if you wanted to use a custom context...

Good pointer towards why we might want to switch to truststore over certifi.

Perhaps you could take a look at #3409 and see if that'd resolve things for you.

[agrueneberg]

Sorry for the late response. Our dependency (qdrant-client) does in fact pass additional arguments to httpx, so the problem is not as bad as I thought. I still liked the configuration-free approach that SSL_CERT_FILE offered, being able to run in different environments without a change in code (e.g., dev / prod environment).

Truststore appears to be a step in the right direction.

[agrueneberg]

That said, I've never seen a code snippet where an explicit SSLContext is passed as an argument to verify. SSL_CERT_FILE is not universal (despite being mentioned in PEP 476) because requests only supports REQUESTS_CA_BUNDLE instead, but passing a string pointing to the CA bundle as an argument to verify is such a common solution to SSL problems that I'm not sure if breaking that behavior is worth it.

[lovelydinosaur]

passing a string pointing to the CA bundle as an argument to verify is such a common solution to SSL problems that I'm not sure if breaking that behavior is worth it.

@agrueneberg That's a concession I'd be happy for us to take for a 0.28.0 release. Are you interested in issuing a PR resolving that?

[agrueneberg]

Godspeed, thanks for hearing me out :)

[lovelydinosaur]

Okay, as much as I'd like to push forward with this quickly we really need a deprecation path rather than hard breakages here.

So... #3419