[master] c65d257ab man: Document built-in subs in a reference manual
Nils Goroll
nils.goroll at uplex.de
Mon May 15 13:27:06 UTC 2023
commit c65d257ab9e7cee5a77a35aa0128f9fce701db1c
Author: Walid Boudebouda <walid.boudebouda at gmail.com>
Date: Tue Mar 28 16:10:56 2023 +0200
man: Document built-in subs in a reference manual
Instead of documenting built-in subroutines in the user guide, a new
vcl-step(7) manual is added. It is structured with a vcl-step.rst file
that includes a vcl_step.rst file containing the actual list of steps.
This is similar to how the vcl-var(7) manual is constructed to later
make it authoritative.
diff --git a/doc/sphinx/conf.py.in b/doc/sphinx/conf.py.in
index 30c527a50..a0bb5d40b 100644
--- a/doc/sphinx/conf.py.in
+++ b/doc/sphinx/conf.py.in
@@ -64,7 +64,7 @@ release = '@VERSION@'
# List of directories, relative to source directory, that shouldn't be searched
# for source files.
-exclude_patterns = ['build','include/*.rst','reference/vcl_var.rst']
+exclude_patterns = ['build','include/*.rst','reference/vcl_*.rst']
# The reST default role (used for this markup: `text`) to use for all documents.
#default_role = None
diff --git a/doc/sphinx/reference/index.rst b/doc/sphinx/reference/index.rst
index cb50ea6ff..8eec67414 100644
--- a/doc/sphinx/reference/index.rst
+++ b/doc/sphinx/reference/index.rst
@@ -19,6 +19,7 @@ The VCL language
VCL - The Varnish Configuration Language <vcl>
VCL Variables <vcl-var>
+ VCL Steps <vcl-step>
VCL backend configuration <vcl-backend>
VCL backend health probe <vcl-probe>
states.rst
diff --git a/doc/sphinx/reference/states.rst b/doc/sphinx/reference/states.rst
index b816c25d7..2a4cbbacc 100644
--- a/doc/sphinx/reference/states.rst
+++ b/doc/sphinx/reference/states.rst
@@ -18,7 +18,7 @@ state machines. Whenever a state is entered, a C function is called,
which in turn calls the appropriate Varnish core code functions to
process the request or response at this stage. For most states, core
code also calls into a state-specific function compiled from VCL, a
-VCL subroutine (see :ref:`vcl-built-in-subs` ).
+VCL subroutine (see :ref:`vcl_steps`).
As a general guideline, core code aims to prepare objects accessible
from VCL with good defaults for the most common cases before calling
diff --git a/doc/sphinx/reference/vcl-step.rst b/doc/sphinx/reference/vcl-step.rst
new file mode 100644
index 000000000..011e84e00
--- /dev/null
+++ b/doc/sphinx/reference/vcl-step.rst
@@ -0,0 +1,63 @@
+..
+ Copyright (c) 2013-2021 Varnish Software AS
+ SPDX-License-Identifier: BSD-2-Clause
+ See LICENSE file for full text of license
+
+
+.. role:: ref(emphasis)
+
+.. _vcl-steps(7):
+
+=========
+VCL-steps
+=========
+
+--------------------
+Built-in subroutines
+--------------------
+
+:Manual section: 7
+
+
+DESCRIPTION
+===========
+
+Various built-in subroutines are called during processing of client
+and backend requests as well as upon ``vcl.load`` and ``vcl.discard``.
+
+See :ref:`reference-states` for a detailed graphical overview of the
+states and how they relate to core code functions and VCL subroutines.
+
+Built-in subroutines always terminate with a ``return (<action>)``,
+where ``<action>`` determines how processing continues in the request
+processing state machine.
+
+The behaviour of actions is identical or at least similar across
+subroutines, so differences are only documented where relevant.
+
+Common actions are documented in
+:ref:`user-guide-vcl_actions`. Actions specific to only one or some
+subroutines are documented herein.
+
+A default behavior is provided for all :ref:`reference-states` in the
+:ref:`vcl-built-in-code` code.
+
+
+.. include:: vcl_step.rst
+
+
+
+SEE ALSO
+========
+
+* :ref:`varnishd(1)`
+* :ref:`vcl(7)`
+
+COPYRIGHT
+=========
+
+This document is licensed under the same license as Varnish
+itself. See LICENSE for details.
+
+* Copyright (c) 2006 Verdens Gang AS
+* Copyright (c) 2006-2021 Varnish Software AS
diff --git a/doc/sphinx/reference/vcl.rst b/doc/sphinx/reference/vcl.rst
index 3770dc626..5143f0ff0 100644
--- a/doc/sphinx/reference/vcl.rst
+++ b/doc/sphinx/reference/vcl.rst
@@ -445,6 +445,7 @@ SEE ALSO
* :ref:`varnishd(1)`
* :ref:`vcl-backend(7)`
* :ref:`vcl-probe(7)`
+* :ref:`vcl-steps(7)`
* :ref:`vcl-var(7)`
* :ref:`vmod_directors(3)`
* :ref:`vmod_std(3)`
diff --git a/doc/sphinx/users-guide/vcl-built-in-subs.rst b/doc/sphinx/reference/vcl_step.rst
similarity index 52%
rename from doc/sphinx/users-guide/vcl-built-in-subs.rst
rename to doc/sphinx/reference/vcl_step.rst
index 3d6b67f04..30d946a9a 100644
--- a/doc/sphinx/users-guide/vcl-built-in-subs.rst
+++ b/doc/sphinx/reference/vcl_step.rst
@@ -1,36 +1,11 @@
-..
- Copyright (c) 2013-2021 Varnish Software AS
- SPDX-License-Identifier: BSD-2-Clause
- See LICENSE file for full text of license
-.. _vcl-built-in-subs:
+.. _vcl_steps:
-Built-in subroutines
-====================
+VCL Steps
+=========
-Various built-in subroutines are called during processing of client-
-and backend requests as well as upon ``vcl.load`` and ``vcl.discard``.
-
-See :ref:`reference-states` for a detailed graphical overview of the
-states and how they relate to core code functions and VCL subroutines.
-
-Built-in subroutines always terminate with a ``return (<action>)``,
-where ``<action>`` determines how processing continues in the request
-processing state machine.
-
-The behaviour of actions is identical or at least similar across
-subroutines, so differences are only documented where relevant.
-
-Common actions are documented in
-:ref:`user-guide-vcl_actions`. Actions specific to only one or some
-subroutines are documented herein.
-
-A default behavior is provided for all :ref:`reference-states` in the
-:ref:`vcl-built-in-code` code.
-
-
-client side
------------
+Client side
+###########
.. _vcl_recv:
@@ -48,40 +23,41 @@ be set as a default for the backend processing side.
The `vcl_recv` subroutine may terminate with calling ``return()`` on one
of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``synth(status code, reason)``
- see :ref:`synth`
-
- ``restart``
- see :ref:`restart`
-
- ``pass``
- see :ref:`pass`
-
- ``pipe``
- see :ref:`pipe`
-
- ``hash``
- Continue processing the object as a potential candidate for
- caching. Passes the control over to :ref:`vcl_hash`.
-
- ``purge``
- Purge the object and it's variants. Control passes through
- :ref:`vcl_hash` to :ref:`vcl_purge`.
-
- ``vcl(label)``
- Switch to vcl labelled *label*.
-
- This will roll back the request as if ``std.rollback(req)`` was
- called and continue vcl processing in :ref:`vcl_recv` of the vcl
- labelled *label* as if it was the active vcl.
-
- The ``vcl(label)`` return is only valid while the ``req.restarts``
- count is zero and if used from the active vcl.
-
- See the :ref:`ref_cli_vcl_label` command.
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``synth(status code, reason)``
+ | see :ref:`synth`
+ |
+ | ``restart``
+ | see :ref:`restart`
+ |
+ | ``pass``
+ | see :ref:`pass`
+ |
+ | ``pipe``
+ | see :ref:`pipe`
+ |
+ | ``hash``
+ | Continue processing the object as a potential candidate for
+ | caching. Passes the control over to :ref:`vcl_hash`.
+ |
+ | ``purge``
+ | Purge the object and it's variants. Control passes through
+ | :ref:`vcl_hash` to :ref:`vcl_purge`.
+ |
+ | ``vcl(label)``
+ | Switch to vcl labelled *label*.
+ |
+ | This will roll back the request as if ``std.rollback(req)`` was
+ | called and continue vcl processing in :ref:`vcl_recv` of the vcl
+ | labelled *label* as if it was the active vcl.
+ |
+ | The ``vcl(label)`` return is only valid while the ``req.restarts``
+ | count is zero and if used from the active vcl.
+ |
+ | See the :ref:`ref_cli_vcl_label` command.
.. _vcl_pipe:
@@ -98,14 +74,15 @@ other VCL subroutine will ever get called after `vcl_pipe`.
The `vcl_pipe` subroutine may terminate with calling ``return()`` with one
of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``synth(status code, reason)``
- see :ref:`synth`
-
- ``pipe``
- Proceed with pipe mode.
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``synth(status code, reason)``
+ | see :ref:`synth`
+ |
+ | ``pipe``
+ | Proceed with pipe mode.
.. _vcl_pass:
@@ -120,17 +97,18 @@ submitted over the same client connection are handled normally.
The `vcl_pass` subroutine may terminate with calling ``return()`` with one
of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``synth(status code, reason)``
- see :ref:`synth`
-
- ``restart``
- see :ref:`restart`
-
- ``fetch``
- Proceed with pass mode - initiate a backend request.
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``synth(status code, reason)``
+ | see :ref:`synth`
+ |
+ | ``restart``
+ | see :ref:`restart`
+ |
+ | ``fetch``
+ | Proceed with pass mode - initiate a backend request.
.. _vcl_hash:
@@ -143,26 +121,27 @@ used as a key to look up the object in Varnish.
The `vcl_hash` subroutine may terminate with calling ``return()`` with one
of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``lookup``
- Look up the object in cache.
-
- Control passes to :ref:`vcl_purge` when coming from a ``purge``
- return in `vcl_recv`.
-
- Otherwise control passes to the next subroutine depending on the
- result of the cache lookup:
-
- * a hit: pass to :ref:`vcl_hit`
-
- * a miss or a hit on a hit-for-miss object (an object with
- ``obj.uncacheable == true``): pass to :ref:`vcl_miss`
-
- * a hit on a hit-for-pass object (for which ``pass(DURATION)`` had been
- previously returned from ``vcl_backend_response``): pass to
- :ref:`vcl_pass`
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``lookup``
+ | Look up the object in cache.
+ |
+ | Control passes to :ref:`vcl_purge` when coming from a ``purge``
+ | return in `vcl_recv`.
+ |
+ | Otherwise control passes to the next subroutine depending on the
+ | result of the cache lookup:
+ |
+ | * a hit: pass to :ref:`vcl_hit`
+ |
+ | * a miss or a hit on a hit-for-miss object (an object with
+ | ``obj.uncacheable == true``): pass to :ref:`vcl_miss`
+ |
+ | * a hit on a hit-for-pass object (for which ``pass(DURATION)`` had been
+ | previously returned from ``vcl_backend_response``): pass to
+ | :ref:`vcl_pass`
.. _vcl_purge:
@@ -174,14 +153,15 @@ Called after the purge has been executed and all its variants have been evicted.
The `vcl_purge` subroutine may terminate with calling ``return()`` with one
of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``synth(status code, reason)``
- see :ref:`synth`
-
- ``restart``
- see :ref:`restart`
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``synth(status code, reason)``
+ | see :ref:`synth`
+ |
+ | ``restart``
+ | see :ref:`restart`
.. _vcl_miss:
@@ -198,21 +178,22 @@ the backend processing side.
The `vcl_miss` subroutine may terminate with calling ``return()`` with one
of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``synth(status code, reason)``
- see :ref:`synth`
-
- ``restart``
- see :ref:`restart`
-
- ``pass``
- see :ref:`pass`
-
- ``fetch``
- Retrieve the requested object from the backend. Control will
- eventually pass to `vcl_backend_fetch`.
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``synth(status code, reason)``
+ | see :ref:`synth`
+ |
+ | ``restart``
+ | see :ref:`restart`
+ |
+ | ``pass``
+ | see :ref:`pass`
+ |
+ | ``fetch``
+ | Retrieve the requested object from the backend. Control will
+ | eventually pass to `vcl_backend_fetch`.
.. _vcl_hit:
@@ -226,21 +207,21 @@ stale: It can have a zero or negative `ttl` with only `grace` or
The `vcl_hit` subroutine may terminate with calling ``return()``
with one of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``synth(status code, reason)``
- see :ref:`synth`
-
- ``restart``
- see :ref:`restart`
-
- ``pass``
- see :ref:`pass`
-
- ``deliver``
- Deliver the object. If it is stale, a background fetch to refresh
- it is triggered.
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``synth(status code, reason)``
+ | see :ref:`synth`
+ |
+ | ``restart``
+ | see :ref:`restart`
+ |
+ | ``pass``
+ | see :ref:`pass`
+ |
+ | ``deliver``
+ | Deliver the object. If it is stale, a background fetch to refresh
+ | it is triggered.
.. _vcl_deliver:
@@ -252,17 +233,18 @@ Called before any object except a `vcl_synth` result is delivered to the client.
The `vcl_deliver` subroutine may terminate with calling ``return()`` with one
of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``synth(status code, reason)``
- see :ref:`synth`
-
- ``restart``
- see :ref:`restart`
-
- ``deliver``
- Deliver the object to the client.
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``synth(status code, reason)``
+ | see :ref:`synth`
+ |
+ | ``restart``
+ | see :ref:`restart`
+ |
+ | ``deliver``
+ | Deliver the object to the client.
.. _vcl_synth:
@@ -279,18 +261,19 @@ A `vcl_synth` defined object never enters the cache, contrary to a
The subroutine may terminate with calling ``return()`` with one of the
following keywords:
- ``fail``
- see :ref:`fail`
-
- ``restart``
- see :ref:`restart`
-
- ``deliver``
- Directly deliver the object defined by `vcl_synth` to the client
- without calling `vcl_deliver`.
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``restart``
+ | see :ref:`restart`
+ |
+ | ``deliver``
+ | Directly deliver the object defined by `vcl_synth` to the client
+ | without calling `vcl_deliver`.
Backend Side
-------------
+############
.. _vcl_backend_fetch:
@@ -303,19 +286,20 @@ typically alter the request before it gets to the backend.
The `vcl_backend_fetch` subroutine may terminate with calling
``return()`` with one of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``abandon``
- see :ref:`abandon`
-
- ``fetch``
- Fetch the object from the backend.
-
- ``error(status code, reason)``
- Transition to :ref:`vcl_backend_error` with ``beresp.status`` and
- ``beresp.reason`` being preset to the arguments of ``error()`` if
- arguments are provided.
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``abandon``
+ | see :ref:`abandon`
+ |
+ | ``fetch``
+ | Fetch the object from the backend.
+ |
+ | ``error(status code, reason)``
+ | Transition to :ref:`vcl_backend_error` with ``beresp.status`` and
+ | ``beresp.reason`` being preset to the arguments of ``error()`` if
+ | arguments are provided.
Before calling `vcl_backend_fetch`, Varnish core prepares the `bereq`
backend request as follows:
@@ -356,32 +340,33 @@ the backend.
The `vcl_backend_response` subroutine may terminate with calling
``return()`` with one of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``abandon``
- see :ref:`abandon`
-
- ``deliver``
- For a 304 response, create an updated cache object.
- Otherwise, fetch the object body from the backend and initiate
- delivery to any waiting client requests, possibly in parallel
- (streaming).
-
- ``retry``
- Retry the backend transaction. Increases the `retries` counter.
- If the number of retries is higher than *max_retries*,
- control will be passed to :ref:`vcl_backend_error`.
-
- ``pass(duration)``
- Mark the object as a hit-for-pass for the given duration. Subsequent
- lookups hitting this object will be turned into passed transactions,
- as if ``vcl_recv`` had returned ``pass``.
-
- ``error(status code, reason)``
- Transition to :ref:`vcl_backend_error` with ``beresp.status`` and
- ``beresp.reason`` being preset to the arguments of ``error()`` if
- arguments are provided.
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``abandon``
+ | see :ref:`abandon`
+ |
+ | ``deliver``
+ | For a 304 response, create an updated cache object.
+ | Otherwise, fetch the object body from the backend and initiate
+ | delivery to any waiting client requests, possibly in parallel
+ | (streaming).
+ |
+ | ``retry``
+ | Retry the backend transaction. Increases the `retries` counter.
+ | If the number of retries is higher than *max_retries*,
+ | control will be passed to :ref:`vcl_backend_error`.
+ |
+ | ``pass(duration)``
+ | Mark the object as a hit-for-pass for the given duration. Subsequent
+ | lookups hitting this object will be turned into passed transactions,
+ | as if ``vcl_recv`` had returned ``pass``.
+ |
+ | ``error(status code, reason)``
+ | Transition to :ref:`vcl_backend_error` with ``beresp.status`` and
+ | ``beresp.reason`` being preset to the arguments of ``error()`` if
+ | arguments are provided.
.. _vcl_backend_error:
@@ -410,25 +395,26 @@ zero in ``vcl_backend_error``.
The `vcl_backend_error` subroutine may terminate with calling ``return()``
with one of the following keywords:
- ``fail``
- see :ref:`fail`
-
- ``abandon``
- see :ref:`abandon`
-
- ``deliver``
- Deliver and possibly cache the object defined in
- `vcl_backend_error` **as if it was fetched from the backend**, also
- referred to as a "backend synth".
-
- ``retry``
- Retry the backend transaction. Increases the `retries` counter.
- If the number of retries is higher than *max_retries*,
- :ref:`vcl_synth` on the client side is called with ``resp.status``
- preset to 503.
+ |
+ | ``fail``
+ | see :ref:`fail`
+ |
+ | ``abandon``
+ | see :ref:`abandon`
+ |
+ | ``deliver``
+ | Deliver and possibly cache the object defined in
+ | `vcl_backend_error` **as if it was fetched from the backend**, also
+ | referred to as a "backend synth".
+ |
+ | ``retry``
+ | Retry the backend transaction. Increases the `retries` counter.
+ | If the number of retries is higher than *max_retries*,
+ | :ref:`vcl_synth` on the client side is called with ``resp.status``
+ | preset to 503.
During vcl.load / vcl.discard
------------------------------
+#############################
.. _vcl_init:
@@ -441,11 +427,12 @@ Typically used to initialize VMODs.
The `vcl_init` subroutine may terminate with calling ``return()``
with one of the following keywords:
- ``ok``
- Normal return, VCL continues loading.
-
- ``fail``
- Abort loading of this VCL.
+ |
+ | ``ok``
+ | Normal return, VCL continues loading.
+ |
+ | ``fail``
+ | Abort loading of this VCL.
.. _vcl_fini:
@@ -458,5 +445,6 @@ Typically used to clean up VMODs.
The `vcl_fini` subroutine may terminate with calling ``return()``
with one of the following keywords:
- ``ok``
- Normal return, VCL will be discarded.
+ |
+ | ``ok``
+ | Normal return, VCL will be discarded.
diff --git a/doc/sphinx/users-guide/vcl-actions.rst b/doc/sphinx/users-guide/vcl-actions.rst
index 5eb13c799..b51b1bf92 100644
--- a/doc/sphinx/users-guide/vcl-actions.rst
+++ b/doc/sphinx/users-guide/vcl-actions.rst
@@ -14,7 +14,7 @@ processing in varnish continues as shown in :ref:`reference-states`.
Common actions are documented here, while additional actions specific
to only one or some subroutines are documented in
-:ref:`vcl-built-in-subs` as well as which action can be used from
+:ref:`vcl-steps(7)` as well as which action can be used from
which built in subroutine.
common actions for the client and backend side
diff --git a/doc/sphinx/users-guide/vcl-built-in-code.rst b/doc/sphinx/users-guide/vcl-built-in-code.rst
index 2bd72ed50..59383e4ef 100644
--- a/doc/sphinx/users-guide/vcl-built-in-code.rst
+++ b/doc/sphinx/users-guide/vcl-built-in-code.rst
@@ -4,7 +4,7 @@ Built-in VCL
============
Whenever a VCL program is loaded, the built-in VCL is appended to it. The
-:ref:`vcl-built-in-subs` have a special property, they can appear multiple
+vcl built-in subs (:ref:`vcl_steps`) have a special property, they can appear multiple
times and the result is concatenation of all built-in subroutines.
For example, let's take the following snippet::
diff --git a/doc/sphinx/users-guide/vcl-syntax.rst b/doc/sphinx/users-guide/vcl-syntax.rst
index 7ef4dd7e7..10748596a 100644
--- a/doc/sphinx/users-guide/vcl-syntax.rst
+++ b/doc/sphinx/users-guide/vcl-syntax.rst
@@ -99,7 +99,7 @@ Built in subroutines
Varnish has quite a few built-in subroutines that are called for each
transaction as it flows through Varnish. These built-in subroutines are
-all named ``vcl_*`` and are explained in :ref:`vcl-built-in-subs`.
+all named ``vcl_*`` and are explained in :ref:`vcl_steps`.
Processing in built-in subroutines ends with ``return (<action>)``
(see :ref:`user-guide-vcl_actions`).
@@ -130,7 +130,7 @@ values.
``return (<action>)`` (see :ref:`user-guide-vcl_actions`) as shown in
the example above returns all the way from the top level built in
-subroutine (see :ref:`vcl-built-in-subs`) which, possibly through
+subroutine (see :ref:`vcl_steps`) which, possibly through
multiple steps, lead to the call of the custom subroutine.
``return`` without an action resumes execution after the ``call``
diff --git a/doc/sphinx/users-guide/vcl.rst b/doc/sphinx/users-guide/vcl.rst
index 831a24071..2647a6491 100644
--- a/doc/sphinx/users-guide/vcl.rst
+++ b/doc/sphinx/users-guide/vcl.rst
@@ -40,7 +40,6 @@ code commented out in the file `builtin.vcl` that ships with Varnish Cache.
:maxdepth: 1
vcl-syntax
- vcl-built-in-subs
vcl-built-in-code
vcl-variables
vcl-actions
diff --git a/man/Makefile.am b/man/Makefile.am
index b78dc7cfe..4b89fce68 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -7,6 +7,7 @@ dist_man_MANS = \
vcl-backend.7 \
vcl-probe.7 \
vcl-var.7 \
+ vcl-step.7 \
vsl.7 \
vsl-query.7 \
varnishadm.1 \
@@ -60,6 +61,10 @@ vcl-probe.7: $(top_builddir)/doc/sphinx/reference/vcl-probe.rst
vcl-var.7: $(top_builddir)/doc/sphinx/reference/vcl-var.rst
$(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vcl-var.rst $@
+vcl-step.7: $(top_builddir)/doc/sphinx/reference/vcl-step.rst \
+ $(top_builddir)/doc/sphinx/reference/vcl_step.rst
+ $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vcl-step.rst $@
+
vsl.7: $(top_builddir)/doc/sphinx/reference/vsl.rst \
$(top_builddir)/doc/sphinx/include/vsl-tags.rst
$(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vsl.rst $@
More information about the varnish-commit
mailing list