romenskiy2012/curl
1
0
Fork 0
mirror of https://github.com/curl/curl.git synced 2026-06-14 17:05:37 +03:00
Code Issues Projects Releases Packages Wiki Activity

lib: transfer origin and proxy handling

Browse source 
Add `data->state.origin` as the origin the transfer is sending the
current request to/gets the response from. Use it for request specific
properties like authentication, hsts and cookie handling, etc.

Unless talking to a forwarding HTTP proxy (e.g. not tunneling),
`data->state.origin` and `conn->origin` are the same.

With a forwarding HTTP proxy in play, `conn->origin` is set to
`conn->http_proxy.peer` and `conn->bits.origin_is_proxy` (a new bit) is
set.

Remove the connection bits, now replaced with:

* `conn->bits.socksproxy` -> `conn->socks_proy.peer`
* `conn->bits.httpproxy` -> `conn->http_proy.peer`
* `conn->bits.proxy` -> `(conn->socks_proy.peer || conn->http_proy.peer`)
* `conn->bits.tunnel_proxy` -> (`conn->http_proy.peer && !conn->bits.origin_is_proxy`)
* `(conn->bits.httpproxy && !conn->bits.tunnel_proxy)` -> `conn->bits.origin_is_proxy`

Rename `noproxy.[ch]` to `proxy.[ch]`. Move the connection proxy setup
code from `url.c` to `proxy.c`.

Remove `data->info.conn_remote_port` as no one uses it.

Add test_40_02b for a SOCKS connection to a forwarding HTTPS proxy.

Update internal documentation about peers and creds.

Closes #21967
This commit is contained in:
Stefan Eissing 2026-06-12 12:02:08 +02:00 • committed by Daniel Stenberg
parent c951368579
commit 73daec6620
No known key found for this signature in database
GPG key ID: 5CC908FDB71E12C2
30 changed files with 1083 additions and 1014 deletions
Download patch file Download diff file Expand all files Collapse all files

7
docs/internals/CREDENTIALS.md
View file

@ -38,9 +38,10 @@ suitable connection. For an `easy_perform()` this may happen several times
if, for example, http redirects are followed.
When an `easy_perform()` starts, the transfer's `data->state.initial_origin`
peer is cleared. When creating the connection, `conn->origin` is calculated
(e.g. who the request talks to). If `data->state.initial_origin` is not
set, the first `conn->origin` is linked there. Now `libcurl` knows where
peer is cleared. When creating the connection, `data->state.origin` is
calculated (e.g. who the request talks to). If `data->state.initial_origin`
is not set, the first `data->state.origin` is linked there.
Now `libcurl` knows where
the transfer initially talked to on all possible subsequent requests.
Credential information from `CURLOPT_*` settings is only applicable for the

27
docs/internals/PEERS.md
View file

@ -20,13 +20,25 @@ A `peer` in curl internals is represented by a `struct Curl_peer`. It has the fo
A peer, in short, is a communication endpoint.
## peers and transfers
The peer a transfer, e.g. easy handle, works against is determined at the
start of each request. It is kept in `data->state.origin`. For the first
request done in a `curl_easy_perform()` or equivalent, this origin is
linked to `data->state.initial_origin`. This allows checks if properties
of `data->set.*` should apply to a request or not.
`data->state.origin` is relevant for cookie processing, signing requests
and other request/response based processing.
## peers and connections
A network connection always goes *somewhere*. That *somewhere* is called
the `origin` of the connection (e.g. the source of responses/downloads).
It is kept in `conn->origin` and is always present in a connection.
The `origin` is *logical* endpoint a connection talks to.
The `origin` is *logical* endpoint a connection talks to. In most
configurations it is the same as `data->state.origin` (see proxies below).
For most connections, the `origin` is connected to *directly*. It
can be directed to another peer, however.
@ -56,6 +68,19 @@ might connect as:
5. curl --> socks_proxy.peer --> http_proxy.peer --> conn->via_peer/origin
```
A `conn->(socks|http)_proxy.peer` is only ever present when the proxy
is in use and `NULL` otherwise.
SOCKS proxies are always used for tunneling, either to the origin or
the HTTP proxy. They operate in a connection filter.
HTTP proxies can operate in two modes: tunneling or forwarding. When tunneling,
they also operate in a connection filter. In forwarding mode however, they
become the `origin` the connection talks to.
Therefore, connections that talk to a forwarding HTTP proxy have `conn->origin`
set to `conn->http_proxy.peer` and `conn->bits.origin_is_proxy` is set.
The connection filter `SETUP`, that assembles the filters for a connection,
figures out which peer to pass to which filter in order to make it all work.
The individual filters get passed a specific peer and do not need be concerned