129 lines
5.5 KiB
Groff
129 lines
5.5 KiB
Groff
.\" generated by cd2nroff 0.1 from CURLOPT_FOLLOWLOCATION.md
|
|
.TH CURLOPT_FOLLOWLOCATION 3 "2025-07-07" libcurl
|
|
.SH NAME
|
|
CURLOPT_FOLLOWLOCATION \- follow HTTP 3xx redirects
|
|
.SH SYNOPSIS
|
|
.nf
|
|
#include <curl/curl.h>
|
|
|
|
CURLcode curl_easy_setopt(CURL *handle, CURLOPT_FOLLOWLOCATION, long mode);
|
|
.fi
|
|
.SH DESCRIPTION
|
|
This option tells the library to follow \fILocation:\fP header redirects that an
|
|
HTTP server sends in a 30x response. The \fILocation:\fP header can specify a
|
|
relative or an absolute URL to follow. The long parameter \fImode\fP instructs how
|
|
libcurl should act on subsequent requests.
|
|
|
|
\fImode\fP only had a single value (1L) for a long time that enables redirect
|
|
following. Since 8.13.0, two additional modes are also supported. See below.
|
|
|
|
When following redirects, libcurl issues another request for the new URL and
|
|
follows subsequent new \fILocation:\fP redirects all the way until no more such
|
|
headers are returned or the maximum limit is reached. \fICURLOPT_MAXREDIRS(3)\fP is
|
|
used to limit the number of redirects libcurl follows.
|
|
|
|
libcurl restricts what protocols it automatically follow redirects to. The
|
|
accepted target protocols are set with \fICURLOPT_REDIR_PROTOCOLS_STR(3)\fP. By
|
|
default libcurl allows HTTP, HTTPS, FTP and FTPS on redirects.
|
|
|
|
When following a redirect, the specific 30x response code also dictates which
|
|
request method libcurl uses in the subsequent request: For 301, 302 and 303
|
|
responses libcurl switches method from POST to GET unless \fICURLOPT_POSTREDIR(3)\fP
|
|
instructs libcurl otherwise. All other redirect response codes make libcurl
|
|
use the same method again.
|
|
|
|
When libcurl switches method to GET, it then uses that method without sending
|
|
any request body. If it does not change the method, it sends the subsequent
|
|
request the same way as the previous one; including the request body if one
|
|
was provided.
|
|
|
|
For users who think the existing location following is too naive, too simple
|
|
or just lacks features, it is easy to instead implement your own redirect
|
|
follow logic with the use of \fIcurl_easy_getinfo(3)\fP\(aqs \fICURLINFO_REDIRECT_URL(3)\fP
|
|
option instead of using \fICURLOPT_FOLLOWLOCATION(3)\fP.
|
|
|
|
By default, libcurl only sends \fIAuthentication:\fP or explicitly set \fICookie:\fP
|
|
headers to the initial host given in the original URL, to avoid leaking
|
|
username + password to other sites. \fICURLOPT_UNRESTRICTED_AUTH(3)\fP is provided
|
|
to change that behavior.
|
|
|
|
Due to the way HTTP works, almost any header can be made to contain data a
|
|
client may not want to pass on to other servers than the initially intended
|
|
host and for all other headers than the two mentioned above, there is no
|
|
protection from this happening when libcurl is told to follow redirects.
|
|
|
|
Pick one of the following modes:
|
|
.IP "CURLFOLLOW_ALL (1)"
|
|
Before 8.13.0 this bit had no name and 1L was just the value to enable this
|
|
option. This makes a set custom method be used in all HTTP requests, even
|
|
after redirects.
|
|
.IP "CURLFOLLOW_OBEYCODE (2)"
|
|
When there is a custom request method set with \fICURLOPT_CUSTOMREQUEST(3)\fP, that
|
|
set method replaces what libcurl would otherwise use. If a 301/302/303
|
|
response code is returned to signal a redirect, the method is changed from
|
|
POST to \fIGET\fP. For 307/308, the custom method remains set and used.
|
|
|
|
Note that only POST (or a custom post) is changed to GET on 301/302, its not
|
|
change PUT etc \- and therefore also not when libcurl issues a custom PUT. A
|
|
303 response makes it switch to GET independently of the original method
|
|
(except for HEAD).
|
|
|
|
To control for which of the 301/302/303 status codes libcurl should \fInot\fP
|
|
switch back to GET for when doing a custom POST, and instead keep the custom
|
|
method, use \fICURLOPT_POSTREDIR(3)\fP.
|
|
|
|
If you prefer a custom POST method to be reset to exactly the method \fIPOST\fP,
|
|
use CURLFOLLOW_FIRSTONLY instead.
|
|
.IP "CURLFOLLOW_FIRSTONLY (3)"
|
|
When there is a custom request method set with \fICURLOPT_CUSTOMREQUEST(3)\fP, that
|
|
set method replaces what libcurl would otherwise use in the first outgoing
|
|
request only. The second request is then done according to the redirect
|
|
response code.
|
|
|
|
If you prefer your custom method to remain in use after a 307/308 redirect,
|
|
use CURLFOLLOW_OBEYCODE instead.
|
|
.PP
|
|
.SH NOTE
|
|
Since libcurl changes method or not based on the specific HTTP response code,
|
|
setting \fICURLOPT_CUSTOMREQUEST(3)\fP while following redirects may change what
|
|
libcurl would otherwise do and if not that carefully may even make it
|
|
misbehave since \fICURLOPT_CUSTOMREQUEST(3)\fP overrides the method libcurl would
|
|
otherwise select internally.
|
|
|
|
Setting the CURLFOLLOW_OBEYCODE bit makes libcurl \fInot\fP use the custom set
|
|
method after redirects for 301, 302 and 303 responses. Unless the
|
|
\fICURLOPT_POSTREDIR(3)\fP bits are set for those status codes.
|
|
.SH DEFAULT
|
|
0, disabled
|
|
.SH PROTOCOLS
|
|
This functionality affects http only
|
|
.SH EXAMPLE
|
|
.nf
|
|
int main(void)
|
|
{
|
|
CURL *curl = curl_easy_init();
|
|
if(curl) {
|
|
curl_easy_setopt(curl, CURLOPT_URL, "https://example.com");
|
|
|
|
/* example.com is redirected, so we tell libcurl to follow redirection */
|
|
curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
|
|
|
|
curl_easy_perform(curl);
|
|
}
|
|
}
|
|
.fi
|
|
.SH AVAILABILITY
|
|
Added in curl 7.1
|
|
.SH RETURN VALUE
|
|
\fIcurl_easy_setopt(3)\fP returns a CURLcode indicating success or error.
|
|
|
|
CURLE_OK (0) means everything was OK, non\-zero means an error occurred, see
|
|
\fIlibcurl\-errors(3)\fP.
|
|
.SH SEE ALSO
|
|
.BR CURLINFO_REDIRECT_COUNT (3),
|
|
.BR CURLINFO_REDIRECT_URL (3),
|
|
.BR CURLOPT_POSTREDIR (3),
|
|
.BR CURLOPT_PROTOCOLS_STR (3),
|
|
.BR CURLOPT_REDIR_PROTOCOLS_STR (3),
|
|
.BR CURLOPT_UNRESTRICTED_AUTH (3)
|