Check for correct handling of missing pseudo-headers, and invalid
characters.
Signed-off-by: Asad Sajjad Ahmed <asadsa@varnish-software.com>

We should apply the same restrictions on the list of allowed characters inside
H/2 pseudo-headers as we do for H/1. This error is translated into the
headers we send to a backend over H/1.

Failure to do so could permit various exploits against a backend not handling
malformed H/1 requests.
Signed-off-by: Asad Sajjad Ahmed <asadsa@varnish-software.com>

This expands the perfect hash lookup table to be able to match any entry
in the list of well-known headers from tbl/http_headers.h.

Previously only the headers that had a non-zero filter flag section was
kept in the fast match table.

Fixes: VSV00010

Limit the fuzzer runs to PRs on `varnishcache`'s repositories. The build
scripts won't work correctly from anywhere else anyways.

Ref d72caa00

I think that the other late additions to changes.rst do not qualify
for the release docs.

Thank you to Dridi and phk for preparing most of the docs and thank
you to Martin for the opportunity for some last minute additions.

The #3830 info is taken from 137d9814

due to vrt_ctx change in a8483cf5

Ref c23ef4c3 870f16ce

Closes #3846

When a request comes back from the waiting list, it is accounted for in
the client_req counter, despite not being a new request. To avoid the
spurious increments, a request is counted only after leaving the state
machine for good. This has no effect on when the client_req increment
becomes visible since it is part of the "wrk" group in the first place.

In 2e66e0b9 the client_req increment was
moved from the request state machine (R_STP_TRANSPORT) to individual
transport. This patch can't be reverted because shortly aftwerwards the
ESI transport changed in 2c59afe2 and
now runs the R_STP_TRANSPORT step and the client_req counter does not
count sub-requests.

Refs 2e66e0b9
Refs 2c59afe2

Varnish is not subject to CVE 2022 37434, we never use "extra" data.

Otherwise a source tree bootstrapped --without-config would not
distribute the contrib script and test, that are needed for the
distcheck target and general redistribution.

There seems to be no output right now, and the test case is failing.

Restructured so that:

* 'Upgrading' is limited to work that has to be done to upgrade from
  a current deployment to the new version.

* 'Changes' is a comprehensive, user-level description of changes and
  new features.

I was initially going to align the output only if the nonstandard
column(1) command was present.

As I was comparing the output of two varnishstat executions that were
captured after a fresh start of varnishd followed by the workloads to
compare, I realized diff(1) was giving me a hard time, and git-diff(1)
barely improved the situation.

Looking for generic command line utilities to compare metrics I wasn't
able to find anything. So instead I came up with the output format I
thought would help me spot interesting differences and came up with a
format inspired by the unified diff, with a twist. I wanted metrics to
be vertically aligned to easily see differences in orders of magnitude
and reduce the noise to a minimum.

The result is that taking this detour to script varnishstatdiff sped
my research up ultimately.

This should hopefully be portable to POSIX systems.

This will add scripts we ship to the PATH, so they remain reachable for
VPATH builds.

This removes the ability to run in -i mode without finding a makefile to
derive ${topbuild} from, which shouldn't exist in the first place.

In the top makefile we make the check target depend on the all target,
so we ensure that everything is built before we start using varnishtest.

I accidentally broke the installation in 9f996c1f

Stumpled over (unsigned:1)var = FEATURE(...) not being true
when it should have been...

Related: We might want to remove some redundancy from common_param.h...

Motivated by and in preparation of #3826

The filter check does not make sense in the context of bereq
and the macros became overloaded with two different cases.

Motivated by and in preparation of #3826

The goal is to prevent grace mode from adding load to a saturated
Varnish server.

A background fetch entering the queue will block the client task that
triggerred it until it starts its execution, and reaches the point
where it no longer needs to hold onto its req.

On a saturated system this can result in significant client latency
despite a grace hit. A stale object can be served until the end of its
grace period, at which point a regular fetch would be attempted, and
eligible to queuing if that is still necessary.

This turns the Pool_Task() failure dead branch from VBF_Fetch() into a
reachable one.