Module client 

Deciding which address a request actually came from.

Every connection-level filter rests on this answer, so getting it wrong either locks out legitimate clients or hands an attacker a trivial bypass.

Two deployments have to work:

• Direct. The socket peer address is the client. Nothing else is believed, and a forwarded-for header from a client that made it up is ignored.
• Behind a reverse proxy. Every peer is the proxy, so the real client only exists in a header. That header is believed only when the peer is itself listed in filter.trusted_proxies — otherwise anyone could set X-Forwarded-For: 10.0.0.1 and inherit an allowlisted address.

The default is the direct case with an empty trusted list, i.e. headers are never believed.

Beside that answer sit the other two things every layer that records or checks where a request came from shares: the address helpers (parse_net, canonical, [nets_contain]) and the request id (RequestId). They live here, below the filters, the audit trail and the middlewares that all read them, rather than in any one of those.

Structs

ClientIp

The client address for a request, inserted into the request extensions by add_filter_middleware so handlers can pass it to the identifier hook.

ProxyPolicy

How to derive a client address from the socket peer plus request headers.

RequestId

Extension wrapper for the HTTP Request ID.

Functions

canonical

Normalizes an address for comparison.

parse_net

Parses one allow-list entry as a network.

parse_nets

Parses a list of network entries, naming the setting in any error.