sigsegv_handler is on by default since 2015, ref
1955e460

noticed via argv dump in panic d0e986a6

This is solely to make bug reports more useful

Some browsers are strict about this and simply drop responses containing
such headers. Since this is not filtering a context switch between a
client and a backend transaction (or cache hit) a new filtering flag is
added to the HTTP headers table for connection-specific headers. This
new flag cannot be compounded as HTTPH_R_FETCH|HTTPH_A_INS because the
TE header is an exception and left alone, even though trailers aren't
supported.

Better diff with the --ignore-all-space option.

We could go further and consider any client request containing one as
malformed as mandated by RFC 7540.

Closes #3416

Close #3417

They either take both a dynamic struct and buffer, or both are static.

For niov == 0, we reserve up to IOV_MAX io vectors, otherwise niov io
vectors capped to IOV_MAX.

We used to handle the two cases differently and delay the WS_Release for
niov == 0 until V1L_Close(). There is no need to do so, in both cases we
can just reduce the reservation (turned into allocation) to the amount
of space we actually use.

As we are rolling back the workspace in V1L_Close(), this neither has
any influence on the state after the close.

to clarify that it holds a workspace snapshot

Once we ask the backend to close the connection after a given request
there is no benefit from putting the backend connection back in the
pool. It's actually a surefire way to force a subsequent backend fetch
to fail its first attempt and go straight to its extra chance.

Since we try to maximize connection reuse this would have to come from
VCL and a user asking for the backend to close the connection should
have a good reason to do so, for example when the backend is known to
misbehave under certain circumstances.

Closes #3400
Refs #3405

I came across a VMOD that has a method named like the constructor to
conceptually reinitialize the object's state. That's an implementation
detail of the VMOD in question and arguably undefined behavior in
Varnish.

In order to not accidentally break this assumption, add some test
coverage and document this possibility.

- Complete the missing HTTP response codes / messages from :
https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

ref 8816c6f9

so far, it is only used in assertions - this change enables use in
panic code.

motivated by #3415

(Also changes forgotten in previous commit)

for the actual bytes in the body, not for the (chunked) overhead.

The new VSL record is 'VdpAcct' and masked by default.

Fix the name of VDP_close() to VDP_Close() since I'm touching
all the lines anyway.

Fixes #3354

This starts a 6.5.1 changes entry, with only the major bump present.

Retroactively fix up the heading for the 6.5.0 release in the changelog.

In the Varnish Cache 6.5.0 release we forgot to bump the VRT major
version. Do it now.

If direnv is installed you will get a warning otherwise.

Closes #3410

If we lose a header from http_SetHeader() we don't formally run out of
workspace prior to calling http_fail().

Refs #3410