Commit 4e15755c authored by Geoff Simmons's avatar Geoff Simmons

Update references to the Varnish version in the docs.

parent a43f0388
......@@ -43,9 +43,9 @@ deployment.
## Varnish image
The Varnish image currently runs Varnish version 6.1.1. The image runs
The Varnish image currently runs Varnish version 6.3.2. The image runs
Varnish in the foreground as its entry point (``varnishd -F``, see
[``varnishd(1)``](https://varnish-cache.org/docs/6.0/reference/varnishd.html));
[``varnishd(1)``](https://varnish-cache.org/docs/6.3/reference/varnishd.html));
so the image runs the Varnish master process as PID 1, which in turn
controls the child or worker process that implements the HTTP proxy.
......
......@@ -243,7 +243,7 @@ properly:
The Deployment configuration in the current folder shows the default
Pod template for running Varnish, but it can be customized by setting
[varnishd command-line options](https://varnish-cache.org/docs/6.1/reference/varnishd.html#options)
[varnishd command-line options](https://varnish-cache.org/docs/6.3/reference/varnishd.html#options)
in ``args`` and/or environment variables in ``env``. You may need to
do so, for example, to set the PROXY protocol for the HTTP listener,
change container port numbers, or configure Varnish tunables. See the
......
......@@ -2,7 +2,7 @@
You can implement your own logic for caching policy and request
processing by writing custom
[VCL](https://varnish-cache.org/docs/6.1/reference/vcl.html),
[VCL](https://varnish-cache.org/docs/6.3/reference/vcl.html),
configured simply as the string value of ``spec.vcl`` in a
[VarnishConfig](/docs/ref-varnish-cfg.md#specvcl) manifest. The string
is appended "as-is" to VCL code that is generated by the controller to
......@@ -11,19 +11,19 @@ Varnish instances in your cluster. This gives you all of the
capabilites of VCL, subject to the restrictions described in the
following.
The Varnish container specialized for Ingress runs Varnish 6.1.1, and
The Varnish container specialized for Ingress runs Varnish 6.3.2, and
the generated VCL code is at version 4.0. So your custom VCL must be
compatible with those versions.
For further information about VCL see:
* [vcl(7)](https://varnish-cache.org/docs/6.1/reference/vcl.html)
* [vcl(7)](https://varnish-cache.org/docs/6.3/reference/vcl.html)
* [Varnish Processing States](https://varnish-cache.org/docs/6.1/reference/states.html)
* [Varnish Processing States](https://varnish-cache.org/docs/6.3/reference/states.html)
in the Varnish reference manual.
* The
[VCL chapter](https://varnish-cache.org/docs/6.1/users-guide/vcl.html)
[VCL chapter](https://varnish-cache.org/docs/6.3/users-guide/vcl.html)
in the Varnish User's Guide.
* The
......@@ -37,7 +37,7 @@ For further information about VCL see:
* The
[VCL Basics](https://book.varnish-software.com/4.0/chapters/VCL_Basics.html)
chapter in Varnish Software's "Varnish Book" (written for Varnish
4.0, but mostly still correct for version 6.1).
4.0, but mostly still correct for version 6.3).
See the [``examples/`` folder](/examples/custom-vcl) for a simple
working example of custom VCL.
......@@ -78,7 +78,7 @@ change something that the generated code depends on.
``beresp.status``) are reserved for generated code.
VCL allows you to set
[status codes >= 1000](https://varnish-cache.org/docs/6.1/reference/vcl.html#beresp) --
[status codes >= 1000](https://varnish-cache.org/docs/6.3/reference/vcl.html#beresp) --
these are truncated to 3-digit codes in a client response, so as to form
a valid HTTP response. This is a way to control logic in VCL -- set a
special response code for which specific behaviors are implemented (for
......@@ -88,13 +88,13 @@ reserved range, you avoid affecting the work of the generated code.
* Custom VCL is always appended *after* generated VCL.
VCL allows you to define the ``vcl_*`` subroutines
[more than once](https://varnish-cache.org/docs/6.1/reference/vcl.html#multiple-subroutines) --
[more than once](https://varnish-cache.org/docs/6.3/reference/vcl.html#multiple-subroutines) --
they are concatenated in the order in which they appear in the VCL
source, and hence have the effect of being executed in that order,
until one of them calls ``return``, or all of them fall through. If
none of them calls ``return``, then the built-in versions of the
subroutines run (in other words,
[``builtin.vcl``](https://github.com/varnishcache/varnish-cache/blob/varnish-6.1.1/bin/varnishd/builtin.vcl)
[``builtin.vcl``](https://github.com/varnishcache/varnish-cache/blob/varnish-6.3.2/bin/varnishd/builtin.vcl)
is implicitly concatenated last).
By appending custom VCL after generated VCL, the controller ensures
......@@ -104,12 +104,12 @@ anything in custom VCL that may change the flow of control.
## Further restrictions
* It is not possible to use the
[``include`` directive](https://varnish-cache.org/docs/6.1/reference/vcl.html#include-statement) --
[``include`` directive](https://varnish-cache.org/docs/6.3/reference/vcl.html#include-statement) --
all of your custom VCL must form a single string in the VarnishConfig
manifest.
* You cannot
[``return(vcl(LABEL))``](https://varnish-cache.org/docs/6.1/users-guide/vcl-built-in-subs.html?highlight=label#vcl-recv)
[``return(vcl(LABEL))``](https://varnish-cache.org/docs/6.3/users-guide/vcl-built-in-subs.html?highlight=label#vcl-recv)
from ``vcl_recv``. The code is already running in a labeled VCL
instance, and it is not possible to branch from a label to another
label. The controller uses labels for the readiness state and to
......
......@@ -121,7 +121,7 @@ of concerns for the controller:
realize configurations from Ingress and VarnishConfig resources.
This package imports ``code.uplex.de/uplex-varnish/varnishapi/admin``,
which is a client for the
[Varnish CLI](https://varnish-cache.org/docs/6.1/reference/varnish-cli.html),
[Varnish CLI](https://varnish-cache.org/docs/6.3/reference/varnish-cli.html),
used to load VCL and administer Varnish instances.
* ``pkg/varnish/vcl`` encapsulates the use of templates to generate
......
......@@ -130,17 +130,17 @@ following:
* Connect to the admin port
* Issue the
[``ping`` command](https://varnish-cache.org/docs/6.1/reference/varnish-cli.html#ping-timestamp)
[``ping`` command](https://varnish-cache.org/docs/6.3/reference/varnish-cli.html#ping-timestamp)
* Issue the
[``status`` command](https://varnish-cache.org/docs/6.1/reference/varnish-cli.html#status)
[``status`` command](https://varnish-cache.org/docs/6.3/reference/varnish-cli.html#status)
to read the state of the Varnish cache process.
* Check if a
[panic](https://varnish-cache.org/docs/6.1/reference/varnish-cli.html#panic-show)
[panic](https://varnish-cache.org/docs/6.3/reference/varnish-cli.html#panic-show)
has occurred
* [Discard](https://varnish-cache.org/docs/6.1/reference/varnish-cli.html#vcl-discard-configname-label)
* [Discard](https://varnish-cache.org/docs/6.3/reference/varnish-cli.html#vcl-discard-configname-label)
configurations that were loaded by the controller and have gone cold.
* Update to the instance with a configuration for the current desired state,
......
......@@ -7,7 +7,7 @@ for Services that are named as a ``backend`` in an Ingress definition;
that is, the Services to which requests are routed according to an
Ingress based on the Host header and/or URL path. These are implemented
as
[backends](https://varnish-cache.org/docs/6.1/users-guide/vcl-backends.html)
[backends](https://varnish-cache.org/docs/6.3/users-guide/vcl-backends.html)
in Varnish, and BackendConfig allows you to set features for them
such as timeouts, health probes, and the load balancing algorithm.
......@@ -89,12 +89,12 @@ Service that forms a ``backend`` in an Ingress.
The ``spec`` object may have any of these properties, all optional,
which correspond to attributes of a
[Varnish backend configuration](https://varnish-cache.org/docs/6.1/reference/vcl.html#backend-definition):
[Varnish backend configuration](https://varnish-cache.org/docs/6.3/reference/vcl.html#backend-definition):
* ``host-header``: non-empty string
* ``connect-timeout``: MUST have the form of a
[VCL DURATION](https://varnish-cache.org/docs/6.1/reference/vcl.html#durations)
[VCL DURATION](https://varnish-cache.org/docs/6.3/reference/vcl.html#durations)
* ``first-byte-timeout``: VCL DURATION
......@@ -124,7 +124,7 @@ spec:
### ``spec.probe``
The ``probe`` object is optional, and if present it specifies a
[health probe](https://varnish-cache.org/docs/6.1/reference/vcl.html#probes)
[health probe](https://varnish-cache.org/docs/6.3/reference/vcl.html#probes)
for the backend. Its properties correspond to attributes of a Varnish
probe:
......@@ -137,7 +137,7 @@ probe:
* ``expected_response``: 3-digit HTTP response code
* ``timeout``: MUST have the form of a
[VCL DURATION](https://varnish-cache.org/docs/6.1/reference/vcl.html#durations)
[VCL DURATION](https://varnish-cache.org/docs/6.3/reference/vcl.html#durations)
* ``interval``: VCL DURATION
......@@ -200,7 +200,7 @@ Example:
```
spec:
# Health probe config
# see: https://varnish-cache.org/docs/6.1/reference/vcl.html#probes
# see: https://varnish-cache.org/docs/6.3/reference/vcl.html#probes
probe:
url: /tea/healthz
expected-response: 204
......@@ -215,7 +215,7 @@ spec:
The ``director`` object is optional, and if present it specifies
properties of the
[Varnish director](https://varnish-cache.org/docs/6.1/reference/vmod_directors.generated.html)
[Varnish director](https://varnish-cache.org/docs/6.3/reference/vmod_directors.generated.html)
that corresponds to the backend Service. Varnish directors implement
load-balancing for a group of backends; for the Ingress
implementation, Varnish routes requests to one of the Endpoints of the
......@@ -228,20 +228,20 @@ All of the properties of ``spec.director`` are optional:
``round-robin``
* ``warmup`` (integer 0 to 100): the
[``warmup`` parameter](https://varnish-cache.org/docs/6.1/reference/vmod_directors.generated.html#func-shard-set-warmup)
[``warmup`` parameter](https://varnish-cache.org/docs/6.3/reference/vmod_directors.generated.html#func-shard-set-warmup)
of the ``shard`` director, expressed as a probability in percent.
Ignored for the other directors.
* ``rampup`` ([VCL DURATION](https://varnish-cache.org/docs/6.1/reference/vcl.html#durations)):
* ``rampup`` ([VCL DURATION](https://varnish-cache.org/docs/6.3/reference/vcl.html#durations)):
the
[``rampup`` parameter](https://varnish-cache.org/docs/6.1/reference/vmod_directors.generated.html#void-xshard-set-rampup-duration-duration-0)
[``rampup`` parameter](https://varnish-cache.org/docs/6.3/reference/vmod_directors.generated.html#void-xshard-set-rampup-duration-duration-0)
of the ``shard`` director. Ignored for the other directors.
With ``type`` you can choose the
[round-robin](https://varnish-cache.org/docs/6.1/reference/vmod_directors.generated.html#obj-round-robin),
[random](https://varnish-cache.org/docs/6.1/reference/vmod_directors.generated.html#obj-random)
[round-robin](https://varnish-cache.org/docs/6.3/reference/vmod_directors.generated.html#obj-round-robin),
[random](https://varnish-cache.org/docs/6.3/reference/vmod_directors.generated.html#obj-random)
or
[shard](https://varnish-cache.org/docs/6.1/reference/vmod_directors.generated.html#obj-shard)
[shard](https://varnish-cache.org/docs/6.3/reference/vmod_directors.generated.html#obj-shard)
director, default round-robin. The shard director shards requests
to Endpoints by URL path.
......
......@@ -7,13 +7,13 @@ are processed further after the request headers have been received.
The configuration in ``req-disposition`` causes the definition of [VCL
subroutine
``vcl_recv``](https://varnish-cache.org/docs/6.1/users-guide/vcl-built-in-subs.html#vcl-recv)
``vcl_recv``](https://varnish-cache.org/docs/6.3/users-guide/vcl-built-in-subs.html#vcl-recv)
in
[``builtin.vcl``](https://github.com/varnishcache/varnish-cache/blob/6.1/bin/varnishd/builtin.vcl)
[``builtin.vcl``](https://github.com/varnishcache/varnish-cache/blob/6.3/bin/varnishd/builtin.vcl)
to be overridden. ``builtin.vcl`` acts as "default VCL"; after a
subroutine in the VCL generated by the controller has been executed,
if it does not use ``return`` to branch to another [processing
state](https://varnish-cache.org/docs/6.1/reference/states.html), then
state](https://varnish-cache.org/docs/6.3/reference/states.html), then
the subroutine in ``builtin.vcl`` is executed. Built-in ``vcl_recv``
establishes default policies for client requests such as:
......@@ -22,7 +22,7 @@ establishes default policies for client requests such as:
* which requests bypass cache lookup, and hence are never cache hits
(and avoid the effects of [request
coalescing](https://varnish-cache.org/docs/6.1/users-guide/increasing-your-hitrate.html#cache-misses)).
coalescing](https://varnish-cache.org/docs/6.3/users-guide/increasing-your-hitrate.html#cache-misses)).
* how to handle requests with non-standard request methods.
......@@ -65,7 +65,7 @@ examples of configurations for ``req-disposition``. Among these are:
## Configuration
The configuration in ``req-disposition`` determines the next
[state](https://varnish-cache.org/docs/6.1/reference/states.html) in
[state](https://varnish-cache.org/docs/6.3/reference/states.html) in
the processing of a client request. The implementation of
``req-disposition`` is executed after everything else that runs in
``vcl_recv``, and bypasses built-in ``vcl_recv`` as discussed above.
......@@ -89,7 +89,7 @@ then the request proceeds to cache lookup (``return(hash)``).
* ``action`` (required): one of the following strings, corresponding
to a [``return()`` keyword for
``vcl_recv``](https://varnish-cache.org/docs/6.1/users-guide/vcl-built-in-subs.html#vcl-recv);
``vcl_recv``](https://varnish-cache.org/docs/6.3/users-guide/vcl-built-in-subs.html#vcl-recv);
* ``hash``: cache lookup
......@@ -98,18 +98,18 @@ then the request proceeds to cache lookup (``return(hash)``).
* ``synth``: return a synthetic response
* ``pipe``: Varnish acts as a
[tunnel](https://varnish-cache.org/docs/6.1/users-guide/vcl-built-in-subs.html#vcl-pipe)
[tunnel](https://varnish-cache.org/docs/6.3/users-guide/vcl-built-in-subs.html#vcl-pipe)
between client and backend
* ``restart``:
[restart](https://varnish-cache.org/docs/6.1/users-guide/vcl-built-in-subs.html#restart)
[restart](https://varnish-cache.org/docs/6.3/users-guide/vcl-built-in-subs.html#restart)
request processing
* ``purge``: evict the cache object that corresponds to the
request
* ``fail``: invoke [VCL
failure](https://varnish-cache.org/docs/6.1/users-guide/vcl-built-in-subs.html#fail)
failure](https://varnish-cache.org/docs/6.3/users-guide/vcl-built-in-subs.html#fail)
* ``status``: the HTTP status of the synthetic response when
``action`` is ``synth``. Required for ``synth``, and ignored for
......@@ -131,7 +131,7 @@ fulfill to invoke the corresponding ``disposition``:
* ``comparand`` (required): the "thing to be compared" -- one of the
following
(cf. [vcl(7)](https://varnish-cache.org/docs/6.1/reference/vcl.html#req-and-req-top)):
(cf. [vcl(7)](https://varnish-cache.org/docs/6.3/reference/vcl.html#req-and-req-top)):
* ``req.url``: URL path
......
......@@ -105,7 +105,7 @@ Properties that may be specifed for ``self-sharding`` are:
* ``probe``: object
If specified, ``max-secondary-ttl`` MUST have the form of the VCL
[DURATION type](https://varnish-cache.org/docs/6.1/reference/vcl.html#durations)
[DURATION type](https://varnish-cache.org/docs/6.3/reference/vcl.html#durations)
(examples are ``90s`` for ninety seconds, or ``2m`` for two
minutes). This value is the TTL for "secondary" caching -- the upper
bound for a cached response forwarded from the "primary" Varnish instance
......@@ -124,7 +124,7 @@ for one another). Its properties are:
* ``threshold``: integer
These properties configure the corresponding values for
[health probes](https://varnish-cache.org/docs/6.1/reference/vcl.html#probes),
[health probes](https://varnish-cache.org/docs/6.3/reference/vcl.html#probes),
and they default to the default values for Varnish probes. If the
``probe`` object is left out altogether, then defaults hold for all of
its properties.
......@@ -220,7 +220,7 @@ interpreted as a fixed string, and ``comparand`` is tested for
(in)equality with ``value``. Otherwise, ``value`` is interpreted as a
regular expression, and the ``comparand`` is tested for
(non-)match. Regexen are implemented as
[VCL regular expressions](https://varnish-cache.org/docs/6.1/reference/vcl.html#regular-expressions),
[VCL regular expressions](https://varnish-cache.org/docs/6.3/reference/vcl.html#regular-expressions),
and hence have the syntax and semantics of
[PCRE](https://www.pcre.org/original/doc/html/).
......@@ -386,7 +386,7 @@ invoked for an IP that does match the ACL.
against which the ACL is matched, and can have one of these values:
* ``client.ip``: interpreted as in
[VCL](https://varnish-cache.org/docs/6.1/reference/vcl.html#local-server-remote-and-client)
[VCL](https://varnish-cache.org/docs/6.3/reference/vcl.html#local-server-remote-and-client)
* ``server.ip``: as in VCL
......@@ -496,7 +496,7 @@ The ``vcl`` element is optional, and if present contains a non-empty
string that is appended "as-is" to VCL code generated by the
controller that is loaded by Varnish instances. This provides a means
to write custom
[VCL](https://varnish-cache.org/docs/6.1/reference/vcl.html). For
[VCL](https://varnish-cache.org/docs/6.3/reference/vcl.html). For
example:
```
......@@ -774,7 +774,7 @@ Elements of the ``rewrites`` array may have these fields, of which
If the conditions required by ``unique`` or ``exact`` are not met,
then
[VCL failure](https://varnish-cache.org/docs/6.1/users-guide/vcl-built-in-subs.html#common-return-keywords)
[VCL failure](https://varnish-cache.org/docs/6.3/users-guide/vcl-built-in-subs.html#common-return-keywords)
is invoked after the comparison attempt. This means in most cases
that a synthetic response with status 503 and the reason "VCL
failed" is returned for the request.
......@@ -785,7 +785,7 @@ Elements of the ``rewrites`` array may have these fields, of which
[``match-flags`` reference](/docs/ref-match-flags.md) for details.
* ``vcl-sub`` is an enum indicating the
[VCL subroutine](https://varnish-cache.org/docs/6.1/reference/states.html)
[VCL subroutine](https://varnish-cache.org/docs/6.3/reference/states.html)
in which the rewrite is executed; that is, the phase of request
processing at which the rewrite is performed.
......@@ -830,8 +830,8 @@ Elements of the ``rewrites`` array may have these fields, of which
* ``backend_error``
See the
[VCL](https://varnish-cache.org/docs/6.1/reference/vcl.html)
[docs](https://varnish-cache.org/docs/6.1/reference/states.html)
[VCL](https://varnish-cache.org/docs/6.3/reference/vcl.html)
[docs](https://varnish-cache.org/docs/6.3/reference/states.html)
for details.
If more than one rewrite in the ``rewrites`` array specifies the
......
......@@ -98,7 +98,7 @@ required -- it can, for example, continue distributing requests to
Varnishen in round-robin order.
This is done by applying Varnish's
[shard director](https://varnish-cache.org/docs/6.1/reference/vmod_directors.generated.html#new-xshard-directors-shard)
[shard director](https://varnish-cache.org/docs/6.3/reference/vmod_directors.generated.html#new-xshard-directors-shard)
to the Varnish instances in the cluster. If an instance finds that the
director shards the request to itself, then it handles the request
itself as the primary cache for the request. See the documentation at
......@@ -207,7 +207,7 @@ TTLs serves to reduce the total memory load for caching in the
cluster.
The ``probe`` object specfies properties of the
[health probes](https://varnish-cache.org/docs/6.1/reference/vcl.html#probes),
[health probes](https://varnish-cache.org/docs/6.3/reference/vcl.html#probes),
that Varnish instances in the cluster send to one another (since they
are backends for one another when self-sharding is implemented).
......
......@@ -13,7 +13,7 @@ environment variables in ``env``. You may want to do this in order to:
for the Varnish listener
* set
[Varnish runtime parameters and tunables](https://varnish-cache.org/docs/6.1/reference/varnishd.html)
[Varnish runtime parameters and tunables](https://varnish-cache.org/docs/6.3/reference/varnishd.html)
such as the cache size, default TTLs and timeouts, thread pool
dimensions, workspace sizes (and many more)
......@@ -28,7 +28,7 @@ document describes what may, and what may not be customized.
## varnishd Command-Line options
See
[``varnishd(1)``](https://varnish-cache.org/docs/6.1/reference/varnishd.html#options)
[``varnishd(1)``](https://varnish-cache.org/docs/6.3/reference/varnishd.html#options)
for details about available options.
```
......@@ -94,10 +94,10 @@ option:
You may of course choose a different path name. Note that this use of
``-n`` means that other commands in the Varnish container that access
shared memory, such as
[``varnishlog``](https://varnish-cache.org/docs/6.1/reference/varnishlog.html),
[``varnishstat``](https://varnish-cache.org/docs/6.1/reference/varnishstat.html)
[``varnishlog``](https://varnish-cache.org/docs/6.3/reference/varnishlog.html),
[``varnishstat``](https://varnish-cache.org/docs/6.3/reference/varnishstat.html)
or
[``varnishadm``](https://varnish-cache.org/docs/6.1/reference/varnishadm.html),
[``varnishadm``](https://varnish-cache.org/docs/6.3/reference/varnishadm.html),
must also be called with the ``-n`` option set to the Varnish home
directory (for example when executed via ``kubectl exec``).
......@@ -145,7 +145,7 @@ These environment variables can be used to change the configuration
from defaults:
* ``PROTO``: sets the
[PROTO sub-argument](https://varnish-cache.org/docs/6.1/reference/varnishd.html#basic-options)
[PROTO sub-argument](https://varnish-cache.org/docs/6.3/reference/varnishd.html#basic-options)
for the HTTP listener. Legal values are ``HTTP`` or ``PROXY``,
default ``HTTP``.
......@@ -156,7 +156,7 @@ from defaults:
readiness checks, default 8080.
* ``ADMIN_PORT``: sets the port at which Varnish listens for
[CLI commands](https://varnish-cache.org/docs/6.1/reference/varnish-cli.html),
[CLI commands](https://varnish-cache.org/docs/6.3/reference/varnish-cli.html),
used by the controller; default 6081.
* ``SECRET_PATH``: sets the path mounted to the volume that is
......
......@@ -49,14 +49,14 @@ do not match the ACL.
The ``comparand`` has the default value ``client.ip``. This means that
the ACL is matched against the VCL
[``client.ip`` object](https://varnish-cache.org/docs/6.1/reference/vcl.html#local-server-remote-and-client),
[``client.ip`` object](https://varnish-cache.org/docs/6.3/reference/vcl.html#local-server-remote-and-client),
which is the client address sent in the PROXY header if the PROXY
protocol is in use, or the peer address of the connection if not.
(See the [docs](/docs/varnish-pod-template.md) about how to use the
PROXY protocol.) If ``comparand`` is set to any of ``server.ip``,
``remote.ip`` or ``local.ip``, then the IP address to be matched is
also evaluated as in VCL -- see the
[docs](https://varnish-cache.org/docs/6.1/reference/vcl.html#local-server-remote-and-client)
[docs](https://varnish-cache.org/docs/6.3/reference/vcl.html#local-server-remote-and-client)
for details.
The ``conditions`` field is not set in this example, so the ACL match
......@@ -65,7 +65,7 @@ is executed for every client request.
## ACL restricted to requests for a Service
The next example re-creates the ACL shown as an example in
[vcl(7)](https://varnish-cache.org/docs/6.1/reference/vcl.html#access-control-list-acl):
[vcl(7)](https://varnish-cache.org/docs/6.3/reference/vcl.html#access-control-list-acl):
```
- name: man-vcl-example
......
......@@ -44,7 +44,7 @@ spec:
mask-bits: 16
# This is the ACL shown as an example in vcl(7):
# https://varnish-cache.org/docs/6.1/reference/vcl.html#access-control-list-acl
# https://varnish-cache.org/docs/6.3/reference/vcl.html#access-control-list-acl
# The ACL matches:
# - the IP resolved for "localhost" at VCL load time
# - 192.0.2.0/24
......
......@@ -49,7 +49,7 @@ spec:
```
These top-level properties of ``spec`` correspond to attributes of a
[Varnish backend definition](https://varnish-cache.org/docs/6.1/reference/vcl.html#backend-definition).
[Varnish backend definition](https://varnish-cache.org/docs/6.3/reference/vcl.html#backend-definition).
The configuration in the example means that:
* The Host header of a backend request is set to ``cafe.example.com``
......@@ -67,7 +67,7 @@ The configuration in the example means that:
* No more than 200 connections to an Endpoint may be opened.
The properties of ``spec.probe`` correspond to attributes of a
[Varnish health probe](https://varnish-cache.org/docs/6.1/reference/vcl.html#probes):
[Varnish health probe](https://varnish-cache.org/docs/6.3/reference/vcl.html#probes):
```
spec:
......@@ -98,7 +98,7 @@ that:
* At startup, one probe is implicitly assumed to be good.
The last part of the BackendConfig for ``tea-svc`` selects the
[random](https://varnish-cache.org/docs/6.1/reference/vmod_directors.generated.html#new-xrandom-directors-random)
[random](https://varnish-cache.org/docs/6.3/reference/vmod_directors.generated.html#new-xrandom-directors-random)
director -- load-balancing requests to Endpoints is random (the
default is round-robin):
......
......@@ -12,7 +12,7 @@ spec:
- varnish-ingress
# Custom VCL is appended "as-is" to VCL generated by the controller.
# see: https://varnish-cache.org/docs/6.1/reference/vcl.html
# see: https://varnish-cache.org/docs/6.3/reference/vcl.html
vcl: |
sub vcl_deliver {
set resp.http.Hello = "world";
......
......@@ -5,10 +5,10 @@ client requests -- how client requests are further processed after
request headers have been received. The ``req-disposition`` field of
the [``VarnishConfig`` custom resource](/docs/ref-varnish-cfg.md)
determines the next [processing
state](https://varnish-cache.org/docs/6.1/reference/states.html) for a
state](https://varnish-cache.org/docs/6.3/reference/states.html) for a
request, subject to properties of the request. It overrides the
implementation of ``vcl_recv`` in
[``builtin.vcl``](https://github.com/varnishcache/varnish-cache/blob/6.1/bin/varnishd/builtin.vcl).
[``builtin.vcl``](https://github.com/varnishcache/varnish-cache/blob/6.3/bin/varnishd/builtin.vcl).
A common use case for ``req-disposition`` is to allow caching for
requests that use cookies or basic authentication, since the Varnish
......@@ -28,7 +28,7 @@ A variety of other features can be implemented with
* white- and blacklisting requests
* defining a means to use the
[purge](https://varnish-cache.org/docs/6.1/users-guide/purging.html)
[purge](https://varnish-cache.org/docs/6.3/users-guide/purging.html)
facility via client requets, for example by defining a ``PURGE``
request method.
......@@ -119,7 +119,7 @@ synthetic response with status ``400 Bad Request`` -- an HTTP/1.1
request without a ``Host`` header is illegal.
The next element specifies that the request is processed in [pipe
mode](https://varnish-cache.org/docs/6.1/users-guide/vcl-built-in-subs.html#vcl-pipe)
mode](https://varnish-cache.org/docs/6.3/users-guide/vcl-built-in-subs.html#vcl-pipe)
for request method ``CONNECT``, or any non-standard request method:
```
......@@ -167,7 +167,7 @@ requests, for example, bypass cache lookup:
Setting the ``disposition`` to ``pass`` for requests whose responses
are known to be uncacheable can be advantageous, because potential
waiting due to [request
coalescing](https://varnish-cache.org/docs/6.1/users-guide/increasing-your-hitrate.html#passing-client-requests)
coalescing](https://varnish-cache.org/docs/6.3/users-guide/increasing-your-hitrate.html#passing-client-requests)
is avoided.
The next two elements are the ones that most commonly require an override
......@@ -812,7 +812,7 @@ $ curl -x $IP:$PORT -v http://cafe.example.com/tea/sugar/black/foo
## Defining a PURGE method
The final example demonstrates a way to make the Varnish
[purge](https://varnish-cache.org/docs/6.1/users-guide/purging.html)
[purge](https://varnish-cache.org/docs/6.3/users-guide/purging.html)
facility available via a ``PURGE`` request method. When the processing
state is set to ``purge``, and the request is a cache hit, the cached
object and all of its variants are invlaidated, and Varnish send a
......
......@@ -18,7 +18,7 @@ spec:
# then the request is processed further as specified in the
# corresponding disposition field. The disposition specifies the
# next state of request processing, see:
# https://varnish-cache.org/docs/6.1/reference/states.html
# https://varnish-cache.org/docs/6.3/reference/states.html
#
# The conditions are evaluated in order, and the first set of
# conditions that evaluate to true invoke the corresponding
......@@ -27,7 +27,7 @@ spec:
#
# This configuration reconstructs vcl_recv from builtin.vcl,
# see:
# https://github.com/varnishcache/varnish-cache/blob/6.1/bin/varnishd/builtin.vcl
# https://github.com/varnishcache/varnish-cache/blob/6.3/bin/varnishd/builtin.vcl
req-disposition:
# If the request method is "PRI", then send a synthetic "405
......
......@@ -34,7 +34,7 @@ spec:
status: 400
# Divert to purge when the request method is PURGE.
# See: https://varnish-cache.org/docs/6.1/users-guide/purging.html
# See: https://varnish-cache.org/docs/6.3/users-guide/purging.html
- conditions:
- comparand: req.method
compare: equal
......
......@@ -593,7 +593,7 @@ $ curl -x $IP:$PORT -v http://cafe.example.com/coffee
>
< HTTP/1.1 200 OK
[...]
< Via: 1.1 varnish (Varnish/6.1)
< Via: 1.1 varnish (Varnish/6.3)
[...]
# With an appropriate value for the Delete-Via request header, the Via
......
......@@ -27,7 +27,7 @@ also used for other types of controllers, such as DaemonSets.
```
See
[``varnishd(1)``](https://varnish-cache.org/docs/6.1/reference/varnishd.html#options)
[``varnishd(1)``](https://varnish-cache.org/docs/6.3/reference/varnishd.html#options)
for details.
[``proxy.yaml``](proxy.yaml) just sets the ``PROTO`` environment
......
......@@ -358,7 +358,7 @@ type ReqCondition struct {
}
// RecvReturn is a name for the disposition of a client request.
// See: https://varnish-cache.org/docs/6.1/reference/states.html
// See: https://varnish-cache.org/docs/6.3/reference/states.html
type RecvReturn string
const (
......@@ -370,7 +370,7 @@ const (
// client and backend with no further intervention.
RecvPipe = "pipe"
// RecvPurge to purge a cache object.
// See: https://varnish-cache.org/docs/6.1/users-guide/purging.html?highlight=purge#http-purging
// See: https://varnish-cache.org/docs/6.3/users-guide/purging.html?highlight=purge#http-purging
RecvPurge = "purge"
// RecvSynth to generate a synthetic response with a given
// HTTP response status.
......@@ -443,7 +443,7 @@ type BackendConfigSpec struct {
}
// DirectorType specfies the class of director to be used, see:
// https://varnish-cache.org/docs/6.1/reference/vmod_directors.generated.html
// https://varnish-cache.org/docs/6.3/reference/vmod_directors.generated.html
type DirectorType string
const (
......
......@@ -71,7 +71,7 @@ func (a byIPPort) Less(i, j int) bool {
}
// DirectorType corresponds to a class of director, see:
// https://varnish-cache.org/docs/6.1/reference/vmod_directors.generated.html
// https://varnish-cache.org/docs/6.3/reference/vmod_directors.generated.html
type DirectorType uint8
const (
......@@ -677,7 +677,7 @@ type Condition struct {
}
// RecvReturn is a name for the disposition of a client request.
// See: https://varnish-cache.org/docs/6.1/reference/states.html
// See: https://varnish-cache.org/docs/6.3/reference/states.html
type RecvReturn string
const (
......@@ -689,7 +689,7 @@ const (
// client and backend with no further intervention.
RecvPipe = "pipe"
// RecvPurge to purge a cache object.
// See: https://varnish-cache.org/docs/6.1/users-guide/purging.html?highlight=purge#http-purging
// See: https://varnish-cache.org/docs/6.3/users-guide/purging.html?highlight=purge#http-purging
RecvPurge = "purge"
// RecvSynth to generate a synthetic response with a given
// HTTP response status.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment