Update references to the Varnish version in the docs.

container/README.md

@@ -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.
 

deploy/README.md

@@ -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

docs/custom-vcl.md

@@ -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

docs/dev.md

@@ -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

docs/monitor.md

@@ -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,

docs/ref-backend-cfg.md

@@ -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.
 

docs/ref-req-disposition.md

@@ -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
 

docs/ref-varnish-cfg.md

@@ -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

docs/self-sharding.md

@@ -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).
 

docs/varnish-pod-template.md

@@ -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

examples/acl/README.md

@@ -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

examples/acl/acl.yaml

@@ -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

examples/backend-config/README.md

@@ -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):
 

examples/custom-vcl/custom-vcl.yaml

@@ -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";

examples/req-disposition/README.md

@@ -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

examples/req-disposition/builtin.yaml

@@ -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

examples/req-disposition/purge-method.yaml

@@ -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

examples/rewrite/README.md

@@ -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

examples/varnish_pod_template/README.md

@@ -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

pkg/apis/varnishingress/v1alpha1/types.go

@@ -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 (

pkg/varnish/vcl/spec.go

@@ -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.