mirror of
https://github.com/curl/curl.git
synced 2025-02-17 14:59:45 +08:00
GHA: add a job scanning for "bad words" in markdown
This means words, phrases or things we have decided not to use - words that are spelled right according to the dictionary but we want to avoid. In the name of consistency and better documentation. Closes #12764
This commit is contained in:
parent
2620aa930b
commit
e5000e797f
67
.github/scripts/badwords.pl
vendored
Executable file
67
.github/scripts/badwords.pl
vendored
Executable file
@ -0,0 +1,67 @@
|
||||
#!/usr/bin/perl
|
||||
# Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
#
|
||||
# SPDX-License-Identifier: curl
|
||||
#
|
||||
# bad[:=]correct
|
||||
#
|
||||
# If separator is '=', the string will be compared case sensitively.
|
||||
# If separator is ':', the check is done case insensitively.
|
||||
#
|
||||
my $w;
|
||||
while(<STDIN>) {
|
||||
chomp;
|
||||
if($_ =~ /^#/) {
|
||||
next;
|
||||
}
|
||||
if($_ =~ /^([^:=]*)([:=])(.*)/) {
|
||||
my ($bad, $sep, $better)=($1, $2, $3);
|
||||
push @w, $bad;
|
||||
$alt{$bad} = $better;
|
||||
if($sep eq "=") {
|
||||
$exactcase{$bad} = 1;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
my $errors;
|
||||
|
||||
sub file {
|
||||
my ($f) = @_;
|
||||
my $l = 0;
|
||||
open(F, "<$f");
|
||||
while(<F>) {
|
||||
my $in = $_;
|
||||
$l++;
|
||||
chomp $in;
|
||||
if($in =~ /^ /) {
|
||||
next;
|
||||
}
|
||||
# remove the link part
|
||||
$in =~ s/(\[.*\])\(.*\)/$1/g;
|
||||
# remove backticked texts
|
||||
$in =~ s/\`.*\`//g;
|
||||
foreach my $w (@w) {
|
||||
my $case = $exactcase{$w};
|
||||
if(($in =~ /^(.*)$w/i && !$case) ||
|
||||
($in =~ /^(.*)$w/ && $case) ) {
|
||||
my $p = $1;
|
||||
my $c = length($p)+1;
|
||||
print STDERR "$f:$l:$c: error: found bad word \"$w\"\n";
|
||||
printf STDERR " %4d | $in\n", $l;
|
||||
printf STDERR " | %*s^%s\n", length($p), " ",
|
||||
"~" x (length($w)-1);
|
||||
printf STDERR " maybe use \"%s\" instead?\n", $alt{$w};
|
||||
$errors++;
|
||||
}
|
||||
}
|
||||
}
|
||||
close(F);
|
||||
}
|
||||
|
||||
my @files = @ARGV;
|
||||
|
||||
foreach my $each (@files) {
|
||||
file($each);
|
||||
}
|
||||
exit $errors;
|
45
.github/scripts/badwords.txt
vendored
Normal file
45
.github/scripts/badwords.txt
vendored
Normal file
@ -0,0 +1,45 @@
|
||||
# Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
#
|
||||
# SPDX-License-Identifier: curl
|
||||
#
|
||||
back-end:backend
|
||||
e-mail:email
|
||||
run-time:runtime
|
||||
set-up:setup
|
||||
tool chain:toolchain
|
||||
tool-chain:toolchain
|
||||
wild-card:wildcard
|
||||
wild card:wildcard
|
||||
i'm:I am
|
||||
you've:You have
|
||||
they've:They have
|
||||
they're:They are
|
||||
should've:should have
|
||||
don't:do not
|
||||
could've:could have
|
||||
doesn't:does not
|
||||
isn't:is not
|
||||
a html: an html
|
||||
a http: an http
|
||||
a ftp: an ftp
|
||||
url =URL
|
||||
internet\W=Internet
|
||||
isation:ization
|
||||
it's:it is
|
||||
there's:there is
|
||||
[^.]\. And: Rewrite it somehow?
|
||||
\. But: Rewrite it somehow?
|
||||
file name :filename
|
||||
\. So : Rewrite without "so" ?
|
||||
dir :directory
|
||||
you'd:you would
|
||||
you'll:you will
|
||||
can't:cannot
|
||||
that's:that is
|
||||
web page:webpage
|
||||
host name\W:hostname
|
||||
file name\W:filename
|
||||
didn't:did not
|
||||
doesn't:does not
|
||||
won't:will not
|
||||
couldn't:could not
|
1
.github/scripts/spellcheck.words
vendored
1
.github/scripts/spellcheck.words
vendored
@ -885,6 +885,7 @@ WB
|
||||
web page
|
||||
WebDAV
|
||||
WebOS
|
||||
webpage
|
||||
WebSocket
|
||||
WEBSOCKET
|
||||
WHATWG
|
||||
|
27
.github/workflows/badwords.yml
vendored
Normal file
27
.github/workflows/badwords.yml
vendored
Normal file
@ -0,0 +1,27 @@
|
||||
# Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
||||
#
|
||||
# SPDX-License-Identifier: curl
|
||||
|
||||
name: badwords
|
||||
|
||||
on:
|
||||
# Trigger the workflow on push or pull requests, but only for the
|
||||
# master branch
|
||||
push:
|
||||
branches:
|
||||
- master
|
||||
- '*/ci'
|
||||
pull_request:
|
||||
branches:
|
||||
- master
|
||||
|
||||
jobs:
|
||||
check:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
|
||||
- name: check
|
||||
run: ./.github/scripts/badwords.pl < .github/scripts/badwords.txt docs/*.md docs/libcurl/*.md docs/libcurl/opts/*.md
|
@ -5,7 +5,7 @@
|
||||
Curl and libcurl keep being developed. Adding features and changing code
|
||||
means that bugs will sneak in, no matter how hard we try to keep them out.
|
||||
|
||||
Of course there are lots of bugs left. And lots of misfeatures.
|
||||
Of course there are lots of bugs left. Not to mention misfeatures.
|
||||
|
||||
To help us make curl the stable and solid product we want it to be, we need
|
||||
bug reports and bug fixes.
|
||||
|
@ -363,10 +363,10 @@ individual TLS 1.3 cipher suites since Schannel does not support it directly.
|
||||
`TLS_AES_128_CCM_8_SHA256`
|
||||
`TLS_AES_128_CCM_SHA256`
|
||||
|
||||
Note if you set TLS 1.3 ciphers without also setting the minimum TLS version to
|
||||
1.3 then it's possible Schannel may negotiate an earlier TLS version and cipher
|
||||
suite if your libcurl and OS settings allow it. You can set the minimum TLS
|
||||
version by using `CURLOPT_SSLVERSION` or `--tlsv1.3`.
|
||||
Note if you set TLS 1.3 ciphers without also setting the minimum TLS version
|
||||
to 1.3 then it is possible Schannel may negotiate an earlier TLS version and
|
||||
cipher suite if your libcurl and OS settings allow it. You can set the minimum
|
||||
TLS version by using `CURLOPT_SSLVERSION` or `--tlsv1.3`.
|
||||
|
||||
## BearSSL
|
||||
|
||||
|
@ -28,7 +28,10 @@ The `type` argument specifies what the bytes in `buf` actually are. The followin
|
||||
#define CLIENTWRITE_TRAILER (1<<6) /* a trailer HEADER */
|
||||
```
|
||||
|
||||
The main types here are `CLIENTWRITE_BODY` and `CLIENTWRITE_HEADER`. They are mutually exclusive. The other bits are enhancements to `CLIENTWRITE_HEADER` to specify what the header is about. And they are only used in HTTP and related protocols (RTSP and WebSocket).
|
||||
The main types here are `CLIENTWRITE_BODY` and `CLIENTWRITE_HEADER`. They are
|
||||
mutually exclusive. The other bits are enhancements to `CLIENTWRITE_HEADER` to
|
||||
specify what the header is about. They are only used in HTTP and related
|
||||
protocols (RTSP and WebSocket).
|
||||
|
||||
The implementation of `Curl_client_write()` uses a chain of *client writer* instances to process the call and make sure that the bytes reach the proper application callbacks. This is similar to the design of connection filters: client writers can be chained to process the bytes written through them. The definition is:
|
||||
|
||||
|
@ -221,7 +221,7 @@ too long, the statement too hard to read, or due to other style guidelines
|
||||
above. In such a case the statement will span multiple lines.
|
||||
|
||||
If a continuation line is part of an expression or sub-expression then you
|
||||
should align on the appropriate column so that it's easy to tell what part of
|
||||
should align on the appropriate column so that it is easy to tell what part of
|
||||
the statement it is. Operators should not start continuation lines. In other
|
||||
cases follow the 2-space indent guideline. Here are some examples from
|
||||
libcurl:
|
||||
|
@ -115,11 +115,13 @@ The currently existing filter types (curl 8.5.0) are:
|
||||
* `TCP`, `UDP`, `UNIX`: filters that operate on a socket, providing raw I/O.
|
||||
* `SOCKET-ACCEPT`: special TCP socket that has a socket that has been `accept()`ed in a `listen()`
|
||||
* `SSL`: filter that applies TLS en-/decryption and handshake. Manages the underlying TLS backend implementation.
|
||||
* `HTTP-PROXY`, `H1-PROXY`, `H2-PROXY`: the first manages the connection to a HTTP proxy server and uses the other depending on which ALPN protocol has been negotiated.
|
||||
* `HTTP-PROXY`, `H1-PROXY`, `H2-PROXY`: the first manages the connection to an
|
||||
HTTP proxy server and uses the other depending on which ALPN protocol has
|
||||
been negotiated.
|
||||
* `SOCKS-PROXY`: filter for the various SOCKS proxy protocol variations
|
||||
* `HAPROXY`: filter for the protocol of the same name, providing client IP information to a server.
|
||||
* `HTTP/2`: filter for handling multiplexed transfers over a HTTP/2 connection
|
||||
* `HTTP/3`: filter for handling multiplexed transfers over a HTTP/3+QUIC connection
|
||||
* `HTTP/2`: filter for handling multiplexed transfers over an HTTP/2 connection
|
||||
* `HTTP/3`: filter for handling multiplexed transfers over an HTTP/3+QUIC connection
|
||||
* `HAPPY-EYEBALLS`: meta filter that implements IPv4/IPv6 "happy eyeballing". It creates up to 2 sub-filters that race each other for a connection.
|
||||
* `SETUP`: meta filter that manages the creation of sub-filter chains for a specific transport (e.g. TCP or QUIC).
|
||||
* `HTTPS-CONNECT`: meta filter that races a TCP+TLS and a QUIC connection against each other to determine if HTTP/1.1, HTTP/2 or HTTP/3 shall be used for a transfer.
|
||||
@ -159,7 +161,9 @@ Similar checks can determine if a connection is multiplexed or not.
|
||||
|
||||
Filters may make use of special trace macros like `CURL_TRC_CF(data, cf, msg, ...)`. With `data` being the transfer and `cf` being the filter instance. These traces are normally not active and their execution is guarded so that they are cheap to ignore.
|
||||
|
||||
Users of `curl` may activate them by adding the name of the filter type to the `--trace-config` argument. For example, in order to get more detailed tracing of a HTTP/2 request, invoke curl with:
|
||||
Users of `curl` may activate them by adding the name of the filter type to the
|
||||
`--trace-config` argument. For example, in order to get more detailed tracing
|
||||
of an HTTP/2 request, invoke curl with:
|
||||
|
||||
```
|
||||
> curl -v --trace-config ids,time,http/2 https://curl.se
|
||||
@ -170,7 +174,11 @@ Which will give you trace output with time information, transfer+connection ids
|
||||
|
||||
Meta filters is a catch-all name for filter types that do not change the transfer data in any way but provide other important services to curl. In general, it is possible to do all sorts of silly things with them. One of the commonly used, important things is "eyeballing".
|
||||
|
||||
The `HAPPY-EYEBALLS` filter is involved in the connect phase. It's job is to try the various IPv4 and IPv6 addresses that are known for a server. If only one address family is known (or configured), it tries the addresses one after the other with timeouts calculated from the amount of addresses and the overall connect timeout.
|
||||
The `HAPPY-EYEBALLS` filter is involved in the connect phase. Its job is to
|
||||
try the various IPv4 and IPv6 addresses that are known for a server. If only
|
||||
one address family is known (or configured), it tries the addresses one after
|
||||
the other with timeouts calculated from the amount of addresses and the
|
||||
overall connect timeout.
|
||||
|
||||
When more than one address family is to be tried, it splits the address list into IPv4 and IPv6 and makes parallel attempts. The connection filter chain will look like this:
|
||||
|
||||
|
@ -101,9 +101,9 @@ archive is quite OK as well.
|
||||
### Documentation
|
||||
|
||||
Writing docs is dead boring and one of the big problems with many open source
|
||||
projects. But someone's gotta do it. It makes things a lot easier if you
|
||||
submit a small description of your fix or your new features with every
|
||||
contribution so that it can be swiftly added to the package documentation.
|
||||
projects but someone's gotta do it. It makes things a lot easier if you submit
|
||||
a small description of your fix or your new features with every contribution
|
||||
so that it can be swiftly added to the package documentation.
|
||||
|
||||
The documentation is always made in man pages (nroff formatted) or plain
|
||||
ASCII files. All HTML files on the website and in the release archives are
|
||||
@ -240,10 +240,10 @@ make sure that you have your own user and email setup correctly in git before
|
||||
you commit.
|
||||
|
||||
Add whichever header lines as appropriate, with one line per person if more
|
||||
than one person was involved. There is no need to credit yourself unless you are
|
||||
using --author=... which hides your identity. Do not include people's e-mail
|
||||
addresses in headers to avoid spam, unless they are already public from a
|
||||
previous commit; saying `{userid} on github` is OK.
|
||||
than one person was involved. There is no need to credit yourself unless you
|
||||
are using --author=... which hides your identity. Do not include people's
|
||||
email addresses in headers to avoid spam, unless they are already public from
|
||||
a previous commit; saying `{userid} on github` is OK.
|
||||
|
||||
### Write Access to git Repository
|
||||
|
||||
|
@ -105,7 +105,7 @@ Write italics like:
|
||||
|
||||
This is *italics*.
|
||||
|
||||
Due to how man pages don't support backticks especially formatted, such
|
||||
Due to how man pages do not support backticks especially formatted, such
|
||||
occurrences in the source will instead just use italics in the generated
|
||||
output:
|
||||
|
||||
|
@ -10,8 +10,8 @@ how your use case cannot be satisfied properly using a workaround.
|
||||
|
||||
This NTLM authentication method is powered by a separate tool,
|
||||
`ntlm_auth`. Barely anyone uses this method. It was always a quirky
|
||||
implementation (including fork + exec), it has limited portability and we
|
||||
don't test it in the test suite and CI.
|
||||
implementation (including fork + exec), it has limited portability and we do
|
||||
not test it in the test suite and CI.
|
||||
|
||||
We keep the native NTLM implementation.
|
||||
|
||||
|
@ -82,8 +82,8 @@
|
||||
- active/passive using PORT, EPRT, PASV or EPSV
|
||||
- single file size information (compare to HTTP HEAD)
|
||||
- 'type=' URL support
|
||||
- dir listing
|
||||
- dir listing names-only
|
||||
- directory listing
|
||||
- directory listing names-only
|
||||
- upload
|
||||
- upload append
|
||||
- upload via http-proxy as HTTP PUT
|
||||
@ -94,7 +94,7 @@
|
||||
- via HTTP proxy, HTTPS proxy or SOCKS proxy
|
||||
- all operations can be tunneled through proxy
|
||||
- customizable to retrieve file modification date
|
||||
- no dir depth limit
|
||||
- no directory depth limit
|
||||
|
||||
## FTPS (1)
|
||||
|
||||
|
@ -31,7 +31,7 @@ the master branch using pull-requests, just like ordinary changes.
|
||||
To fix before we remove the experimental label:
|
||||
|
||||
- the used QUIC library needs to consider itself non-beta
|
||||
- it's fine to "leave" individual backends as experimental if necessary
|
||||
- it is fine to "leave" individual backends as experimental if necessary
|
||||
|
||||
# ngtcp2 version
|
||||
|
||||
@ -341,9 +341,9 @@ handshake or time out.
|
||||
|
||||
Note that all this happens in addition to IP version happy eyeballing. If the
|
||||
name resolution for the server gives more than one IP address, curl will try
|
||||
all those until one succeeds - just as with all other protocols. And if those
|
||||
IP addresses contain both IPv6 and IPv4, those attempts will happen, delayed,
|
||||
in parallel (the actual eyeballing).
|
||||
all those until one succeeds - just as with all other protocols. If those IP
|
||||
addresses contain both IPv6 and IPv4, those attempts will happen, delayed, in
|
||||
parallel (the actual eyeballing).
|
||||
|
||||
## Known Bugs
|
||||
|
||||
|
@ -123,8 +123,8 @@ If you are a curl developer and use gcc, you might want to enable more debug
|
||||
options with the `--enable-debug` option.
|
||||
|
||||
curl can be built to use a whole range of libraries to provide various useful
|
||||
services, and configure will try to auto-detect a decent default. But if you
|
||||
want to alter it, you can select how to deal with each individual library.
|
||||
services, and configure will try to auto-detect a decent default. If you want
|
||||
to alter it, you can select how to deal with each individual library.
|
||||
|
||||
## Select TLS backend
|
||||
|
||||
@ -146,7 +146,7 @@ you cannot add another OpenSSL fork (or wolfSSL) simply because they have
|
||||
conflicting identical symbol names.
|
||||
|
||||
When you build with multiple TLS backends, you can select the active one at
|
||||
run-time when curl starts up.
|
||||
runtime when curl starts up.
|
||||
|
||||
## configure finding libs in wrong directory
|
||||
|
||||
@ -174,8 +174,8 @@ Building for Windows XP is required as a minimum.
|
||||
KB140584 is a must for any Windows developer. Especially important is full
|
||||
understanding if you are not going to follow the advice given above.
|
||||
|
||||
- [How To Use the C Run-Time](https://support.microsoft.com/help/94248/how-to-use-the-c-run-time)
|
||||
- [Run-Time Library Compiler Options](https://docs.microsoft.com/cpp/build/reference/md-mt-ld-use-run-time-library)
|
||||
- [How To Use the C Runtime](https://support.microsoft.com/help/94248/how-to-use-the-c-run-time)
|
||||
- [Runtime Library Compiler Options](https://docs.microsoft.com/cpp/build/reference/md-mt-ld-use-run-time-library)
|
||||
- [Potential Errors Passing CRT Objects Across DLL Boundaries](https://docs.microsoft.com/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries)
|
||||
|
||||
If your app is misbehaving in some strange way, or it is suffering from memory
|
||||
@ -340,14 +340,14 @@ In all above, the built libraries and executables can be found in the
|
||||
|
||||
# Android
|
||||
|
||||
When building curl for Android it's recommended to use a Linux/macOS environment
|
||||
since using curl's `configure` script is the easiest way to build curl
|
||||
for Android. Before you can build curl for Android, you need to install the
|
||||
Android NDK first. This can be done using the SDK Manager that is part of
|
||||
Android Studio. Once you have installed the Android NDK, you need to figure out
|
||||
where it has been installed and then set up some environment variables before
|
||||
launching `configure`. On macOS, those variables could look like this to compile
|
||||
for `aarch64` and API level 29:
|
||||
When building curl for Android it is recommended to use a Linux/macOS
|
||||
environment since using curl's `configure` script is the easiest way to build
|
||||
curl for Android. Before you can build curl for Android, you need to install
|
||||
the Android NDK first. This can be done using the SDK Manager that is part of
|
||||
Android Studio. Once you have installed the Android NDK, you need to figure
|
||||
out where it has been installed and then set up some environment variables
|
||||
before launching `configure`. On macOS, those variables could look like this
|
||||
to compile for `aarch64` and API level 29:
|
||||
|
||||
```bash
|
||||
export ANDROID_NDK_HOME=~/Library/Android/sdk/ndk/25.1.8937393 # Point into your NDK.
|
||||
@ -367,13 +367,13 @@ to adjust those variables accordingly. After that you can build curl like this:
|
||||
|
||||
./configure --host aarch64-linux-android --with-pic --disable-shared
|
||||
|
||||
Note that this will not give you SSL/TLS support. If you need SSL/TLS, you have
|
||||
to build curl against a SSL/TLS layer, e.g. OpenSSL, because it's impossible for
|
||||
curl to access Android's native SSL/TLS layer. To build curl for Android using
|
||||
OpenSSL, follow the OpenSSL build instructions and then install `libssl.a` and
|
||||
`libcrypto.a` to `$TOOLCHAIN/sysroot/usr/lib` and copy `include/openssl` to
|
||||
`$TOOLCHAIN/sysroot/usr/include`. Now you can build curl for Android using
|
||||
OpenSSL like this:
|
||||
Note that this will not give you SSL/TLS support. If you need SSL/TLS, you
|
||||
have to build curl against a SSL/TLS layer, e.g. OpenSSL, because it is
|
||||
impossible for curl to access Android's native SSL/TLS layer. To build curl
|
||||
for Android using OpenSSL, follow the OpenSSL build instructions and then
|
||||
install `libssl.a` and `libcrypto.a` to `$TOOLCHAIN/sysroot/usr/lib` and copy
|
||||
`include/openssl` to `$TOOLCHAIN/sysroot/usr/include`. Now you can build curl
|
||||
for Android using OpenSSL like this:
|
||||
|
||||
```bash
|
||||
LIBS="-lssl -lcrypto -lc++" # For OpenSSL/BoringSSL. In general, you will need to the SSL/TLS layer's transitive dependencies if you are linking statically.
|
||||
|
87
docs/IPFS.md
87
docs/IPFS.md
@ -19,12 +19,29 @@ By explicitly requesting [application/vnd.ipld.raw](https://www.iana.org/assignm
|
||||
This enables users to use untrusted, public gateways without worrying they might return invalid/malicious bytes.
|
||||
|
||||
## IPFS and IPNS protocol handling
|
||||
There are various ways to access data from the IPFS network. One such way is through the concept of public "[gateways](https://docs.ipfs.tech/concepts/ipfs-gateway/#overview)". The short version is that entities can offer gateway services. An example here that is hosted by Protocol Labs (who also makes IPFS) is `dweb.link` and `ipfs.io`. Both sites expose gateway functionality. Getting a file through `ipfs.io` looks like this: `https://ipfs.io/ipfs/bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi`
|
||||
|
||||
If you were to be [running your own IPFS node](https://docs.ipfs.tech/how-to/command-line-quick-start/) then you, by default, also have a [local gateway](https://specs.ipfs.tech/http-gateways/) running. In it's default configuration the earlier example would then also work in this link: `http://127.0.0.1:8080/ipfs/bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi`
|
||||
There are various ways to access data from the IPFS network. One such way is
|
||||
through the concept of public
|
||||
"[gateways](https://docs.ipfs.tech/concepts/ipfs-gateway/#overview)". The
|
||||
short version is that entities can offer gateway services. An example here
|
||||
that is hosted by Protocol Labs (who also makes IPFS) is `dweb.link` and
|
||||
`ipfs.io`. Both sites expose gateway functionality. Getting a file through
|
||||
`ipfs.io` looks like this:
|
||||
`https://ipfs.io/ipfs/bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi`
|
||||
|
||||
If you were to be [running your own IPFS
|
||||
node](https://docs.ipfs.tech/how-to/command-line-quick-start/) then you, by
|
||||
default, also have a [local gateway](https://specs.ipfs.tech/http-gateways/)
|
||||
running. In its default configuration the earlier example would then also work
|
||||
in this link:
|
||||
|
||||
`http://127.0.0.1:8080/ipfs/bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi`
|
||||
|
||||
## cURL handling of the IPFS protocols
|
||||
The IPFS integration in cURL hides this gateway logic for you. So instead of providing a full URL to a file on IPFS like this:
|
||||
|
||||
The IPFS integration in cURL hides this gateway logic for you. Instead of
|
||||
providing a full URL to a file on IPFS like this:
|
||||
|
||||
```
|
||||
curl http://127.0.0.1:8080/ipfs/bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi
|
||||
```
|
||||
@ -34,49 +51,75 @@ You can provide it with the IPFS protocol instead:
|
||||
curl ipfs://bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi
|
||||
```
|
||||
|
||||
With the IPFS protocol way of asking a file, cURL still needs to know the gateway. curl essentially just rewrites the IPFS based URL to a gateway URL.
|
||||
With the IPFS protocol way of asking a file, cURL still needs to know the
|
||||
gateway. curl essentially just rewrites the IPFS based URL to a gateway URL.
|
||||
|
||||
### IPFS_GATEWAY environment variable
|
||||
If the `IPFS_GATEWAY` environment variable is found, it's value is used as gateway.
|
||||
|
||||
If the `IPFS_GATEWAY` environment variable is found, its value is used as
|
||||
gateway.
|
||||
|
||||
### Automatic gateway detection
|
||||
When you provide no additional details to cURL then cURL will:
|
||||
|
||||
1. First look for the `IPFS_GATEWAY` environment variable and use that if it's set.
|
||||
2. Look for the file: `~/.ipfs/gateway`. If it can find that file then it means that you have a local gateway running and that file contains the URL to your local gateway.
|
||||
1. First look for the `IPFS_GATEWAY` environment variable and use that if it
|
||||
is set.
|
||||
2. Look for the file: `~/.ipfs/gateway`. If it can find that file then it
|
||||
means that you have a local gateway running and that file contains the URL
|
||||
to your local gateway.
|
||||
|
||||
If cURL fails you'll be presented with an error message and a link to this page to the option most applicable to solving the issue.
|
||||
If cURL fails you will be presented with an error message and a link to this
|
||||
page to the option most applicable to solving the issue.
|
||||
|
||||
### `--ipfs-gateway` argument
|
||||
You can also provide a `--ipfs-gateway` argument to cURL. This overrules any other gateway setting. curl won't fallback to the other options if the provided gateway didn't work.
|
||||
|
||||
You can also provide a `--ipfs-gateway` argument to cURL. This overrules any
|
||||
other gateway setting. curl will not fallback to the other options if the
|
||||
provided gateway did not work.
|
||||
|
||||
## Gateway redirects
|
||||
A gateway could redirect to another place. For example, `dweb.link` redirects [path based](https://docs.ipfs.tech/how-to/address-ipfs-on-web/#path-gateway) requests to [subdomain based](https://docs.ipfs.tech/how-to/address-ipfs-on-web/#subdomain-gateway) ones. So a request to:
|
||||
```
|
||||
|
||||
A gateway could redirect to another place. For example, `dweb.link` redirects
|
||||
[path based](https://docs.ipfs.tech/how-to/address-ipfs-on-web/#path-gateway)
|
||||
requests to [subdomain
|
||||
based](https://docs.ipfs.tech/how-to/address-ipfs-on-web/#subdomain-gateway)
|
||||
ones. A request using:
|
||||
|
||||
curl ipfs://bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi --ipfs-gateway https://dweb.link
|
||||
```
|
||||
|
||||
Which would be translated to:
|
||||
```
|
||||
|
||||
https://dweb.link/ipfs/bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi
|
||||
```
|
||||
|
||||
Will redirect to:
|
||||
```
|
||||
|
||||
https://bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi.ipfs.dweb.link
|
||||
```
|
||||
|
||||
If you trust this behavior from your gateway of choice then passing the `-L` option will follow the redirect.
|
||||
|
||||
## Error messages and hints
|
||||
|
||||
Depending on the arguments, cURL could present the user with an error.
|
||||
|
||||
### Gateway file and environment variable
|
||||
cURL tried to look for the file: `~/.ipfs/gateway` but couldn't find it. It also tried to look for the `IPFS_GATEWAY` environment variable but couldn't find that either. This happens when no extra arguments are passed to cURL and letting it try to figure it out [automatically](#automatic-gateway-detection).
|
||||
|
||||
Any IPFS implementation that has gateway support should expose it's URL in `~/.ipfs/gateway`. If you are already running a gateway, make sure it exposes the file where cURL expects to find it.
|
||||
cURL tried to look for the file: `~/.ipfs/gateway` but could not find it. It
|
||||
also tried to look for the `IPFS_GATEWAY` environment variable but could not
|
||||
find that either. This happens when no extra arguments are passed to cURL and
|
||||
letting it try to figure it out [automatically](#automatic-gateway-detection).
|
||||
|
||||
Alternatively you could set the `IPFS_GATEWAY` environment variable or pass the `--ipfs-gateway` flag to the cURL command.
|
||||
Any IPFS implementation that has gateway support should expose its URL in
|
||||
`~/.ipfs/gateway`. If you are already running a gateway, make sure it exposes
|
||||
the file where cURL expects to find it.
|
||||
|
||||
Alternatively you could set the `IPFS_GATEWAY` environment variable or pass
|
||||
the `--ipfs-gateway` flag to the cURL command.
|
||||
|
||||
### Malformed gateway URL
|
||||
The command executed evaluates in an invalid URL. This could be anywhere in the URL, but a likely point is a wrong gateway URL.
|
||||
|
||||
Inspect the URL set via the `IPFS_GATEWAY` environment variable or passed with the `--ipfs-gateway` flag.
|
||||
Alternatively opt to go for the [automatic](#automatic-gateway-detection) gateway detection.
|
||||
The command executed evaluates in an invalid URL. This could be anywhere in
|
||||
the URL, but a likely point is a wrong gateway URL.
|
||||
|
||||
Inspect the URL set via the `IPFS_GATEWAY` environment variable or passed with
|
||||
the `--ipfs-gateway` flag. Alternatively opt to go for the
|
||||
[automatic](#automatic-gateway-detection) gateway detection.
|
||||
|
@ -556,7 +556,7 @@ transfer stalls during periods.
|
||||
## Config File
|
||||
|
||||
Curl automatically tries to read the `.curlrc` file (or `_curlrc` file on
|
||||
Microsoft Windows systems) from the user's home dir on startup.
|
||||
Microsoft Windows systems) from the user's home directory on startup.
|
||||
|
||||
The config file could be made up with normal command line switches, but you
|
||||
can also specify the long options without the dashes to make it more
|
||||
|
@ -38,9 +38,9 @@ Example:
|
||||
## Behavior differences
|
||||
|
||||
Connections are shared fine between different easy handles, but the
|
||||
"authentication contexts" are not. So for example doing HTTP Digest auth with
|
||||
one handle for a particular transfer and then continue on with another handle
|
||||
that reuses the same connection, the second handle cannot send the necessary
|
||||
"authentication contexts" are not. For example doing HTTP Digest auth with one
|
||||
handle for a particular transfer and then continue on with another handle that
|
||||
reuses the same connection, the second handle cannot send the necessary
|
||||
Authorization header at once since the context is only kept in the original
|
||||
easy handle.
|
||||
|
||||
|
@ -87,7 +87,7 @@
|
||||
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. And yeah, the formal name is not URL, it is URI.
|
||||
canonical spec. The formal name is not URL, it is **URI**.
|
||||
|
||||
## Host
|
||||
|
||||
@ -309,12 +309,10 @@
|
||||
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:
|
||||
|
||||
```html
|
||||
<form method="POST" enctype='multipart/form-data' action="upload.cgi">
|
||||
<input type=file name=upload>
|
||||
<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`.
|
||||
@ -630,18 +628,17 @@
|
||||
|
||||
It should be noted that curl selects which methods to use on its own
|
||||
depending on what action to ask for. `-d` will do POST, `-I` will do 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 will 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 will still think it
|
||||
sends a POST . You can change the normal GET to a POST method by simply
|
||||
adding `-X POST` in a command line like:
|
||||
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 will 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 will
|
||||
still think it sends a POST. You can change the normal GET to a POST method
|
||||
by simply adding `-X POST` in a command line like:
|
||||
|
||||
curl -X POST http://example.org/
|
||||
|
||||
... but curl will still think and act as if it sent a GET so it will not send
|
||||
any request body etc.
|
||||
curl will however still act as if it sent a GET so it will not send any
|
||||
request body etc.
|
||||
|
||||
# Web Login
|
||||
|
||||
|
@ -95,9 +95,9 @@ Outputs version information about the installed libcurl.
|
||||
## --vernum
|
||||
|
||||
Outputs version information about the installed libcurl, in numerical mode.
|
||||
This outputs the version number, in hexadecimal, with 8 bits for each part:
|
||||
major, minor, and patch. So that libcurl 7.7.4 would appear as 070704 and libcurl
|
||||
12.13.14 would appear as 0c0d0e... Note that the initial zero might be
|
||||
This shows the version number, in hexadecimal, using 8 bits for each part:
|
||||
major, minor, and patch numbers. This makes libcurl 7.7.4 appear as 070704 and
|
||||
libcurl 12.13.14 appear as 0c0d0e... Note that the initial zero might be
|
||||
omitted. (This option was broken in the 7.15.0 release.)
|
||||
|
||||
# EXAMPLES
|
||||
|
@ -40,15 +40,15 @@ calling curl_easy_perform(3) or curl_multi_perform(3). Note that
|
||||
curl_easy_send(3) does not work on connections that were created without
|
||||
this option.
|
||||
|
||||
The call returns **CURLE_AGAIN** if it's not possible to send data right now
|
||||
The call returns **CURLE_AGAIN** if it is not possible to send data right now
|
||||
- the socket is used in non-blocking mode internally. When **CURLE_AGAIN**
|
||||
is returned, use your operating system facilities like *select(2)* to wait
|
||||
until the socket is writable. The socket may be obtained using
|
||||
curl_easy_getinfo(3) with CURLINFO_ACTIVESOCKET(3).
|
||||
|
||||
Furthermore if you wait on the socket and it tells you it's writable,
|
||||
curl_easy_send(3) may return **CURLE_AGAIN** if the only data that was
|
||||
sent was for internal SSL processing, and no other data could be sent.
|
||||
Furthermore if you wait on the socket and it tells you it is writable,
|
||||
curl_easy_send(3) may return **CURLE_AGAIN** if the only data that was sent
|
||||
was for internal SSL processing, and no other data could be sent.
|
||||
|
||||
# EXAMPLE
|
||||
|
||||
|
@ -431,7 +431,7 @@ Enable .netrc parsing. See CURLOPT_NETRC(3)
|
||||
|
||||
## CURLOPT_NETRC_FILE
|
||||
|
||||
&.netrc file name. See CURLOPT_NETRC_FILE(3)
|
||||
.netrc filename. See CURLOPT_NETRC_FILE(3)
|
||||
|
||||
## CURLOPT_USERPWD
|
||||
|
||||
@ -1283,11 +1283,11 @@ SHA256 of host's public key. See CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256(3)
|
||||
|
||||
## CURLOPT_SSH_PUBLIC_KEYFILE
|
||||
|
||||
File name of public key. See CURLOPT_SSH_PUBLIC_KEYFILE(3)
|
||||
Filename of the public key. See CURLOPT_SSH_PUBLIC_KEYFILE(3)
|
||||
|
||||
## CURLOPT_SSH_PRIVATE_KEYFILE
|
||||
|
||||
File name of private key. See CURLOPT_SSH_PRIVATE_KEYFILE(3)
|
||||
Filename of the private key. See CURLOPT_SSH_PRIVATE_KEYFILE(3)
|
||||
|
||||
## CURLOPT_SSH_KNOWNHOSTS
|
||||
|
||||
|
@ -144,8 +144,8 @@ internally chosen one.
|
||||
## CURLFORM_FILENAME
|
||||
|
||||
is used in combination with *CURLFORM_FILE*. Followed by a pointer to a
|
||||
string, it tells libcurl to use the given string as the *filename* in the
|
||||
file upload part instead of the actual file name.
|
||||
string, it tells libcurl to use the given string as the *filename* in the file
|
||||
upload part instead of the actual filename.
|
||||
|
||||
## CURLFORM_BUFFER
|
||||
|
||||
|
@ -83,7 +83,7 @@ Details about HTTP/3 handling: connect, frames, events, I/O etc.
|
||||
|
||||
## http-proxy
|
||||
|
||||
Involved when transfers are tunneled through a HTTP proxy. "h1-proxy" or
|
||||
Involved when transfers are tunneled through an HTTP proxy. "h1-proxy" or
|
||||
"h2-proxy" are also involved, depending on the HTTP version negotiated with
|
||||
the proxy.
|
||||
|
||||
|
@ -103,8 +103,8 @@ independently set this field.
|
||||
|
||||
## CURLUPART_HOST
|
||||
|
||||
The host name. If it is International Domain Name (IDN) the string must then
|
||||
be encoded as your locale says or UTF-8 (when WinIDN is used). If it is a
|
||||
The hostname. If it is International Domain Name (IDN) the string must then be
|
||||
encoded as your locale says or UTF-8 (when WinIDN is used). If it is a
|
||||
bracketed IPv6 numeric address it may contain a zone id (or you can use
|
||||
*CURLUPART_ZONEID*).
|
||||
|
||||
@ -180,9 +180,9 @@ are set.
|
||||
|
||||
If set, allows the URL to be set without a scheme and it instead "guesses"
|
||||
which scheme that was intended based on the hostname. If the outermost
|
||||
subdomain name matches DICT, FTP, IMAP, LDAP, POP3 or SMTP then that scheme
|
||||
is used, otherwise it picks HTTP. Conflicts with the
|
||||
*CURLU_DEFAULT_SCHEME* option which takes precedence if both are set.
|
||||
subdomain name matches DICT, FTP, IMAP, LDAP, POP3 or SMTP then that scheme is
|
||||
used, otherwise it picks HTTP. Conflicts with the *CURLU_DEFAULT_SCHEME*
|
||||
option which takes precedence if both are set.
|
||||
|
||||
## CURLU_NO_AUTHORITY
|
||||
|
||||
|
@ -115,4 +115,4 @@ Debug-version of the *ntlm-wb* executable.
|
||||
## CURL_OPENLDAP_TRACE
|
||||
|
||||
OpenLDAP tracing is enabled if this variable exists and its value is 1 or
|
||||
greater. There's a number of debug levels, refer to *openldap.c* comments.
|
||||
greater. There is a number of debug levels, refer to *openldap.c* comments.
|
||||
|
@ -398,9 +398,9 @@ Failed to shut down the SSL connection.
|
||||
|
||||
## CURLE_AGAIN (81)
|
||||
|
||||
Socket is not ready for send/recv wait till it's ready and try again. This
|
||||
return code is only returned from curl_easy_recv(3) and
|
||||
curl_easy_send(3) (Added in 7.18.2)
|
||||
Socket is not ready for send/recv. Wait until it is ready and try again. This
|
||||
return code is only returned from curl_easy_recv(3) and curl_easy_send(3)
|
||||
(Added in 7.18.2)
|
||||
|
||||
## CURLE_SSL_CRL_BADFILE (82)
|
||||
|
||||
|
@ -393,13 +393,12 @@ transactions.
|
||||
# Server-supplied Names
|
||||
|
||||
A server can supply data which the application may, in some cases, use as a
|
||||
file name. The curl command-line tool does this with
|
||||
*--remote-header-name*, using the Content-disposition: header to generate
|
||||
a file name. An application could also use CURLINFO_EFFECTIVE_URL(3) to
|
||||
generate a file name from a server-supplied redirect URL. Special care must be
|
||||
taken to sanitize such names to avoid the possibility of a malicious server
|
||||
supplying one like **"/etc/passwd"**, **"autoexec.bat"**, **"prn:"**
|
||||
or even **".bashrc"**.
|
||||
filename. The curl command-line tool does this with *--remote-header-name*,
|
||||
using the Content-disposition: header to generate a filename. An application
|
||||
could also use CURLINFO_EFFECTIVE_URL(3) to generate a filename from a
|
||||
server-supplied redirect URL. Special care must be taken to sanitize such
|
||||
names to avoid the possibility of a malicious server supplying one like
|
||||
**"/etc/passwd"**, **"autoexec.bat"**, **"prn:"** or even **".bashrc"**.
|
||||
|
||||
# Server Certificates
|
||||
|
||||
|
@ -739,9 +739,8 @@ becomes:
|
||||
curl_mime_filename(part, NULL);
|
||||
~~~
|
||||
|
||||
Use of curl_mime_filedata(3) sets the remote file name as a side effect:
|
||||
it is therefore necessary to clear it for *CURLFORM_FILECONTENT*
|
||||
emulation.
|
||||
Use of curl_mime_filedata(3) sets the remote filename as a side effect: it is
|
||||
therefore necessary to clear it for *CURLFORM_FILECONTENT* emulation.
|
||||
|
||||
# Showing Progress
|
||||
|
||||
@ -757,8 +756,8 @@ instead is interesting is the ability to specify a progress callback. The
|
||||
function pointer you pass to libcurl is then called on irregular intervals
|
||||
with information about the current transfer.
|
||||
|
||||
Set the progress callback by using CURLOPT_PROGRESSFUNCTION(3). And pass
|
||||
a pointer to a function that matches this prototype:
|
||||
Set the progress callback by using CURLOPT_PROGRESSFUNCTION(3). Pass a pointer
|
||||
to a function that matches this prototype:
|
||||
|
||||
~~~c
|
||||
int progress_callback(void *clientp,
|
||||
@ -913,7 +912,7 @@ for such innovative actions either!
|
||||
## Proxy Auto-Config
|
||||
|
||||
Netscape first came up with this. It is basically a webpage (usually using a
|
||||
&.pac extension) with a JavaScript that when executed by the browser with the
|
||||
.pac extension) with a JavaScript that when executed by the browser with the
|
||||
requested URL as input, returns information to the browser on how to connect
|
||||
to the URL. The returned information might be "DIRECT" (which means no proxy
|
||||
should be used), "PROXY host:port" (to tell the browser where the proxy for
|
||||
@ -1180,10 +1179,10 @@ libcurl automatically finds out what kind of file it is and acts accordingly.
|
||||
Perhaps the most advanced cookie operation libcurl offers, is saving the
|
||||
entire internal cookie state back into a Netscape/Mozilla formatted cookie
|
||||
file. We call that the cookie-jar. When you set a filename with
|
||||
CURLOPT_COOKIEJAR(3), that file name is created and all received cookies
|
||||
get stored in it when curl_easy_cleanup(3) is called. This enables
|
||||
cookies to get passed on properly between multiple handles without any
|
||||
information getting lost.
|
||||
CURLOPT_COOKIEJAR(3), that filename is created and all received cookies get
|
||||
stored in it when curl_easy_cleanup(3) is called. This enables cookies to get
|
||||
passed on properly between multiple handles without any information getting
|
||||
lost.
|
||||
|
||||
# FTP Peculiarities We Need
|
||||
|
||||
|
@ -195,12 +195,12 @@ and end of the program -- that is just usually the easiest way to do it.
|
||||
You can call both of these multiple times, as long as all calls meet
|
||||
these requirements and the number of calls to each is the same.
|
||||
|
||||
The global constant situation merits special consideration when the
|
||||
code you are writing to use libcurl is not the main program, but rather
|
||||
a modular piece of a program, e.g. another library. As a module,
|
||||
your code does not know about other parts of the program -- it does not
|
||||
know whether they use libcurl or not. And its code does not necessarily
|
||||
run at the start and end of the whole program.
|
||||
The global constant situation merits special consideration when the code you
|
||||
are writing to use libcurl is not the main program, but rather a modular piece
|
||||
of a program, e.g. another library. As a module, your code does not know about
|
||||
other parts of the program -- it does not know whether they use libcurl or
|
||||
not. Its code does not necessarily run at the start and end of the whole
|
||||
program.
|
||||
|
||||
A module like this must have global constant functions of its own, just like
|
||||
curl_global_init(3) and curl_global_cleanup(3). The module thus
|
||||
|
@ -107,9 +107,9 @@ retrieve a second in-use SSL session associated with an easy handle.
|
||||
|
||||
This option has not been thoroughly tested with clear text protocols that can
|
||||
be upgraded/downgraded to/from SSL: FTP, SMTP, POP3, IMAP when used with
|
||||
CURLOPT_USE_SSL(3). Though you can to retrieve the SSL pointer, it's
|
||||
possible that before you can do that, data (including auth) may have already
|
||||
been sent over a connection after it was upgraded.
|
||||
CURLOPT_USE_SSL(3). Though you can to retrieve the SSL pointer, it is possible
|
||||
that before you can do that, data (including auth) may have already been sent
|
||||
over a connection after it was upgraded.
|
||||
|
||||
Renegotiation. If unsafe renegotiation or renegotiation in a way that the
|
||||
certificate is allowed to change is allowed by your SSL library this may occur
|
||||
|
@ -24,12 +24,12 @@ CURLMcode curl_multi_setopt(CURLM *handle, CURLMOPT_MAX_HOST_CONNECTIONS,
|
||||
|
||||
# DESCRIPTION
|
||||
|
||||
Pass a long to indicate **max**. The set number is used as the maximum
|
||||
amount of simultaneously open connections to a single host (a host being the
|
||||
same as a host name + port number pair). For each new session to a host,
|
||||
libcurl might open a new connection up to the limit set by
|
||||
CURLMOPT_MAX_HOST_CONNECTIONS(3). When the limit is reached, new
|
||||
sessions are kept pending until a connection becomes available.
|
||||
Pass a long to indicate **max**. The set number is used as the maximum amount
|
||||
of simultaneously open connections to a single host (a host being the same as
|
||||
a hostname + port number pair). For each new session to a host, libcurl might
|
||||
open a new connection up to the limit set by
|
||||
CURLMOPT_MAX_HOST_CONNECTIONS(3). When the limit is reached, new sessions are
|
||||
kept pending until a connection becomes available.
|
||||
|
||||
The default **max** value is 0, unlimited. This set limit is also used for
|
||||
proxy connections, and then the proxy is considered to be the host for which
|
||||
|
@ -45,8 +45,8 @@ It is extracted from the host name specified in the URL if omitted.
|
||||
|
||||
## service
|
||||
|
||||
The argument is a function provided by a cloud.
|
||||
It is extracted from the host name specified in the URL if omitted.
|
||||
The argument is a function provided by a cloud. It is extracted from the
|
||||
hostname specified in the URL if omitted.
|
||||
|
||||
NOTE: This call set CURLOPT_HTTPAUTH(3) to CURLAUTH_AWS_SIGV4.
|
||||
Calling CURLOPT_HTTPAUTH(3) with CURLAUTH_AWS_SIGV4 is the same
|
||||
@ -109,8 +109,8 @@ method special. This method cannot be combined with other auth types.
|
||||
|
||||
A sha256 checksum of the request payload is used as input to the signature
|
||||
calculation. For POST requests, this is a checksum of the provided
|
||||
CURLOPT_POSTFIELDS(3). Otherwise, it's the checksum of an empty buffer.
|
||||
For requests like PUT, you can provide your own checksum in an HTTP header named
|
||||
CURLOPT_POSTFIELDS(3). Otherwise, it is the checksum of an empty buffer. For
|
||||
requests like PUT, you can provide your own checksum in an HTTP header named
|
||||
**x-provider2-content-sha256**.
|
||||
|
||||
For **aws:s3**, a **x-amz-content-sha256** header is added to every request
|
||||
|
@ -32,8 +32,8 @@ Such a cookie can be either a single line in Netscape / Mozilla format or just
|
||||
regular HTTP-style header (Set-Cookie: ...) format. This option also enables
|
||||
the cookie engine. This adds that single cookie to the internal cookie store.
|
||||
|
||||
We strongly advice against loading cookies from a HTTP header file, as that is
|
||||
an inferior data exchange format.
|
||||
We strongly advice against loading cookies from an HTTP header file, as that
|
||||
is an inferior data exchange format.
|
||||
|
||||
Exercise caution if you are using this option and multiple transfers may
|
||||
occur. If you use the Set-Cookie format and the string does not specify a
|
||||
|
@ -27,8 +27,8 @@ CURLcode curl_easy_setopt(CURL *handle, CURLOPT_FOLLOWLOCATION, long enable);
|
||||
# DESCRIPTION
|
||||
|
||||
A long parameter set to 1 tells the library to follow any Location: header
|
||||
redirects that a HTTP server sends in a 30x response. The Location: header can
|
||||
specify a relative or an absolute URL to follow.
|
||||
redirects that an HTTP server sends in a 30x response. The Location: header
|
||||
can specify a relative or an absolute URL to follow.
|
||||
|
||||
libcurl issues another request for the new URL and follows subsequent new
|
||||
Location: redirects all the way until no more such headers are returned or the
|
||||
|
@ -59,7 +59,7 @@ accept response data is used instead. That is the function specified with
|
||||
CURLOPT_WRITEFUNCTION(3), or if it is not specified or NULL - the
|
||||
default, stream-writing function.
|
||||
|
||||
It's important to note that the callback is invoked for the headers of all
|
||||
It is important to note that the callback is invoked for the headers of all
|
||||
responses received after initiating a request and not just the final
|
||||
response. This includes all responses which occur during authentication
|
||||
negotiation. If you need to operate on only the headers from the final
|
||||
|
@ -93,8 +93,8 @@ providing the Content-Length: field in the request.
|
||||
|
||||
# SPECIFIC MIME HEADERS
|
||||
|
||||
When used to build a MIME e-mail for IMAP or SMTP, the following
|
||||
document-level headers can be set to override libcurl-generated values:
|
||||
When used to build a MIME email for IMAP or SMTP, the following document-level
|
||||
headers can be set to override libcurl-generated values:
|
||||
|
||||
## Mime-Version:
|
||||
|
||||
|
@ -29,7 +29,7 @@ Pass *version* a long, set to one of the values described below. They ask
|
||||
libcurl to use the specific HTTP versions.
|
||||
|
||||
Note that the HTTP version is just a request. libcurl still prioritizes to
|
||||
reuse existing connections so it might then reuse a connection using a HTTP
|
||||
reuse existing connections so it might then reuse a connection using an HTTP
|
||||
version you have not asked for.
|
||||
|
||||
## CURL_HTTP_VERSION_NONE
|
||||
|
@ -34,8 +34,8 @@ mandatory.
|
||||
|
||||
To unset this value again, set it to -1.
|
||||
|
||||
Using CURLOPT_UPLOAD(3) to a HTTP/1.1 server and this value set to -1,
|
||||
makes libcurl do a chunked transfer-encoded upload.
|
||||
Using CURLOPT_UPLOAD(3) to an HTTP/1.1 server and this value set to -1, makes
|
||||
libcurl do a chunked transfer-encoded upload.
|
||||
|
||||
When sending emails using SMTP, this command can be used to specify the
|
||||
optional SIZE parameter for the MAIL FROM command.
|
||||
|
@ -43,8 +43,8 @@ HTTP browsers used to do backslash-escaping in the past but have over time
|
||||
transitioned to use percent-encoding. This option allows one to address
|
||||
server-side applications that have not yet have been converted.
|
||||
|
||||
As an example, consider field or file name *strangename"kind*.
|
||||
When the containing multipart form is sent, this is normally transmitted as
|
||||
As an example, consider field or filename *strangename"kind*. When the
|
||||
containing multipart form is sent, this is normally transmitted as
|
||||
*strangename%22kind*. When this option is set, it is sent as
|
||||
*strangename"kind*.
|
||||
|
||||
|
@ -61,9 +61,9 @@ If you issue a POST request and then want to make a HEAD or GET using the same
|
||||
reused handle, you must explicitly set the new request type using
|
||||
CURLOPT_NOBODY(3) or CURLOPT_HTTPGET(3) or similar.
|
||||
|
||||
When setting CURLOPT_POST(3) to 0, libcurl resets the request type to
|
||||
the default to disable the POST. Typically that would mean it's reset to GET.
|
||||
Instead you should set a new request type explicitly as described above.
|
||||
When setting CURLOPT_POST(3) to 0, libcurl resets the request type to the
|
||||
default to disable the POST. Typically that means gets reset to GET. Instead
|
||||
you should set a new request type explicitly as described above.
|
||||
|
||||
# DEFAULT
|
||||
|
||||
|
@ -23,10 +23,9 @@ CURLcode curl_easy_setopt(CURL *handle, CURLOPT_PRE_PROXY, char *preproxy);
|
||||
|
||||
# DESCRIPTION
|
||||
|
||||
Set the *preproxy* to use for the upcoming request. The parameter
|
||||
should be a char * to a null-terminated string holding the host name or dotted
|
||||
numerical IP address. A numerical IPv6 address must be written within
|
||||
[brackets].
|
||||
Set the *preproxy* to use for the upcoming request. The parameter should be a
|
||||
char * to a null-terminated string holding the hostname or dotted numerical IP
|
||||
address. A numerical IPv6 address must be written within [brackets].
|
||||
|
||||
To specify port number in this string, append :[port] to the end of the host
|
||||
name. The proxy's port number may optionally be specified with the separate
|
||||
|
@ -95,15 +95,15 @@ cannot be used.
|
||||
# Environment variables
|
||||
|
||||
libcurl respects the proxy environment variables named **http_proxy**,
|
||||
**ftp_proxy**, **sftp_proxy** etc. If set, libcurl uses the specified
|
||||
proxy for that URL scheme. So for a "FTP://" URL, the **ftp_proxy** is
|
||||
**ftp_proxy**, **sftp_proxy** etc. If set, libcurl uses the specified proxy
|
||||
for that URL scheme. For an "FTP://" URL, the **ftp_proxy** is
|
||||
considered. **all_proxy** is used if no protocol specific proxy was set.
|
||||
|
||||
If **no_proxy** (or **NO_PROXY**) is set, it is the exact equivalent of
|
||||
setting the CURLOPT_NOPROXY(3) option.
|
||||
|
||||
The CURLOPT_PROXY(3) and CURLOPT_NOPROXY(3) options override
|
||||
environment variables.
|
||||
The CURLOPT_PROXY(3) and CURLOPT_NOPROXY(3) options override environment
|
||||
variables.
|
||||
|
||||
# DEFAULT
|
||||
|
||||
|
@ -49,8 +49,8 @@ the option is zero, the peer certificate verification succeeds regardless.
|
||||
Authenticating the certificate is not enough to be sure about the server. You
|
||||
typically also want to ensure that the server is the server you mean to be
|
||||
talking to. Use CURLOPT_PROXY_SSL_VERIFYHOST(3) for that. The check that the
|
||||
host name in the certificate is valid for the host name you are connecting to
|
||||
is done independently of the CURLOPT_PROXY_SSL_VERIFYPEER(3) option.
|
||||
hostname in the certificate is valid for the hostname you are connecting to is
|
||||
done independently of the CURLOPT_PROXY_SSL_VERIFYPEER(3) option.
|
||||
|
||||
WARNING: disabling verification of the certificate allows bad guys to
|
||||
man-in-the-middle the communication without you knowing it. Disabling
|
||||
|
@ -28,8 +28,8 @@ CURLcode curl_easy_setopt(CURL *handle, CURLOPT_RESOLVE,
|
||||
Pass a pointer to a linked list of strings with hostname resolve information
|
||||
to use for requests with this handle. The linked list should be a fully valid
|
||||
list of **struct curl_slist** structs properly filled in. Use
|
||||
curl_slist_append(3) to create the list and curl_slist_free_all(3)
|
||||
to clean up an entire list.
|
||||
curl_slist_append(3) to create the list and curl_slist_free_all(3) to clean up
|
||||
an entire list.
|
||||
|
||||
Each resolve rule to add should be written using the format
|
||||
|
||||
|
@ -33,9 +33,9 @@ shown above.
|
||||
This callback function gets called by libcurl every time before a new resolve
|
||||
request is started.
|
||||
|
||||
*resolver_state* points to a backend-specific resolver state. Currently
|
||||
only the ares resolver backend has a resolver state. It can be used to set up
|
||||
any desired option on the ares channel before it's used, for example setting up
|
||||
*resolver_state* points to a backend-specific resolver state. Currently only
|
||||
the ares resolver backend has a resolver state. It can be used to set up any
|
||||
desired option on the ares channel before it is used, for example setting up
|
||||
socket callback options.
|
||||
|
||||
*reserved* is reserved.
|
||||
|
@ -86,15 +86,14 @@ an empty GET_PARAMETER request.
|
||||
|
||||
## CURL_RTSPREQ_SET_PARAMETER
|
||||
|
||||
Set a parameter on the server. By default, libcurl uses a
|
||||
*Content-Type: text/parameters* header unless a custom one is set.
|
||||
The interaction with SET_PARAMETER is much like an HTTP PUT or POST. An
|
||||
application may either use CURLOPT_UPLOAD(3) with
|
||||
CURLOPT_READDATA(3) like a HTTP PUT, or it may use
|
||||
CURLOPT_POSTFIELDS(3) like an HTTP POST. No chunked transfers are
|
||||
allowed, so the application must set the CURLOPT_INFILESIZE(3) in the
|
||||
former and CURLOPT_POSTFIELDSIZE(3) in the latter. Also, there is no use
|
||||
of multi-part POSTs within RTSP.
|
||||
Set a parameter on the server. By default, libcurl uses a *Content-Type:
|
||||
text/parameters* header unless a custom one is set. The interaction with
|
||||
SET_PARAMETER is much like an HTTP PUT or POST. An application may either use
|
||||
CURLOPT_UPLOAD(3) with CURLOPT_READDATA(3) like an HTTP PUT, or it may use
|
||||
CURLOPT_POSTFIELDS(3) like an HTTP POST. No chunked transfers are allowed, so
|
||||
the application must set the CURLOPT_INFILESIZE(3) in the former and
|
||||
CURLOPT_POSTFIELDSIZE(3) in the latter. Also, there is no use of multi-part
|
||||
POSTs within RTSP.
|
||||
|
||||
## CURL_RTSPREQ_RECORD
|
||||
|
||||
|
@ -25,8 +25,8 @@ CURLcode curl_easy_setopt(CURL *handle, CURLOPT_SSLCERT, char *cert);
|
||||
# DESCRIPTION
|
||||
|
||||
Pass a pointer to a null-terminated string as parameter. The string should be
|
||||
the file name of your client certificate. The default format is "P12" on
|
||||
Secure Transport and "PEM" on other engines, and can be changed with
|
||||
the filename of your client certificate. The default format is "P12" on Secure
|
||||
Transport and "PEM" on other engines, and can be changed with
|
||||
CURLOPT_SSLCERTTYPE(3).
|
||||
|
||||
With Secure Transport, this can also be the nickname of the certificate you
|
||||
|
@ -32,8 +32,8 @@ If the blob is initialized with the flags member of struct curl_blob set to
|
||||
CURL_BLOB_COPY, the application does not have to keep the buffer around after
|
||||
setting this.
|
||||
|
||||
This option is an alternative to CURLOPT_SSLKEY(3) which instead expects
|
||||
a file name as input.
|
||||
This option is an alternative to CURLOPT_SSLKEY(3) which instead expects a
|
||||
filename as input.
|
||||
|
||||
# DEFAULT
|
||||
|
||||
|
@ -49,9 +49,9 @@ and the peer certificate verification is simply skipped.
|
||||
|
||||
Authenticating the certificate is not enough to be sure about the server. You
|
||||
typically also want to ensure that the server is the server you mean to be
|
||||
talking to. Use CURLOPT_SSL_VERIFYHOST(3) for that. The check that the
|
||||
host name in the certificate is valid for the host name you are connecting to
|
||||
is done independently of the CURLOPT_SSL_VERIFYPEER(3) option.
|
||||
talking to. Use CURLOPT_SSL_VERIFYHOST(3) for that. The check that the host
|
||||
name in the certificate is valid for the hostname you are connecting to is
|
||||
done independently of the CURLOPT_SSL_VERIFYPEER(3) option.
|
||||
|
||||
WARNING: disabling verification of the certificate allows bad guys to
|
||||
man-in-the-middle the communication without you knowing it. Disabling
|
||||
|
@ -38,10 +38,10 @@ sent to the server the next time an HTTP/2 frame is sent to the server.
|
||||
See section 5.3 of RFC 7540 for protocol details.
|
||||
|
||||
Streams with the same parent should be allocated resources proportionally
|
||||
based on their weight. So if you have two streams going, stream A with weight
|
||||
16 and stream B with weight 32, stream B gets two thirds (32/48) of the
|
||||
available bandwidth (assuming the server can send off the data equally for
|
||||
both streams).
|
||||
based on their weight. If you have two streams going, stream A with weight 16
|
||||
and stream B with weight 32, stream B gets two thirds (32/48) of the available
|
||||
bandwidth (assuming the server can send off the data equally for both
|
||||
streams).
|
||||
|
||||
# DEFAULT
|
||||
|
||||
|
@ -28,7 +28,7 @@ When CURLOPT_HTTPPROXYTUNNEL(3) is used and a CONNECT request is made,
|
||||
suppress proxy CONNECT response headers from the user callback functions
|
||||
CURLOPT_HEADERFUNCTION(3) and CURLOPT_WRITEFUNCTION(3).
|
||||
|
||||
Proxy CONNECT response headers can complicate header processing since it's
|
||||
Proxy CONNECT response headers can complicate header processing since it is
|
||||
essentially a separate set of headers. You can enable this option to suppress
|
||||
those headers.
|
||||
|
||||
|
@ -42,10 +42,9 @@ password to other sites.
|
||||
|
||||
This option should be used with caution: when curl follows redirects it
|
||||
blindly fetches the next URL as instructed by the server. Setting
|
||||
CURLOPT_UNRESTRICTED_AUTH(3) to 1L therefore also makes curl trust the
|
||||
server and sends possibly sensitive credentials to any host the server points
|
||||
out. And then maybe again and again as the following hosts can keep
|
||||
redirecting to new hosts.
|
||||
CURLOPT_UNRESTRICTED_AUTH(3) to 1L makes curl trust the server and sends
|
||||
possibly sensitive credentials to any host the server points to, possibly
|
||||
again and again as the following hosts can keep redirecting to new hosts.
|
||||
|
||||
# DEFAULT
|
||||
|
||||
|
@ -50,10 +50,10 @@ default protocol, see CURLOPT_DEFAULT_PROTOCOL(3) for details.
|
||||
|
||||
Should the protocol, either as specified by the URL scheme or deduced by
|
||||
libcurl from the hostname, not be supported by libcurl then
|
||||
*CURLE_UNSUPPORTED_PROTOCOL* is returned from either the
|
||||
curl_easy_perform(3) or curl_multi_perform(3) functions when you
|
||||
call them. Use curl_version_info(3) for detailed information of which
|
||||
protocols are supported by the build of libcurl you are using.
|
||||
*CURLE_UNSUPPORTED_PROTOCOL* is returned from either the curl_easy_perform(3)
|
||||
or curl_multi_perform(3) functions when you call them. Use
|
||||
curl_version_info(3) for detailed information of which protocols are supported
|
||||
by the build of libcurl you are using.
|
||||
|
||||
CURLOPT_PROTOCOLS_STR(3) can be used to limit what protocols libcurl may
|
||||
use for this transfer, independent of what libcurl has been compiled to
|
||||
|
@ -43,12 +43,12 @@ respectively.
|
||||
Some HTTP servers (on Windows) support inclusion of the domain for Basic
|
||||
authentication as well.
|
||||
|
||||
When using HTTP and CURLOPT_FOLLOWLOCATION(3), libcurl might perform
|
||||
several requests to possibly different hosts. libcurl only sends this user and
|
||||
When using HTTP and CURLOPT_FOLLOWLOCATION(3), libcurl might perform several
|
||||
requests to possibly different hosts. libcurl only sends this user and
|
||||
password information to hosts using the initial hostname (unless
|
||||
CURLOPT_UNRESTRICTED_AUTH(3) is set), so if libcurl follows redirects to
|
||||
other hosts, it does not send the user and password to those. This is enforced
|
||||
to prevent accidental information leakage.
|
||||
CURLOPT_UNRESTRICTED_AUTH(3) is set), so if libcurl follows redirects to other
|
||||
hosts, it does not send the user and password to those. This is enforced to
|
||||
prevent accidental information leakage.
|
||||
|
||||
Use CURLOPT_HTTPAUTH(3) to specify the authentication method for HTTP
|
||||
based connections or CURLOPT_LOGIN_OPTIONS(3) to control IMAP, POP3 and
|
||||
|
@ -26,9 +26,9 @@ CURLcode curl_easy_setopt(CURL *handle, CURLOPT_WILDCARDMATCH, long onoff);
|
||||
# DESCRIPTION
|
||||
|
||||
Set *onoff* to 1 if you want to transfer multiple files according to a
|
||||
file name pattern. The pattern can be specified as part of the
|
||||
CURLOPT_URL(3) option, using an **fnmatch**-like pattern (Shell
|
||||
Pattern Matching) in the last part of URL (file name).
|
||||
filename pattern. The pattern can be specified as part of the CURLOPT_URL(3)
|
||||
option, using an **fnmatch**-like pattern (Shell Pattern Matching) in the last
|
||||
part of URL (filename).
|
||||
|
||||
By default, libcurl uses its internal wildcard matching implementation. You
|
||||
can provide your own matching function by the
|
||||
@ -38,18 +38,16 @@ A brief introduction of its syntax follows:
|
||||
|
||||
## * - ASTERISK
|
||||
|
||||
~~~c
|
||||
ftp://example.com/some/path/*.txt
|
||||
~~~
|
||||
|
||||
for all txt's from the root directory. Only two asterisks are allowed within
|
||||
the same pattern string.
|
||||
|
||||
## ? - QUESTION MARK
|
||||
|
||||
Question mark matches any (exactly one) character.
|
||||
~~~c
|
||||
|
||||
ftp://example.com/some/path/photo?.jpg
|
||||
~~~
|
||||
|
||||
## [ - BRACKET EXPRESSION
|
||||
|
||||
@ -63,9 +61,9 @@ right bracket and matches exactly one character. Some examples follow:
|
||||
|
||||
**[^abc]** or **[!abc]** - negation
|
||||
|
||||
**[[:name:]]** class expression. Supported classes are
|
||||
**alnum**,**lower**, **space**, **alpha**, **digit**, **print**,
|
||||
**upper**, **blank**, **graph**, **xdigit**.
|
||||
**[[:name:]]** class expression. Supported classes are **alnum**,**lower**,
|
||||
**space**, **alpha**, **digit**, **print**, **upper**, **blank**, **graph**,
|
||||
**xdigit**.
|
||||
|
||||
**[][-!^]** - special case - matches only '-', ']', '[', '!' or '^'. These
|
||||
characters have no special purpose.
|
||||
@ -73,9 +71,8 @@ characters have no special purpose.
|
||||
**[[]]** - escape syntax. Matches '[', ']' or 'e'.
|
||||
|
||||
Using the rules above, a filename pattern can be constructed:
|
||||
~~~c
|
||||
|
||||
ftp://example.com/some/path/[a-z[:upper:]\\].jpg
|
||||
~~~
|
||||
|
||||
# PROTOCOLS
|
||||
|
||||
@ -84,7 +81,6 @@ This feature is only supported for FTP download.
|
||||
# EXAMPLE
|
||||
|
||||
~~~c
|
||||
|
||||
extern long begin_cb(struct curl_fileinfo *, void *, int);
|
||||
extern long end_cb(void *ptr);
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user