SearchVarnish Enterprise 6.0.17r3 is a feature and bug fix release. It contains important bug fixes and stability improvements, and all users are encouraged to upgrade.
Note: Versions 6.0.17r1 and 6.0.17r2 were pulled before publication and never released. 6.0.17r3 is the first public 6.0.17 release and includes all of the changes that were prepared for the earlier iterations.
Key highlights of this release include follow-up visibility and
defensive hardening related to
VSV00018 (originally
fixed in 6.0.16r12), expanded TLS capabilities (CRLs, per-certificate
security levels, PROXY-on-TLS listeners), new .tls.* backend
properties, and a number of new VMOD features and bug fixes across the
stack.
The new features and notable changes are highlighted below. Please see the changelog for the complete list of changes for the 6.0.17 series.
Certificate Revocation Lists: Client certificate verification can now
consult a CRL. A CRL file may be loaded either via a new -R <crl-file>
flag to tls.cert.load, or via the client-verify-crl directive in the
TLS configuration file. A new tls_crl_strict parameter controls whether
missing, expired, or not-yet-valid CRLs fail the handshake (default: on)
or are accepted (off).
Per-certificate OpenSSL security level: A new -L <level> flag to
tls.cert.load sets the OpenSSL security level (0–5) on a per-certificate
basis. This allows loading certificates that would otherwise be rejected
by the system default, or enforcing a stricter level than the default.
PROXY protocol on TLS listeners: Listen sockets configured with both PROXY and TLS now parse the PROXY header before the TLS handshake begins.
tls.cert.list -j now includes new client_verify and crl fields.
This release ships follow-up visibility and defensive hardening
related to VSV00018,
which was originally fixed in 6.0.16r12. These changes complement
that fix by surfacing absolute-form request-targets in the logs and
counters, and by adding a precautionary req.url check to the
built-in VCL.
The https_scheme parameter is now enabled by default to process
https:// absolute-form request-targets.
A new ReqTarget VSL tag logs the original request-target before any
handling of absolute-form request-targets. To preserve existing log format
and ordering, the tag is masked by default and can be unmasked by adding
+ReqTarget to the vsl_mask parameter.
A new MAIN.http1_absolute_form counter tracks the number of HTTP/1.1
requests that arrived with an absolute-form request-target.
The ReqStart VSL record now includes the protocol scheme (http or
https) as a fourth field. varnishncsa uses this to emit https:// in
the request line (%r) for TLS connections. (VS issue #3136)
The built-in VCL has been changed to require req.url to start with /,
unless the request method is CONNECT or OPTIONS. For CONNECT, no
additional check is applied (and CONNECT is not allowed by default). For
OPTIONS, * is also allowed.
VCL backends now accept a new .dscp attribute to specify the
Differentiated Services Code Point (DSCP) value for outgoing TCP
connections.
Backend properties .ssl, .ssl_sni, .ssl_verify_peer and
.ssl_verify_host now have .tls-prefixed aliases that take BOOL values
(true/false) instead of INT (0/1): .tls, .tls_sni,
.tls_verify_peer and .tls_verify_host. The original .ssl names
continue to work.
vmod_otel: New otel.set_attribute() function for injecting OTel
attributes onto transactions.
vmod_utils: New utils.set_esi_limit() function to override the
global esi_limit parameter on a per-request basis from VCL.
vmod_goto: New last_byte_timeout parameter on dns_director and
dns_backend().
vmod_udo: New optional host_header argument to udir.subscribe()
decouples the TLS SNI name and default Host header from the FQDN that
ActiveDNS or vmod_nodes resolved for address lookup.
vmod_nodes: Per-group counters (VMOD_NODES_CG.*) are now prefixed
with the VCL name, so instances sharing a name across different VCLs can
be distinguished (e.g. VMOD_NODES_CG.vcl1.conf.n_nodes). The
unknown_events counter has moved from the per-group VSC to the global
VMOD_NODES.* counter set.
VCL compilation now warns when the varnishd binary has been replaced on
disk (e.g. after a package upgrade), hinting that a restart is needed to
complete the upgrade. The same condition is reported on VMOD ABI mismatch
errors. (VS issue #3167)
A new identity CLI command outputs the server identity configured with
varnishd -i.
When an HTTP/2 request fails before reaching vcl_recv, it is now logged
on a best-effort basis along with a synthetic minimal response, to give
log consumers like varnishncsa some context. (VS issue #3156)
A minimal SELinux policy for varnish-controller-agent is now shipped to
ensure that it creates files properly labeled for varnishd. Since this
policy is not comprehensive, varnish_controller_agent_t is made
permissive, so that varnishd_t can run in enforcing mode. (VS issue
#3169)
Stale-revive waiting list bug: Reviving a stale object could interrupt
an ongoing waiting-list rush, leaving orphaned requests hanging for a
fetch that no longer existed. For HTTP/1 clients, such requests could
remain in the waiting list virtually forever, manifesting as discarded
VCLs not going away or as long-lived waiting-state requests in
varnishscoreboard output. The fix treats the revival of a stale object
like a new cache insertion, similar to regular 304 revalidation. Affected
features include stale.revive() and utils.fast_304(). (VS issue
#3186)
HTTP/2 object head reference leak: An HTTP/2 client disconnecting could under certain circumstances leak an object head reference. (VS issue #3165)
TLS SNI client verification: Per-certificate client verification flags
(tls.cert.load -V) were not applied when the certificate was selected
via SNI during the TLS handshake. (VS issue #3141)