mirror/curl
2
0
Fork 0
mirror of https://github.com/curl/curl.git synced 2025-03-25 15:50:32 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: use a space after RFC when spelling out RFC numbers

Browse Source 
Closes
This commit is contained in:
Daniel Stenberg 2023-06-25 10:50:17 +02:00
parent 9bf89bdc5b
commit 22c92a6d51
No known key found for this signature in database
GPG Key ID: 5CC908FDB71E12C2
35 changed files with 73 additions and 70 deletions

6
docs/CIPHERS.md

@ -51,7 +51,7 @@ When specifying multiple cipher names, separate them with colon (`:`).
`ADH-RC4-MD5`
`ADH-DES-CBC3-SHA`
### AES cipher suites from RFC3268, extending TLS v1.0
### AES cipher suites from RFC 3268, extending TLS v1.0
`AES128-SHA`
`AES256-SHA`
@ -66,7 +66,7 @@ When specifying multiple cipher names, separate them with colon (`:`).
`ADH-AES128-SHA`
`ADH-AES256-SHA`
### SEED cipher suites from RFC4162, extending TLS v1.0
### SEED cipher suites from RFC 4162, extending TLS v1.0
`SEED-SHA`
`DH-DSS-SEED-SHA`
@ -148,7 +148,7 @@ When specifying multiple cipher names, separate them with colon (`:`).
`ECDHE-ECDSA-AES128-CCM8`
`ECDHE-ECDSA-AES256-CCM8`
### Camellia HMAC-Based cipher suites from RFC6367, extending TLS v1.2
### Camellia HMAC-Based cipher suites from RFC 6367, extending TLS v1.2
`ECDHE-ECDSA-CAMELLIA128-SHA256`
`ECDHE-ECDSA-CAMELLIA256-SHA384`

6
docs/FAQ

@ -817,7 +817,7 @@ FAQ
4.5 Why do I get return code XXX from an HTTP server?
RFC2616 clearly explains the return codes. This is a short transcript. Go
RFC 2616 clearly explains the return codes. This is a short transcript. Go
read the RFC for exact details:
4.5.1 "400 Bad Request"
@ -985,7 +985,7 @@ FAQ
To use explicit FTPS, you use an FTP:// URL and the --ftp-ssl option (or one
of its related flavors). This is the most common method, and the one
mandated by RFC4217. This kind of connection will then of course use the
mandated by RFC 4217. This kind of connection will then of course use the
standard FTP port 21 by default.
4.16 My HTTP POST or PUT requests are slow
@ -1332,7 +1332,7 @@ FAQ
directory listing. How does it know what's a file and what's a directory and
what's a symlink etc. If the FTP server supports the MLSD command then it
will return data in a machine-readable format that can be parsed for type.
The types are specified by RFC3659 section 7.5.1. If MLSD is not supported
The types are specified by RFC 3659 section 7.5.1. If MLSD is not supported
then you have to work with what you are given. The LIST output format is
entirely at the server's own liking and the NLST output does not reveal any
types and in many cases does not even include all the directory entries.

2
docs/FEATURES.md

@ -43,7 +43,7 @@
- PUT
- HEAD
- POST
- multipart formpost (RFC1867-style)
- multipart formpost (RFC 1867-style)
- authentication: Basic, Digest, NTLM (9) and Negotiate (SPNEGO) (3)
to server and proxy
- resume (both GET and PUT)

4
docs/HTTP-COOKIES.md

@ -17,7 +17,7 @@
For a long time, the only spec explaining how to use cookies was the
original [Netscape spec from 1994](https://curl.se/rfc/cookie_spec.html).
In 2011, [RFC6265](https://www.ietf.org/rfc/rfc6265.txt) was finally
In 2011, [RFC 6265](https://www.ietf.org/rfc/rfc6265.txt) was finally
published and details how cookies work within HTTP. In 2016, an update which
added support for prefixes was
[proposed](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cookie-prefixes-00),
@ -26,7 +26,7 @@
to deprecate modification of 'secure' cookies from non-secure origins. Both
of these drafts have been incorporated into a proposal to
[replace](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-11)
RFC6265. Cookie prefixes and secure cookie modification protection has been
RFC 6265. Cookie prefixes and secure cookie modification protection has been
implemented by curl.
curl considers `http://localhost` to be a *secure context*, meaning that it

8
docs/TODO

@ -188,7 +188,7 @@
20.3 more protocols supported
20.4 more platforms supported
20.5 Add support for concurrent connections
20.6 Use the RFC6265 test suite
20.6 Use the RFC 6265 test suite
20.7 Support LD_PRELOAD on macOS
20.8 Run web-platform-tests URL tests
@ -570,7 +570,7 @@
4.5 ASCII support
FTP ASCII transfers do not follow RFC959. They do not convert the data
FTP ASCII transfers do not follow RFC 959. They do not convert the data
accordingly.
4.6 GSSAPI via Windows SSPI
@ -1239,7 +1239,7 @@
18.27 -J and -O with %-encoded file names
-J/--remote-header-name does not decode %-encoded file names. RFC6266 details
-J/--remote-header-name does not decode %-encoded file names. RFC 6266 details
how it should be done. The can of worm is basically that we have no charset
handling in curl and ascii >=128 is a challenge for us. Not to mention that
decoding also means that we need to check for nastiness that is attempted,
@ -1358,7 +1358,7 @@
should not do in these tests) and thus the wait for connections loop is never
entered to receive the second connection.
20.6 Use the RFC6265 test suite
20.6 Use the RFC 6265 test suite
A test suite made for HTTP cookies (RFC 6265) by Adam Barth is available at
https://github.com/abarth/http-state/tree/master/tests

2
docs/TheArtOfHttpScripting.md

@ -304,7 +304,7 @@
Back in late 1995 they defined an additional way to post data over HTTP. It
is documented in the RFC 1867, why this method sometimes is referred to as
RFC1867-posting.
RFC 1867-posting.
This method is mainly designed to better support file uploads. A form that
allows a user to upload a file could be written like this in HTML:

2
docs/URL-SYNTAX.md

@ -52,7 +52,7 @@ security concerns:
3. Such a URL might use other schemes than you thought of or planned for.
## "RFC3986 plus"
## "RFC 3986 plus"
curl recognizes a URL syntax that we call "RFC 3986 plus". It is grounded on
the well established RFC 3986 to make sure previously written command lines and

2
docs/cmdline-opts/mail-rcpt.d

@ -15,7 +15,7 @@ option several times to send to multiple recipients.
When performing an address verification (VRFY command), the recipient should be
specified as the user name or user name and domain (as per Section 3.5 of
RFC5321). (Added in 7.34.0)
RFC 5321). (Added in 7.34.0)
When performing a mailing list expand (EXPN command), the recipient should be
specified using the mailing list name, such as "Friends" or "London-Office".

5
docs/cmdline-opts/tcp-fastopen.d

@ -8,4 +8,7 @@ Example: --tcp-fastopen $URL
See-also: false-start
Multi: boolean
---
Enable use of TCP Fast Open (RFC7413).
Enable use of TCP Fast Open (RFC 7413). TCP Fast Open is a TCP extension that
allows data to get sent earlier over the connection (before the final
handshake ACK) if the client and server have been connected previously.

4
docs/examples/imap-append.c

@ -49,11 +49,11 @@ static const char *payload_text =
"Message-ID: "
"<dcd7cb36-11db-487a-9f3a-e652a9458efd@rfcpedant.example.org>\r\n"
"Subject: IMAP example message\r\n"
"\r\n" /* empty line to divide headers from body, see RFC5322 */
"\r\n" /* empty line to divide headers from body, see RFC 5322 */
"The body of the message starts here.\r\n"
"\r\n"
"It could be a lot of lines, could be MIME encoded, whatever.\r\n"
"Check RFC5322.\r\n";
"Check RFC 5322.\r\n";
struct upload_status {
size_t bytes_read;

2
docs/examples/postit2-formadd.c

@ -28,7 +28,7 @@
/*
* Example code that uploads a file name 'foo' to a remote script that accepts
* "HTML form based" (as described in RFC1738) uploads using HTTP POST.
* "HTML form based" (as described in RFC 1738) uploads using HTTP POST.
*
* Warning: this example uses the deprecated form api. See "postit2.c"
* for a similar example using the mime api.

2
docs/examples/postit2.c

@ -26,7 +26,7 @@
* </DESC>
*/
/* Example code that uploads a file name 'foo' to a remote script that accepts
* "HTML form based" (as described in RFC1738) uploads using HTTP POST.
* "HTML form based" (as described in RFC 1738) uploads using HTTP POST.
*
* The imaginary form we will fill in looks like:
*

4
docs/examples/smtp-authzid.c

@ -57,11 +57,11 @@ static const char *payload_text =
"Message-ID: <dcd7cb36-11db-487a-9f3a-e652a9458efd@"
"rfcpedant.example.org>\r\n"
"Subject: SMTP example message\r\n"
"\r\n" /* empty line to divide headers from body, see RFC5322 */
"\r\n" /* empty line to divide headers from body, see RFC 5322 */
"The body of the message starts here.\r\n"
"\r\n"
"It could be a lot of lines, could be MIME encoded, whatever.\r\n"
"Check RFC5322.\r\n";
"Check RFC 5322.\r\n";
struct upload_status {
size_t bytes_read;

4
docs/examples/smtp-mail.c

@ -54,11 +54,11 @@ static const char *payload_text =
"Message-ID: <dcd7cb36-11db-487a-9f3a-e652a9458efd@"
"rfcpedant.example.org>\r\n"
"Subject: SMTP example message\r\n"
"\r\n" /* empty line to divide headers from body, see RFC5322 */
"\r\n" /* empty line to divide headers from body, see RFC 5322 */
"The body of the message starts here.\r\n"
"\r\n"
"It could be a lot of lines, could be MIME encoded, whatever.\r\n"
"Check RFC5322.\r\n";
"Check RFC 5322.\r\n";
struct upload_status {
size_t bytes_read;

4
docs/examples/smtp-multi.c

@ -47,11 +47,11 @@ static const char *payload_text =
"Message-ID: <dcd7cb36-11db-487a-9f3a-e652a9458efd@"
"rfcpedant.example.org>\r\n"
"Subject: SMTP example message\r\n"
"\r\n" /* empty line to divide headers from body, see RFC5322 */
"\r\n" /* empty line to divide headers from body, see RFC 5322 */
"The body of the message starts here.\r\n"
"\r\n"
"It could be a lot of lines, could be MIME encoded, whatever.\r\n"
"Check RFC5322.\r\n";
"Check RFC 5322.\r\n";
struct upload_status {
size_t bytes_read;

4
docs/examples/smtp-ssl.c

@ -51,11 +51,11 @@ static const char *payload_text =
"Message-ID: <dcd7cb36-11db-487a-9f3a-e652a9458efd@"
"rfcpedant.example.org>\r\n"
"Subject: SMTP example message\r\n"
"\r\n" /* empty line to divide headers from body, see RFC5322 */
"\r\n" /* empty line to divide headers from body, see RFC 5322 */
"The body of the message starts here.\r\n"
"\r\n"
"It could be a lot of lines, could be MIME encoded, whatever.\r\n"
"Check RFC5322.\r\n";
"Check RFC 5322.\r\n";
struct upload_status {
size_t bytes_read;

6
docs/examples/smtp-tls.c

@ -51,11 +51,11 @@ static const char *payload_text =
"Message-ID: <dcd7cb36-11db-487a-9f3a-e652a9458efd@"
"rfcpedant.example.org>\r\n"
"Subject: SMTP example message\r\n"
"\r\n" /* empty line to divide headers from body, see RFC5322 */
"\r\n" /* empty line to divide headers from body, see RFC 5322 */
"The body of the message starts here.\r\n"
"\r\n"
"It could be a lot of lines, could be MIME encoded, whatever.\r\n"
"Check RFC5322.\r\n";
"Check RFC 5322.\r\n";
struct upload_status {
size_t bytes_read;
@ -101,7 +101,7 @@ int main(void)
/* This is the URL for your mailserver. Note the use of port 587 here,
* instead of the normal SMTP port (25). Port 587 is commonly used for
* secure mail submission (see RFC4403), but you should use whatever
* secure mail submission (see RFC 4403), but you should use whatever
* matches your server configuration. */
curl_easy_setopt(curl, CURLOPT_URL, "smtp://mainserver.example.net:587");

30
docs/libcurl/libcurl-tutorial.3

@ -473,18 +473,18 @@ that list to libcurl.
While the simple examples above cover the majority of all cases where HTTP
POST operations are required, they do not do multi-part formposts. Multi-part
formposts were introduced as a better way to post (possibly large) binary data
and were first documented in the RFC1867 (updated in RFC2388). they are called
multi-part because they are built by a chain of parts, each part being a single
unit of data. Each part has its own name and contents. You can in fact create
and post a multi-part formpost with the regular libcurl POST support described
above, but that would require that you build a formpost yourself and provide
to libcurl. To make that easier, libcurl provides a MIME API consisting in
several functions: using those, you can create and fill a multi-part form.
Function \fIcurl_mime_init(3)\fP creates a multi-part body; you can then
append new parts to a multi-part body using \fIcurl_mime_addpart(3)\fP.
There are three possible data sources for a part: memory using
\fIcurl_mime_data(3)\fP, file using \fIcurl_mime_filedata(3)\fP and
user-defined data read callback using \fIcurl_mime_data_cb(3)\fP.
and were first documented in the RFC 1867 (updated in RFC 2388). they are
called multi-part because they are built by a chain of parts, each part being
a single unit of data. Each part has its own name and contents. You can in
fact create and post a multi-part formpost with the regular libcurl POST
support described above, but that would require that you build a formpost
yourself and provide to libcurl. To make that easier, libcurl provides a MIME
API consisting in several functions: using those, you can create and fill a
multi-part form. Function \fIcurl_mime_init(3)\fP creates a multi-part body;
you can then append new parts to a multi-part body using
\fIcurl_mime_addpart(3)\fP. There are three possible data sources for a part:
memory using \fIcurl_mime_data(3)\fP, file using \fIcurl_mime_filedata(3)\fP
and user-defined data read callback using \fIcurl_mime_data_cb(3)\fP.
\fIcurl_mime_name(3)\fP sets a part's (i.e.: form field) name, while
\fIcurl_mime_filename(3)\fP fills in the remote file name. With
\fIcurl_mime_type(3)\fP, you can tell the MIME type of a part,
@ -1057,9 +1057,9 @@ Not all protocols are HTTP-like, and thus the above may not help you when
you want to make, for example, your FTP transfers to behave differently.
Sending custom commands to an FTP server means that you need to send the
commands exactly as the FTP server expects them (RFC959 is a good guide here),
and you can only use commands that work on the control-connection alone. All
kinds of commands that require data interchange and thus need a
commands exactly as the FTP server expects them (RFC 959 is a good guide
here), and you can only use commands that work on the control-connection
alone. All kinds of commands that require data interchange and thus need a
data-connection must be left to libcurl's own judgment. Also be aware that
libcurl will do its best to change directory to the target directory before
doing any transfer, so if you change directory (with CWD or similar) you might

4
docs/libcurl/opts/CURLINFO_HTTPAUTH_AVAIL.3

@ -66,8 +66,8 @@ if(curl) {
}
.fi
.SH AVAILABILITY
Added RFC2617 in 7.10.8
Added RFC7616 in 7.57.0
Added RFC 2617 in 7.10.8
Added RFC 7616 in 7.57.0
.SH RETURN VALUE
Returns CURLE_OK if the option is supported, and CURLE_UNKNOWN_OPTION if not.
.SH "SEE ALSO"

4
docs/libcurl/opts/CURLINFO_PROXYAUTH_AVAIL.3

@ -68,8 +68,8 @@ if(curl) {
}
.fi
.SH AVAILABILITY
Added RFC2617 in 7.10.8
Added RFC7616 in 7.57.0
Added RFC 2617 in 7.10.8
Added RFC 7616 in 7.57.0
.SH RETURN VALUE
Returns CURLE_OK if the option is supported, and CURLE_UNKNOWN_OPTION if not.
.SH "SEE ALSO"

2
docs/libcurl/opts/CURLOPT_FTP_FILEMETHOD.3

@ -41,7 +41,7 @@ what the standards say should work.
The argument should be one of the following alternatives:
.IP CURLFTPMETHOD_MULTICWD
libcurl does a single CWD operation for each path part in the given URL. For
deep hierarchies this means many commands. This is how RFC1738 says it should
deep hierarchies this means many commands. This is how RFC 1738 says it should
be done. This is the default but the slowest behavior.
.IP CURLFTPMETHOD_NOCWD
libcurl does no CWD at all. libcurl will do SIZE, RETR, STOR etc and give a

4
docs/libcurl/opts/CURLOPT_HTTPAUTH.3

@ -49,12 +49,12 @@ that is in wide-spread use and supported virtually everywhere. This sends
the user name and password over the network in plain text, easily captured by
others.
.IP CURLAUTH_DIGEST
HTTP Digest authentication. Digest authentication is defined in RFC2617 and
HTTP Digest authentication. Digest authentication is defined in RFC 2617 and
is a more secure way to do authentication over public networks than the
regular old-fashioned Basic method.
.IP CURLAUTH_DIGEST_IE
HTTP Digest authentication with an IE flavor. Digest authentication is
defined in RFC2617 and is a more secure way to do authentication over public
defined in RFC 2617 and is a more secure way to do authentication over public
networks than the regular old-fashioned Basic method. The IE flavor is simply
that libcurl will use a special "quirk" that IE is known to have used before
version 7 and that some servers require the client to use.

5
docs/libcurl/opts/CURLOPT_INTERLEAVEFUNCTION.3

@ -44,9 +44,8 @@ contains exactly one upper-layer protocol unit (e.g. one RTP packet). Curl
writes the interleaved header as well as the included data for each call. The
first byte is always an ASCII dollar sign. The dollar sign is followed by a
one byte channel identifier and then a 2 byte integer length in network byte
order. See \fIRFC2326 Section 10.12\fP for more information on how RTP
interleaving behaves. If unset or set to NULL, curl will use the default write
function.
order. See RFC 2326 Section 10.12 for more information on how RTP interleaving
behaves. If unset or set to NULL, curl will use the default write function.
Interleaved RTP poses some challenges for the client application. Since the
stream data is sharing the RTSP control connection, it is critical to service

2
docs/libcurl/opts/CURLOPT_LOGIN_OPTIONS.3

@ -35,7 +35,7 @@ CURLcode curl_easy_setopt(CURL *handle, CURLOPT_LOGIN_OPTIONS, char *options);
Pass a char * as parameter, which should be pointing to the null-terminated
\fIoptions\fP string to use for the transfer.
For more information about the login options please see RFC2384, RFC5092 and
For more information about the login options please see RFC 2384, RFC 5092 and
the IETF draft \fBdraft-earhart-url-smtp-00.txt\fP.
\fICURLOPT_LOGIN_OPTIONS(3)\fP can be used to set protocol specific login

2
docs/libcurl/opts/CURLOPT_MAIL_AUTH.3

@ -46,7 +46,7 @@ be used for this parameter.
Unlike \fICURLOPT_MAIL_FROM(3)\fP and \fICURLOPT_MAIL_RCPT(3)\fP, the address
should not be specified within a pair of angled brackets (<>). However, if an
empty string is used then a pair of brackets will be sent by libcurl as
required by RFC2554.
required by RFC 2554.
The application does not have to keep the string around after setting this
option.

2
docs/libcurl/opts/CURLOPT_MAIL_RCPT.3

@ -45,7 +45,7 @@ and enclose that address within brackets for you.
When performing an address verification (\fBVRFY\fP command), each recipient
should be specified as the user name or user name and domain (as per Section
3.5 of RFC5321).
3.5 of RFC 5321).
When performing a mailing list expand (\fBEXPN\fP command), each recipient
should be specified using the mailing list name, such as "Friends" or

2
docs/libcurl/opts/CURLOPT_PROXY_TLSAUTH_TYPE.3

@ -39,7 +39,7 @@ method is "SRP".
.IP SRP
TLS-SRP authentication. Secure Remote Password authentication for TLS is
defined in RFC5054 and provides mutual authentication if both sides have a
defined in RFC 5054 and provides mutual authentication if both sides have a
shared secret. To use TLS-SRP, you must also set the
\fICURLOPT_PROXY_TLSAUTH_USERNAME(3)\fP and
\fICURLOPT_PROXY_TLSAUTH_PASSWORD(3)\fP options.

2
docs/libcurl/opts/CURLOPT_QUOTE.3

@ -46,7 +46,7 @@ When speaking to an FTP server, prefix the command with an asterisk (*) to
make libcurl continue even if the command fails as by default libcurl will
stop at first failure.
The set of valid FTP commands depends on the server (see RFC959 for a list of
The set of valid FTP commands depends on the server (see RFC 959 for a list of
mandatory commands).
libcurl does not inspect, parse or "understand" the commands passed to the

2
docs/libcurl/opts/CURLOPT_RANGE.3

@ -43,7 +43,7 @@ techniques). Unfortunately, the HTTP standard (RFC 7233 section 3.1) allows
servers to ignore range requests so even when you set \fICURLOPT_RANGE(3)\fP
for a request, you may end up getting the full response sent back.
For RTSP, the formatting of a range should follow RFC2326 Section 12.29. For
For RTSP, the formatting of a range should follow RFC 2326 Section 12.29. For
RTSP, byte ranges are \fBnot\fP permitted. Instead, ranges should be given in
\fBnpt\fP, \fButc\fP, or \fBsmpte\fP formats.

2
docs/libcurl/opts/CURLOPT_SOCKS5_GSSAPI_NEC.3

@ -33,7 +33,7 @@ CURLcode curl_easy_setopt(CURL *handle, CURLOPT_SOCKS5_GSSAPI_NEC, long nec);
.fi
.SH DESCRIPTION
Pass a long set to 1 to enable or 0 to disable. As part of the GSSAPI
negotiation a protection mode is negotiated. The RFC1961 says in section
negotiation a protection mode is negotiated. The RFC 1961 says in section
4.3/4.4 it should be protected, but the NEC reference implementation does not.
If enabled, this option allows the unprotected exchange of the protection mode
negotiation.

2
docs/libcurl/opts/CURLOPT_TCP_FASTOPEN.3

@ -34,7 +34,7 @@ CURLcode curl_easy_setopt(CURL *handle, CURLOPT_TCP_FASTOPEN, long enable);
.SH DESCRIPTION
Pass a long as parameter set to 1L to enable or 0 to disable.
TCP Fast Open (RFC7413) is a mechanism that allows data to be carried in the
TCP Fast Open (RFC 7413) is a mechanism that allows data to be carried in the
SYN and SYN-ACK packets and consumed by the receiving end during the initial
connection handshake, saving up to one full round-trip time (RTT).

2
docs/libcurl/opts/CURLOPT_TFTP_BLKSIZE.3

@ -33,7 +33,7 @@ CURLcode curl_easy_setopt(CURL *handle, CURLOPT_TFTP_BLKSIZE, long blocksize);
.fi
.SH DESCRIPTION
Specify \fIblocksize\fP to use for TFTP data transmission. Valid range as per
RFC2348 is 8-65464 bytes. The default of 512 bytes will be used if this option
RFC 2348 is 8-65464 bytes. The default of 512 bytes will be used if this option
is not specified. The specified block size will only be used pending support
by the remote server. If the server does not return an option acknowledgment
or returns an option acknowledgment with no block size, the default of 512

4
docs/libcurl/opts/CURLOPT_TFTP_NO_OPTIONS.3

@ -32,8 +32,8 @@ CURLOPT_TFTP_NO_OPTIONS \- send no TFTP options requests
CURLcode curl_easy_setopt(CURL *handle, CURLOPT_TFTP_NO_OPTIONS, long onoff);
.fi
.SH DESCRIPTION
Set \fIonoff\fP to 1L to exclude all TFTP options defined in RFC2347, RFC2348
and RFC2349 from read and write requests.
Set \fIonoff\fP to 1L to exclude all TFTP options defined in RFC 2347,
RFC 2348 and RFC 2349 from read and write requests.
This option improves interoperability with legacy servers that do not
acknowledge or properly implement TFTP options. When this option is used

2
docs/libcurl/opts/CURLOPT_TLSAUTH_TYPE.3

@ -37,7 +37,7 @@ the method of the TLS authentication. Supported method is "SRP".
.IP SRP
TLS-SRP authentication. Secure Remote Password authentication for TLS is
defined in RFC5054 and provides mutual authentication if both sides have a
defined in RFC 5054 and provides mutual authentication if both sides have a
shared secret. To use TLS-SRP, you must also set the
\fICURLOPT_TLSAUTH_USERNAME(3)\fP and \fICURLOPT_TLSAUTH_PASSWORD(3)\fP
options.

3
docs/libcurl/opts/CURLOPT_URL.3

@ -1,3 +1,4 @@
.\" **************************************************************************
.\" * _ _ ____ _
.\" * Project ___| | | | _ \| |
@ -38,7 +39,7 @@ format:
scheme://host:port/path
For a greater explanation of the format please see RFC3986.
For a greater explanation of the format please see RFC 3986.
libcurl does not validate the syntax or use this variable until the transfer is
issued. Even if you set a crazy value here, \fIcurl_easy_setopt(3)\fP will