SearchVarnish Enterprise 6.0.16r7 is a feature and bug fix release that focuses on hardening security workflows and improving backend failure handling.
Key highlights include new vmod_s3 capabilities for verifying signed
client requests and handling unsigned payloads, as well as more
flexible TLS certificate loading. This release also introduces
+rush_failure, a new mechanism to reduce latency during backend
outages by waking up waiting lists faster.
The features and optimizations are highlighted below. For the complete list of changes, please see the Changelog.
The S3 VMOD has been updated and it can now verify client requests
signed using the AWS-HMAC-SHA256 algorithm, as well as pre-signed
requests. This allows Varnish to validate incoming requests before
they are passed to the backend, adding a layer of security at the
edge.
Additionally, vmod_s3 can now operate with unsigned payloads. This
removes the previous requirement to prefetch the client request body
using std.cache_req_body(), streamlining the VCL and reducing
overhead. For more information, please refer to the documentation for
vmod_s3.
Varnish now allows the loading of certificates that include duplicate or conflicting server name entries. In previous versions, such conflicts would cause the certificate loading to fail. With this update, if a conflict occurs, the certificate loaded last takes precedence.
This behavior can be controlled via the new tls_err_dup_servername
parameter (default: off). ``` # Allow duplicate server names
(default behavior in 6.0.16r7) param.set tls_err_dup_servername off
A new experimental flag, +rush_failure, ensures the exponential
propagation of all backend fetch failures to the object’s waiting
list.
Without this flag, certain failure conditions might only wake up a single request from the waiting list. This can lead to increased latency and an accumulation of clients in the waiting state during repeated failures. Enabling this flag ensures that failures are propagated quickly to all waiting clients.
When a request wakes up due to this mechanism, it logs a specific Error record:
Error: Backend failure wake-up
vmod_slicer has a new mode for initiating backend requests. The
slicer.enable() method can now accept an additional argument
method=GET when used in sub vcl_backend_fetch.
sub vcl_backend_fetch {
# Issue the initial request as a GET with Range: bytes=0-0
slicer.enable(method=GET);
}
This causes the slicer to issue its initial backend request as an HTTP
GET with a Range: bytes=0-0 header, rather than the default HEAD
request. The method is automatically restored to its original value
after retries.
For more information, please refer to the documentation for
vmod_slicer.
A new variable req.is_reset is available in vcl_synth. This allows
the VCL to detect whether a client disconnected or an HTTP/2 stream
was reset.
sub vcl_synth {
if (req.is_reset) {
return (deliver); # Don't build a body for a disconnected client
}
}
The built-in VCL has also been updated to automatically skip building synthetic responses when it is known they will not be delivered.