`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`
`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`
`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`
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"
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
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.
- 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)
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),
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
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
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
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,
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
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:
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
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".
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.
"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;
/*
* 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.
* </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:
*
"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;
"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;
"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;
"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;
"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;
/* 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");
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,
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
}
.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"
}
.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"
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
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.
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
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
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.
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
.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.
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
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.
.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.
.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).
.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
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
.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.
+
.\" **************************************************************************
.\" * _ _ ____ _
.\" * Project ___| | | | _ \| |
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
projects / thirdparty / curl.git / commitdiff
