curl: add --follow

[bagder]

Makes curl follow redirects an act on the response code and change a custom method accordingly, contrary to --location.

Potential future command line to send QUERY and following a redirect according to the status code:

curl -d "request-body" -X QUERY --follow https://example.com 

[divinity76]

all, obey, first => keep, spec, initial?

[bagder]

all, obey, first => keep, spec, initial?

I like that! 👍

[dboehmer]

I’m still thinking about the naming of the parameter and its modes 🫤

This not so much about handling the Location header with the next address but about which request method to use for requests following 30[12378] response codes. But I see that existing curl options are named --location-*.

Currently the man page will read:

--location-mode <mode>

and as mode is no preexisting technical term (like --create-file-mode is for Unix modes for permissions) I think it’s redundant and one could come up with a more descriptive name. I suggest --location-method <mode>.

My two cents on the mode names then:

• spec—really great and unambiguous 👍
• init—I have some trouble with that because keep is drafted to mean “use method from initial request” and they could be easy to be mixed up. Thinking about my comment appending the doc saying that subsequent requests will all be GET could this simply be get?
• keep—I think I also liked all a lot. I’d very much prefer to see a reference to “use method from initial request” but init is currently chosen for “set only for initial request”—this doesn’t match to the parameter name, though, which focuses on the subsequent “location” requests

[icing]

I read --location-mode more as --follow-X with values spec|same|reset.

[bagder]

Naming is hard!

[bagder]

To give us more time to think and discuss about the parameter naming, even on the option itself, we have decided to let this PR wait for the next feature window, presumably for 8.15.0 instead of 8.14.0.

[bagder]

Alternative names for the command line option to consider:

--follow [mode]
--redirect [mode]

We can also ponder making this new option also enable --location so that using this option alone is enough. Makes for shorter/easier command lines.

[dfandrich]

Enabling --location automatically has the disadvantage that this option can't be added to .curlrc as a default without also enabling location processing.

[bagder]

Enabling --location automatically has the disadvantage that this option can't be added to .curlrc as a default without also enabling location processing.

Right, but that can also be an advantage since that will force users to do it "right" and make old curl not work with it. Putting something in your .curlrc in your machine and having others run the same script without the new thing might lead to one invoke doing the right thing and another doing the wrong thing...

[bagder]

Now the option is --redirect [mode] and is a replacement for --location.

[bagder]

Now I'm thinking about removing the "mode" argument and just have --redirect do the "spec" mode...

[icing]

Now I'm thinking about removing the "mode" argument and just have --redirect do the "spec" mode...

Makes sense to me.

(Can't miss the opportunity to bikeshed: --follow would also work for me😌)

[bagder]

Any final words, comments, advice or objections?

[dboehmer]

Your latest commit message f2a641c seems to have two typos:

curl: add --redirEct
                 ^ "e" missing
Makes curl follow redirects an act on the response code and change a custom method accordingly, contrary to --location.
                            ^^ should this mean "and"?

[dboehmer]

Did you consider naming it --redirects (plural)? --redirect sounds like an imperative/command but it’s actually a mode of handling incoming redirect responses (possibly multiple of them).

[bagder]

A good point and a solid argument for @icing's proposal --follow.

One more rename...

[Krinkle]

For those looking, the handling of this new mode landed a few months earlier in libcurl at #16473