Components of the cache key that stand for something this request
said - the coding it accepts, the image formats it takes - and that
another request for the same url has others in the place of.
Represents the state of a request/response cycle, tracking various metrics and properties
including connection details, caching information, and upstream server interactions.
An Inflight type tracks the frequency of actions that are actively occurring. When the value
is dropped from scope, the count will automatically decrease.
One request in flight on a backend, for as long as this is kept: the
count goes up when it is made and down when it is dropped, whichever
way the request ends.
Takes the place of a plugin that a location names but that is not loaded:
the name is misspelled, or the plugin failed to build. It fails every
request of that location.
What pingora’s own connector takes from the peer for the socket it
opens. A connector that stands in for it is given the address and
nothing else, so these come with it.
A Ctx value the access log can print. The {:name} in a log format
parses into one of these once, when the format is read, so writing a
log line dispatches on an enum instead of comparing the name against
every key on every request.
The names access_log accepts in place of a format. Here, and not with
the formats themselves in pingap-logger, so that the config validation
knows a preset from a word that is none.
The most a notification that could not be delivered is sent again.
Each wait is twice the one before, from a second: ten of them are a
quarter of an hour, by which time it is news no longer.
What a plugin does with the body of the request as it is passed on to
the upstream: looks at it (a digest to check) or keeps a copy of it (a
mirror). It does not change it.
The value of a header as one component of the cache key. The
components are joined with :, so one inside a value is written
%3A (and % as %25): Origin: https://a.com with nothing after it
and Origin: https followed by //a.com: were one key, and whoever
sent the second chose the response the first was given.
normalize_path in a form that can be sent on: the same path, with
what a uri cannot carry as it is - a space, a ? that was %3F, a
byte that is not ASCII - percent-encoded again.
Whether the client reached the site over https, as far as that can be
vouched for: what a trusted proxy says of it, and otherwise whether
this connection is one.
Compares two byte slices in constant time relative to their length, avoiding
the early exit of == that can leak (via timing) how many leading bytes
matched. Use it for verifying secrets, MACs and signatures. The slice
lengths are not treated as secret and are compared up front.
The value of a query parameter as the client meant it, with its
percent-encoding decoded. + stays a plus: that it stands for a space
is a rule of html forms, not of urls. A value that does not decode to
text is returned as it came.
Whether path has a . or .. segment, read the way
normalize_path reads it: %2e%2e, ..;x, and the ones that only
show once %2F or \ is taken for a separator (a%2F..%2Fb).
Whether ip is one of basic.trusted_proxies: an address whose word
about a client is taken, before there is a request to ask it of (the
PROXY protocol header of a connection). Never without a list.
The error a plugin stops a response of the upstream with, for the
proxy to answer status itself - with the error page of the location -
in place of what the upstream sent (error_page with intercept).
The path of a request in the form it is matched by: percent-encoding
decoded, path parameters left out, a backslash taken for a slash, .
and .. segments resolved, repeated slashes merged.
What a deployment may be called (basic.name): one line of at most
64 bytes. It is put ahead of the title of a message and into the lines
of an access log.
The labels of a deployment, as the configuration has them
(basic.labels): each key:value. The key is made of letters, digits,
_ and -, which is what every place that names one can write: a
template, a placeholder of the access log, a tag.
The level below which notifications are not sent, as the
configuration names it (webhook_min_level): info, warn or
error, and info where it names none.
The server and the topic of a notification for ntfy, as the
configuration has them (webhook): the url of the topic,
https://ntfy.sh/mytopic. A user and a password in it, and what
follows a ?, stay with the server.
Whether the connection of the request comes from one of the trusted
proxies. Never without a list of them: there is then nobody whose word
about a client could be taken.
Resolves a header value that cannot change for the life of the process -
$hostname and $<ENV_VAR> - so it can be stored as a plain value when
the configuration is loaded instead of being looked up on every request
(std::env::var takes a process-wide lock and allocates each time).
Values that depend on the request ($host, $http_*, :key, …) and
plain values come back unchanged, as does a $NAME whose variable is not
set, so the request path treats it exactly as before.
example.com. is example.com with the root label written out, and
names the same host. Matched as it came, it missed every location
configured for the host and fell through to the catch-all, past the
plugins that guard the host, while the upstream served it as that host.