Added Cyg-Win
This commit is contained in:
parent
82cbc206eb
commit
413c315806
10586 changed files with 3806249 additions and 0 deletions
278
Agent-Windows/OGP64/usr/share/doc/curl/CIPHERS.md
Normal file
278
Agent-Windows/OGP64/usr/share/doc/curl/CIPHERS.md
Normal file
|
|
@ -0,0 +1,278 @@
|
|||
<!--
|
||||
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
|
||||
SPDX-License-Identifier: curl
|
||||
-->
|
||||
|
||||
## curl cipher options
|
||||
|
||||
A TLS handshake involves many parameters which take part in the negotiation
|
||||
between client and server in order to agree on the TLS version and set of
|
||||
algorithms to use for a connection.
|
||||
|
||||
What has become known as a "cipher" or better "cipher suite" in TLS
|
||||
are names for specific combinations of
|
||||
[key exchange](https://en.wikipedia.org/wiki/Key_exchange),
|
||||
[bulk encryption](https://en.wikipedia.org/wiki/Link_encryption),
|
||||
[message authentication code](https://en.wikipedia.org/wiki/Message_authentication_code)
|
||||
and with TLSv1.3 the
|
||||
[authenticated encryption](https://en.wikipedia.org/wiki/Authenticated_encryption).
|
||||
In addition, there are other parameters that influence the TLS handshake, like
|
||||
[DHE](https://en.wikipedia.org/wiki/Diffie%e2%80%93Hellman_key_exchange) "groups"
|
||||
and [ECDHE](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%e2%80%93Hellman)
|
||||
with its "curves".
|
||||
|
||||
### History
|
||||
|
||||
curl's way of letting users configure these settings closely followed OpenSSL
|
||||
in its API. TLS learned new parameters, OpenSSL added new API functions and
|
||||
curl added command line options.
|
||||
|
||||
Several other TLS backends followed the OpenSSL approach, more or less closely,
|
||||
and curl maps the command line options to these TLS backends. Some TLS
|
||||
backends do not support all of it and command line options are either
|
||||
ignored or lead to an error.
|
||||
|
||||
Many examples below show the OpenSSL-like use of these options. GnuTLS
|
||||
however chose a different approach. These are described in a separate
|
||||
section further below.
|
||||
|
||||
## ciphers, the OpenSSL way
|
||||
|
||||
With curl's option
|
||||
[`--tls13-ciphers`](https://curl.se/docs/manpage.html#--tls13-ciphers)
|
||||
or
|
||||
[`CURLOPT_TLS13_CIPHERS`](https://curl.se/libcurl/c/CURLOPT_TLS13_CIPHERS.html)
|
||||
users can control which cipher suites to consider when negotiating TLS 1.3
|
||||
connections. With option
|
||||
[`--ciphers`](https://curl.se/docs/manpage.html#--ciphers)
|
||||
or
|
||||
[`CURLOPT_SSL_CIPHER_LIST`](https://curl.se/libcurl/c/CURLOPT_SSL_CIPHER_LIST.html)
|
||||
users can control which cipher suites to consider when negotiating
|
||||
TLS 1.2 (1.1, 1.0) connections.
|
||||
|
||||
By default, curl may negotiate TLS 1.3 and TLS 1.2 connections, so the cipher
|
||||
suites considered when negotiating a TLS connection are a union of the TLS 1.3
|
||||
and TLS 1.2 cipher suites. If you want curl to consider only TLS 1.3 cipher
|
||||
suites for the connection, you have to set the minimum TLS version to 1.3 by
|
||||
using [`--tlsv1.3`](https://curl.se/docs/manpage.html#--tlsv13)
|
||||
or [`CURLOPT_SSLVERSION`](https://curl.se/libcurl/c/CURLOPT_SSLVERSION.html)
|
||||
with `CURL_SSLVERSION_TLSv1_3`.
|
||||
|
||||
Both the TLS 1.3 and TLS 1.2 cipher options expect a list of cipher suites
|
||||
separated by colons (`:`). This list is parsed opportunistically, cipher suites
|
||||
that are not recognized or implemented are ignored. As long as there is at
|
||||
least one recognized cipher suite in the list, the list is considered valid.
|
||||
|
||||
For both the TLS 1.3 and TLS 1.2 cipher options, the order in which the
|
||||
cipher suites are specified determine the preference of them. When negotiating
|
||||
a TLS connection the server picks a cipher suite from the intersection of the
|
||||
cipher suites supported by the server and the cipher suites sent by curl. If
|
||||
the server is configured to honor the client's cipher preference, the first
|
||||
common cipher suite in the list sent by curl is chosen.
|
||||
|
||||
### TLS 1.3 cipher suites
|
||||
|
||||
Setting TLS 1.3 cipher suites is supported by curl with
|
||||
OpenSSL (1.1.1+, curl 7.61.0+), LibreSSL (3.4.1+, curl 8.3.0+),
|
||||
wolfSSL (curl 8.10.0+) and mbedTLS (3.6.0+, curl 8.10.0+).
|
||||
|
||||
The list of cipher suites that can be used for the `--tls13-ciphers` option:
|
||||
|
||||
```
|
||||
TLS_AES_128_GCM_SHA256
|
||||
TLS_AES_256_GCM_SHA384
|
||||
TLS_CHACHA20_POLY1305_SHA256
|
||||
TLS_AES_128_CCM_SHA256
|
||||
TLS_AES_128_CCM_8_SHA256
|
||||
```
|
||||
|
||||
#### wolfSSL notes
|
||||
|
||||
In addition to above list the following cipher suites can be used:
|
||||
`TLS_SM4_GCM_SM3` `TLS_SM4_CCM_SM3` `TLS_SHA256_SHA256` `TLS_SHA384_SHA384`.
|
||||
Usage of these cipher suites is not recommended. (The last two cipher suites
|
||||
are NULL ciphers, offering no encryption whatsoever.)
|
||||
|
||||
### TLS 1.2 (1.1, 1.0) cipher suites
|
||||
|
||||
Setting TLS 1.2 cipher suites is supported by curl with OpenSSL, LibreSSL,
|
||||
BoringSSL, mbedTLS (curl 8.8.0+), wolfSSL (curl 7.53.0+). Schannel does not
|
||||
support setting cipher suites directly, but does support setting algorithms
|
||||
(curl 7.61.0+), see Schannel notes below.
|
||||
|
||||
For TLS 1.2 cipher suites there are multiple naming schemes, the two most used
|
||||
are with OpenSSL names (e.g. `ECDHE-RSA-AES128-GCM-SHA256`) and IANA names
|
||||
(e.g. `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`). IANA names of TLS 1.2 cipher
|
||||
suites look similar to TLS 1.3 cipher suite names, to distinguish them note
|
||||
that TLS 1.2 names contain `_WITH_`, while TLS 1.3 names do not. When setting
|
||||
TLS 1.2 cipher suites with curl it is recommended that you use OpenSSL names
|
||||
as these are most widely recognized by the supported SSL backends.
|
||||
|
||||
The complete list of cipher suites that may be considered for the `--ciphers`
|
||||
option is extensive, it consists of more than 300 ciphers suites. Nowadays,
|
||||
most of them are discouraged, and support for a lot of them has been removed
|
||||
from the various SSL backends, if ever implemented at all.
|
||||
|
||||
A shortened list (based on [recommendations by
|
||||
Mozilla](https://wiki.mozilla.org/Security/Server_Side_TLS)) of cipher suites,
|
||||
which are (mostly) supported by all SSL backends, that can be used for the
|
||||
`--ciphers` option:
|
||||
|
||||
```
|
||||
ECDHE-ECDSA-AES128-GCM-SHA256
|
||||
ECDHE-RSA-AES128-GCM-SHA256
|
||||
ECDHE-ECDSA-AES256-GCM-SHA384
|
||||
ECDHE-RSA-AES256-GCM-SHA384
|
||||
ECDHE-ECDSA-CHACHA20-POLY1305
|
||||
ECDHE-RSA-CHACHA20-POLY1305
|
||||
DHE-RSA-AES128-GCM-SHA256
|
||||
DHE-RSA-AES256-GCM-SHA384
|
||||
DHE-RSA-CHACHA20-POLY1305
|
||||
ECDHE-ECDSA-AES128-SHA256
|
||||
ECDHE-RSA-AES128-SHA256
|
||||
ECDHE-ECDSA-AES128-SHA
|
||||
ECDHE-RSA-AES128-SHA
|
||||
ECDHE-ECDSA-AES256-SHA384
|
||||
ECDHE-RSA-AES256-SHA384
|
||||
ECDHE-ECDSA-AES256-SHA
|
||||
ECDHE-RSA-AES256-SHA
|
||||
DHE-RSA-AES128-SHA256
|
||||
DHE-RSA-AES256-SHA256
|
||||
AES128-GCM-SHA256
|
||||
AES256-GCM-SHA384
|
||||
AES128-SHA256
|
||||
AES256-SHA256
|
||||
AES128-SHA
|
||||
AES256-SHA
|
||||
DES-CBC3-SHA
|
||||
```
|
||||
|
||||
See this [list](https://github.com/curl/curl/blob/master/docs/CIPHERS-TLS12.md)
|
||||
for a complete list of TLS 1.2 cipher suites.
|
||||
|
||||
#### OpenSSL notes
|
||||
|
||||
In addition to specifying a list of cipher suites, OpenSSL also accepts a
|
||||
format with specific cipher strings (like `TLSv1.2`, `AESGCM`, `CHACHA20`) and
|
||||
`!`, `-` and `+` operators. Refer to the
|
||||
[OpenSSL cipher documentation](https://docs.openssl.org/master/man1/openssl-ciphers/#cipher-list-format)
|
||||
for further information on that format.
|
||||
|
||||
#### Schannel notes
|
||||
|
||||
Schannel does not support setting individual TLS 1.2 cipher suites directly.
|
||||
It only allows the enabling and disabling of encryption algorithms. These are
|
||||
in the form of `CALG_xxx`, see the [Schannel `ALG_ID`
|
||||
documentation](https://learn.microsoft.com/windows/win32/seccrypto/alg-id)
|
||||
for a list of these algorithms. Also, (since curl 7.77.0)
|
||||
`SCH_USE_STRONG_CRYPTO` can be given to pass that flag to Schannel, lookup the
|
||||
[documentation for the Windows version in
|
||||
use](https://learn.microsoft.com/windows/win32/secauthn/cipher-suites-in-schannel)
|
||||
to see how that affects the cipher suite selection. When not specifying the
|
||||
`--ciphers` and `--tls13-ciphers` options curl passes this flag by default.
|
||||
|
||||
### Examples
|
||||
|
||||
```sh
|
||||
curl \
|
||||
--tls13-ciphers TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 \
|
||||
--ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:\
|
||||
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 \
|
||||
https://example.com/
|
||||
```
|
||||
|
||||
Restrict ciphers to `aes128-gcm` and `chacha20`. Works with OpenSSL, LibreSSL,
|
||||
mbedTLS and wolfSSL.
|
||||
|
||||
```sh
|
||||
curl \
|
||||
--tlsv1.3 \
|
||||
--tls13-ciphers TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 \
|
||||
https://example.com/
|
||||
```
|
||||
|
||||
Restrict to only TLS 1.3 with `aes128-gcm` and `chacha20` ciphers. Works with
|
||||
OpenSSL, LibreSSL, mbedTLS, wolfSSL and Schannel.
|
||||
|
||||
```sh
|
||||
curl \
|
||||
--ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:\
|
||||
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 \
|
||||
https://example.com/
|
||||
```
|
||||
|
||||
Restrict TLS 1.2 ciphers to `aes128-gcm` and `chacha20`, use default TLS 1.3
|
||||
ciphers (if TLS 1.3 is available). Works with OpenSSL, LibreSSL, BoringSSL,
|
||||
mbedTLS and wolfSSL.
|
||||
|
||||
## ciphers, the GnuTLS way
|
||||
|
||||
With GnuTLS, curl allows configuration of all TLS parameters via option
|
||||
[`--ciphers`](https://curl.se/docs/manpage.html#--ciphers)
|
||||
or
|
||||
[`CURLOPT_SSL_CIPHER_LIST`](https://curl.se/libcurl/c/CURLOPT_SSL_CIPHER_LIST.html)
|
||||
only. The option
|
||||
[`--tls13-ciphers`](https://curl.se/docs/manpage.html#--tls13-ciphers)
|
||||
or
|
||||
[`CURLOPT_TLS13_CIPHERS`](https://curl.se/libcurl/c/CURLOPT_TLS13_CIPHERS.html)
|
||||
is being ignored.
|
||||
|
||||
`--ciphers` is used to set the GnuTLS **priority string** in
|
||||
the following way:
|
||||
|
||||
* When the set string starts with '+', '-' or '!' it is *appended* to the
|
||||
priority string libcurl itself generates (separated by ':'). This initial
|
||||
priority depends other settings such as CURLOPT_SSLVERSION(3),
|
||||
CURLOPT_TLSAUTH_USERNAME(3) (for SRP) or if HTTP/3 (QUIC)
|
||||
is being negotiated.
|
||||
* Otherwise, the set string fully *replaces* the libcurl generated one. While
|
||||
giving full control to the application, the set priority needs to
|
||||
provide for everything the transfer may need to negotiate. Example: if
|
||||
the set priority only allows TLSv1.2, all HTTP/3 attempts fail.
|
||||
|
||||
Users may specify via `--ciphers` anything that GnuTLS supports: ciphers,
|
||||
key exchange, MAC, compression, TLS versions, signature algorithms, groups,
|
||||
elliptic curves, certificate types. In addition, GnuTLS has a variety of
|
||||
other keywords that tweak its operations. Applications or a system
|
||||
may define new alias names for priority strings that can then be used here.
|
||||
|
||||
Since the order of items in priority strings is significant, it makes no
|
||||
sense for curl to puzzle other ssl options somehow together. `--ciphers`
|
||||
is the single way to change priority.
|
||||
|
||||
### Examples
|
||||
|
||||
```sh
|
||||
curl \
|
||||
--ciphers '-CIPHER_ALL:+AES-128-GCM:+CHACHA20-POLY1305' \
|
||||
https://example.com/
|
||||
```
|
||||
|
||||
Restrict ciphers to `aes128-gcm` and `chacha20` in GnuTLS.
|
||||
|
||||
```sh
|
||||
curl \
|
||||
--ciphers 'NORMAL:-VERS-ALL:+TLS1.3:-AES-256-GCM' \
|
||||
https://example.com/
|
||||
```
|
||||
|
||||
Restrict to only TLS 1.3 without the `aes256-gcm` cipher.
|
||||
|
||||
```sh
|
||||
curl \
|
||||
--ciphers 'NORMAL:-VERS-ALL:+TLS1.2:-CIPHER_ALL:+CAMELLIA-128-GCM' \
|
||||
https://example.com/
|
||||
```
|
||||
|
||||
Restrict to only TLS 1.2 with the `CAMELLIA-128-GCM` cipher.
|
||||
|
||||
## Further reading
|
||||
|
||||
- [OpenSSL cipher suite names documentation](https://docs.openssl.org/master/man1/openssl-ciphers/#cipher-suite-names)
|
||||
- [wolfSSL cipher support documentation](https://www.wolfssl.com/documentation/manuals/wolfssl/chapter04.html#cipher-support)
|
||||
- [mbedTLS cipher suites reference](https://mbed-tls.readthedocs.io/projects/api/en/development/api/file/ssl__ciphersuites_8h/)
|
||||
- [Schannel cipher suites documentation](https://learn.microsoft.com/windows/win32/secauthn/cipher-suites-in-schannel)
|
||||
- [IANA cipher suites list](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4)
|
||||
- [Wikipedia cipher suite article](https://en.wikipedia.org/wiki/Cipher_suite)
|
||||
- [GnuTLS Priority Strings](https://gnutls.org/manual/html_node/Priority-Strings.html)
|
||||
22
Agent-Windows/OGP64/usr/share/doc/curl/COPYING
Normal file
22
Agent-Windows/OGP64/usr/share/doc/curl/COPYING
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
COPYRIGHT AND PERMISSION NOTICE
|
||||
|
||||
Copyright (c) 1996 - 2026, Daniel Stenberg, <daniel@haxx.se>, and many
|
||||
contributors, see the THANKS file.
|
||||
|
||||
All rights reserved.
|
||||
|
||||
Permission to use, copy, modify, and distribute this software for any purpose
|
||||
with or without fee is hereby granted, provided that the above copyright
|
||||
notice and this permission notice appear in all copies.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN
|
||||
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
|
||||
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
|
||||
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
|
||||
OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
|
||||
Except as contained in this notice, the name of a copyright holder shall not
|
||||
be used in advertising or otherwise to promote the sale, use or other dealings
|
||||
in this Software without prior written authorization of the copyright holder.
|
||||
1427
Agent-Windows/OGP64/usr/share/doc/curl/FAQ.md
Normal file
1427
Agent-Windows/OGP64/usr/share/doc/curl/FAQ.md
Normal file
File diff suppressed because it is too large
Load diff
249
Agent-Windows/OGP64/usr/share/doc/curl/FEATURES.md
Normal file
249
Agent-Windows/OGP64/usr/share/doc/curl/FEATURES.md
Normal file
|
|
@ -0,0 +1,249 @@
|
|||
<!--
|
||||
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
|
||||
SPDX-License-Identifier: curl
|
||||
-->
|
||||
|
||||
# Features -- what curl can do
|
||||
|
||||
## curl tool
|
||||
|
||||
- config file support
|
||||
- multiple URLs in a single command line
|
||||
- range "globbing" support: [0-13], {one,two,three}
|
||||
- multiple file upload on a single command line
|
||||
- redirect stderr
|
||||
- parallel transfers
|
||||
|
||||
## libcurl
|
||||
|
||||
- URL RFC 3986 syntax
|
||||
- custom maximum download time
|
||||
- custom lowest download speed acceptable
|
||||
- custom output result after completion
|
||||
- guesses protocol from hostname unless specified
|
||||
- supports .netrc
|
||||
- progress bar with time statistics while downloading
|
||||
- standard proxy environment variables support
|
||||
- have run on 101 operating systems and 28 CPU architectures
|
||||
- selectable network interface for outgoing traffic
|
||||
- IPv6 support on Unix and Windows
|
||||
- happy eyeballs dual-stack IPv4 + IPv6 connects
|
||||
- persistent connections
|
||||
- SOCKS 4 + 5 support, with or without local name resolving
|
||||
- *pre-proxy* support, for *proxy chaining*
|
||||
- supports username and password in proxy environment variables
|
||||
- operations through HTTP proxy "tunnel" (using CONNECT)
|
||||
- replaceable memory functions (malloc, free, realloc, etc)
|
||||
- asynchronous name resolving
|
||||
- both a push and a pull style interface
|
||||
- international domain names (IDN)
|
||||
- transfer rate limiting
|
||||
- stable API and ABI
|
||||
- TCP keep alive
|
||||
- TCP Fast Open
|
||||
- DNS cache (that can be shared between transfers)
|
||||
- non-blocking single-threaded parallel transfers
|
||||
- Unix domain sockets to server or proxy
|
||||
- DNS-over-HTTPS
|
||||
- uses non-blocking name resolves
|
||||
- selectable name resolver backend
|
||||
|
||||
## URL API
|
||||
|
||||
- parses RFC 3986 URLs
|
||||
- generates URLs from individual components
|
||||
- manages "redirects"
|
||||
|
||||
## Header API
|
||||
|
||||
- easy access to HTTP response headers, from all contexts
|
||||
- named headers
|
||||
- iterate over headers
|
||||
|
||||
## TLS
|
||||
|
||||
- selectable TLS backend(s)
|
||||
- TLS False Start
|
||||
- TLS version control
|
||||
- TLS session resumption
|
||||
- key pinning
|
||||
- mutual authentication
|
||||
- Use dedicated CA cert bundle
|
||||
- Use OS-provided CA store
|
||||
- separate TLS options for HTTPS proxy
|
||||
|
||||
## HTTP
|
||||
|
||||
- HTTP/0.9 responses are optionally accepted
|
||||
- HTTP/1.0
|
||||
- HTTP/1.1
|
||||
- HTTP/2, including multiplexing and server push
|
||||
- GET
|
||||
- PUT
|
||||
- HEAD
|
||||
- POST
|
||||
- multipart formpost (RFC 1867-style)
|
||||
- authentication: Basic, Digest, NTLM (9) and Negotiate (SPNEGO)
|
||||
to server and proxy
|
||||
- resume transfers
|
||||
- follow redirects
|
||||
- maximum amount of redirects to follow
|
||||
- custom HTTP request
|
||||
- cookie get/send fully parsed
|
||||
- reads/writes the Netscape cookie file format
|
||||
- custom headers (replace/remove internally generated headers)
|
||||
- custom user-agent string
|
||||
- custom referrer string
|
||||
- range
|
||||
- proxy authentication
|
||||
- time conditions
|
||||
- via HTTP proxy, HTTPS proxy or SOCKS proxy
|
||||
- HTTP/2 or HTTP/1.1 to HTTPS proxy
|
||||
- retrieve file modification date
|
||||
- Content-Encoding support for deflate, gzip, brotli and zstd
|
||||
- "Transfer-Encoding: chunked" support in uploads
|
||||
- HSTS
|
||||
- alt-svc
|
||||
- ETags
|
||||
- HTTP/1.1 trailers, both sending and getting
|
||||
|
||||
## HTTPS
|
||||
|
||||
- HTTP/3
|
||||
- using client certificates
|
||||
- verify server certificate
|
||||
- via HTTP proxy, HTTPS proxy or SOCKS proxy
|
||||
- select desired encryption
|
||||
- select usage of a specific TLS version
|
||||
- ECH
|
||||
|
||||
## FTP
|
||||
|
||||
- download
|
||||
- authentication
|
||||
- Kerberos 5
|
||||
- active/passive using PORT, EPRT, PASV or EPSV
|
||||
- single file size information (compare to HTTP HEAD)
|
||||
- 'type=' URL support
|
||||
- directory listing
|
||||
- directory listing names-only
|
||||
- upload
|
||||
- upload append
|
||||
- upload via http-proxy as HTTP PUT
|
||||
- download resume
|
||||
- upload resume
|
||||
- custom ftp commands (before and/or after the transfer)
|
||||
- simple "range" support
|
||||
- via HTTP proxy, HTTPS proxy or SOCKS proxy
|
||||
- all operations can be tunneled through proxy
|
||||
- customizable to retrieve file modification date
|
||||
- no directory depth limit
|
||||
|
||||
## FTPS
|
||||
|
||||
- implicit `ftps://` support that use SSL on both connections
|
||||
- explicit "AUTH TLS" and "AUTH SSL" usage to "upgrade" plain `ftp://`
|
||||
connection to use SSL for both or one of the connections
|
||||
|
||||
## SSH (both SCP and SFTP)
|
||||
|
||||
- selectable SSH backend
|
||||
- known hosts support
|
||||
- public key fingerprinting
|
||||
- both password and public key auth
|
||||
|
||||
## SFTP
|
||||
|
||||
- both password and public key auth
|
||||
- with custom commands sent before/after the transfer
|
||||
- directory listing
|
||||
|
||||
## TFTP
|
||||
|
||||
- download
|
||||
- upload
|
||||
|
||||
## TELNET
|
||||
|
||||
- connection negotiation
|
||||
- custom telnet options
|
||||
- stdin/stdout I/O
|
||||
|
||||
## LDAP
|
||||
|
||||
- full LDAP URL support
|
||||
|
||||
## DICT
|
||||
|
||||
- extended DICT URL support
|
||||
|
||||
## FILE
|
||||
|
||||
- URL support
|
||||
- upload
|
||||
- resume
|
||||
|
||||
## SMB
|
||||
|
||||
- SMBv1 over TCP and SSL
|
||||
- download
|
||||
- upload
|
||||
- authentication with NTLMv1
|
||||
|
||||
## SMTP
|
||||
|
||||
- authentication: Plain, Login, CRAM-MD5, Digest-MD5, NTLM, Kerberos 5 and
|
||||
External
|
||||
- send emails
|
||||
- mail from support
|
||||
- mail size support
|
||||
- mail auth support for trusted server-to-server relaying
|
||||
- multiple recipients
|
||||
- via http-proxy
|
||||
|
||||
## SMTPS
|
||||
|
||||
- implicit `smtps://` support
|
||||
- explicit "STARTTLS" usage to "upgrade" plain `smtp://` connections to use SSL
|
||||
- via http-proxy
|
||||
|
||||
## POP3
|
||||
|
||||
- authentication: Clear Text, APOP and SASL
|
||||
- SASL based authentication: Plain, Login, CRAM-MD5, Digest-MD5, NTLM,
|
||||
Kerberos 5 and External
|
||||
- list emails
|
||||
- retrieve emails
|
||||
- enhanced command support for: CAPA, DELE, TOP, STAT, UIDL and NOOP via
|
||||
custom requests
|
||||
- via http-proxy
|
||||
|
||||
## POP3S
|
||||
|
||||
- implicit `pop3s://` support
|
||||
- explicit `STLS` usage to "upgrade" plain `pop3://` connections to use SSL
|
||||
- via http-proxy
|
||||
|
||||
## IMAP
|
||||
|
||||
- authentication: Clear Text and SASL
|
||||
- SASL based authentication: Plain, Login, CRAM-MD5, Digest-MD5, NTLM,
|
||||
Kerberos 5 and External
|
||||
- list the folders of a mailbox
|
||||
- select a mailbox with support for verifying the `UIDVALIDITY`
|
||||
- fetch emails with support for specifying the UID and SECTION
|
||||
- upload emails via the append command
|
||||
- enhanced command support for: EXAMINE, CREATE, DELETE, RENAME, STATUS,
|
||||
STORE, COPY and UID via custom requests
|
||||
- via http-proxy
|
||||
|
||||
## IMAPS
|
||||
|
||||
- implicit `imaps://` support
|
||||
- explicit "STARTTLS" usage to "upgrade" plain `imap://` connections to use SSL
|
||||
- via http-proxy
|
||||
|
||||
## MQTT
|
||||
|
||||
- Subscribe to and publish topics using URL scheme `mqtt://broker/topic`
|
||||
171
Agent-Windows/OGP64/usr/share/doc/curl/HTTP-COOKIES.md
Normal file
171
Agent-Windows/OGP64/usr/share/doc/curl/HTTP-COOKIES.md
Normal file
|
|
@ -0,0 +1,171 @@
|
|||
<!--
|
||||
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
|
||||
SPDX-License-Identifier: curl
|
||||
-->
|
||||
|
||||
# HTTP Cookies
|
||||
|
||||
## Cookie overview
|
||||
|
||||
Cookies are `name=contents` pairs that an HTTP server tells the client to
|
||||
hold and then the client sends back those to the server on subsequent
|
||||
requests to the same domains and paths for which the cookies were set.
|
||||
|
||||
Cookies are either "session cookies" which typically are forgotten when the
|
||||
session is over which is often translated to equal when browser quits, or
|
||||
the cookies are not session cookies they have expiration dates after which
|
||||
the client throws them away.
|
||||
|
||||
Cookies are set to the client with the Set-Cookie: header and are sent to
|
||||
servers with the Cookie: header.
|
||||
|
||||
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, [RFC 6265](https://datatracker.ietf.org/doc/html/rfc6265) 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),
|
||||
and in 2017, another update was
|
||||
[drafted](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cookie-alone-01)
|
||||
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)
|
||||
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
|
||||
allows and uses cookies marked with the `secure` keyword even when done over
|
||||
plain HTTP for this host. curl does this to match how popular browsers work
|
||||
with secure cookies.
|
||||
|
||||
## Super cookies
|
||||
|
||||
A single cookie can be set for a domain that matches multiple hosts. Like if
|
||||
set for `example.com` it gets sent to both `aa.example.com` as well as
|
||||
`bb.example.com`.
|
||||
|
||||
A challenge with this concept is that there are certain domains for which
|
||||
cookies should not be allowed at all, because they are *Public
|
||||
Suffixes*. Similarly, a client never accepts cookies set directly for the
|
||||
top-level domain like for example `.com`. Cookies set for *too broad*
|
||||
domains are generally referred to as *super cookies*.
|
||||
|
||||
If curl is built with PSL (**Public Suffix List**) support, it detects and
|
||||
discards cookies that are specified for such suffix domains that should not
|
||||
be allowed to have cookies.
|
||||
|
||||
if curl is *not* built with PSL support, it has no ability to stop super
|
||||
cookies.
|
||||
|
||||
## Cookies saved to disk
|
||||
|
||||
Netscape once created a file format for storing cookies on disk so that they
|
||||
would survive browser restarts. curl adopted that file format to allow
|
||||
sharing the cookies with browsers, only to see browsers move away from that
|
||||
format. Modern browsers no longer use it, while curl still does.
|
||||
|
||||
The Netscape cookie file format stores one cookie per physical line in the
|
||||
file with a bunch of associated meta data, each field separated with
|
||||
TAB. That file is called the cookie jar in curl terminology.
|
||||
|
||||
When libcurl saves a cookie jar, it creates a file header of its own in
|
||||
which there is a URL mention that links to the web version of this document.
|
||||
|
||||
## Cookie file format
|
||||
|
||||
The cookie file format is text based and stores one cookie per line. Lines
|
||||
that start with `#` are treated as comments. An exception is lines that
|
||||
start with `#HttpOnly_`, which is a prefix for cookies that have the
|
||||
`HttpOnly` attribute set.
|
||||
|
||||
Each line that specifies a single cookie consists of seven text fields
|
||||
separated with TAB characters. A valid line must end with a newline
|
||||
character.
|
||||
|
||||
### Fields in the file
|
||||
|
||||
Field number, what type and example data and the meaning of it:
|
||||
|
||||
0. string `example.com` - the domain name
|
||||
1. boolean `FALSE` - include subdomains
|
||||
2. string `/foobar/` - path
|
||||
3. boolean `TRUE` - send/receive over HTTPS only
|
||||
4. number `1462299217` - expires at - seconds since Jan 1st 1970, or 0
|
||||
5. string `person` - name of the cookie
|
||||
6. string `daniel` - value of the cookie
|
||||
|
||||
## Cookies with curl the command line tool
|
||||
|
||||
curl has a full cookie "engine" built in. If you activate it, you can have
|
||||
curl receive and send cookies exactly as mandated in the specs.
|
||||
|
||||
Command line options:
|
||||
|
||||
[`-b, --cookie`](https://curl.se/docs/manpage.html#-b)
|
||||
|
||||
tell curl a file to read cookies from and start the cookie engine, or if it
|
||||
is not a file it passes on the given string. `-b name=var` works and so does
|
||||
`-b cookiefile`.
|
||||
|
||||
[`-j, --junk-session-cookies`](https://curl.se/docs/manpage.html#-j)
|
||||
|
||||
when used in combination with -b, it skips all "session cookies" on load so
|
||||
as to appear to start a new cookie session.
|
||||
|
||||
[`-c, --cookie-jar`](https://curl.se/docs/manpage.html#-c)
|
||||
|
||||
tell curl to start the cookie engine and write cookies to the given file
|
||||
after the request(s)
|
||||
|
||||
## Cookies with libcurl
|
||||
|
||||
libcurl offers several ways to enable and interface the cookie engine. These
|
||||
options are the ones provided by the native API. libcurl bindings may offer
|
||||
access to them using other means.
|
||||
|
||||
[`CURLOPT_COOKIE`](https://curl.se/libcurl/c/CURLOPT_COOKIE.html)
|
||||
|
||||
Is used when you want to specify the exact contents of a cookie header to
|
||||
send to the server.
|
||||
|
||||
[`CURLOPT_COOKIEFILE`](https://curl.se/libcurl/c/CURLOPT_COOKIEFILE.html)
|
||||
|
||||
Tell libcurl to activate the cookie engine, and to read the initial set of
|
||||
cookies from the given file. Read-only.
|
||||
|
||||
[`CURLOPT_COOKIEJAR`](https://curl.se/libcurl/c/CURLOPT_COOKIEJAR.html)
|
||||
|
||||
Tell libcurl to activate the cookie engine, and when the easy handle is
|
||||
closed save all known cookies to the given cookie jar file. Write-only.
|
||||
|
||||
[`CURLOPT_COOKIELIST`](https://curl.se/libcurl/c/CURLOPT_COOKIELIST.html)
|
||||
|
||||
Provide detailed information about a single cookie to add to the internal
|
||||
storage of cookies. Pass in the cookie as an HTTP header with all the
|
||||
details set, or pass in a line from a Netscape cookie file. This option can
|
||||
also be used to flush the cookies etc.
|
||||
|
||||
[`CURLOPT_COOKIESESSION`](https://curl.se/libcurl/c/CURLOPT_COOKIESESSION.html)
|
||||
|
||||
Tell libcurl to ignore all cookies it is about to load that are session
|
||||
cookies.
|
||||
|
||||
[`CURLINFO_COOKIELIST`](https://curl.se/libcurl/c/CURLINFO_COOKIELIST.html)
|
||||
|
||||
Extract cookie information from the internal cookie storage as a linked
|
||||
list.
|
||||
|
||||
## Cookies with JavaScript
|
||||
|
||||
These days a lot of the web is built up by JavaScript. The web browser loads
|
||||
complete programs that render the page you see. These JavaScript programs
|
||||
can also set and access cookies.
|
||||
|
||||
Since curl and libcurl are plain HTTP clients without any knowledge of or
|
||||
capability to handle JavaScript, such cookies are not detected or used.
|
||||
|
||||
Often, if you want to mimic what a browser does on such websites, you can
|
||||
record web browser HTTP traffic when using such a site and then repeat the
|
||||
cookie operations using curl or libcurl.
|
||||
582
Agent-Windows/OGP64/usr/share/doc/curl/KNOWN_BUGS.md
Normal file
582
Agent-Windows/OGP64/usr/share/doc/curl/KNOWN_BUGS.md
Normal file
|
|
@ -0,0 +1,582 @@
|
|||
<!--
|
||||
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
|
||||
SPDX-License-Identifier: curl
|
||||
-->
|
||||
|
||||
# Known bugs intro
|
||||
|
||||
These are problems and bugs known to exist at the time of this release. Feel
|
||||
free to join in and help us correct one or more of these. Also be sure to
|
||||
check the changelog of the current development status, as one or more of these
|
||||
problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
# TLS
|
||||
|
||||
## IMAPS connection fails with Rustls error
|
||||
|
||||
[curl issue 10457](https://github.com/curl/curl/issues/10457)
|
||||
|
||||
## Access violation sending client cert with Schannel
|
||||
|
||||
When using Schannel to do client certs, curl sets `PKCS12_NO_PERSIST_KEY` to
|
||||
avoid leaking the private key into the filesystem. Unfortunately that flag
|
||||
instead seems to trigger a crash.
|
||||
|
||||
See [curl issue 17626](https://github.com/curl/curl/issues/17626)
|
||||
|
||||
## Client cert handling with Issuer `DN` differs between backends
|
||||
|
||||
When the specified client certificate does not match any of the
|
||||
server-specified `DN` fields, the OpenSSL and GnuTLS backends behave
|
||||
differently. The GitHub discussion may contain a solution.
|
||||
|
||||
See [curl issue 1411](https://github.com/curl/curl/issues/1411)
|
||||
|
||||
## Client cert (MTLS) issues with Schannel
|
||||
|
||||
See [curl issue 3145](https://github.com/curl/curl/issues/3145)
|
||||
|
||||
## Schannel TLS 1.2 handshake bug in old Windows versions
|
||||
|
||||
In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake
|
||||
implementation likely has a bug that can rarely cause the key exchange to
|
||||
fail, resulting in error SEC_E_BUFFER_TOO_SMALL or SEC_E_MESSAGE_ALTERED.
|
||||
|
||||
[curl issue 5488](https://github.com/curl/curl/issues/5488)
|
||||
|
||||
## `CURLOPT_CERTINFO` results in `CURLE_OUT_OF_MEMORY` with Schannel
|
||||
|
||||
[curl issue 8741](https://github.com/curl/curl/issues/8741)
|
||||
|
||||
## mbedTLS and CURLE_AGAIN handling
|
||||
|
||||
[curl issue 15801](https://github.com/curl/curl/issues/15801)
|
||||
|
||||
## Native CA roots incomplete on Windows with OpenSSL (or fork)
|
||||
|
||||
Certain Windows installations may be missing CA roots.
|
||||
|
||||
[curl issue 20897](https://github.com/curl/curl/issues/20897)
|
||||
[curl issue 12303](https://github.com/curl/curl/issues/12303)
|
||||
|
||||
# Email protocols
|
||||
|
||||
## IMAP `SEARCH ALL` truncated response
|
||||
|
||||
IMAP `SEARCH ALL` truncates output on large boxes. "A quick search of the code
|
||||
reveals that `pingpong.c` contains some truncation code, at line 408, when it
|
||||
deems the server response to be too large truncating it to 40 characters"
|
||||
|
||||
https://curl.se/bug/view.cgi?id=1366
|
||||
|
||||
## No disconnect command
|
||||
|
||||
The disconnect commands (`LOGOUT` and `QUIT`) may not be sent by IMAP, POP3
|
||||
and SMTP if a failure occurs during the authentication phase of a connection.
|
||||
|
||||
## `AUTH PLAIN` for SMTP is not working on all servers
|
||||
|
||||
Specifying `--login-options AUTH=PLAIN` on the command line does not seem to
|
||||
work correctly.
|
||||
|
||||
See [curl issue 4080](https://github.com/curl/curl/issues/4080)
|
||||
|
||||
## `APOP` authentication fails on POP3
|
||||
|
||||
See [curl issue 10073](https://github.com/curl/curl/issues/10073)
|
||||
|
||||
## POP3 issue when reading small chunks
|
||||
|
||||
CURL_DBG_SOCK_RMAX=4 ./runtests.pl -v 982
|
||||
|
||||
See [curl issue 12063](https://github.com/curl/curl/issues/12063)
|
||||
|
||||
# Command line
|
||||
|
||||
## `-T /dev/stdin` may upload with an incorrect content length
|
||||
|
||||
`-T` stats the path to figure out its size in bytes to use it as
|
||||
`Content-Length` if it is a regular file.
|
||||
|
||||
The problem with that is that on BSD and some other UNIX systems (not Linux),
|
||||
open(path) may not give you a file descriptor with a 0 offset from the start
|
||||
of the file.
|
||||
|
||||
See [curl issue 12177](https://github.com/curl/curl/issues/12177)
|
||||
|
||||
## `-T -` always uploads chunked
|
||||
|
||||
When the `<` shell operator is used. curl should realize that stdin is a
|
||||
regular file in this case, and that it can do a non-chunked upload, like it
|
||||
would do if you used `-T` file.
|
||||
|
||||
See [curl issue 12171](https://github.com/curl/curl/issues/12171)
|
||||
|
||||
## Windows stdin relay accepts unauthenticated local connections
|
||||
|
||||
curl features a Windows-only stdin relay in `src/tool_doswin.c` that creates a
|
||||
loopback TCP listener and spawns a thread to accept the first incoming
|
||||
connection, then forwards stdin to it. There is no authentication or peer
|
||||
validation on the accepted socket. A local attacker can race to connect to the
|
||||
ephemeral loopback port (discoverable via local port enumeration/scan) before
|
||||
curl connects, causing the thread to send stdin/upload data to the attacker or
|
||||
to disrupt the transfer.
|
||||
|
||||
The function should verify the client-side with a random number similar to the
|
||||
socketpair emulation function in libcurl. It cannot verify the source address
|
||||
and port since there is this widespread habit on Windows to run tools that
|
||||
MITM even local TCP connections for security.
|
||||
|
||||
# Build and portability issues
|
||||
|
||||
## OS400 port requires deprecated IBM library
|
||||
|
||||
curl for OS400 requires `QADRT` to build, which provides ASCII wrappers for
|
||||
libc/POSIX functions in the ILE, but IBM no longer supports or even offers
|
||||
this library to download.
|
||||
|
||||
See [curl issue 5176](https://github.com/curl/curl/issues/5176)
|
||||
|
||||
## `curl-config --libs` contains private details
|
||||
|
||||
`curl-config --libs` include details set in `LDFLAGS` when configure is run
|
||||
that might be needed only for building libcurl. Further, `curl-config
|
||||
--cflags` suffers from the same effects with `CFLAGS`/`CPPFLAGS`.
|
||||
|
||||
## `LDFLAGS` passed too late making libs linked incorrectly
|
||||
|
||||
Compiling latest curl on HP-UX and linking against a custom OpenSSL (which is
|
||||
on the default loader/linker path), fails because the generated Makefile has
|
||||
`LDFLAGS` passed on after `LIBS`.
|
||||
|
||||
See [curl issue 14893](https://github.com/curl/curl/issues/14893)
|
||||
|
||||
## Cygwin: make install installs curl-config.1 twice
|
||||
|
||||
[curl issue 8839](https://github.com/curl/curl/issues/8839)
|
||||
|
||||
## flaky CI builds
|
||||
|
||||
We run many CI builds for each commit and PR on GitHub, and especially a
|
||||
number of the Windows builds are flaky. This means that we rarely get all CI
|
||||
builds go green and complete without errors. This is unfortunate as it makes
|
||||
us sometimes miss actual build problems and it is surprising to newcomers to
|
||||
the project who (rightfully) do not expect this.
|
||||
|
||||
See [curl issue 6972](https://github.com/curl/curl/issues/6972)
|
||||
|
||||
## long paths are not fully supported on Windows
|
||||
|
||||
curl on Windows cannot access long paths (paths longer than 260 characters).
|
||||
As a workaround, the Windows path prefix `\\?\` which disables all path
|
||||
interpretation may work to allow curl to access the path. For example:
|
||||
`\\?\c:\longpath`.
|
||||
|
||||
See [curl issue 8361](https://github.com/curl/curl/issues/8361)
|
||||
|
||||
## Unicode on Windows
|
||||
|
||||
Passing in a Unicode filename with -o:
|
||||
|
||||
[curl issue 11461](https://github.com/curl/curl/issues/11461)
|
||||
|
||||
Passing in Unicode character with -d:
|
||||
|
||||
[curl issue 12231](https://github.com/curl/curl/issues/12231)
|
||||
|
||||
Windows Unicode builds use the home directory in current locale.
|
||||
|
||||
The Windows Unicode builds of curl use the current locale, but expect Unicode
|
||||
UTF-8 encoded paths for internal use such as open, access and stat. The user's
|
||||
home directory is retrieved via curl_getenv in the current locale and not as
|
||||
UTF-8 encoded Unicode.
|
||||
|
||||
See [curl pull request 7252](https://github.com/curl/curl/pull/7252) and [curl pull request 7281](https://github.com/curl/curl/pull/7281)
|
||||
|
||||
Cannot handle Unicode arguments in non-Unicode builds on Windows
|
||||
|
||||
If a URL or filename cannot be encoded using the user's current code page then
|
||||
it can only be encoded properly in the Unicode character set. Windows uses
|
||||
UTF-16 encoding for Unicode and stores it in wide characters, however curl and
|
||||
libcurl are not equipped for that at the moment except when built with
|
||||
_UNICODE and UNICODE defined. Except for Cygwin, Windows cannot use UTF-8 as a
|
||||
locale.
|
||||
|
||||
https://curl.se/bug/?i=345
|
||||
https://curl.se/bug/?i=731
|
||||
https://curl.se/bug/?i=3747
|
||||
|
||||
NTLM authentication and Unicode
|
||||
|
||||
NTLM authentication involving Unicode username or password only works properly
|
||||
if built with UNICODE defined together with the Schannel backend. The original
|
||||
problem was mentioned in: https://curl.se/mail/lib-2009-10/0024.html and
|
||||
https://curl.se/bug/view.cgi?id=896
|
||||
|
||||
The Schannel version verified to work as mentioned in
|
||||
https://curl.se/mail/lib-2012-07/0073.html
|
||||
|
||||
# Authentication
|
||||
|
||||
## Digest `auth-int` for PUT/POST
|
||||
|
||||
We do not support auth-int for Digest using PUT or POST
|
||||
|
||||
## MIT Kerberos for Windows build
|
||||
|
||||
libcurl fails to build with MIT Kerberos for Windows (`KfW`) due to its
|
||||
library header files exporting symbols/macros that should be kept private to
|
||||
the library.
|
||||
|
||||
## NTLM in system context uses wrong name
|
||||
|
||||
NTLM authentication using SSPI (on Windows) when (lib)curl is running in
|
||||
"system context" makes it use wrong(?) username - at least when compared to
|
||||
what `winhttp` does. See https://curl.se/bug/view.cgi?id=535
|
||||
|
||||
## NTLM does not support password with Unicode 'SECTION SIGN' character
|
||||
|
||||
Code point: U+00A7
|
||||
|
||||
https://en.wikipedia.org/wiki/Section_sign
|
||||
[curl issue 2120](https://github.com/curl/curl/issues/2120)
|
||||
|
||||
## libcurl can fail to try alternatives with `--proxy-any`
|
||||
|
||||
When connecting via a proxy using `--proxy-any`, a failure to establish an
|
||||
authentication causes libcurl to abort trying other options if the failed
|
||||
method has a higher preference than the alternatives. As an example,
|
||||
`--proxy-any` against a proxy which advertise Negotiate and NTLM, but which
|
||||
fails to set up Kerberos authentication does not proceed to try authentication
|
||||
using NTLM.
|
||||
|
||||
[curl issue 876](https://github.com/curl/curl/issues/876)
|
||||
|
||||
## Do not clear digest for single realm
|
||||
|
||||
[curl issue 3267](https://github.com/curl/curl/issues/3267)
|
||||
|
||||
## SHA-256 digest not supported in Windows SSPI builds
|
||||
|
||||
Windows builds of curl that have SSPI enabled use the native Windows API calls
|
||||
to create authentication strings. The call to `InitializeSecurityContext` fails
|
||||
with `SEC_E_QOP_NOT_SUPPORTED` which causes curl to fail with
|
||||
`CURLE_AUTH_ERROR`.
|
||||
|
||||
Microsoft does not document supported digest algorithms and that `SEC_E` error
|
||||
code is not a documented error for `InitializeSecurityContext` (digest).
|
||||
|
||||
[curl issue 6302](https://github.com/curl/curl/issues/6302)
|
||||
|
||||
## curl never completes Negotiate over HTTP
|
||||
|
||||
Apparently it is not working correctly...?
|
||||
|
||||
See [curl issue 5235](https://github.com/curl/curl/issues/5235)
|
||||
|
||||
## Negotiate on Windows fails
|
||||
|
||||
When using `--negotiate` (or NTLM) with curl on Windows, SSL/TLS handshake
|
||||
fails despite having a valid kerberos ticket cached. Works without any issue
|
||||
in Unix/Linux.
|
||||
|
||||
[curl issue 5881](https://github.com/curl/curl/issues/5881)
|
||||
|
||||
## Negotiate authentication against Hadoop
|
||||
|
||||
[curl issue 8264](https://github.com/curl/curl/issues/8264)
|
||||
|
||||
# FTP
|
||||
|
||||
## FTP with ACCT
|
||||
|
||||
When doing an operation over FTP that requires the `ACCT` command (but not when
|
||||
logging in), the operation fails since libcurl does not detect this and thus
|
||||
fails to issue the correct command: https://curl.se/bug/view.cgi?id=635
|
||||
|
||||
## FTPS server compatibility on Windows with Schannel
|
||||
|
||||
FTPS is not widely used with the Schannel TLS backend and so there may be more
|
||||
bugs compared to other TLS backends such as OpenSSL. In the past users have
|
||||
reported hanging and failed connections. It is likely some changes to curl
|
||||
since then fixed the issues. None of the reported issues can be reproduced any
|
||||
longer.
|
||||
|
||||
If you encounter an issue connecting to your server via FTPS with the latest
|
||||
curl and Schannel then please search for open issues or file a new issue.
|
||||
|
||||
# SFTP and SCP
|
||||
|
||||
## SFTP does not do `CURLOPT_POSTQUOTE` correct
|
||||
|
||||
When libcurl sends `CURLOPT_POSTQUOTE` commands when connected to an SFTP
|
||||
server using the multi interface, the commands are not being sent correctly
|
||||
and instead the connection is canceled (the operation is considered done)
|
||||
prematurely. There is a half-baked (busy-looping) patch provided in the bug
|
||||
report but it cannot be accepted as-is. See
|
||||
https://curl.se/bug/view.cgi?id=748
|
||||
|
||||
## Remote recursive folder creation with SFTP
|
||||
|
||||
On this servers, the curl fails to create directories on the remote server
|
||||
even when the `CURLOPT_FTP_CREATE_MISSING_DIRS` option is set.
|
||||
|
||||
See [curl issue 5204](https://github.com/curl/curl/issues/5204)
|
||||
|
||||
## libssh blocking and infinite loop problem
|
||||
|
||||
In the `SSH_SFTP_INIT` state for libssh, the ssh session working mode is set
|
||||
to blocking mode. If the network is suddenly disconnected during sftp
|
||||
transmission, curl is stuck, even if curl is configured with a timeout.
|
||||
|
||||
[curl issue 8632](https://github.com/curl/curl/issues/8632)
|
||||
|
||||
## Cygwin: "WARNING: UNPROTECTED PRIVATE KEY FILE!"
|
||||
|
||||
Running SCP and SFTP tests on Cygwin makes this warning message appear.
|
||||
|
||||
[curl issue 11244](https://github.com/curl/curl/issues/11244)
|
||||
|
||||
# Connection
|
||||
|
||||
## `--interface` with link-scoped IPv6 address
|
||||
|
||||
When you give the `--interface` option telling curl to use a specific
|
||||
interface for its outgoing traffic in combination with an IPv6 address in the
|
||||
URL that uses a link-local scope, curl might pick the wrong address from the
|
||||
named interface and the subsequent transfer fails.
|
||||
|
||||
Example command line:
|
||||
|
||||
curl --interface eth0 'http://[fe80:928d:xxff:fexx:xxxx]/'
|
||||
|
||||
The fact that the given IP address is link-scoped should probably be used as
|
||||
input to somehow make curl make a better choice for this.
|
||||
|
||||
[curl issue 14782](https://github.com/curl/curl/issues/14782)
|
||||
|
||||
## Does not acknowledge getaddrinfo sorting policy
|
||||
|
||||
Even if a user edits `/etc/gai.conf` to prefer IPv4, curl still prefers and
|
||||
tries IPv6 addresses first.
|
||||
|
||||
[curl issue 16718](https://github.com/curl/curl/issues/16718)
|
||||
|
||||
## SOCKS-SSPI discards the security context
|
||||
|
||||
After a successful SSPI/GSS-API exchange, the function queries and logs the
|
||||
authenticated username and reports the supported data-protection level, but
|
||||
then immediately deletes the negotiated SSPI security context and frees the
|
||||
credentials before returning. The negotiated context is not stored on the
|
||||
connection and is therefore never used to protect later SOCKS5 traffic.
|
||||
|
||||
## cannot use absolute Unix domain filename for SOCKS on Windows
|
||||
|
||||
curl supports using a Unix domain socket path for speaking SOCKS to a proxy,
|
||||
by providing a filename in the URL used for `-x` (`CURLOPT_PROXY`), but that
|
||||
path cannot be a proper absolute Windows path with a drive letter etc.
|
||||
|
||||
A solution for this probably requires that we add and provide a
|
||||
`--unix-socket` (`CURLOPT_UNIX_SOCKET_PATH`) option alternative for proxy
|
||||
communication.
|
||||
|
||||
See [curl issue 19825](https://github.com/curl/curl/issues/19825)
|
||||
|
||||
# Internals
|
||||
|
||||
## GSSAPI library name + version is missing in `curl_version_info()`
|
||||
|
||||
The struct needs to be expanded and code added to store this info.
|
||||
|
||||
See [curl issue 13492](https://github.com/curl/curl/issues/13492)
|
||||
|
||||
## error buffer not set if connection to multiple addresses fails
|
||||
|
||||
If you ask libcurl to resolve a hostname like example.com to IPv6 addresses
|
||||
when you only have IPv4 connectivity. libcurl fails with
|
||||
`CURLE_COULDNT_CONNECT`, but the error buffer set by `CURLOPT_ERRORBUFFER`
|
||||
remains empty. Issue: [curl issue 544](https://github.com/curl/curl/issues/544)
|
||||
|
||||
## HTTP test server 'connection-monitor' problems
|
||||
|
||||
The `connection-monitor` feature of the HTTP test server does not work
|
||||
properly if some tests are run in unexpected order. Like 1509 and then 1525.
|
||||
|
||||
See [curl issue 868](https://github.com/curl/curl/issues/868)
|
||||
|
||||
## Connection information when using TCP Fast Open
|
||||
|
||||
`CURLINFO_LOCAL_PORT` (and possibly a few other) fails when TCP Fast Open is
|
||||
enabled.
|
||||
|
||||
See [curl issue 1332](https://github.com/curl/curl/issues/1332) and
|
||||
[curl issue 4296](https://github.com/curl/curl/issues/4296)
|
||||
|
||||
## test cases sometimes timeout
|
||||
|
||||
Occasionally, one of the tests timeouts. Inexplicably.
|
||||
|
||||
See [curl issue 13350](https://github.com/curl/curl/issues/13350)
|
||||
|
||||
## `CURLOPT_CONNECT_TO` does not work for HTTPS proxy
|
||||
|
||||
It is unclear if the same option should even cover the proxy connection or if
|
||||
if requires a separate option.
|
||||
|
||||
See [curl issue 14481](https://github.com/curl/curl/issues/14481)
|
||||
|
||||
## WinIDN test failures
|
||||
|
||||
Test 165 disabled when built with WinIDN.
|
||||
|
||||
## setting a disabled option should return `CURLE_NOT_BUILT_IN`
|
||||
|
||||
When curl has been built with specific features or protocols disabled, setting
|
||||
such options with `curl_easy_setopt()` should rather return
|
||||
`CURLE_NOT_BUILT_IN` instead of `CURLE_UNKNOWN_OPTION` to signal the
|
||||
difference to the application
|
||||
|
||||
See [curl issue 15472](https://github.com/curl/curl/issues/15472)
|
||||
|
||||
# LDAP
|
||||
|
||||
## OpenLDAP hangs after returning results
|
||||
|
||||
By configuration defaults, OpenLDAP automatically chase referrals on secondary
|
||||
socket descriptors. The OpenLDAP backend is asynchronous and thus should
|
||||
monitor all socket descriptors involved. Currently, these secondary
|
||||
descriptors are not monitored, causing OpenLDAP library to never receive data
|
||||
from them.
|
||||
|
||||
As a temporary workaround, disable referrals chasing by configuration.
|
||||
|
||||
The fix is not easy: proper automatic referrals chasing requires a synchronous
|
||||
bind callback and monitoring an arbitrary number of socket descriptors for a
|
||||
single easy handle (currently limited to 5).
|
||||
|
||||
Generic LDAP is synchronous: OK.
|
||||
|
||||
See [curl issue 622](https://github.com/curl/curl/issues/622) and
|
||||
https://curl.se/mail/lib-2016-01/0101.html
|
||||
|
||||
## LDAP on Windows does authentication wrong?
|
||||
|
||||
[curl issue 3116](https://github.com/curl/curl/issues/3116)
|
||||
|
||||
## LDAP on Windows does not work
|
||||
|
||||
A simple curl command line getting `ldap://ldap.forumsys.com` returns an error
|
||||
that says `no memory` !
|
||||
|
||||
[curl issue 4261](https://github.com/curl/curl/issues/4261)
|
||||
|
||||
## LDAPS requests to Active Directory server hang
|
||||
|
||||
[curl issue 9580](https://github.com/curl/curl/issues/9580)
|
||||
|
||||
# TCP/IP
|
||||
|
||||
## telnet code does not handle partial writes properly
|
||||
|
||||
It probably does not happen too easily because of how slow and infrequent
|
||||
sends are normally performed.
|
||||
|
||||
## Trying local ports fails on Windows
|
||||
|
||||
This makes `--local-port [range]` to not work since curl cannot properly
|
||||
detect if a port is already in use, so it tries the first port, uses that and
|
||||
then subsequently fails anyway if that was actually in use.
|
||||
|
||||
[curl issue 8112](https://github.com/curl/curl/issues/8112)
|
||||
|
||||
# CMake
|
||||
|
||||
## cmake outputs: no version information available
|
||||
|
||||
Something in the SONAME generation seems to be wrong in the cmake build.
|
||||
|
||||
[curl issue 11158](https://github.com/curl/curl/issues/11158)
|
||||
|
||||
## uses `-lpthread` instead of `Threads::Threads`
|
||||
|
||||
See [curl issue 6166](https://github.com/curl/curl/issues/6166)
|
||||
|
||||
## generated `.pc` file contains strange entries
|
||||
|
||||
The `Libs.private` field of the generated `.pc` file contains `-lgcc -lgcc_s
|
||||
-lc -lgcc -lgcc_s`.
|
||||
|
||||
See [curl issue 6167](https://github.com/curl/curl/issues/6167)
|
||||
|
||||
## CMake build with MIT Kerberos does not work
|
||||
|
||||
Minimum CMake version was bumped in curl 7.71.0 (#5358) Since CMake 3.2
|
||||
try_compile started respecting the `CMAKE_EXE_FLAGS`. The code dealing with
|
||||
MIT Kerberos detection sets few variables to potentially weird mix of space,
|
||||
and ;-separated flags. It had to blow up at some point. All the CMake checks
|
||||
that involve compilation are doomed from that point, the configured tree
|
||||
cannot be built.
|
||||
|
||||
[curl issue 6904](https://github.com/curl/curl/issues/6904)
|
||||
|
||||
# Authentication
|
||||
|
||||
## `--aws-sigv4` does not handle multipart/form-data correctly
|
||||
|
||||
[curl issue 13351](https://github.com/curl/curl/issues/13351)
|
||||
|
||||
# HTTP/2
|
||||
|
||||
## HTTP/2 prior knowledge over proxy
|
||||
|
||||
[curl issue 12641](https://github.com/curl/curl/issues/12641)
|
||||
|
||||
## HTTP/2 frames while in the connection pool kill reuse
|
||||
|
||||
If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
|
||||
curl while the connection is held in curl's connection pool, the socket is
|
||||
found readable when considered for reuse and that makes curl think it is dead
|
||||
and then it is closed and a new connection gets created instead.
|
||||
|
||||
This is *best* fixed by adding monitoring to connections while they are kept
|
||||
in the pool so that pings can be responded to appropriately.
|
||||
|
||||
## `ENHANCE_YOUR_CALM` causes infinite retries
|
||||
|
||||
Infinite retries with 2 parallel requests on one connection receiving `GOAWAY`
|
||||
with `ENHANCE_YOUR_CALM` error code.
|
||||
|
||||
See [curl issue 5119](https://github.com/curl/curl/issues/5119)
|
||||
|
||||
## HTTP/2 + TLS spends a lot of time in recv
|
||||
|
||||
It has been observed that by making the speed limit less accurate we could
|
||||
improve this performance. (by reverting
|
||||
[db5c9f4f9e0779](https://github.com/curl/curl/commit/db5c9f4f9e0779b49624752b135281a0717b277b))
|
||||
Can we find a golden middle ground?
|
||||
|
||||
See https://curl.se/mail/lib-2024-05/0026.html and
|
||||
[curl issue 13416](https://github.com/curl/curl/issues/13416)
|
||||
|
||||
# HTTP/3
|
||||
|
||||
## connection migration does not work
|
||||
|
||||
[curl issue 7695](https://github.com/curl/curl/issues/7695)
|
||||
|
||||
## quiche: QUIC connection is draining
|
||||
|
||||
The transfer ends with error "QUIC connection is draining".
|
||||
|
||||
[curl issue 12037](https://github.com/curl/curl/issues/12037)
|
||||
|
||||
# RTSP
|
||||
|
||||
## Some methods do not support response bodies
|
||||
|
||||
The RTSP implementation is written to assume that a number of RTSP methods
|
||||
always get responses without bodies, even though there seems to be no
|
||||
indication in the RFC that this is always the case.
|
||||
|
||||
[curl issue 12414](https://github.com/curl/curl/issues/12414)
|
||||
257
Agent-Windows/OGP64/usr/share/doc/curl/MAIL-ETIQUETTE.md
Normal file
257
Agent-Windows/OGP64/usr/share/doc/curl/MAIL-ETIQUETTE.md
Normal file
|
|
@ -0,0 +1,257 @@
|
|||
<!--
|
||||
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
|
||||
SPDX-License-Identifier: curl
|
||||
-->
|
||||
|
||||
# Mail etiquette
|
||||
|
||||
## About the lists
|
||||
|
||||
### Mailing Lists
|
||||
|
||||
The mailing lists we have are all listed and described on the [curl
|
||||
website](https://curl.se/mail/).
|
||||
|
||||
Each mailing list is targeted to a specific set of users and subjects, please
|
||||
use the one or the ones that suit you the most.
|
||||
|
||||
Each mailing list has hundreds up to thousands of readers, meaning that each
|
||||
mail sent is received and read by a large number of people. People from
|
||||
various cultures, regions, religions and continents.
|
||||
|
||||
### Netiquette
|
||||
|
||||
Netiquette is a common term for how to behave on the Internet. Of course, in
|
||||
each particular group and subculture there are differences in what is
|
||||
acceptable and what is considered good manners.
|
||||
|
||||
This document outlines what we in the curl project consider to be good
|
||||
etiquette, and primarily this focus on how to behave on and how to use our
|
||||
mailing lists.
|
||||
|
||||
### Do Not Mail a Single Individual
|
||||
|
||||
Many people send one question to one person. One person gets many mails, and
|
||||
there is only one person who can give you a reply. The question may be
|
||||
something that other people would also like to ask. These other people have no
|
||||
way to read the reply, but to ask the one person the question. The one person
|
||||
consequently gets overloaded with mail.
|
||||
|
||||
If you really want to contact an individual and perhaps pay for his or her
|
||||
services, by all means go ahead, but if it is another curl question, take it
|
||||
to a suitable list instead.
|
||||
|
||||
### Subscription Required
|
||||
|
||||
All curl mailing lists require that you are subscribed to allow a mail to go
|
||||
through to all the subscribers.
|
||||
|
||||
If you post without being subscribed (or from a different mail address than
|
||||
the one you are subscribed with), your mail is silently discarded. You
|
||||
have to subscribe first, then post.
|
||||
|
||||
The reason for this unfortunate and strict subscription policy is of course to
|
||||
stop spam from pestering the lists.
|
||||
|
||||
### Moderation of new posters
|
||||
|
||||
Several of the curl mailing lists automatically make all posts from new
|
||||
subscribers be moderated. After you have subscribed and sent your first mail
|
||||
to a list, that mail is not let through to the list until a mailing list
|
||||
administrator has verified that it is OK and permits it to get posted.
|
||||
|
||||
Once a first post has been made that proves the sender is actually talking
|
||||
about curl-related subjects, the moderation "flag" is switched off and future
|
||||
posts go through without being moderated.
|
||||
|
||||
The reason for this moderation policy is that we do suffer from spammers who
|
||||
actually subscribe and send spam to our lists.
|
||||
|
||||
### Handling trolls and spam
|
||||
|
||||
Despite our good intentions and hard work to keep spam off the lists and to
|
||||
maintain a friendly and positive atmosphere, there are times when spam and or
|
||||
trolls get through.
|
||||
|
||||
Troll - "someone who posts inflammatory, extraneous, or off-topic messages in
|
||||
an online community"
|
||||
|
||||
Spam - "use of electronic messaging systems to send unsolicited bulk messages"
|
||||
|
||||
No matter what, we NEVER EVER respond to trolls or spammers on the list. If
|
||||
you believe the list admin should do something in particular, contact them
|
||||
off-list. The subject is taken care of as much as possible to prevent repeated
|
||||
offenses, but responding on the list to such messages never leads to anything
|
||||
good and only puts the light even more on the offender: which was the entire
|
||||
purpose of it getting sent to the list in the first place.
|
||||
|
||||
Do not feed the trolls.
|
||||
|
||||
### How to unsubscribe
|
||||
|
||||
You can unsubscribe the same way you subscribed in the first place. You go to
|
||||
the page for the particular mailing list you are subscribed to and you enter
|
||||
your email address and password and press the unsubscribe button.
|
||||
|
||||
Also, the instructions to unsubscribe are included in the headers of every
|
||||
mail that is sent out to all curl related mailing lists and there is a footer
|
||||
in each mail that links to the "admin" page on which you can unsubscribe and
|
||||
change other options.
|
||||
|
||||
You NEVER EVER email the mailing list requesting someone else to take you off
|
||||
the list.
|
||||
|
||||
### I posted, now what?
|
||||
|
||||
If you are not subscribed with the same email address that you used to send
|
||||
the email, your post is silently discarded.
|
||||
|
||||
If you posted for the first time to the mailing list, you first need to wait
|
||||
for an administrator to allow your email to go through (moderated). This
|
||||
normally happens quickly but in case we are asleep, you may have to wait a few
|
||||
hours.
|
||||
|
||||
Once your email goes through it is sent out to several hundred or even
|
||||
thousands of recipients. Your email may cover an area that not that many
|
||||
people know about or are interested in. Or possibly the person who knows about
|
||||
it is on vacation or under a heavy work load right now. You may have to wait
|
||||
for a response and you should not expect to get a response at all. Ideally,
|
||||
you get an answer within a couple of days.
|
||||
|
||||
You do yourself and all of us a service when you include as many details as
|
||||
possible already in your first email. Mention your operating system and
|
||||
environment. Tell us which curl version you are using and tell us what you
|
||||
did, what happened and what you expected would happen. Preferably, show us
|
||||
what you did with details enough to allow others to help point out the problem
|
||||
or repeat the steps in their locations.
|
||||
|
||||
Failing to include details only delays responses and make people respond and
|
||||
ask for more details and you have to send follow-up emails that include them.
|
||||
|
||||
Expect the responses to primarily help YOU debug the issue, or ask YOU
|
||||
questions that can lead you or others towards a solution or explanation to
|
||||
whatever you experience.
|
||||
|
||||
If you are a repeat offender to the guidelines outlined in this document,
|
||||
chances are that people ignore you and your chances to get responses in the
|
||||
future greatly diminish.
|
||||
|
||||
### Your emails are public
|
||||
|
||||
Your email, its contents and all its headers and the details in those headers
|
||||
are received by every subscriber of the mailing list that you send your email
|
||||
to.
|
||||
|
||||
Your email as sent to a curl mailing list ends up in mail archives, on the
|
||||
curl website and elsewhere, for others to see and read. Today and in the
|
||||
future. In addition to the archives, the mail is sent out to thousands of
|
||||
individuals. There is no way to undo a sent email.
|
||||
|
||||
When sending emails to a curl mailing list, do not include sensitive
|
||||
information such as usernames and passwords; use fake ones, temporary ones or
|
||||
remove them completely from the mail. Note that this includes base64 encoded
|
||||
HTTP Basic auth headers.
|
||||
|
||||
This public nature of the curl mailing lists makes automatically inserted mail
|
||||
footers about mails being "private" or "only meant for the recipient" or
|
||||
similar even more silly than usual. Because they are absolutely not private
|
||||
when sent to a public mailing list.
|
||||
|
||||
## Sending mail
|
||||
|
||||
### Reply or New Mail
|
||||
|
||||
Please do not reply to an existing message as a short-cut to post a message to
|
||||
the lists.
|
||||
|
||||
Many mail programs and web archivers use information within mails to keep them
|
||||
together as "threads", as collections of posts that discuss a certain subject.
|
||||
If you do not intend to reply on the same or similar subject, do not hit reply
|
||||
on an existing mail and change the subject, create a new mail.
|
||||
|
||||
### Reply to the List
|
||||
|
||||
When replying to a message from the list, make sure that you do "group reply"
|
||||
or "reply to all", and not reply to the author of the single mail you reply
|
||||
to.
|
||||
|
||||
We are actively discouraging replying to the single person by setting the
|
||||
correct field in outgoing mails back asking for replies to get sent to the
|
||||
mailing list address, making it harder for people to reply to the author only
|
||||
by mistake.
|
||||
|
||||
### Use a Sensible Subject
|
||||
|
||||
Please use a subject of the mail that makes sense and that is related to the
|
||||
contents of your mail. It makes it a lot easier to find your mail afterwards
|
||||
and it makes it easier to track mail threads and topics.
|
||||
|
||||
### Do Not Top-Post
|
||||
|
||||
If you reply to a message, do not use top-posting. Top-posting is when you
|
||||
write the new text at the top of a mail and you insert the previous quoted
|
||||
mail conversation below. It forces users to read the mail in a backwards order
|
||||
to properly understand it.
|
||||
|
||||
This is why top posting is so bad (in top posting order):
|
||||
|
||||
A: Because it messes up the order in which people normally read text.
|
||||
Q: Why is top-posting such a bad thing?
|
||||
A: Top-posting.
|
||||
Q: What is the most annoying thing in email?
|
||||
|
||||
Apart from the screwed up read order (especially when mixed together in a
|
||||
thread when someone responds using the mandated bottom-posting style), it also
|
||||
makes it impossible to quote only parts of the original mail.
|
||||
|
||||
When you reply to a mail. You let the mail client insert the previous mail
|
||||
quoted. Then you put the cursor on the first line of the mail and you move
|
||||
down through the mail, deleting all parts of the quotes that do not add
|
||||
context for your comments. When you want to add a comment you do so, inline,
|
||||
right after the quotes that relate to your comment. Then you continue
|
||||
downwards again.
|
||||
|
||||
When most of the quotes have been removed and you have added your own words,
|
||||
you are done.
|
||||
|
||||
### HTML is not for mails
|
||||
|
||||
Please switch off those HTML encoded messages. You can mail all those funny
|
||||
mails to your friends. We speak plain text mails.
|
||||
|
||||
### Quoting
|
||||
|
||||
Quote as little as possible. Enough to provide the context you cannot leave
|
||||
out.
|
||||
|
||||
### Digest
|
||||
|
||||
We allow subscribers to subscribe to the "digest" version of the mailing
|
||||
lists. A digest is a collection of mails lumped together in one single mail.
|
||||
|
||||
Should you decide to reply to a mail sent out as a digest, there are two
|
||||
things you MUST consider if you really, really cannot subscribe normally
|
||||
instead:
|
||||
|
||||
Cut off all mails and chatter that is not related to the mail you want to
|
||||
reply to.
|
||||
|
||||
Change the subject name to something sensible and related to the subject,
|
||||
preferably even the actual subject of the single mail you wanted to reply to
|
||||
|
||||
### Please Tell Us How You Solved The Problem
|
||||
|
||||
Many people mail questions to the list, people spend some of their time and
|
||||
make an effort in providing good answers to these questions.
|
||||
|
||||
If you are the one who asks, please consider responding once more in case one
|
||||
of the hints was what solved your problems. The guys who write answers feel
|
||||
good to know that they provided a good answer and that you fixed the problem.
|
||||
Far too often, the person who asked the question is never heard from again,
|
||||
and we never get to know if they are gone because the problem was solved or
|
||||
perhaps because the problem was unsolvable.
|
||||
|
||||
Getting the solution posted also helps other users that experience the same
|
||||
problem(s). They get to see (possibly in the web archives) that the suggested
|
||||
fixes actually have helped at least one person.
|
||||
1007
Agent-Windows/OGP64/usr/share/doc/curl/MANUAL.md
Normal file
1007
Agent-Windows/OGP64/usr/share/doc/curl/MANUAL.md
Normal file
File diff suppressed because it is too large
Load diff
50
Agent-Windows/OGP64/usr/share/doc/curl/README
Normal file
50
Agent-Windows/OGP64/usr/share/doc/curl/README
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
_ _ ____ _
|
||||
___| | | | _ \| |
|
||||
/ __| | | | |_) | |
|
||||
| (__| |_| | _ <| |___
|
||||
\___|\___/|_| \_\_____|
|
||||
|
||||
README
|
||||
|
||||
Curl is a command line tool for transferring data specified with URL
|
||||
syntax. Find out how to use curl by reading the curl.1 man page or the
|
||||
MANUAL document. Find out how to install Curl by reading the INSTALL
|
||||
document.
|
||||
|
||||
libcurl is the library curl is using to do its job. It is readily
|
||||
available to be used by your software. Read the libcurl.3 man page to
|
||||
learn how.
|
||||
|
||||
You find answers to the most frequent questions we get in the FAQ.md
|
||||
document.
|
||||
|
||||
Study the COPYING file for distribution terms.
|
||||
|
||||
Those documents and more can be found in the docs/ directory.
|
||||
|
||||
CONTACT
|
||||
|
||||
If you have problems, questions, ideas or suggestions, please contact us
|
||||
by posting to a suitable mailing list. See https://curl.se/mail/
|
||||
|
||||
All contributors to the project are listed in the THANKS document.
|
||||
|
||||
WEBSITE
|
||||
|
||||
Visit the curl website for the latest news and downloads:
|
||||
|
||||
https://curl.se/
|
||||
|
||||
GIT
|
||||
|
||||
To download the latest source code off the GIT server, do this:
|
||||
|
||||
git clone https://github.com/curl/curl
|
||||
|
||||
(you will get a directory named curl created, filled with the source code)
|
||||
|
||||
SECURITY PROBLEMS
|
||||
|
||||
Report suspected security problems privately and not in public.
|
||||
|
||||
https://curl.se/dev/vuln-disclosure.html
|
||||
18
Agent-Windows/OGP64/usr/share/doc/curl/README.md
Normal file
18
Agent-Windows/OGP64/usr/share/doc/curl/README.md
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
<!--
|
||||
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
|
||||
SPDX-License-Identifier: curl
|
||||
-->
|
||||
|
||||
|
||||
|
||||
# Documentation
|
||||
|
||||
You find a mix of various documentation in this directory and subdirectories,
|
||||
using several different formats. Some of them are not ideal for reading
|
||||
directly in your browser.
|
||||
|
||||
If you would rather see the rendered version of the documentation, check out the
|
||||
curl website's [documentation section](https://curl.se/docs/) for
|
||||
general curl stuff or the [libcurl section](https://curl.se/libcurl/) for
|
||||
libcurl related documentation.
|
||||
628
Agent-Windows/OGP64/usr/share/doc/curl/RELEASE-NOTES
Normal file
628
Agent-Windows/OGP64/usr/share/doc/curl/RELEASE-NOTES
Normal file
|
|
@ -0,0 +1,628 @@
|
|||
curl and libcurl 8.20.0
|
||||
|
||||
Public curl releases: 274
|
||||
Command line options: 273
|
||||
curl_easy_setopt() options: 308
|
||||
Public functions in libcurl: 100
|
||||
Authors: 1463
|
||||
Contributors: 3664
|
||||
|
||||
This release includes the following changes:
|
||||
|
||||
o async-thrdd: use thread queue for resolving [144]
|
||||
o build: make NTLM disabled by default [90]
|
||||
o cmake: drop support for CMake 3.17 and older [108]
|
||||
o lib: add thread pool and queue [74]
|
||||
o lib: drop support for < c-ares 1.16.0 [64]
|
||||
o lib: make SMB support opt-in [18]
|
||||
o multi.h: add CURLMNWC_CLEAR_ALL [127]
|
||||
o rtmp: drop support [91]
|
||||
|
||||
This release includes the following bugfixes:
|
||||
|
||||
o altsvc: cap the list at 5,000 entries [183]
|
||||
o altsvc: drop the prio field from the struct [185]
|
||||
o altsvc: skip expired entries read from file [187]
|
||||
o asyn-ares: connect async [220]
|
||||
o asyn-ares: drop orphaned variable references [86]
|
||||
o asyn-ares: fix HTTPS-lookup when not on port 443 [100]
|
||||
o asyn-thrdd: drop redundant `result` check [291]
|
||||
o asyn-thrdd: fix clang-tidy unused value warning [125]
|
||||
o async-ares: fix query counter handling [195]
|
||||
o autotools: limit checksrc target to ignore non-repo test sources [12]
|
||||
o badwords-all: exit with correct code on errors [50]
|
||||
o badwords: combine the whitelisting into a single regex [1]
|
||||
o badwords: detect the the and with with [51]
|
||||
o badwords: only check comments and strings in source code [61]
|
||||
o badwords: rework exceptions, fix many of them [15]
|
||||
o boringssl: fix more coexist cases with Schannel/WinCrypt [170]
|
||||
o build: adjust/add casts to fix `-Wformat-signedness` [218]
|
||||
o build: assume `snprintf()` in `mprintf`, drop feature check [107]
|
||||
o build: compiler warning silencing tidy-ups [4]
|
||||
o build: drop `openssl` module dependency for BoringSSL from `libcurl.pc` [33]
|
||||
o build: drop duplicate `pthread.h` includes [158]
|
||||
o build: drop redundant `USE_QUICHE` guards [159]
|
||||
o build: enable `-Wimplicit-int-enum-cast` compiler warning, fix issues [84]
|
||||
o build: fix `-Wformat-signedness` by adjusting printf masks [226]
|
||||
o build: link `bcrypt.lib` via vcxproj files [239]
|
||||
o build: skip detecting `pipe2()` for Apple targets [227]
|
||||
o build: stop building and installing `runtests.1` and `testcurl.1` [235]
|
||||
o cf-https-connect: silence `-Wimplicit-int-enum-cast` with HTTPS-RR [132]
|
||||
o cf-https-connect: silence `-Wimplicit-int-enum-cast` with HTTPS-RR [63]
|
||||
o cf-ip-happy: limit concurrent attempts [191]
|
||||
o cf-socket: avoid low risk integer overflow on ancient Solaris [56]
|
||||
o cfilters: fix Curl_pollset_poll() return code mixup [206]
|
||||
o clang-tidy: avoid assignments in `if` expressions [175]
|
||||
o clang-tidy: enable more checks, fix fallouts [254]
|
||||
o cmake: add CMake Config-based dependency detection [87]
|
||||
o cmake: add CMake Config-based dependency detection for c-ares, wolfSSL [134]
|
||||
o cmake: do not install `wcurl` when `BUILD_CURL_EXE=OFF` [265]
|
||||
o cmake: do not install shell completions when `BUILD_CURL_EXE=OFF` [263]
|
||||
o cmake: document functions used from Windows system DLLs [103]
|
||||
o cmake: enable pthreads for BoringSSL/AWS-LC [196]
|
||||
o cmake: resolve targets recursively when generating `libcurl.pc` [45]
|
||||
o cmake: rework binutils ld hack to not read `LOCATION` property [41]
|
||||
o cmake: silence bad library `Threads::Threads` warning [131]
|
||||
o cmake: use `AIX` built-in variable (with CMake 4.0+) [163]
|
||||
o config2setopts: make --capath work in proxy disabled builds [113]
|
||||
o configure: fix `--with-ngtcp2=<path>` option for crypto libs [26]
|
||||
o configure: fix LibreSSL ngtcp2 1.15.0+ crypto lib selection logic [3]
|
||||
o configure: prefer dependency-specific variables over `$withval` [35]
|
||||
o configure: remove superfluous experimental warning for HTTP/3 [169]
|
||||
o configure: silence useless clang warnings in C89 builds [156]
|
||||
o configure: tidy up comments [202]
|
||||
o connect: fix typo on error message
|
||||
o cookie: fix rejection when tabs in value [189]
|
||||
o curl-wolfssl.m4: fix to use the correct value for pkg-config directory [36]
|
||||
o curl.h: replace macros with C++-friendly method to enforce 3 args [110]
|
||||
o curl_ctype.h: fix spelling in a couple of locally used macros [28]
|
||||
o curl_get_line: error out on read errors [9]
|
||||
o curl_get_line: fix potential infinite loop when filename is a directory [46]
|
||||
o curl_ngtcp2: extend and update callbacks for 1.22.0+ [165]
|
||||
o curl_ntlm_core: drop redundant PP condition [140]
|
||||
o curl_ntlm_core: use wolfCrypt DES API with wolfSSL [200]
|
||||
o curl_setup.h: drop stray/unused `USE_OPENSSL_QUIC` guard [210]
|
||||
o curl_sha512_256: support delegating to wolfSSL API [149]
|
||||
o curl_version_info.md: clarify age details [69]
|
||||
o CURLOPT_HAPROXY_CLIENT_IP.md: mention assumption on data format [96]
|
||||
o CURLOPT_RTSP_SESSION_ID.md: clarify reuse "dangers" [270]
|
||||
o CURLOPT_RTSP_SESSION_ID.md: expand the comment [267]
|
||||
o CURLOPT_RTSP_SESSION_ID.md: minor language fix
|
||||
o CURLOPT_SOCKS5_AUTH.md: an access property [212]
|
||||
o CURLOPT_SSL_CTX_FUNCTION.md: expand on effects connection reuse [105]
|
||||
o CURLOPT_UPLOAD_FLAGS.md: expand [223]
|
||||
o curlx_now(), prevent zero timestamp [93]
|
||||
o DEPRECATE: fix minor release number typo
|
||||
o digest: pass in the user name quoted (as well) [34]
|
||||
o dns: https-eyeballing async [229]
|
||||
o dnscache: own source file, improvements [116]
|
||||
o docs/cmdline-opts/write-out.md: tls_earlydata was adeded in 8.13.0
|
||||
o docs/cmdline-opts: tidy up retry-connrefused [190]
|
||||
o docs/lib: fix typos [53]
|
||||
o docs/libcurl: improve easy setopt examples [266]
|
||||
o docs: clarify retry-max-time timing [294]
|
||||
o docs: CURLOPT_LOGIN_OPTIONS is a login property [228]
|
||||
o docs: enable more compiler warnings for C snippets, fix 3 finds [71]
|
||||
o docs: list more dependencies for running Python HTTP tests [123]
|
||||
o docs: mention more zip bomb precautions [166]
|
||||
o docs: minor wording tweaks
|
||||
o docs: noproxy wants the punycoded hostname version [214]
|
||||
o docs: SSH host verification is done at connect time [197]
|
||||
o docs: use the correct CURLOPT_WRITEFUNCTION signature [142]
|
||||
o doh: fix memory-leak when doing a second DoH resolve [55]
|
||||
o doh: remove superfluous doh_req check [222]
|
||||
o examples/websocket: fix to sleep more on Windows [92]
|
||||
o examples: drop warning silencers no longer hit [14]
|
||||
o examples: fix typo in comment [75]
|
||||
o file: init fd to -1 to prevent close fd 0 on early failure [40]
|
||||
o fopen: for temp files, inherit permissions only for owner [146]
|
||||
o ftp: do not strdup DATA hostname [29]
|
||||
o ftp: make the MDTM date parser stricter (again) [115]
|
||||
o ftp: reject PWD responses containing control characters [95]
|
||||
o gcc: guard `#pragma diagnostic` in core code for <4.6 [94]
|
||||
o generate.bat: remove extra % from VC11 and VC12 runs
|
||||
o genserv.pl: make external calls safe [119]
|
||||
o getinfo: initialize `PureInfo` field `used_proxy` [43]
|
||||
o getinfo: repair CURLINFO_TLS_SESSION [193]
|
||||
o gnutls: fix clang-tidy warning with !verbose [126]
|
||||
o gtls: fail for large files in `load_file()` [174]
|
||||
o h3: HTTPS-RR use in HTTP/3 [221]
|
||||
o Happy Eyeballs: add resolution time delay [238]
|
||||
o haproxy: use correct ip version on client supplied address [275]
|
||||
o hostip: clear the sockaddr_in6 structure before use [20]
|
||||
o hostip: init the curl_jmpenv_lock appropriately [278]
|
||||
o hostip: resolve user supplied ip addresses [259]
|
||||
o HSTS: cap the list [177]
|
||||
o hsts: make the HSTS read callback handle name dupes [141]
|
||||
o hsts: skip expired HSTS entries read from file [188]
|
||||
o hsts: when a dupe host adds subdomains, use that [130]
|
||||
o http2: clear the h2 session at delete [99]
|
||||
o http2: prevent secure schemes pushed over insecure connections [181]
|
||||
o http2: return error on OOM in push headers [65]
|
||||
o HTTP3.md: drop outdated mentions of OpenSSL-QUIC [2]
|
||||
o http: clear credentials better on redirect [204]
|
||||
o http: clear digest nonce on cross-orgin redirect [269]
|
||||
o http: clear the proxy credentials as well on port or scheme change [246]
|
||||
o http: fix auth_used and auth_avail [154]
|
||||
o http: fix Curl_compareheader for multi value headers [11]
|
||||
o http: make Curl_compareheader handle multiple commas in header
|
||||
o http: on 303, switch to GET [208]
|
||||
o http: use header_has_value() instead of duplicate code [251]
|
||||
o imap: reset the UIDVALIDITY state between transfers [7]
|
||||
o include: drop 'will' from public headers [73]
|
||||
o INSTALL.md: update Cygwin instructions [198]
|
||||
o keylog.h: replace literal number with macro in declaration [171]
|
||||
o keylog: drop unused/redundant includes and guards [172]
|
||||
o ldap: drop duplicate `ldap_set_option()` on Windows [42]
|
||||
o ldap: fix to initialize cleartext connection on Windows [49]
|
||||
o lib1560: fix comment typo
|
||||
o lib1960: fix test failure [255]
|
||||
o lib: accept larger input to md5/hmac/sha256/sha512 functions [194]
|
||||
o lib: always use Curl_1st_fatal instead of Curl_1st_err [89]
|
||||
o lib: fix typos in comments [240]
|
||||
o lib: make resolving HTTPS DNS records reliable: [176]
|
||||
o lib: minor comment typos [237]
|
||||
o lib: move request specific allocations to the request struct [256]
|
||||
o lib: replace `PRI*32` printf masks with C89 ones [201]
|
||||
o libssh2: allocate libssh2-friendly memory in kbd_callback [225]
|
||||
o libssh2: fix error handling on quote errors [21]
|
||||
o libssh: fix 64-bit printf mask for mingw-w64 <=6.0.0 [215]
|
||||
o libssh: fix `-Wsign-compare` in 32-bit builds [217]
|
||||
o libssh: path length precaution [164]
|
||||
o libssh: propagate error back in SFTP function [178]
|
||||
o libtest: drop duplicate include [111]
|
||||
o location/follow: mention netrc [138]
|
||||
o man: fix argument type for `CURLSHOPT_[UN]SHARE` options [211]
|
||||
o mbedtls: cleanup more without care for 'initialized' [262]
|
||||
o mbedtls: fix ECJPAKE matching [135]
|
||||
o mbedtls: remove failf() call with first argument as NULL [249]
|
||||
o md4, md5: switch to wolfCrypt API in wolfSSL builds [139]
|
||||
o mime: only allow 40 levels of calls [241]
|
||||
o misc: fix code quality findings [209]
|
||||
o mk-ca-bundle.pl: make `ca-bundle.crt` timestamp match `certdata.txt`'s [44]
|
||||
o multi: enhance pending handles fairness [284]
|
||||
o multi: fix connection retry for non-http [180]
|
||||
o multi: improve wakeup and wait code [118]
|
||||
o netrc: find login-less password when user is given in URL [6]
|
||||
o netrc: remove unused parsenetrc() macro for netrc-disabled [121]
|
||||
o netrc: skip malformed macdef lines [67]
|
||||
o openssl channel_binding: lookup digest algorithm without NID [117]
|
||||
o openssl: drop obsolete SSLv2 logic [27]
|
||||
o openssl: fix build with 4.0.0-beta1 no-deprecated [184]
|
||||
o openssl: fix memory leaks in ECH code (OpenSSL 3) [78]
|
||||
o openssl: fix unused variable warnings in !verbose builds [252]
|
||||
o openssl: trace count of found / imported Windows native CA roots [8]
|
||||
o OS400: add new definitions to the ILE/RPG binding. [153]
|
||||
o os400sys: fix typo in comment (symetry -> symmetry) [58]
|
||||
o parsedate: bsearch the time zones [232]
|
||||
o parsedate: fix wrong treatment of "military time zones" [182]
|
||||
o parsedate: refactor [230]
|
||||
o perl: harden external command invocations [133]
|
||||
o progress: count amount of data "delivered" to application [66]
|
||||
o protocol.h: fix the CURLPROTO_MASK [31]
|
||||
o protocol: disable connection reuse for SMB(S) [199]
|
||||
o protocol: use scheme names lowercase [38]
|
||||
o proxy: chunked response, error code [143]
|
||||
o pytest: add additional quiche check for flaky test_05_01 [22]
|
||||
o pytest: check 429 handling [268]
|
||||
o rand: use `BCryptGenRandom()` in UWP builds [88]
|
||||
o ratelimit: reset on start [150]
|
||||
o request: reset resp_trailer in new requests [186]
|
||||
o runtests: skip setting ed25519 SSH key format [264]
|
||||
o rustls: fix memory leak on repeated SSLKEYLOGFILE fails [280]
|
||||
o rustls: handle EOF during initial handshake [203]
|
||||
o schannel: increase renegotiation timeout to 60 seconds [261]
|
||||
o scripts: drop redundant double-quotes: `"$var"` -> `$var` (Perl) [109]
|
||||
o scripts: harden / tidy up more Perl `system()` calls [70]
|
||||
o sectrust: fail on missing OCSP stapling [250]
|
||||
o sendf: fix CR detection if no LF is in the chunk [219]
|
||||
o setopt: clear proxy auth properties when switching [192]
|
||||
o setopt: fix typos in comments [257]
|
||||
o setopt: move CURLOPT_CURLU [260]
|
||||
o setup connection filter: mark as setup [234]
|
||||
o sha256, sha512_256: switch to wolfCrypt API [147]
|
||||
o sha256: support delegating to wolfSSL API [148]
|
||||
o share: concurrency handling, easy updates [104]
|
||||
o share: do bitshifts after the type is checked to be valid [216]
|
||||
o socks: reject zero-length GSSAPI/SSPI tokens from proxy [157]
|
||||
o socks: use dns filter for resolving [244]
|
||||
o spelling: fix typos [173]
|
||||
o src: use ftruncate() unconditionally [128]
|
||||
o sshserver.pl: harden more `system()` calls [81]
|
||||
o sshserver.pl: pass command-line to `system()` safely [82]
|
||||
o strerr: correct the strerror_s() return code condition [25]
|
||||
o sws: fix potential OOB write [80]
|
||||
o synctime: fix off-by-one read and write to a read-only buffer (Windows) [85]
|
||||
o test 766: flag as timing-dependent [136]
|
||||
o test1675: unit tests for URL API helper functions [248]
|
||||
o test459: switch to mode="warn" for stderr check [5]
|
||||
o testcurl.pl: replace shell commands with Perl `rmtree()` [76]
|
||||
o tests/unit/README: describe how to unit test static functions [60]
|
||||
o tests: avoid infinite recursion for `make check` [253]
|
||||
o tests: use %b64[] instead of "raw" base64 [245]
|
||||
o tool: check for curlinfo->age when determining if ssh backend [77]
|
||||
o tool: fix memory mixups [106]
|
||||
o tool: fix retries in parallel mode [137]
|
||||
o tool: fix two more allocator mismatches [155]
|
||||
o tool_cb_hdr: only truncate etags output when regular file [129]
|
||||
o tool_cb_rea: make waitfd() return void [168]
|
||||
o tool_cb_wrt: fix no-clobber error handling [39]
|
||||
o tool_cfgable: free the SSL signature algorithms [62]
|
||||
o tool_dirhie: fix to create drive-relative directory [276]
|
||||
o tool_formparse: propagate my_get_line errors when reading headers [102]
|
||||
o tool_getparam: use correct free function for libcurl memory [68]
|
||||
o tool_ipfs: accept IPFS gateway URL without set port number [13]
|
||||
o tool_msgs: avoid null pointer deref for early errors [98]
|
||||
o tool_operate: actually apply the --parallel-max-host limit [167]
|
||||
o tool_operate: drop the scheme-guessing in the -G handling [54]
|
||||
o tool_operate: fix condition for loading `curl-ca-bundle.crt` (Windows) [79]
|
||||
o tool_operate: fix memory-leak on failed uploads [124]
|
||||
o tool_operate: fix minor memory-leak on early error [23]
|
||||
o tool_operate: reset the upload glob counter for next URL [162]
|
||||
o tool_operhlp: fix `add_file_name_to_url()` result on OOM [32]
|
||||
o tool_operhlp: iterate through all slashes to find name [114]
|
||||
o tool_operhlp: propagate low-level OOM in `add_file_name_to_url()` [112]
|
||||
o tool_setopt: return error on OOM correctly [152]
|
||||
o tool_urlglob: fix memory-leak on glob range overflow [19]
|
||||
o top-complexity: prevent filename-based shell injection risk [101]
|
||||
o transfer: clear the old autoreferer [236]
|
||||
o transfer: clear the URL pointer in OOM to avoid UAF [179]
|
||||
o transfer: enable custom methods again on next transfer [30]
|
||||
o transfer: enhance secure check [10]
|
||||
o unit1675: fix `-Wformat-signedness` [274]
|
||||
o url: do not reuse a non-tls starttls connection if new requires TLS [145]
|
||||
o url: improve connection reuse on negotiate [160]
|
||||
o url: init req.no_body in DO so that it works for h2 push [161]
|
||||
o url: set default upload flags to CURLULFLAG_SEEN [224]
|
||||
o url: use the socks type for socks proxy [47]
|
||||
o url: use URL for url even in comments [52]
|
||||
o urlapi: fix handling of "file:///" [122]
|
||||
o urlapi: make dedotdotify handle leading dots correctly [97]
|
||||
o urlapi: same origin tests [213]
|
||||
o urlapi: stop extracting hostname from file:// URLs on Windows [247]
|
||||
o urlapi: verify the last letter of a scheme when set explicitly [16]
|
||||
o urldata.h: fix typo and lingering backtick [279]
|
||||
o urldata: connection bit ipv6_ip is wrong [59]
|
||||
o urldata: import port types and conn destination format [57]
|
||||
o urldata: make hstslist only present in HSTS builds [120]
|
||||
o urldata: make speeder_c uint32 [37]
|
||||
o urldata: move cookiehost to struct SingleRequest [242]
|
||||
o urldata: remove trailers_state [17]
|
||||
o vquic: fix variable name in fallback code [207]
|
||||
o vtls: fix comment typos and tidy up a type [285]
|
||||
o vtls: log when key logging is enabled. [288]
|
||||
o vtls_scache: check reentrancy [243]
|
||||
o vtls_scache: include cert_blob independently of verifypeer [231]
|
||||
o wolfssl: document v5.0.0 (2021-11-01) as minimum required [151]
|
||||
o wolfssl: fix `-Wmissing-prototypes` [233]
|
||||
o wolfssl: fix handling of abrupt connection close [24]
|
||||
o write-out.md: minor language fix [273]
|
||||
o write-out.md: tls_earlydata was adeded in 8.13.0
|
||||
o ws: fix a blocking curl_ws_send() to report written length correctly [258]
|
||||
o x509asn1: fix to return error in an error case from `encodeOID()` [83]
|
||||
o x509asn1: fixed and adapted for ASN1tostr unit testing [48]
|
||||
o x509asn1: improve encodeOID [72]
|
||||
|
||||
This release includes the following known bugs:
|
||||
|
||||
See https://curl.se/docs/knownbugs.html
|
||||
|
||||
For all changes ever done in curl:
|
||||
|
||||
See https://curl.se/changes.html
|
||||
|
||||
Planned upcoming removals include:
|
||||
|
||||
o local crypto implementations
|
||||
o NTLM
|
||||
o SMB
|
||||
o TLS-SRP support
|
||||
|
||||
See https://curl.se/dev/deprecate.html
|
||||
|
||||
This release would not have looked like this without help, code, reports and
|
||||
advice from friends like these:
|
||||
|
||||
Alex Hamilton, am-perip on hackerone, Arkadi Vainbrand, bird on github,
|
||||
BlackFuffey on github, Carlos Carrillo, Carlos Henrique Lima Melara,
|
||||
crawfordxx, Cutiapreta on hackerone, Dag-Erling Smørgrav, Dan Arnfield,
|
||||
Dan Fandrich, Daniel McCarney, Daniel Schulte, Daniel Stenberg,
|
||||
dependabot[bot], Dexter Gerig, Dio Putra, Dwij Mehta, Ercan Ermis,
|
||||
fds242 on github, finkjsc on github, Fiona Klute, Flavio Amieiro,
|
||||
Geeknik Labs, Greg Kroah-Hartman, Harry Sintonen, Henrique Pereira,
|
||||
herbenderbler on github, Ian Spence, Izan on hackerone, James Fuller,
|
||||
Jason Stangroome, John Haugabook, Juan Belón, Kai Pastor, Kaixuan Li, kpcyrd,
|
||||
lg_oled77c5pua on hackerone, M42kL33 on hackerone, m777m0 on hackerone,
|
||||
Marcel Raad, Martin Dürrmeier, Mehtab Zafar, Michael Hendricks,
|
||||
Michael Kaufmann, Muhamad Arga Reksapati, Ngoc Hieu, nitrogene on github,
|
||||
Orgad Shaneh, Osama Hamad, Otis Cui Lei, Patrick Monnerat, Quac Tran,
|
||||
Ray Satiro, renovate[bot], Richard Tollerton, Rob Crittenden,
|
||||
Samuel Henrique, Scott Boudreaux, Sergey Fedorov, sergio-nsk on github,
|
||||
Stefan Eissing, Ted Lyngmo, Terrance Wong, Tim Omta, Viktor Szakats,
|
||||
Vladimír Marek, xkilua on hackerone, Yalguun Tumenkhuu, Yedaya Katsman,
|
||||
Yiwei Hou, Yoshiro Yoneya
|
||||
(73 contributors)
|
||||
|
||||
References to bug reports and discussions on issues:
|
||||
|
||||
[1] = https://curl.se/bug/?i=20880
|
||||
[2] = https://curl.se/bug/?i=20914
|
||||
[3] = https://curl.se/bug/?i=20889
|
||||
[4] = https://curl.se/bug/?i=20908
|
||||
[5] = https://curl.se/bug/?i=20910
|
||||
[6] = https://curl.se/bug/?i=20950
|
||||
[7] = https://curl.se/bug/?i=20962
|
||||
[8] = https://curl.se/bug/?i=20899
|
||||
[9] = https://curl.se/bug/?i=20958
|
||||
[10] = https://curl.se/bug/?i=20951
|
||||
[11] = https://curl.se/bug/?i=20894
|
||||
[12] = https://curl.se/bug/?i=20898
|
||||
[13] = https://curl.se/bug/?i=20957
|
||||
[14] = https://curl.se/bug/?i=20896
|
||||
[15] = https://curl.se/bug/?i=20886
|
||||
[16] = https://curl.se/bug/?i=20893
|
||||
[17] = https://curl.se/bug/?i=20960
|
||||
[18] = https://curl.se/bug/?i=20846
|
||||
[19] = https://curl.se/bug/?i=20956
|
||||
[20] = https://curl.se/bug/?i=20885
|
||||
[21] = https://curl.se/bug/?i=20883
|
||||
[22] = https://curl.se/bug/?i=20952
|
||||
[23] = https://curl.se/bug/?i=20954
|
||||
[24] = https://curl.se/bug/?i=21002
|
||||
[25] = https://curl.se/bug/?i=20955
|
||||
[26] = https://curl.se/bug/?i=18022
|
||||
[27] = https://curl.se/bug/?i=20945
|
||||
[28] = https://curl.se/bug/?i=20810
|
||||
[29] = https://curl.se/bug/?i=20953
|
||||
[30] = https://curl.se/bug/?i=21037
|
||||
[31] = https://curl.se/bug/?i=21031
|
||||
[32] = https://curl.se/bug/?i=21011
|
||||
[33] = https://curl.se/bug/?i=20926
|
||||
[34] = https://curl.se/bug/?i=20940
|
||||
[35] = https://curl.se/bug/?i=20944
|
||||
[36] = https://curl.se/bug/?i=20943
|
||||
[37] = https://curl.se/bug/?i=21036
|
||||
[38] = https://curl.se/bug/?i=21033
|
||||
[39] = https://curl.se/bug/?i=20939
|
||||
[40] = https://curl.se/bug/?i=21029
|
||||
[41] = https://curl.se/bug/?i=20839
|
||||
[42] = https://curl.se/bug/?i=20930
|
||||
[43] = https://curl.se/bug/?i=21020
|
||||
[44] = https://curl.se/bug/?i=20528
|
||||
[45] = https://curl.se/bug/?i=20840
|
||||
[46] = https://curl.se/bug/?i=20823
|
||||
[47] = https://curl.se/bug/?i=21025
|
||||
[48] = https://curl.se/bug/?i=21013
|
||||
[49] = https://curl.se/bug/?i=20927
|
||||
[50] = https://curl.se/bug/?i=20934
|
||||
[51] = https://curl.se/bug/?i=20934
|
||||
[52] = https://curl.se/bug/?i=20935
|
||||
[53] = https://curl.se/bug/?i=20933
|
||||
[54] = https://curl.se/bug/?i=20992
|
||||
[55] = https://curl.se/bug/?i=20929
|
||||
[56] = https://curl.se/bug/?i=21111
|
||||
[57] = https://curl.se/bug/?i=20918
|
||||
[58] = https://curl.se/bug/?i=20923
|
||||
[59] = https://curl.se/bug/?i=20919
|
||||
[60] = https://curl.se/bug/?i=21018
|
||||
[61] = https://curl.se/bug/?i=20909
|
||||
[62] = https://curl.se/bug/?i=20915
|
||||
[63] = https://curl.se/bug/?i=21057
|
||||
[64] = https://curl.se/bug/?i=20911
|
||||
[65] = https://hackerone.com/reports/3636044
|
||||
[66] = https://curl.se/bug/?i=20787
|
||||
[67] = https://curl.se/bug/?i=21049
|
||||
[68] = https://curl.se/bug/?i=21075
|
||||
[69] = https://curl.se/bug/?i=21052
|
||||
[70] = https://curl.se/bug/?i=21007
|
||||
[71] = https://curl.se/bug/?i=21006
|
||||
[72] = https://curl.se/bug/?i=21003
|
||||
[73] = https://curl.se/bug/?i=21005
|
||||
[74] = https://curl.se/bug/?i=20916
|
||||
[75] = https://curl.se/bug/?i=21001
|
||||
[76] = https://curl.se/bug/?i=21053
|
||||
[77] = https://curl.se/bug/?i=21050
|
||||
[78] = https://curl.se/bug/?i=20993
|
||||
[79] = https://curl.se/bug/?i=20989
|
||||
[80] = https://curl.se/bug/?i=20988
|
||||
[81] = https://curl.se/bug/?i=20997
|
||||
[82] = https://curl.se/bug/?i=20996
|
||||
[83] = https://curl.se/bug/?i=20991
|
||||
[84] = https://curl.se/bug/?i=20990
|
||||
[85] = https://curl.se/bug/?i=20987
|
||||
[86] = https://curl.se/bug/?i=20999
|
||||
[87] = https://curl.se/bug/?i=20814
|
||||
[88] = https://curl.se/bug/?i=20983
|
||||
[89] = https://curl.se/bug/?i=20980
|
||||
[90] = https://curl.se/bug/?i=20698
|
||||
[91] = https://curl.se/bug/?i=20673
|
||||
[92] = https://curl.se/bug/?i=20978
|
||||
[93] = https://curl.se/bug/?i=21034
|
||||
[94] = https://curl.se/bug/?i=20892
|
||||
[95] = https://curl.se/bug/?i=20949
|
||||
[96] = https://curl.se/bug/?i=21042
|
||||
[97] = https://curl.se/bug/?i=20974
|
||||
[98] = https://curl.se/bug/?i=20967
|
||||
[99] = https://curl.se/bug/?i=20975
|
||||
[100] = https://curl.se/bug/?i=20966
|
||||
[101] = https://curl.se/bug/?i=20969
|
||||
[102] = https://curl.se/bug/?i=20963
|
||||
[103] = https://curl.se/bug/?i=20965
|
||||
[104] = https://curl.se/bug/?i=20870
|
||||
[105] = https://curl.se/bug/?i=21164
|
||||
[106] = https://curl.se/bug/?i=21099
|
||||
[107] = https://curl.se/bug/?i=20763
|
||||
[108] = https://curl.se/bug/?i=20407
|
||||
[109] = https://curl.se/bug/?i=21009
|
||||
[110] = https://curl.se/bug/?i=20709
|
||||
[111] = https://curl.se/bug/?i=21046
|
||||
[112] = https://curl.se/bug/?i=21011
|
||||
[113] = https://curl.se/bug/?i=21063
|
||||
[114] = https://curl.se/bug/?i=21165
|
||||
[115] = https://curl.se/bug/?i=21041
|
||||
[116] = https://curl.se/bug/?i=20864
|
||||
[117] = https://curl.se/bug/?i=20590
|
||||
[118] = https://curl.se/bug/?i=20832
|
||||
[119] = https://curl.se/bug/?i=20971
|
||||
[120] = https://curl.se/bug/?i=21068
|
||||
[121] = https://curl.se/bug/?i=21067
|
||||
[122] = https://curl.se/bug/?i=21070
|
||||
[123] = https://curl.se/bug/?i=21110
|
||||
[124] = https://curl.se/bug/?i=21062
|
||||
[125] = https://curl.se/bug/?i=21061
|
||||
[126] = https://curl.se/bug/?i=21060
|
||||
[127] = https://curl.se/bug/?i=20968
|
||||
[128] = https://curl.se/bug/?i=21109
|
||||
[129] = https://curl.se/bug/?i=21103
|
||||
[130] = https://curl.se/bug/?i=21108
|
||||
[131] = https://curl.se/bug/?i=21170
|
||||
[132] = https://curl.se/bug/?i=21167
|
||||
[133] = https://curl.se/bug/?i=21097
|
||||
[134] = https://curl.se/bug/?i=21098
|
||||
[135] = https://curl.se/bug/?i=21264
|
||||
[136] = https://curl.se/bug/?i=21155
|
||||
[137] = https://curl.se/bug/?i=20669
|
||||
[138] = https://curl.se/bug/?i=21091
|
||||
[139] = https://curl.se/bug/?i=21093
|
||||
[140] = https://curl.se/bug/?i=21096
|
||||
[141] = https://curl.se/bug/?i=21201
|
||||
[142] = https://curl.se/bug/?i=21265
|
||||
[143] = https://curl.se/bug/?i=21084
|
||||
[144] = https://curl.se/bug/?i=20936
|
||||
[145] = https://curl.se/bug/?i=21082
|
||||
[146] = https://curl.se/bug/?i=21092
|
||||
[147] = https://curl.se/bug/?i=21090
|
||||
[148] = https://curl.se/bug/?i=21078
|
||||
[149] = https://curl.se/bug/?i=21077
|
||||
[150] = https://curl.se/bug/?i=21086
|
||||
[151] = https://curl.se/bug/?i=21080
|
||||
[152] = https://curl.se/bug/?i=21083
|
||||
[153] = https://curl.se/bug/?i=20672
|
||||
[154] = https://curl.se/bug/?i=21274
|
||||
[155] = https://curl.se/bug/?i=21150
|
||||
[156] = https://curl.se/bug/?i=21263
|
||||
[157] = https://curl.se/bug/?i=21159
|
||||
[158] = https://curl.se/bug/?i=21144
|
||||
[159] = https://curl.se/bug/?i=21135
|
||||
[160] = https://curl.se/bug/?i=21203
|
||||
[161] = https://curl.se/bug/?i=21194
|
||||
[162] = https://curl.se/bug/?i=21402
|
||||
[163] = https://curl.se/bug/?i=21134
|
||||
[164] = https://curl.se/bug/?i=21193
|
||||
[165] = https://curl.se/bug/?i=21152
|
||||
[166] = https://curl.se/bug/?i=21143
|
||||
[167] = https://curl.se/bug/?i=21147
|
||||
[168] = https://curl.se/bug/?i=21127
|
||||
[169] = https://curl.se/bug/?i=21139
|
||||
[170] = https://curl.se/bug/?i=21136
|
||||
[171] = https://curl.se/bug/?i=21141
|
||||
[172] = https://curl.se/bug/?i=21137
|
||||
[173] = https://curl.se/bug/?i=21198
|
||||
[174] = https://curl.se/bug/?i=21256
|
||||
[175] = https://curl.se/bug/?i=21256
|
||||
[176] = https://curl.se/bug/?i=21175
|
||||
[177] = https://curl.se/bug/?i=21190
|
||||
[178] = https://curl.se/bug/?i=21122
|
||||
[179] = https://curl.se/bug/?i=21123
|
||||
[180] = https://curl.se/bug/?i=21121
|
||||
[181] = https://curl.se/bug/?i=21113
|
||||
[182] = https://curl.se/bug/?i=21251
|
||||
[183] = https://curl.se/bug/?i=21183
|
||||
[184] = https://curl.se/bug/?i=21119
|
||||
[185] = https://curl.se/bug/?i=21188
|
||||
[186] = https://curl.se/bug/?i=21112
|
||||
[187] = https://curl.se/bug/?i=21187
|
||||
[188] = https://curl.se/bug/?i=21186
|
||||
[189] = https://curl.se/bug/?i=21185
|
||||
[190] = https://curl.se/bug/?i=21182
|
||||
[191] = https://curl.se/bug/?i=21252
|
||||
[192] = https://curl.se/bug/?i=21453
|
||||
[193] = https://curl.se/bug/?i=21290
|
||||
[194] = https://curl.se/bug/?i=21174
|
||||
[195] = https://curl.se/bug/?i=21399
|
||||
[196] = https://curl.se/bug/?i=21168
|
||||
[197] = https://curl.se/bug/?i=21173
|
||||
[198] = https://curl.se/bug/?i=20995
|
||||
[199] = https://curl.se/bug/?i=21238
|
||||
[200] = https://curl.se/bug/?i=21247
|
||||
[201] = https://curl.se/bug/?i=21234
|
||||
[202] = https://curl.se/bug/?i=21246
|
||||
[203] = https://curl.se/bug/?i=21242
|
||||
[204] = https://curl.se/bug/?i=21345
|
||||
[206] = https://curl.se/bug/?i=21231
|
||||
[207] = https://curl.se/bug/?i=21281
|
||||
[208] = https://curl.se/bug/?i=20715
|
||||
[209] = https://curl.se/bug/?i=21393
|
||||
[210] = https://curl.se/bug/?i=21235
|
||||
[211] = https://curl.se/bug/?i=21232
|
||||
[212] = https://curl.se/bug/?i=21230
|
||||
[213] = https://curl.se/bug/?i=21328
|
||||
[214] = https://curl.se/bug/?i=21228
|
||||
[215] = https://curl.se/bug/?i=21229
|
||||
[216] = https://curl.se/bug/?i=21224
|
||||
[217] = https://curl.se/bug/?i=21225
|
||||
[218] = https://curl.se/bug/?i=21339
|
||||
[219] = https://curl.se/bug/?i=21221
|
||||
[220] = https://curl.se/bug/?i=21205
|
||||
[221] = https://curl.se/bug/?i=21253
|
||||
[222] = https://curl.se/bug/?i=21216
|
||||
[223] = https://curl.se/bug/?i=21218
|
||||
[224] = https://curl.se/bug/?i=21217
|
||||
[225] = https://curl.se/bug/?i=21336
|
||||
[226] = https://curl.se/bug/?i=21335
|
||||
[227] = https://curl.se/bug/?i=21236
|
||||
[228] = https://curl.se/bug/?i=21215
|
||||
[229] = https://curl.se/bug/?i=21267
|
||||
[230] = https://curl.se/bug/?i=21394
|
||||
[231] = https://curl.se/bug/?i=21222
|
||||
[232] = https://curl.se/bug/?i=21266
|
||||
[233] = https://curl.se/bug/?i=21392
|
||||
[234] = https://curl.se/bug/?i=21437
|
||||
[235] = https://curl.se/bug/?i=21461
|
||||
[236] = https://curl.se/bug/?i=21322
|
||||
[237] = https://curl.se/bug/?i=21388
|
||||
[238] = https://curl.se/bug/?i=21354
|
||||
[239] = https://curl.se/bug/?i=21386
|
||||
[240] = https://curl.se/bug/?i=21385
|
||||
[241] = https://curl.se/bug/?i=21384
|
||||
[242] = https://curl.se/bug/?i=21312
|
||||
[243] = https://curl.se/bug/?i=21383
|
||||
[244] = https://curl.se/bug/?i=21297
|
||||
[245] = https://curl.se/bug/?i=21313
|
||||
[246] = https://curl.se/bug/?i=21304
|
||||
[247] = https://curl.se/bug/?i=21296
|
||||
[248] = https://curl.se/bug/?i=21296
|
||||
[249] = https://curl.se/bug/?i=21441
|
||||
[250] = https://curl.se/bug/?i=21444
|
||||
[251] = https://curl.se/bug/?i=21302
|
||||
[252] = https://curl.se/bug/?i=21380
|
||||
[253] = https://curl.se/bug/?i=21378
|
||||
[254] = https://curl.se/bug/?i=20794
|
||||
[255] = https://curl.se/bug/?i=21377
|
||||
[256] = https://curl.se/bug/?i=21301
|
||||
[257] = https://curl.se/bug/?i=21303
|
||||
[258] = https://curl.se/bug/?i=21372
|
||||
[259] = https://curl.se/bug/?i=21146
|
||||
[260] = https://curl.se/bug/?i=21298
|
||||
[261] = https://curl.se/bug/?i=21270
|
||||
[262] = https://curl.se/bug/?i=21440
|
||||
[263] = https://curl.se/bug/?i=21460
|
||||
[264] = https://curl.se/bug/?i=21360
|
||||
[265] = https://curl.se/bug/?i=21458
|
||||
[266] = https://curl.se/bug/?i=21364
|
||||
[267] = https://curl.se/bug/?i=21363
|
||||
[268] = https://curl.se/bug/?i=21357
|
||||
[269] = https://curl.se/bug/?i=21359
|
||||
[270] = https://curl.se/bug/?i=21358
|
||||
[273] = https://curl.se/bug/?i=21455
|
||||
[274] = https://curl.se/bug/?i=21351
|
||||
[275] = https://curl.se/bug/?i=21340
|
||||
[276] = https://curl.se/bug/?i=21449
|
||||
[278] = https://curl.se/bug/?i=21432
|
||||
[279] = https://curl.se/bug/?i=21430
|
||||
[280] = https://curl.se/bug/?i=21427
|
||||
[284] = https://curl.se/bug/?i=21396
|
||||
[285] = https://curl.se/bug/?i=21421
|
||||
[288] = https://curl.se/bug/?i=19814
|
||||
[291] = https://curl.se/bug/?i=21415
|
||||
[294] = https://curl.se/bug/?i=21411
|
||||
97
Agent-Windows/OGP64/usr/share/doc/curl/SSL-PROBLEMS.md
Normal file
97
Agent-Windows/OGP64/usr/share/doc/curl/SSL-PROBLEMS.md
Normal file
|
|
@ -0,0 +1,97 @@
|
|||
<!--
|
||||
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
|
||||
SPDX-License-Identifier: curl
|
||||
-->
|
||||
|
||||
# SSL problems
|
||||
|
||||
First, let's establish that we often refer to TLS and SSL interchangeably as
|
||||
SSL here. The current protocol is called TLS, it was called SSL a long time
|
||||
ago.
|
||||
|
||||
There are several known reasons why a connection that involves SSL might
|
||||
fail. This is a document that attempts to detail the most common ones and
|
||||
how to mitigate them.
|
||||
|
||||
## CA certs
|
||||
|
||||
CA certs are used to digitally verify the server's certificate. You need a
|
||||
"ca bundle" for this. See lots of more details on this in the `SSLCERTS`
|
||||
document.
|
||||
|
||||
## CA bundle missing intermediate certificates
|
||||
|
||||
When using said CA bundle to verify a server cert, you may experience
|
||||
problems if your CA store does not contain the certificates for the
|
||||
intermediates if the server does not provide them.
|
||||
|
||||
The TLS protocol mandates that the intermediate certificates are sent in the
|
||||
handshake, but as browsers have ways to survive or work around such
|
||||
omissions, missing intermediates in TLS handshakes still happen that browser
|
||||
users do not notice.
|
||||
|
||||
Browsers work around this problem in two ways: they cache intermediate
|
||||
certificates from previous transfers and some implement the TLS "AIA"
|
||||
extension that lets the client explicitly download such certificates on
|
||||
demand.
|
||||
|
||||
## Protocol version
|
||||
|
||||
Some broken servers fail to support the protocol negotiation properly that
|
||||
SSL servers are supposed to handle. This may cause the connection to fail
|
||||
completely. Sometimes you may need to explicitly select an SSL version to
|
||||
use when connecting to make the connection succeed.
|
||||
|
||||
An additional complication can be that modern SSL libraries sometimes are
|
||||
built with support for older SSL and TLS versions disabled.
|
||||
|
||||
All versions of SSL and the TLS versions before 1.2 are considered insecure
|
||||
and should be avoided. Use TLS 1.2 or later.
|
||||
|
||||
## Ciphers
|
||||
|
||||
Clients give servers a list of ciphers to select from. If the list does not
|
||||
include any ciphers the server wants/can use, the connection handshake
|
||||
fails.
|
||||
|
||||
curl has recently disabled the user of a whole bunch of seriously insecure
|
||||
ciphers from its default set (slightly depending on SSL backend in use).
|
||||
|
||||
You may have to explicitly provide an alternative list of ciphers for curl
|
||||
to use to allow the server to use a weak cipher for you.
|
||||
|
||||
Note that these weak ciphers are identified as flawed. For example, this
|
||||
includes symmetric ciphers with less than 128-bit keys and RC4.
|
||||
|
||||
Schannel in Windows XP is not able to connect to servers that no longer
|
||||
support the legacy handshakes and algorithms used by those versions, so we
|
||||
advise against building curl to use Schannel on really old Windows versions.
|
||||
|
||||
Reference: [Prohibiting RC4 Cipher
|
||||
Suites](https://datatracker.ietf.org/doc/html/draft-popov-tls-prohibiting-rc4-01)
|
||||
|
||||
## Allow BEAST
|
||||
|
||||
BEAST is the name of a TLS 1.0 attack that surfaced 2011. When adding means
|
||||
to mitigate this attack, it turned out that some broken servers out there in
|
||||
the wild did not work properly with the BEAST mitigation in place.
|
||||
|
||||
To make such broken servers work, the --ssl-allow-beast option was
|
||||
introduced. Exactly as it sounds, it re-introduces the BEAST vulnerability
|
||||
but on the other hand it allows curl to connect to that kind of strange
|
||||
servers.
|
||||
|
||||
## Disabling certificate revocation checks
|
||||
|
||||
Some SSL backends may do certificate revocation checks (CRL, OCSP, etc)
|
||||
depending on the OS or build configuration. The --ssl-no-revoke option was
|
||||
introduced in 7.44.0 to disable revocation checking but currently is only
|
||||
supported for Schannel (the native Windows SSL library), with an exception
|
||||
in the case of Windows' Untrusted Publishers block list which it seems cannot
|
||||
be bypassed. This option may have broader support to accommodate other SSL
|
||||
backends in the future.
|
||||
|
||||
References:
|
||||
|
||||
https://curl.se/docs/ssl-compared.html
|
||||
155
Agent-Windows/OGP64/usr/share/doc/curl/SSLCERTS.md
Normal file
155
Agent-Windows/OGP64/usr/share/doc/curl/SSLCERTS.md
Normal file
|
|
@ -0,0 +1,155 @@
|
|||
<!--
|
||||
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
|
||||
SPDX-License-Identifier: curl
|
||||
-->
|
||||
|
||||
# TLS Certificate Verification
|
||||
|
||||
## Native vs file based
|
||||
|
||||
If curl was built with Schannel support, then curl uses the Windows native CA
|
||||
store for verification. On Apple operating systems, it is possible to use Apple's
|
||||
"SecTrust" services for certain TLS backends, details below.
|
||||
All other TLS libraries use a file based CA store by
|
||||
default.
|
||||
|
||||
## Verification
|
||||
|
||||
Every trusted server certificate is digitally signed by a Certificate
|
||||
Authority, a CA.
|
||||
|
||||
In your local CA store you have a collection of certificates from *trusted*
|
||||
certificate authorities that TLS clients like curl use to verify servers.
|
||||
|
||||
curl does certificate verification by default. This is done by verifying the
|
||||
signature and making sure the certificate was crafted for the server name
|
||||
provided in the URL.
|
||||
|
||||
If you communicate with HTTPS, FTPS or other TLS-using servers using
|
||||
certificates signed by a CA whose certificate is present in the store, you can
|
||||
be sure that the remote server really is the one it claims to be.
|
||||
|
||||
If the remote server uses a self-signed certificate, if you do not install a
|
||||
CA cert store, if the server uses a certificate signed by a CA that is not
|
||||
included in the store you use or if the remote host is an impostor
|
||||
impersonating your favorite site, the certificate check fails and reports an
|
||||
error.
|
||||
|
||||
If you think it wrongly failed the verification, consider one of the following
|
||||
sections.
|
||||
|
||||
### Skip verification
|
||||
|
||||
Tell curl to *not* verify the peer with `-k`/`--insecure`.
|
||||
|
||||
We **strongly** recommend this is avoided and that even if you end up doing
|
||||
this for experimentation or development, **never** skip verification in
|
||||
production.
|
||||
|
||||
### Use a custom CA store
|
||||
|
||||
Get a CA certificate that can verify the remote server and use the proper
|
||||
option to point out this CA cert for verification when connecting - for this
|
||||
specific transfer only.
|
||||
|
||||
With the curl command line tool: `--cacert [file]`
|
||||
|
||||
If you use the curl command line tool without a native CA store, then you can
|
||||
specify your own CA cert file by setting the environment variable
|
||||
`CURL_CA_BUNDLE` to the path of your choice. `SSL_CERT_FILE` and `SSL_CERT_DIR`
|
||||
are also supported.
|
||||
|
||||
If you are using the curl command line tool on Windows, curl searches for a CA
|
||||
cert file named `curl-ca-bundle.crt` in these directories and in this order:
|
||||
1. application's directory
|
||||
2. current working directory
|
||||
3. Windows System directory (e.g. C:\Windows\System32)
|
||||
4. Windows Directory (e.g. C:\Windows)
|
||||
5. all directories along %PATH%
|
||||
|
||||
curl 8.11.0 added a build-time option to disable this search behavior, and
|
||||
another option to restrict search to the application's directory.
|
||||
|
||||
### Use the native store
|
||||
|
||||
In several environments, in particular on Microsoft and Apple operating
|
||||
systems, you can ask curl to use the system's native CA store when verifying
|
||||
the certificate. Depending on how curl was built, this may already be the
|
||||
default.
|
||||
|
||||
With the curl command line tool: `--ca-native`.
|
||||
|
||||
### Modify the CA store
|
||||
|
||||
Add the CA cert for your server to the existing default CA certificate store.
|
||||
|
||||
Usually you can figure out the path to the local CA store by looking at the
|
||||
verbose output that `curl -v` shows when you connect to an HTTPS site.
|
||||
|
||||
### Change curl's default CA store
|
||||
|
||||
The default CA certificate store curl uses is set at build time. When you
|
||||
build curl you can point out your preferred path.
|
||||
|
||||
### Extract CA cert from a server
|
||||
|
||||
curl -w %{certs} https://example.com > cacert.pem
|
||||
|
||||
The certificate has `BEGIN CERTIFICATE` and `END CERTIFICATE` markers.
|
||||
|
||||
### Get the Mozilla CA store
|
||||
|
||||
Download a version of the Firefox CA store converted to PEM format on the [CA
|
||||
Extract](https://curl.se/docs/caextract.html) page. It always features the
|
||||
latest Firefox bundle.
|
||||
|
||||
## Native CA store
|
||||
|
||||
### Windows + Schannel
|
||||
|
||||
If curl was built with Schannel, then curl uses the certificates that are
|
||||
built into the OS. These are the same certificates that appear in the
|
||||
Internet Options control panel (under Windows).
|
||||
Any custom security rules for certificates are honored.
|
||||
|
||||
Schannel runs CRL checks on certificates unless peer verification is disabled.
|
||||
|
||||
### Apple + OpenSSL/GnuTLS
|
||||
|
||||
When curl is built with Apple SecTrust enabled and uses an OpenSSL compatible
|
||||
TLS backend or GnuTLS, the default verification is handled by that Apple
|
||||
service. As in:
|
||||
|
||||
curl https://example.com
|
||||
|
||||
You may still provide your own certificates on the command line, such as:
|
||||
|
||||
curl --cacert mycerts.pem https://example.com
|
||||
|
||||
In this situation, Apple SecTrust is **not** used and verification is done
|
||||
**only** with the trust anchors found in `mycerts.pem`. If you want **both**
|
||||
Apple SecTrust and your own file to be considered, use:
|
||||
|
||||
curl --ca-native --cacert mycerts.pem https://example.com
|
||||
|
||||
#### Other Combinations
|
||||
|
||||
How well the use of native CA stores work in all other combinations depends
|
||||
on the TLS backend and the OS. Many TLS backends offer functionality to access
|
||||
the native CA on a range of operating systems. Some provide this only on specific
|
||||
configurations.
|
||||
|
||||
Specific support in curl exists for Windows and OpenSSL compatible TLS backends.
|
||||
It tries to load the certificates from the Windows "CA" and "ROOT" stores for
|
||||
transfers requesting the native CA. Due to Window's delayed population of those
|
||||
stores, this might not always find all certificates.
|
||||
|
||||
## HTTPS proxy
|
||||
|
||||
curl can do HTTPS to the proxy separately from the connection to the server.
|
||||
This TLS connection is handled and verified separately from the server
|
||||
connection so instead of `--insecure` and `--cacert` to control the
|
||||
certificate verification, you use `--proxy-insecure` and `--proxy-cacert`.
|
||||
With these options, you make sure that the TLS connection and the trust of the
|
||||
proxy can be kept totally separate from the TLS connection to the server.
|
||||
708
Agent-Windows/OGP64/usr/share/doc/curl/TheArtOfHttpScripting.md
Normal file
708
Agent-Windows/OGP64/usr/share/doc/curl/TheArtOfHttpScripting.md
Normal file
|
|
@ -0,0 +1,708 @@
|
|||
<!--
|
||||
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
|
||||
SPDX-License-Identifier: curl
|
||||
-->
|
||||
|
||||
# The Art Of Scripting HTTP Requests Using curl
|
||||
|
||||
## Background
|
||||
|
||||
This document assumes that you are familiar with HTML and general networking.
|
||||
|
||||
The increasing amount of applications moving to the web has made "HTTP
|
||||
Scripting" more frequently requested and wanted. To be able to automatically
|
||||
extract information from the web, to fake users, to post or upload data to
|
||||
web servers are all important tasks today.
|
||||
|
||||
curl is a command line tool for doing all sorts of URL manipulations and
|
||||
transfers, but this particular document focuses on how to use it when doing
|
||||
HTTP requests for fun and profit. This documents assumes that you know how to
|
||||
invoke `curl --help` or `curl --manual` to get basic information about it.
|
||||
|
||||
curl is not written to do everything for you. It makes the requests, it gets
|
||||
the data, it sends data and it retrieves the information. You probably need
|
||||
to glue everything together using some kind of script language or repeated
|
||||
manual invokes.
|
||||
|
||||
## The HTTP Protocol
|
||||
|
||||
HTTP is the protocol used to fetch data from web servers. It is a simple
|
||||
protocol that is built upon TCP/IP. The protocol also allows information to
|
||||
get sent to the server from the client using a few different methods, as is
|
||||
shown here.
|
||||
|
||||
HTTP is plain ASCII text lines being sent by the client to a server to
|
||||
request a particular action, and then the server replies a few text lines
|
||||
before the actual requested content is sent to the client.
|
||||
|
||||
The client, curl, sends an HTTP request. The request contains a method (like
|
||||
GET, POST, HEAD etc), a number of request headers and sometimes a request
|
||||
body. The HTTP server responds with a status line (indicating if things went
|
||||
well), response headers and most often also a response body. The "body" part
|
||||
is the plain data you requested, like the actual HTML or the image etc.
|
||||
|
||||
## See the Protocol
|
||||
|
||||
Using curl's option [`--verbose`](https://curl.se/docs/manpage.html#-v) (`-v`
|
||||
as a short option) displays what kind of commands curl sends to the server,
|
||||
as well as a few other informational texts.
|
||||
|
||||
`--verbose` is the single most useful option when it comes to debug or even
|
||||
understand the curl<->server interaction.
|
||||
|
||||
Sometimes even `--verbose` is not enough. Then
|
||||
[`--trace`](https://curl.se/docs/manpage.html#-trace) and
|
||||
[`--trace-ascii`](https://curl.se/docs/manpage.html#--trace-ascii)
|
||||
offer even more details as they show **everything** curl sends and
|
||||
receives. Use it like this:
|
||||
|
||||
curl --trace-ascii debugdump.txt https://www.example.com/
|
||||
|
||||
## See the Timing
|
||||
|
||||
Many times you may wonder what exactly is taking all the time, or you want to
|
||||
know the amount of milliseconds between two points in a transfer. For those,
|
||||
and other similar situations, the
|
||||
[`--trace-time`](https://curl.se/docs/manpage.html#--trace-time) option is
|
||||
what you need. It prepends the time to each trace output line:
|
||||
|
||||
curl --trace-ascii d.txt --trace-time https://example.com/
|
||||
|
||||
## See which Transfer
|
||||
|
||||
When doing parallel transfers, it is relevant to see which transfer is doing
|
||||
what. When response headers are received (and logged) you need to know which
|
||||
transfer these are for.
|
||||
[`--trace-ids`](https://curl.se/docs/manpage.html#--trace-ids) option is what
|
||||
you need. It prepends the transfer and connection identifier to each trace
|
||||
output line:
|
||||
|
||||
curl --trace-ascii d.txt --trace-ids https://example.com/
|
||||
|
||||
## See the Response
|
||||
|
||||
By default curl sends the response to stdout. You need to redirect it
|
||||
somewhere to avoid that, most often that is done with `-o` or `-O`.
|
||||
|
||||
# URL
|
||||
|
||||
## Spec
|
||||
|
||||
The Uniform Resource Locator format is how you specify the address of a
|
||||
particular resource on the Internet. You know these, you have seen URLs like
|
||||
https://curl.se/ or https://example.com/ a million times. RFC 3986 is the
|
||||
canonical spec. The formal name is not URL, it is **URI**.
|
||||
|
||||
## Host
|
||||
|
||||
The hostname is usually resolved using DNS or your /etc/hosts file to an IP
|
||||
address and that is what curl communicates with. Alternatively you specify
|
||||
the IP address directly in the URL instead of a name.
|
||||
|
||||
For development and other trying out situations, you can point to a different
|
||||
IP address for a hostname than what would otherwise be used, by using curl's
|
||||
[`--resolve`](https://curl.se/docs/manpage.html#--resolve) option:
|
||||
|
||||
curl --resolve www.example.org:80:127.0.0.1 https://www.example.org/
|
||||
|
||||
## Port number
|
||||
|
||||
Each protocol curl supports operates on a default port number, be it over TCP
|
||||
or in some cases UDP. Normally you do not have to take that into
|
||||
consideration, but at times you run test servers on other ports or
|
||||
similar. Then you can specify the port number in the URL with a colon and a
|
||||
number immediately following the hostname. Like when doing HTTP to port
|
||||
1234:
|
||||
|
||||
curl https://www.example.org:1234/
|
||||
|
||||
The port number you specify in the URL is the number that the server uses to
|
||||
offer its services. Sometimes you may use a proxy, and then you may
|
||||
need to specify that proxy's port number separately from what curl needs to
|
||||
connect to the server. Like when using an HTTP proxy on port 4321:
|
||||
|
||||
curl --proxy http://proxy.example.org:4321 https://remote.example.org/
|
||||
|
||||
## Username and password
|
||||
|
||||
Some services are setup to require HTTP authentication and then you need to
|
||||
provide name and password which is then transferred to the remote site in
|
||||
various ways depending on the exact authentication protocol used.
|
||||
|
||||
You can opt to either insert the user and password in the URL or you can
|
||||
provide them separately:
|
||||
|
||||
curl https://user:password@example.org/
|
||||
|
||||
or
|
||||
|
||||
curl -u user:password https://example.org/
|
||||
|
||||
You need to pay attention that this kind of HTTP authentication is not what
|
||||
is usually done and requested by user-oriented websites these days. They tend
|
||||
to use forms and cookies instead.
|
||||
|
||||
## Path part
|
||||
|
||||
The path part is sent off to the server to request that it sends back the
|
||||
associated response. The path is what is to the right side of the slash that
|
||||
follows the hostname and possibly port number.
|
||||
|
||||
# Fetch a page
|
||||
|
||||
## GET
|
||||
|
||||
The simplest and most common request/operation made using HTTP is to GET a
|
||||
URL. The URL could itself refer to a webpage, an image or a file. The client
|
||||
issues a GET request to the server and receives the document it asked for.
|
||||
If you issue the command line
|
||||
|
||||
curl https://curl.se/
|
||||
|
||||
you get a webpage returned in your terminal window. The entire HTML document
|
||||
this URL identifies.
|
||||
|
||||
All HTTP replies contain a set of response headers that are normally hidden,
|
||||
use curl's [`--include`](https://curl.se/docs/manpage.html#-i) (`-i`)
|
||||
option to display them as well as the rest of the document.
|
||||
|
||||
## HEAD
|
||||
|
||||
You can ask the remote server for ONLY the headers by using the
|
||||
[`--head`](https://curl.se/docs/manpage.html#-I) (`-I`) option which makes
|
||||
curl issue a HEAD request. In some special cases servers deny the HEAD method
|
||||
while others still work, which is a particular kind of annoyance.
|
||||
|
||||
The HEAD method is defined and made so that the server returns the headers
|
||||
exactly the way it would do for a GET, but without a body. It means that you
|
||||
may see a `Content-Length:` in the response headers, but there must not be an
|
||||
actual body in the HEAD response.
|
||||
|
||||
## Multiple URLs in a single command line
|
||||
|
||||
A single curl command line may involve one or many URLs. The most common case
|
||||
is probably to use one, but you can specify any amount of URLs. Yes any. No
|
||||
limits. You then get requests repeated over and over for all the given URLs.
|
||||
|
||||
Example, send two GET requests:
|
||||
|
||||
curl https://url1.example.com https://url2.example.com
|
||||
|
||||
If you use [`--data`](https://curl.se/docs/manpage.html#-d) to POST to
|
||||
the URL, using multiple URLs means that you send that same POST to all the
|
||||
given URLs.
|
||||
|
||||
Example, send two POSTs:
|
||||
|
||||
curl --data name=curl https://url1.example.com https://url2.example.com
|
||||
|
||||
## Multiple HTTP methods in a single command line
|
||||
|
||||
Sometimes you need to operate on several URLs in a single command line and do
|
||||
different HTTP methods on each. For this, you might enjoy the
|
||||
[`--next`](https://curl.se/docs/manpage.html#-:) option. It is a separator
|
||||
that separates a bunch of options from the next. All the URLs before `--next`
|
||||
get the same method and get all the POST data merged into one.
|
||||
|
||||
When curl reaches the `--next` on the command line, it resets the method and
|
||||
the POST data and allow a new set.
|
||||
|
||||
Perhaps this is best shown with a few examples. To send first a HEAD and then
|
||||
a GET:
|
||||
|
||||
curl -I https://example.com --next https://example.com
|
||||
|
||||
To first send a POST and then a GET:
|
||||
|
||||
curl -d score=10 https://example.com/post.cgi --next https://example.com/results.html
|
||||
|
||||
# HTML forms
|
||||
|
||||
## Forms explained
|
||||
|
||||
Forms are the general way a website can present an HTML page with fields for
|
||||
the user to enter data in, and then press some kind of 'OK' or 'Submit'
|
||||
button to get that data sent to the server. The server then typically uses
|
||||
the posted data to decide how to act. Like using the entered words to search
|
||||
in a database, or to add the info in a bug tracking system, display the
|
||||
entered address on a map or using the info as a login-prompt verifying that
|
||||
the user is allowed to see what it is about to see.
|
||||
|
||||
Of course there has to be some kind of program on the server end to receive
|
||||
the data you send. You cannot invent something out of the air.
|
||||
|
||||
## GET
|
||||
|
||||
A GET-form uses the method GET, as specified in HTML like:
|
||||
|
||||
```html
|
||||
<form method="GET" action="junk.cgi">
|
||||
<input type=text name="birthyear">
|
||||
<input type=submit name=press value="OK">
|
||||
</form>
|
||||
```
|
||||
|
||||
In your favorite browser, this form appears with a text box to fill in and a
|
||||
press-button labeled "OK". If you fill in '1905' and press the OK button,
|
||||
your browser then creates a new URL to get for you. The URL gets
|
||||
`junk.cgi?birthyear=1905&press=OK` appended to the path part of the previous
|
||||
URL.
|
||||
|
||||
If the original form was seen on the page `www.example.com/when/birth.html`,
|
||||
the second page you get becomes
|
||||
`www.example.com/when/junk.cgi?birthyear=1905&press=OK`.
|
||||
|
||||
Most search engines work this way.
|
||||
|
||||
To make curl do the GET form post for you, enter the expected created URL:
|
||||
|
||||
curl "https://www.example.com/when/junk.cgi?birthyear=1905&press=OK"
|
||||
|
||||
## POST
|
||||
|
||||
The GET method makes all input field names get displayed in the URL field of
|
||||
your browser. That is generally a good thing when you want to be able to
|
||||
bookmark that page with your given data, but it is an obvious disadvantage if
|
||||
you entered secret information in one of the fields or if there are a large
|
||||
amount of fields creating a long and unreadable URL.
|
||||
|
||||
The HTTP protocol then offers the POST method. This way the client sends the
|
||||
data separated from the URL and thus you do not see any of it in the URL
|
||||
address field.
|
||||
|
||||
The form would look similar to the previous one:
|
||||
|
||||
```html
|
||||
<form method="POST" action="junk.cgi">
|
||||
<input type=text name="birthyear">
|
||||
<input type=submit name=press value=" OK ">
|
||||
</form>
|
||||
```
|
||||
|
||||
To use curl to post this form with the same data filled in as before, we
|
||||
could do it like:
|
||||
|
||||
curl --data "birthyear=1905&press=%20OK%20" https://www.example.com/when/junk.cgi
|
||||
|
||||
This kind of POST uses the Content-Type `application/x-www-form-urlencoded`
|
||||
and is the most widely used POST kind.
|
||||
|
||||
The data you send to the server MUST already be properly encoded, curl does
|
||||
not do that for you. For example, if you want the data to contain a space,
|
||||
you need to replace that space with `%20`, etc. Failing to comply with this
|
||||
most likely causes your data to be received wrongly and messed up.
|
||||
|
||||
Recent curl versions can in fact URL encode POST data for you, like this:
|
||||
|
||||
curl --data-urlencode "name=I am Daniel" https://www.example.com
|
||||
|
||||
If you repeat `--data` several times on the command line, curl concatenates
|
||||
all the given data pieces - and put a `&` symbol between each data segment.
|
||||
|
||||
## File Upload POST
|
||||
|
||||
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
|
||||
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:
|
||||
|
||||
<form method="POST" enctype='multipart/form-data' action="upload.cgi">
|
||||
<input name=upload type=file>
|
||||
<input type=submit name=press value="OK">
|
||||
</form>
|
||||
|
||||
This clearly shows that the Content-Type about to be sent is
|
||||
`multipart/form-data`.
|
||||
|
||||
To post to a form like this with curl, you enter a command line like:
|
||||
|
||||
curl --form upload=@localfilename --form press=OK [URL]
|
||||
|
||||
## Hidden Fields
|
||||
|
||||
A common way for HTML based applications to pass state information between
|
||||
pages is to add hidden fields to the forms. Hidden fields are already filled
|
||||
in, they are not displayed to the user and they get passed along as all the
|
||||
other fields.
|
||||
|
||||
A similar example form with one visible field, one hidden field and one
|
||||
submit button could look like:
|
||||
|
||||
```html
|
||||
<form method="POST" action="foobar.cgi">
|
||||
<input type=text name="birthyear">
|
||||
<input type=hidden name="person" value="daniel">
|
||||
<input type=submit name="press" value="OK">
|
||||
</form>
|
||||
```
|
||||
|
||||
To POST this with curl, you do not have to think about if the fields are
|
||||
hidden or not. To curl they are all the same:
|
||||
|
||||
curl --data "birthyear=1905&press=OK&person=daniel" [URL]
|
||||
|
||||
## Figure Out What A POST Looks Like
|
||||
|
||||
When you are about to fill in a form and send it to a server by using curl
|
||||
instead of a browser, you are of course interested in sending a POST exactly
|
||||
the way your browser does.
|
||||
|
||||
An easy way to get to see this, is to save the HTML page with the form on
|
||||
your local disk, modify the 'method' to a GET, and press the submit button
|
||||
(you could also change the action URL if you want to).
|
||||
|
||||
You then clearly see the data get appended to the URL, separated with a
|
||||
`?`-letter as GET forms are supposed to.
|
||||
|
||||
# HTTP upload
|
||||
|
||||
## PUT
|
||||
|
||||
Perhaps the best way to upload data to an HTTP server is to use PUT. Then
|
||||
again, this of course requires that someone put a program or script on the
|
||||
server end that knows how to receive an HTTP PUT stream.
|
||||
|
||||
Put a file to an HTTP server with curl:
|
||||
|
||||
curl --upload-file uploadfile https://www.example.com/receive.cgi
|
||||
|
||||
# HTTP Authentication
|
||||
|
||||
## Basic Authentication
|
||||
|
||||
HTTP Authentication is the ability to tell the server your username and
|
||||
password so that it can verify that you are allowed to do the request you are
|
||||
doing. The Basic authentication used in HTTP (which is the type curl uses by
|
||||
default) is **plain text** based, which means it sends username and password
|
||||
only slightly obfuscated, but still fully readable by anyone that sniffs on
|
||||
the network between you and the remote server.
|
||||
|
||||
To tell curl to use a user and password for authentication:
|
||||
|
||||
curl --user myname:password https://www.example.com
|
||||
|
||||
## Other Authentication
|
||||
|
||||
The site might require a different authentication method (check the headers
|
||||
returned by the server), and then
|
||||
[`--ntlm`](https://curl.se/docs/manpage.html#--ntlm),
|
||||
[`--digest`](https://curl.se/docs/manpage.html#--digest),
|
||||
[`--negotiate`](https://curl.se/docs/manpage.html#--negotiate) or even
|
||||
[`--anyauth`](https://curl.se/docs/manpage.html#--anyauth) might be
|
||||
options that suit you.
|
||||
|
||||
## Proxy Authentication
|
||||
|
||||
Sometimes your HTTP access is only available through the use of an HTTP
|
||||
proxy. This seems to be especially common at various companies. An HTTP proxy
|
||||
may require its own user and password to allow the client to get through to
|
||||
the Internet. To specify those with curl, run something like:
|
||||
|
||||
curl --proxy-user proxyuser:proxypassword curl.se
|
||||
|
||||
If your proxy requires the authentication to be done using the NTLM method,
|
||||
use [`--proxy-ntlm`](https://curl.se/docs/manpage.html#--proxy-ntlm), if
|
||||
it requires Digest use
|
||||
[`--proxy-digest`](https://curl.se/docs/manpage.html#--proxy-digest).
|
||||
|
||||
If you use any one of these user+password options but leave out the password
|
||||
part, curl prompts for the password interactively.
|
||||
|
||||
## Hiding credentials
|
||||
|
||||
Do note that when a program is run, its parameters might be possible to see
|
||||
when listing the running processes of the system. Thus, other users may be
|
||||
able to watch your passwords if you pass them as plain command line
|
||||
options. There are ways to circumvent this.
|
||||
|
||||
It is worth noting that while this is how HTTP Authentication works, many
|
||||
websites do not use this concept when they provide logins etc. See the Web
|
||||
Login chapter further below for more details on that.
|
||||
|
||||
# More HTTP Headers
|
||||
|
||||
## Referer
|
||||
|
||||
An HTTP request may include a 'referer' field (yes it is misspelled), which
|
||||
can be used to tell from which URL the client got to this particular
|
||||
resource. Some programs/scripts check the referer field of requests to verify
|
||||
that this was not arriving from an external site or an unknown page. While
|
||||
this is a stupid way to check something so easily forged, many scripts still
|
||||
do it. Using curl, you can put anything you want in the referer-field and
|
||||
thus more easily be able to fool the server into serving your request.
|
||||
|
||||
Use curl to set the referer field with:
|
||||
|
||||
curl --referer https://www.example.come https://www.example.com
|
||||
|
||||
## User Agent
|
||||
|
||||
Similar to the referer field, all HTTP requests may set the User-Agent
|
||||
field. It names what user agent (client) that is being used. Many
|
||||
applications use this information to decide how to display pages. Silly web
|
||||
programmers try to make different pages for users of different browsers to
|
||||
make them look the best possible for their particular browsers. They usually
|
||||
also do different kinds of JavaScript etc.
|
||||
|
||||
At times, you may learn that getting a page with curl does not return the
|
||||
same page that you see when getting the page with your browser. Then you know
|
||||
it is time to set the User Agent field to fool the server into thinking you
|
||||
are one of those browsers.
|
||||
|
||||
By default, curl uses curl/VERSION, such as User-Agent: curl/8.11.0.
|
||||
|
||||
To make curl look like Internet Explorer 5 on a Windows 2000 box:
|
||||
|
||||
curl --user-agent "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" [URL]
|
||||
|
||||
Or why not look like you are using Netscape 4.73 on an old Linux box:
|
||||
|
||||
curl --user-agent "Mozilla/4.73 [en] (X11; U; Linux 2.2.15 i686)" [URL]
|
||||
|
||||
## Redirects
|
||||
|
||||
## Location header
|
||||
|
||||
When a resource is requested from a server, the reply from the server may
|
||||
include a hint about where the browser should go next to find this page, or a
|
||||
new page keeping newly generated output. The header that tells the browser to
|
||||
redirect is `Location:`.
|
||||
|
||||
curl does not follow `Location:` headers by default, but displays such
|
||||
pages in the same manner it displays all HTTP replies. It does however
|
||||
feature an option that makes it attempt to follow the `Location:` pointers.
|
||||
|
||||
To tell curl to follow a Location:
|
||||
|
||||
curl --location https://www.example.com
|
||||
|
||||
If you use curl to POST to a site that immediately redirects you to another
|
||||
page, you can safely use [`--location`](https://curl.se/docs/manpage.html#-L)
|
||||
(`-L`) and `--data`/`--form` together. curl only uses POST in the first
|
||||
request, and then revert to GET in the following operations.
|
||||
|
||||
## Other redirects
|
||||
|
||||
Browsers typically support at least two other ways of redirects that curl
|
||||
does not: first the html may contain a meta refresh tag that asks the browser
|
||||
to load a specific URL after a set number of seconds, or it may use
|
||||
JavaScript to do it.
|
||||
|
||||
# Cookies
|
||||
|
||||
## Cookie Basics
|
||||
|
||||
The way the web browsers do "client side state control" is by using cookies.
|
||||
Cookies are names with associated contents. The cookies are sent to the client
|
||||
by the server. The server tells the client for what path and hostname it wants
|
||||
the cookie sent back, and it also sends an expiration date and a few more
|
||||
properties.
|
||||
|
||||
When a client communicates with a server with a name and path as previously
|
||||
specified in a received cookie, the client sends back the cookies and their
|
||||
contents to the server, unless of course they are expired.
|
||||
|
||||
Many applications and servers use this method to connect a series of requests
|
||||
into a single logical session. To be able to use curl in such occasions, we
|
||||
must be able to record and send back cookies the way the web application
|
||||
expects them. The same way browsers deal with them.
|
||||
|
||||
## Cookie options
|
||||
|
||||
The simplest way to send a few cookies to the server when getting a page with
|
||||
curl is to add them on the command line like:
|
||||
|
||||
curl --cookie "name=Daniel" https://www.example.com
|
||||
|
||||
Cookies are sent as common HTTP headers. This is practical as it allows curl
|
||||
to record cookies by recording headers. Record cookies with curl by
|
||||
using the [`--dump-header`](https://curl.se/docs/manpage.html#-D) (`-D`)
|
||||
option like:
|
||||
|
||||
curl --dump-header headers_and_cookies https://www.example.com
|
||||
|
||||
(Take note that the
|
||||
[`--cookie-jar`](https://curl.se/docs/manpage.html#-c) option described
|
||||
below is a better way to store cookies.)
|
||||
|
||||
curl has a full blown cookie parsing engine built-in that comes in use if you
|
||||
want to reconnect to a server and use cookies that were stored from a
|
||||
previous connection (or hand-crafted manually to fool the server into
|
||||
believing you had a previous connection). To use previously stored cookies,
|
||||
you run curl like:
|
||||
|
||||
curl --cookie stored_cookies_in_file https://www.example.com
|
||||
|
||||
curl's "cookie engine" gets enabled when you use the
|
||||
[`--cookie`](https://curl.se/docs/manpage.html#-b) option. If you only
|
||||
want curl to understand received cookies, use `--cookie` with a file that
|
||||
does not exist. Example, if you want to let curl understand cookies from a
|
||||
page and follow a location (and thus possibly send back cookies it received),
|
||||
you can invoke it like:
|
||||
|
||||
curl --cookie nada --location https://www.example.com
|
||||
|
||||
curl has the ability to read and write cookie files that use the same file
|
||||
format that Netscape and Mozilla once used. It is a convenient way to share
|
||||
cookies between scripts or invokes. The `--cookie` (`-b`) switch
|
||||
automatically detects if a given file is such a cookie file and parses it,
|
||||
and by using the `--cookie-jar` (`-c`) option you make curl write a new
|
||||
cookie file at the end of an operation:
|
||||
|
||||
curl --cookie cookies.txt --cookie-jar newcookies.txt \
|
||||
https://www.example.com
|
||||
|
||||
# HTTPS
|
||||
|
||||
## HTTPS is HTTP secure
|
||||
|
||||
There are a few ways to do secure HTTP transfers. By far the most common
|
||||
protocol for doing this is what is generally known as HTTPS, HTTP over
|
||||
SSL. SSL encrypts all the data that is sent and received over the network and
|
||||
thus makes it harder for attackers to spy on sensitive information.
|
||||
|
||||
SSL (or TLS as the current version of the standard is called) offers a set of
|
||||
advanced features to do secure transfers over HTTP.
|
||||
|
||||
curl supports encrypted fetches when built to use a TLS library and it can be
|
||||
built to use one out of a fairly large set of libraries - `curl -V` shows
|
||||
which one your curl was built to use (if any). To get a page from an HTTPS
|
||||
server, run curl like:
|
||||
|
||||
curl https://secure.example.com
|
||||
|
||||
## Certificates
|
||||
|
||||
In the HTTPS world, you use certificates to validate that you are the one you
|
||||
claim to be, as an addition to normal passwords. curl supports client- side
|
||||
certificates. All certificates are locked with a passphrase, which you need
|
||||
to enter before the certificate can be used by curl. The passphrase can be
|
||||
specified on the command line or if not, entered interactively when curl
|
||||
queries for it. Use a certificate with curl on an HTTPS server like:
|
||||
|
||||
curl --cert mycert.pem https://secure.example.com
|
||||
|
||||
curl also tries to verify that the server is who it claims to be, by
|
||||
verifying the server's certificate against a locally stored CA cert bundle.
|
||||
Failing the verification causes curl to deny the connection. You must then
|
||||
use [`--insecure`](https://curl.se/docs/manpage.html#-k) (`-k`) in case you
|
||||
want to tell curl to ignore that the server cannot be verified.
|
||||
|
||||
More about server certificate verification and ca cert bundles can be read in
|
||||
the [`SSLCERTS` document](https://curl.se/docs/sslcerts.html).
|
||||
|
||||
At times you may end up with your own CA cert store and then you can tell
|
||||
curl to use that to verify the server's certificate:
|
||||
|
||||
curl --cacert ca-bundle.pem https://example.com/
|
||||
|
||||
# Custom Request Elements
|
||||
|
||||
## Modify method and headers
|
||||
|
||||
Doing fancy stuff, you may need to add or change elements of a single curl
|
||||
request.
|
||||
|
||||
For example, you can change the POST method to `PROPFIND` and send the data
|
||||
as `Content-Type: text/xml` (instead of the default `Content-Type`) like
|
||||
this:
|
||||
|
||||
curl --data "<xml>" --header "Content-Type: text/xml" \
|
||||
--request PROPFIND example.com
|
||||
|
||||
You can delete a default header by providing one without content. Like you
|
||||
can ruin the request by chopping off the `Host:` header:
|
||||
|
||||
curl --header "Host:" https://www.example.com
|
||||
|
||||
You can add headers the same way. Your server may want a `Destination:`
|
||||
header, and you can add it:
|
||||
|
||||
curl --header "Destination: nowhere" https://example.com
|
||||
|
||||
## More on changed methods
|
||||
|
||||
It should be noted that curl selects which methods to use on its own
|
||||
depending on what action to ask for. `-d` makes a POST, `-I` makes a HEAD and
|
||||
so on. If you use the [`--request`](https://curl.se/docs/manpage.html#-X) /
|
||||
`-X` option you can change the method keyword curl selects, but you do not
|
||||
modify curl's behavior. This means that if you for example use -d "data" to
|
||||
do a POST, you can modify the method to a `PROPFIND` with `-X` and curl still
|
||||
thinks it sends a POST. You can change the normal GET to a POST method by
|
||||
adding `-X POST` in a command line like:
|
||||
|
||||
curl -X POST https://example.org/
|
||||
|
||||
curl however still acts as if it sent a GET so it does not send any request
|
||||
body etc.
|
||||
|
||||
# Web Login
|
||||
|
||||
## Some login tricks
|
||||
|
||||
While not strictly HTTP related, it still causes a lot of people problems so
|
||||
here's the executive run-down of how the vast majority of all login forms work
|
||||
and how to login to them using curl.
|
||||
|
||||
It can also be noted that to do this properly in an automated fashion, you
|
||||
most certainly need to script things and do multiple curl invokes etc.
|
||||
|
||||
First, servers mostly use cookies to track the logged-in status of the
|
||||
client, so you need to capture the cookies you receive in the responses.
|
||||
Then, many sites also set a special cookie on the login page (to make sure
|
||||
you got there through their login page) so you should make a habit of first
|
||||
getting the login-form page to capture the cookies set there.
|
||||
|
||||
Some web-based login systems feature various amounts of JavaScript, and
|
||||
sometimes they use such code to set or modify cookie contents. Possibly they
|
||||
do that to prevent programmed logins, like this manual describes how to...
|
||||
Anyway, if reading the code is not enough to let you repeat the behavior
|
||||
manually, capturing the HTTP requests done by your browsers and analyzing the
|
||||
sent cookies is usually a working method to work out how to shortcut the
|
||||
JavaScript need.
|
||||
|
||||
In the actual `<form>` tag for the login, lots of sites fill-in
|
||||
random/session or otherwise secretly generated hidden tags and you may need
|
||||
to first capture the HTML code for the login form and extract all the hidden
|
||||
fields to be able to do a proper login POST. Remember that the contents need
|
||||
to be URL encoded when sent in a normal POST.
|
||||
|
||||
# Debug
|
||||
|
||||
## Some debug tricks
|
||||
|
||||
Many times when you run curl on a site, you notice that the site does not
|
||||
seem to respond the same way to your curl requests as it does to your
|
||||
browser's.
|
||||
|
||||
Then you need to start making your curl requests more similar to your
|
||||
browser's requests:
|
||||
|
||||
- Use the `--trace-ascii` option to store fully detailed logs of the requests
|
||||
for easier analyzing and better understanding
|
||||
|
||||
- Make sure you check for and use cookies when needed (both reading with
|
||||
`--cookie` and writing with `--cookie-jar`)
|
||||
|
||||
- Set user-agent (with [`-A`](https://curl.se/docs/manpage.html#-A)) to
|
||||
one like a recent popular browser does
|
||||
|
||||
- Set referer (with [`-E`](https://curl.se/docs/manpage.html#-E)) like
|
||||
it is set by the browser
|
||||
|
||||
- If you use POST, make sure you send all the fields and in the same order as
|
||||
the browser does it.
|
||||
|
||||
## Check what the browsers do
|
||||
|
||||
A good helper to make sure you do this right, is the web browsers' developers
|
||||
tools that let you view all headers you send and receive (even when using
|
||||
HTTPS).
|
||||
|
||||
A more raw approach is to capture the HTTP traffic on the network with tools
|
||||
such as Wireshark or tcpdump and check what headers that were sent and
|
||||
received by the browser. (HTTPS forces you to use `SSLKEYLOGFILE` to do
|
||||
that.)
|
||||
7758
Agent-Windows/OGP64/usr/share/doc/curl/curl.txt
Normal file
7758
Agent-Windows/OGP64/usr/share/doc/curl/curl.txt
Normal file
File diff suppressed because it is too large
Load diff
BIN
Agent-Windows/OGP64/usr/share/doc/curl/everything-curl.epub
Normal file
BIN
Agent-Windows/OGP64/usr/share/doc/curl/everything-curl.epub
Normal file
Binary file not shown.
BIN
Agent-Windows/OGP64/usr/share/doc/curl/everything-curl.pdf
Normal file
BIN
Agent-Windows/OGP64/usr/share/doc/curl/everything-curl.pdf
Normal file
Binary file not shown.
154
Agent-Windows/OGP64/usr/share/doc/curl/wcurl.md
Normal file
154
Agent-Windows/OGP64/usr/share/doc/curl/wcurl.md
Normal file
|
|
@ -0,0 +1,154 @@
|
|||
---
|
||||
c: Copyright (C) Samuel Henrique <samueloph@debian.org>, Sergio Durigan Junior <sergiodj@debian.org> and many contributors, see the AUTHORS file.
|
||||
SPDX-License-Identifier: curl
|
||||
Title: wcurl
|
||||
Section: 1
|
||||
Source: wcurl
|
||||
See-also:
|
||||
- curl (1)
|
||||
- trurl (1)
|
||||
Added-in: n/a
|
||||
---
|
||||
|
||||
# NAME
|
||||
|
||||
**wcurl** - a simple wrapper around curl to easily download files.
|
||||
|
||||
# SYNOPSIS
|
||||
|
||||
**wcurl \<URL\>...**
|
||||
|
||||
**wcurl [--curl-options \<CURL_OPTIONS\>]... [--dry-run] [--no-decode-filename] [-o|-O|--output \<PATH\>] [--] \<URL\>...**
|
||||
|
||||
**wcurl [--curl-options=\<CURL_OPTIONS\>]... [--dry-run] [--no-decode-filename] [--output=\<PATH\>] [--] \<URL\>...**
|
||||
|
||||
**wcurl -V|--version**
|
||||
|
||||
**wcurl -h|--help**
|
||||
|
||||
# DESCRIPTION
|
||||
|
||||
**wcurl** is a simple curl wrapper which lets you use curl to download files
|
||||
without having to remember any parameters.
|
||||
|
||||
Call **wcurl** with a list of URLs you want to download and **wcurl**
|
||||
picks sane defaults.
|
||||
|
||||
If you need anything more complex, you can provide any of curl's supported
|
||||
parameters via the **--curl-options** option. Beware that you likely should be
|
||||
using curl directly if your use case is not covered.
|
||||
|
||||
By default, **wcurl** does:
|
||||
|
||||
## * Percent-encode whitespace in URLs;
|
||||
|
||||
## * Download multiple URLs in parallel
|
||||
if the installed curl's version is \>= 7.66.0 (--parallel);
|
||||
|
||||
## * Use a total number of 5 parallel connections to the same protocol + hostname + port number target
|
||||
if the installed curl's version is \>= 8.16.0 (--parallel-max-host);
|
||||
|
||||
## * Follow redirects;
|
||||
|
||||
## * Automatically choose a filename as output;
|
||||
|
||||
## * Avoid overwriting files
|
||||
if the installed curl's version is \>= 7.83.0 (--no-clobber);
|
||||
|
||||
## * Perform retries;
|
||||
|
||||
## * Set the downloaded file timestamp
|
||||
to the value provided by the server, if available;
|
||||
|
||||
## * Default to https
|
||||
if the URL does not contain any scheme;
|
||||
|
||||
## * Disable curl's URL globbing parser
|
||||
so {} and [] characters in URLs are not treated specially;
|
||||
|
||||
## * Percent-decode the resulting filename;
|
||||
|
||||
## * Use 'index.html' as the default filename
|
||||
if there is none in the URL.
|
||||
|
||||
# OPTIONS
|
||||
|
||||
## --curl-options, --curl-options=\<CURL_OPTIONS\>...
|
||||
|
||||
Specify extra options to be passed when invoking curl. May be specified more
|
||||
than once.
|
||||
|
||||
## -o, -O, --output, --output=\<PATH\>
|
||||
|
||||
Use the provided output path instead of getting it from the URL. If multiple
|
||||
URLs are provided, resulting files share the same name with a number appended to
|
||||
the end (curl \>= 7.83.0). If this option is provided multiple times, only the
|
||||
last value is considered.
|
||||
|
||||
## --no-decode-filename
|
||||
|
||||
Do not percent-decode the output filename, even if the percent-encoding in the
|
||||
URL was done by **wcurl**, e.g.: The URL contained whitespace.
|
||||
|
||||
## --dry-run
|
||||
|
||||
Do not actually execute curl, print what would be invoked.
|
||||
|
||||
## -V, \--version
|
||||
|
||||
Print version information.
|
||||
|
||||
## -h, \--help
|
||||
|
||||
Print help message.
|
||||
|
||||
# CURL_OPTIONS
|
||||
|
||||
Any option supported by curl can be set here. This is not used by **wcurl**; it
|
||||
is instead forwarded to the curl invocation.
|
||||
|
||||
# URL
|
||||
|
||||
URL to be downloaded. Anything that is not a parameter is considered
|
||||
an URL. Whitespace is percent-encoded and the URL is passed to curl, which
|
||||
then performs the parsing. May be specified more than once.
|
||||
|
||||
# EXAMPLES
|
||||
|
||||
Download a single file:
|
||||
|
||||
**wcurl example.com/filename.txt**
|
||||
|
||||
Download two files in parallel:
|
||||
|
||||
**wcurl example.com/filename1.txt example.com/filename2.txt**
|
||||
|
||||
Download a file passing the **--progress-bar** and **--http2** flags to curl:
|
||||
|
||||
**wcurl --curl-options="--progress-bar --http2" example.com/filename.txt**
|
||||
|
||||
Resume from an interrupted download. The options necessary to resume the download
|
||||
(`--clobber --continue-at -`) must be the **last** options specified in `--curl-options`.
|
||||
Note that the only way to resume interrupted downloads is to allow wcurl to overwrite
|
||||
the destination file:
|
||||
|
||||
**wcurl --curl-options="--clobber --continue-at -" example.com/filename.txt**
|
||||
|
||||
Download multiple files without a limit of concurrent connections per host (the default limit is 5):
|
||||
|
||||
**wcurl --curl-options="--parallel-max-host 0" example.com/filename1.txt example.com/filename2.txt**
|
||||
|
||||
# AUTHORS
|
||||
|
||||
Samuel Henrique \<samueloph@debian.org\>
|
||||
Sergio Durigan Junior \<sergiodj@debian.org\>
|
||||
and many contributors, see the AUTHORS file.
|
||||
|
||||
# REPORTING BUGS
|
||||
|
||||
If you experience any problems with **wcurl** that you do not experience with
|
||||
curl, submit an issue on GitHub: https://github.com/curl/wcurl
|
||||
|
||||
# COPYRIGHT
|
||||
|
||||
**wcurl** is licensed under the curl license
|
||||
Loading…
Add table
Add a link
Reference in a new issue