Not following redirects should be added to the readme.

[Sxderp]

New release decided to change the behavior and disable redirects by default. This is clearly, and bold-faced, mentioned on the website documentation but is not mentioned in the GitHub readme.

This difference should probably be mentioned in where it says "requests compatible API" at the very least. Another good spot would be in the code to the first example.

[florimondmanca]

Hi @Sxderp, I'm curious about this.

Why do you think this item in particular should be mentioned in the README, when there are other compatibility differences we don't mention?

Is the README example too brittle, i.e. it could lead folks to encounter a 3xx if not using the specific https://www.example.org/ URL? (Not that I can see: all of https://example.org, http://www.example.org, etc lead to a 200.)

[Sxderp]

Probably personal bias. I was hit by this and it seemed unexpected. Nothing broke as I found out via the changelogs (I was doing an update cycle). This has been the only incompatibility that I've actually been afflicted by in my own projects (aside from the name of Session vs Client, but I don't really consider that an "incompatibility").

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tomchristie]

I kinda agree that it'll be worthwhile highlighting main points of divergence from requests. Let's keep this one open to track this.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[emann]

I absolutely agree as I just ran into this - we use API clients autogenerated by openapi-python-client which uses httpx under the hood (wouldn't be a bad inclusion for the third party packages list) and suddenly a tool broke out of nowhere after running a poetry update

This change in particular is a really sneaky one. IMO, all divergence from requests should be noted in the README. That could end up being pretty verbose though, so at the very least non-external facing changes that affect the result of a request should be - you'll quickly discover that Session is called Client in httpx, but you could use the library for months before discovering this particular difference. Really it comes down to documenting the "gotchas" that you'll run in to if you're expecting this to be a fairly simple drop-in replacement for requests. A new user would have no way of knowing that there's a critical difference like this without checking the changelog/source code directly.

[emann]

Actually, its even more nefarious - an app could break without you even updating it.

Say I have an app that uses httpx >=0.20, and it makes requests to some third party API. Works fine, is used in factories, medical, whatever critical use case you can think of. If said third party decides to work on a V2 of their API and some of the V1 requests get forwarded to the V2 service, all of a sudden my app breaks overnight.

I'd even argue this example makes a fairly compelling argument for reverting the change in default behavior - unless you read through the changelog before using httpx for the first time, a third party changing their API could brick your app out of nowhere unless you are aware of the possibility and have the foresight to use a Client and set follow_redirects=true. Pointing out this gotcha in the README is the least we can do.

[tomchristie]

Closing as out of date.