If you have to change anything at all for version 5.1, then most likely the command-line options for varnishd in your start scripts, because we have tightened restrictions on which options may be used together. This has served mainly to clarify the use of options for testing purposes, for example using varnishd -C to check a VCL source for syntactic correctness. We have also added some new options.
The details are given in varnishd, but here's a summary:
VCL written for Varnish 5.0 will very likely work without changes in version 5.1. We have added some new elements and capabilities to the language (which you might like to start using), clarified some matters, and deprecated some little-used language elements.
We have put some thought to the interpretation of the + and - operators for various combinations of operands with differing data types, many of which count as corner cases (what does it mean, for example, to subtract a string from an IP address?). Recall that + denotes addition for numeric operands, and string concatenation for string operands; operands may be converted to strings and concatenated, if a string is expected and there is no sensible numeric interpretation.
The semantics have not changed in nearly all cases, but the error messages for illegal combinations of operands have improved. Most importantly, we have taken the time to review these cases, so this will be the way VCL works going forward.
To summarize:
Other notes on data types:
When bereq.backend is set to a director, then it returns an actual backend on subsequent reads if the director resolves to a backend immediately, or the director otherwise. If bereq.backend was set to a director, then beresp.backend references the backend to which it was set for the fetch. When either of these is used in string context, it returns the name of the director or of the resolved backend.
Comparisons between symbols of type BACKEND now work properly:
if (bereq.backend == foo.backend()) {
# do something specific to the foo backends
}
DURATION types may be used in boolean contexts, and are evaluated as false when the duration is less than or equal to zero, true otherwise.
INT, DURATION and REAL values can now be negative.
Response codes 1000 or greater may now be set in VCL internally. resp.status is delivered modulo 1000 in client responses.
IP addresses can now be compared for equality:
if (client.ip == remote.ip) {
call do_if_equal;
}
The objects are equal if they designate equal socket addresses, not including the port number. IPv6 addresses are always unequal to IPv4 addresses (the comparison cannot consider v4-mapped IPv6 addresses).
The data type STEVEDORE for storage backends is now available in VCL and for VMODs. Storage objects with names of the form storage.SNAME will exist in a VCL instance, where SNAME is the name of a storage backend provided with the varnishd command-line option -s. If no -s option is given, then storage.s0 denotes the default storage. The object storage.Transient always exists, designating transient storage. See Storage backends, and the notes about beresp.storage and req.storage below.
For the case where multiple storage backends have been defined with the -s command-line option for varnishd, but none is explicitly set in vcl_backend_response, storage selection and the use of the nuke limit has been reworked (see nuke_limit). Previously, a storage backend was tried first with a nuke limit of 0, and retried on failure with the limit configured as the -p parameter nuke_limit. When no storage was specified, Varnish went through every one in round-robin order with a nuke limit of 0 before retrying.
Now beresp.storage is initialized with a storage backend before vcl_backend_response executes, and the storage set in beresp.storage after its execution will be used. The configured nuke limit is used in all cases.