diff --git a/docs/CIPHERS.md b/docs/CIPHERS.md index e5e5def196..6029378e1c 100644 --- a/docs/CIPHERS.md +++ b/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` diff --git a/docs/FAQ b/docs/FAQ index 5bd899b8a4..78fa9d6dbc 100644 --- a/docs/FAQ +++ b/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. diff --git a/docs/FEATURES.md b/docs/FEATURES.md index 52608c08e3..6f8fa4f972 100644 --- a/docs/FEATURES.md +++ b/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) diff --git a/docs/HTTP-COOKIES.md b/docs/HTTP-COOKIES.md index 2108fb4490..d6fd87d205 100644 --- a/docs/HTTP-COOKIES.md +++ b/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 diff --git a/docs/TODO b/docs/TODO index 999a19bb36..5651a82b90 100644 --- a/docs/TODO +++ b/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 diff --git a/docs/TheArtOfHttpScripting.md b/docs/TheArtOfHttpScripting.md index ffa8fe0892..2973a36cd2 100644 --- a/docs/TheArtOfHttpScripting.md +++ b/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: diff --git a/docs/URL-SYNTAX.md b/docs/URL-SYNTAX.md index 802bbdef96..384aa4a269 100644 --- a/docs/URL-SYNTAX.md +++ b/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 diff --git a/docs/cmdline-opts/mail-rcpt.d b/docs/cmdline-opts/mail-rcpt.d index 3127e6bd8c..ea43397cb4 100644 --- a/docs/cmdline-opts/mail-rcpt.d +++ b/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". diff --git a/docs/cmdline-opts/tcp-fastopen.d b/docs/cmdline-opts/tcp-fastopen.d index 68d9aee4e1..bcf1edbff5 100644 --- a/docs/cmdline-opts/tcp-fastopen.d +++ b/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. diff --git a/docs/examples/imap-append.c b/docs/examples/imap-append.c index e87e1acaa0..33566bb643 100644 --- a/docs/examples/imap-append.c +++ b/docs/examples/imap-append.c @@ -49,11 +49,11 @@ static const char *payload_text = "Message-ID: " "\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; diff --git a/docs/examples/postit2-formadd.c b/docs/examples/postit2-formadd.c index 292c0c93d6..27761fcda3 100644 --- a/docs/examples/postit2-formadd.c +++ b/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. diff --git a/docs/examples/postit2.c b/docs/examples/postit2.c index 3add296d40..a1fb12b0fc 100644 --- a/docs/examples/postit2.c +++ b/docs/examples/postit2.c @@ -26,7 +26,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. * * The imaginary form we will fill in looks like: * diff --git a/docs/examples/smtp-authzid.c b/docs/examples/smtp-authzid.c index d86e1bada8..3425d9a214 100644 --- a/docs/examples/smtp-authzid.c +++ b/docs/examples/smtp-authzid.c @@ -57,11 +57,11 @@ static const char *payload_text = "Message-ID: \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; diff --git a/docs/examples/smtp-mail.c b/docs/examples/smtp-mail.c index 77e6cc4e9d..6d53770a9e 100644 --- a/docs/examples/smtp-mail.c +++ b/docs/examples/smtp-mail.c @@ -54,11 +54,11 @@ static const char *payload_text = "Message-ID: \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; diff --git a/docs/examples/smtp-multi.c b/docs/examples/smtp-multi.c index d80077f8cd..e5bc4011c1 100644 --- a/docs/examples/smtp-multi.c +++ b/docs/examples/smtp-multi.c @@ -47,11 +47,11 @@ static const char *payload_text = "Message-ID: \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; diff --git a/docs/examples/smtp-ssl.c b/docs/examples/smtp-ssl.c index f09f7f4954..1c099a4354 100644 --- a/docs/examples/smtp-ssl.c +++ b/docs/examples/smtp-ssl.c @@ -51,11 +51,11 @@ static const char *payload_text = "Message-ID: \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; diff --git a/docs/examples/smtp-tls.c b/docs/examples/smtp-tls.c index e6fec1906e..a3564912a9 100644 --- a/docs/examples/smtp-tls.c +++ b/docs/examples/smtp-tls.c @@ -51,11 +51,11 @@ static const char *payload_text = "Message-ID: \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"); diff --git a/docs/libcurl/libcurl-tutorial.3 b/docs/libcurl/libcurl-tutorial.3 index 6c79566e55..88c64b6d46 100644 --- a/docs/libcurl/libcurl-tutorial.3 +++ b/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 diff --git a/docs/libcurl/opts/CURLINFO_HTTPAUTH_AVAIL.3 b/docs/libcurl/opts/CURLINFO_HTTPAUTH_AVAIL.3 index 86c7cfa95b..6c8f8280c3 100644 --- a/docs/libcurl/opts/CURLINFO_HTTPAUTH_AVAIL.3 +++ b/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" diff --git a/docs/libcurl/opts/CURLINFO_PROXYAUTH_AVAIL.3 b/docs/libcurl/opts/CURLINFO_PROXYAUTH_AVAIL.3 index 5187ad8cb7..a7f9097fb8 100644 --- a/docs/libcurl/opts/CURLINFO_PROXYAUTH_AVAIL.3 +++ b/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" diff --git a/docs/libcurl/opts/CURLOPT_FTP_FILEMETHOD.3 b/docs/libcurl/opts/CURLOPT_FTP_FILEMETHOD.3 index d37488d2e1..99caebf51e 100644 --- a/docs/libcurl/opts/CURLOPT_FTP_FILEMETHOD.3 +++ b/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 diff --git a/docs/libcurl/opts/CURLOPT_HTTPAUTH.3 b/docs/libcurl/opts/CURLOPT_HTTPAUTH.3 index b29660a24d..e7e1fea10d 100644 --- a/docs/libcurl/opts/CURLOPT_HTTPAUTH.3 +++ b/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. diff --git a/docs/libcurl/opts/CURLOPT_INTERLEAVEFUNCTION.3 b/docs/libcurl/opts/CURLOPT_INTERLEAVEFUNCTION.3 index 949e7505cb..fbdf3dbe18 100644 --- a/docs/libcurl/opts/CURLOPT_INTERLEAVEFUNCTION.3 +++ b/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 diff --git a/docs/libcurl/opts/CURLOPT_LOGIN_OPTIONS.3 b/docs/libcurl/opts/CURLOPT_LOGIN_OPTIONS.3 index aaf164fef2..0fb32a47e2 100644 --- a/docs/libcurl/opts/CURLOPT_LOGIN_OPTIONS.3 +++ b/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 diff --git a/docs/libcurl/opts/CURLOPT_MAIL_AUTH.3 b/docs/libcurl/opts/CURLOPT_MAIL_AUTH.3 index f7237ccfad..d914fc4ce4 100644 --- a/docs/libcurl/opts/CURLOPT_MAIL_AUTH.3 +++ b/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. diff --git a/docs/libcurl/opts/CURLOPT_MAIL_RCPT.3 b/docs/libcurl/opts/CURLOPT_MAIL_RCPT.3 index d6686d5634..0f63c04aa6 100644 --- a/docs/libcurl/opts/CURLOPT_MAIL_RCPT.3 +++ b/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 diff --git a/docs/libcurl/opts/CURLOPT_PROXY_TLSAUTH_TYPE.3 b/docs/libcurl/opts/CURLOPT_PROXY_TLSAUTH_TYPE.3 index fcbc4fd5d5..f01bf459a7 100644 --- a/docs/libcurl/opts/CURLOPT_PROXY_TLSAUTH_TYPE.3 +++ b/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. diff --git a/docs/libcurl/opts/CURLOPT_QUOTE.3 b/docs/libcurl/opts/CURLOPT_QUOTE.3 index 4b36747583..f15396be63 100644 --- a/docs/libcurl/opts/CURLOPT_QUOTE.3 +++ b/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 diff --git a/docs/libcurl/opts/CURLOPT_RANGE.3 b/docs/libcurl/opts/CURLOPT_RANGE.3 index 1400be77f1..fb1f5a9d3d 100644 --- a/docs/libcurl/opts/CURLOPT_RANGE.3 +++ b/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. diff --git a/docs/libcurl/opts/CURLOPT_SOCKS5_GSSAPI_NEC.3 b/docs/libcurl/opts/CURLOPT_SOCKS5_GSSAPI_NEC.3 index ae5d608190..0f6b58430c 100644 --- a/docs/libcurl/opts/CURLOPT_SOCKS5_GSSAPI_NEC.3 +++ b/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. diff --git a/docs/libcurl/opts/CURLOPT_TCP_FASTOPEN.3 b/docs/libcurl/opts/CURLOPT_TCP_FASTOPEN.3 index 1dda94ecbb..06da3bf4c0 100644 --- a/docs/libcurl/opts/CURLOPT_TCP_FASTOPEN.3 +++ b/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). diff --git a/docs/libcurl/opts/CURLOPT_TFTP_BLKSIZE.3 b/docs/libcurl/opts/CURLOPT_TFTP_BLKSIZE.3 index ec8d2d9510..fd79db9dec 100644 --- a/docs/libcurl/opts/CURLOPT_TFTP_BLKSIZE.3 +++ b/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 diff --git a/docs/libcurl/opts/CURLOPT_TFTP_NO_OPTIONS.3 b/docs/libcurl/opts/CURLOPT_TFTP_NO_OPTIONS.3 index b130ea50fd..fc3b3b3f81 100644 --- a/docs/libcurl/opts/CURLOPT_TFTP_NO_OPTIONS.3 +++ b/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 diff --git a/docs/libcurl/opts/CURLOPT_TLSAUTH_TYPE.3 b/docs/libcurl/opts/CURLOPT_TLSAUTH_TYPE.3 index eef31544f8..6f87657bc1 100644 --- a/docs/libcurl/opts/CURLOPT_TLSAUTH_TYPE.3 +++ b/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. diff --git a/docs/libcurl/opts/CURLOPT_URL.3 b/docs/libcurl/opts/CURLOPT_URL.3 index 28971a8bf0..30837862c3 100644 --- a/docs/libcurl/opts/CURLOPT_URL.3 +++ b/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