CURLcode curl_easy_setopt(CURL *handle, CURLOPT_URL, char *URL);
For a greater explanation of the format please see RFC3986.
libcurl doesn't validate the syntax or use this variable until the transfer is issued. Even if you set a crazy value here, curl_easy_setopt(3) will still return CURLE_OK.
If the given URL is missing a scheme name (such as "http://" or "ftp://" etc) then libcurl will make a guess based on the host. If the outermost sub-domain name matches DICT, FTP, IMAP, LDAP, POP3 or SMTP then that protocol will be used, otherwise HTTP will be used. Since 7.45.0 guessing can be disabled by setting a default protocol, see CURLOPT_DEFAULT_PROTOCOL(3) for details.
Should the protocol, either that specified by the scheme or deduced by libcurl from the host name, not be supported by libcurl then CURLE_UNSUPPORTED_PROTOCOL will be returned from either the curl_easy_perform(3) or curl_multi_perform(3) functions when you call them. Use curl_version_info(3) for detailed information of which protocols are supported by the build of libcurl you are using.
CURLOPT_PROTOCOLS(3) can be used to limit what protocols libcurl will use for this transfer, independent of what libcurl has been compiled to support. That may be useful if you accept the URL from an external source and want to limit the accessibility.
The CURLOPT_URL(3) string will be ignored if CURLOPT_CURLU(3) is set.
CURLOPT_URL(3) or CURLOPT_CURLU(3) must be set before a transfer is started.
The application does not have to keep the string around after setting this option.
If libcurl is built with IDN support, the server name part of the URL can use an "international name" by using the current encoding (according to locale) or UTF-8 (when winidn is used).
If libcurl is built without IDN support, the server name is used exactly as specified when passed to the name resolver functions.
Getting a URL from an external untrusted party will bring reasons for several security concerns:
If you have an application that runs as or in a server application, getting an unfiltered URL can easily trick your application to access a local resource instead of a remote. Protecting yourself against localhost accesses is very hard when accepting user provided URLs.
Such custom URLs can also access other ports than you planned as port numbers are part of the regular URL format. The combination of a local host and a custom port number can allow external users to play tricks with your local services.
Accepting external URLs may also use other protocols than http:// or other common ones. Restrict what accept with CURLOPT_PROTOCOLS(3).
User provided URLs can also be made to point to sites that redirect further on (possibly to other protocols too). Consider your CURLOPT_FOLLOWLOCATION(3) and CURLOPT_REDIR_PROTOCOLS(3) settings.
CURL *curl = curl_easy_init();
if(curl) {
curl_easy_setopt(curl, CURLOPT_URL, "https://example.com");
curl_easy_perform(curl);
}
Note that curl_easy_setopt(3) won't actually parse the given string so given a bad URL, it will not be detected until curl_easy_perform(3) or similar is called.