.\" generated by cd2nroff 0.1 from CURLOPT_FOLLOWLOCATION.md
.TH CURLOPT_FOLLOWLOCATION 3 "2024-11-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 enable);
.fi
.SH DESCRIPTION
A long parameter set to 1 tells the library to follow any Location: header
redirects that an HTTP server sends in a 30x response. The Location: header
can specify a relative or an absolute URL to follow.

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.

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.
.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.
.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
Returns CURLE_OK if HTTP is supported, and CURLE_UNKNOWN_OPTION if not.
.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)