Reconsidering auto-redirects?

[tomchristie]

Prompted way back by this thread... https://twitter.com/EWDurbin/status/1315581317627744257

It hadn't ever really significantly occurred to me before that auto-redirects might not be such a wonderful default, but actually there's some pretty good reasons we might want to diverge from requests here.

Auto-redirect by default can easily mean your codebase is needlessly having to send multiple requests over and over. This means your client code will be far slower than it needs to be, and the server side is working much harder than it needs.

We could perfectly well choose to diverge from requests here, and opt out from auto-redirects, except if they're explicitly enabled. Either per-request, or at the client level...

# We're expecting a redirect here, and we'd like to follow it automatically...
response = httpx.get(..., allow_redirects=True)

# Yup we'd like auto-redirects on by default, thanks...
client = httpx.Client(allow_redirects=True)
response = httpx.get(...)

I actually think it'd be a decent feature to be able to promote "doesn't implicitly hide the fact that it might make multiple requests, unless you actually ask it too".

One other consideration here from my point of view is that I'd very much like to add a command line client as part of HTTPX at some point. Being able to seamlessly switch between HTTPX on the consol, and HTTPX in your codebase would be a fantastic feature for us. Other HTTP command line clients (curl, httpie) don't follow redirects by default, and I don't particularly think it'd make sense for an httpx command line client to do so either. We really want the behaviour between the console and client library cases to match up neatly.

[bbkane]

I'm not an expert in this, but you've convinced me :)

[simonw]

I always forget that both requests and httpx have auto-redirecting as a default feature, and every time I do encounter it it's because I'm confused and want to opt-out of it (usually because I'm writing unit test).

[simonw]

I personally prefer follow_redirects=True or follow=True over allow_redirects=True because I usually use the word "allow" in the context of permissions, but requests uses allow_redirects so probably better to stick with that.

[tomchristie]

I much prefer follow_redirects. If we were making a switch in the default behaviour I think we could also diverge on the naming.

[abersheeran]

Yes, following redirects by default will also make debugging difficult. I always set allow_redirects=False in requests.

[abersheeran]

Maybe requests just want to work like a browser, but it's not suitable for programmers. Explicit is greater than implicit.

[ngnpope]

Came here from Twitter where the conversation mentioned that following redirects in production makes sense, but during development you might want to know about it.

What about adding something like a warn_on_redirect option that raises a warning but still allows the redirect to go ahead?

(Could also be styled something like on_redirect taking "follow", "follow+warn", or "stop"... Or something better than that.)

[xkortex]

+1 to follow_redirects naming and follow_redirects=False by default. If that behavior is good enough for curl, it's good enough for me.