From 0bdb420bf03fe4d8bdca4facdcba271d882cda87 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Mon, 16 Feb 2026 08:28:11 +0100 Subject: [PATCH 001/196] Move is done This reverts commit 0038dd19804fd92cd8bd4bfe92e5a515a57d5e8e. --- Makefile.am | 8 -------- README.rst | 38 +++++++++++--------------------------- configure.ac | 7 ------- 3 files changed, 11 insertions(+), 42 deletions(-) diff --git a/Makefile.am b/Makefile.am index 97bfacf0c7..934fb45534 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,11 +1,3 @@ -all: - @echo - @echo - @echo THIS REPOSITORY HAS MOVED. See README.rst - @echo - @echo - exit 1 - ACLOCAL_AMFLAGS = -I m4 -I . SUBDIRS = include lib bin vmod etc doc man contrib diff --git a/README.rst b/README.rst index e260e278e8..ba26725f9d 100644 --- a/README.rst +++ b/README.rst @@ -3,39 +3,23 @@ SPDX-License-Identifier: BSD-2-Clause See LICENSE file for full text of license -===================================== -IMPORTANT - THIS REPOSITORY HAS MOVED -===================================== +Vinyl Cache +=========== -New location: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache +This is Vinyl Cache, the high-performance HTTP accelerator. -The main branch changes from ``master`` to ``main``. +Documentation and additional information about Vinyl is available on +https://vinyl-cache.org/ -The last usable version on github has the ``last`` tag. - -Read this: https://vinyl-cache.org/organization/moving.html - -Varnish Cache -============= - -This is Varnish Cache, the high-performance HTTP accelerator. - -Documentation and additional information about Varnish is available on -https://www.varnish-cache.org/ - -Technical questions about Varnish and this release should be addressed -to . +Technical questions about Vinyl Cache and this release should be addressed +to . Please see CONTRIBUTING for how to contribute patches and report bugs. -For questions about commercial support and services related to Varnish -see the `Varnish HTTP Cache Business page -`_ . - -.. |ccibadge| image:: https://circleci.com/gh/varnishcache/varnish-cache/tree/master.svg?style=svg - :target: https://circleci.com/gh/varnishcache/varnish-cache/tree/master -.. _vtest: https://varnish-cache.org/vtest/ +For questions about commercial support and services related to Vinyl Cache +see the `Vinyl HTTP Cache Business page +`_ . -CircleCI tests: |ccibadge| +.. _vtest: https://vinyl-cache.org/vtest/ More platforms are tested via vtest_ diff --git a/configure.ac b/configure.ac index 1d674e495e..2483dfeac2 100644 --- a/configure.ac +++ b/configure.ac @@ -5,13 +5,6 @@ Copyright 2010-2025 UPLEX - Nils Goroll Systemoptimierung]) AC_REVISION([$Id$]) AC_INIT([Varnish], [trunk], [varnish-dev@varnish-cache.org]) AC_CONFIG_SRCDIR(include/miniobj.h) -AC_MSG_ERROR([ - - - THIS REPOSITORY HAS MOVED. See README.rst - - - ]) if ! test -f "${srcdir}/bin/varnishtest/vtest2/src/vtc_main.c" ; then AC_MSG_ERROR([vtest2 seems to be missing, use "git clone --recursive" or "git submodule update --init"]) fi From ca24a31f8bf4ff9e2405f4d0c39bf2f94cb2779b Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Mon, 16 Feb 2026 15:30:21 +0100 Subject: [PATCH 002/196] git mv README.{rst,md} --- README.rst => README.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename README.rst => README.md (100%) diff --git a/README.rst b/README.md similarity index 100% rename from README.rst rename to README.md From 541e8a1c5d6195895d0a94c1ad0893c62b1ea4eb Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Mon, 16 Feb 2026 15:36:28 +0100 Subject: [PATCH 003/196] Markdownify README --- README.md | 27 ++++++++++----------------- 1 file changed, 10 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index ba26725f9d..c4448407ad 100644 --- a/README.md +++ b/README.md @@ -1,25 +1,18 @@ -.. - Copyright (c) 2016-2020 Varnish Software AS + -Vinyl Cache -=========== +# Vinyl Cache This is Vinyl Cache, the high-performance HTTP accelerator. -Documentation and additional information about Vinyl is available on -https://vinyl-cache.org/ +Documentation and additional information about Vinyl Cache is available on + -Technical questions about Vinyl Cache and this release should be addressed -to . +See [here for how to get help](https://vinyl-cache.org/support/index.html). For +questions about commercial support and services related to Vinyl Cache +see the [Vinyl HTTP Cache Business page](https://vinyl-cache.org/business/index.html). -Please see CONTRIBUTING for how to contribute patches and report bugs. - -For questions about commercial support and services related to Vinyl Cache -see the `Vinyl HTTP Cache Business page -`_ . - -.. _vtest: https://vinyl-cache.org/vtest/ - -More platforms are tested via vtest_ +Most platforms are tested via [vtest](https://vinyl-cache.org/vtest/) From 03fc1ce527b43dfa4e13e0dc1a5bc00c6322f092 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Tue, 17 Feb 2026 10:09:18 +0000 Subject: [PATCH 004/196] Switch to dns-canary-multi.vinyl-cache.org --- bin/varnishtest/tests/v00022.vtc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/varnishtest/tests/v00022.vtc b/bin/varnishtest/tests/v00022.vtc index 953882fd84..1a8bbe5b85 100644 --- a/bin/varnishtest/tests/v00022.vtc +++ b/bin/varnishtest/tests/v00022.vtc @@ -5,6 +5,6 @@ feature dns varnish v1 -errvcl {resolves to too many addresses} { backend b none; sub vcl_recv { - if (remote.ip == "dns-canary-multi.varnish-cache.org") {} + if (remote.ip == "dns-canary-multi.vinyl-cache.org") {} } } From 6c925cca131bb07f339dbeb738a86b4b86fe5660 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Tue, 17 Feb 2026 11:17:09 +0100 Subject: [PATCH 005/196] Fix dist after README rename Ref ca24a31f8bf4ff9e2405f4d0c39bf2f94cb2779b --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 934fb45534..32fbcfba0c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -19,7 +19,7 @@ CLEANFILES = \ EXTRA_DIST = \ $(TESTS) \ - README.rst \ + README.md \ README.Packaging \ LICENSE \ autogen.sh \ From cff8eebafc7282875f675fe4801c0d570a7bb25e Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Tue, 17 Feb 2026 10:12:08 +0000 Subject: [PATCH 006/196] Update vtest2 --- bin/varnishtest/vtest2 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/varnishtest/vtest2 b/bin/varnishtest/vtest2 index b987871958..803dcd000b 160000 --- a/bin/varnishtest/vtest2 +++ b/bin/varnishtest/vtest2 @@ -1 +1 @@ -Subproject commit b987871958a2da46ec000e0b6c46a1407fd5010a +Subproject commit 803dcd000b1328f6e766774e23aedbd7f53e7d97 From c48d195db15dcf430243a4f8e142c1e4532aa84f Mon Sep 17 00:00:00 2001 From: Brett A C Sheffield Date: Mon, 16 Feb 2026 19:50:32 +0100 Subject: [PATCH 007/196] configure: make python output match autotools When calling out from configure to python to check compiler flags, make output from wflags.py consistent with the rest of autotools output rather than printing scary compiler errors. --- wflags.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/wflags.py b/wflags.py index 1c1da40d0b..da799f9cdf 100644 --- a/wflags.py +++ b/wflags.py @@ -108,19 +108,19 @@ def main(): use_flags = [] for i in DESIRABLE_OPTIONS + DESIRABLE_WFLAGS + UNDESIRABLE_WFLAGS: + sys.stderr.write("checking whether C compiler accepts " + i + "... ") j = cc(compiler, i, obj_file.name, src_file.name) if not j: use_flags.append(i) + sys.stderr.write("yes\n") else: - sys.stderr.write(compiler + " cannot " + i + '\n') + sys.stderr.write(" no\n") if b'error: unrecognized command line option' in j: # LLVM pass elif b'warning: unknown warning option' in j: # GCC pass - else: - sys.stderr.write("\n\t" + j.decode('utf8') + '\n') print(" ".join(use_flags)) if __name__ == "__main__": From c382a96889d32d03bb226d043d77e07c0d51546b Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 18 Feb 2026 15:11:12 +0100 Subject: [PATCH 008/196] migrate pull request URLs sed -i 's:/github.com/varnishcache/varnish-cache/pull:/code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls:g' $(git grep -l github.com/varnishcache/varnish-cache/pull) And then manually edited two URLs pointing to individual comments --- bin/varnishd/cache/cache_vcl.c | 4 +- bin/varnishtest/tests/s00010.vtc | 2 +- doc/changes.rst | 96 ++++++++++++++++---------------- 3 files changed, 51 insertions(+), 51 deletions(-) diff --git a/bin/varnishd/cache/cache_vcl.c b/bin/varnishd/cache/cache_vcl.c index 2c21957393..48d8bd039e 100644 --- a/bin/varnishd/cache/cache_vcl.c +++ b/bin/varnishd/cache/cache_vcl.c @@ -411,7 +411,7 @@ vdire_start_iter(struct vdire *vdire) CHECK_OBJ_NOTNULL(vdire, VDIRE_MAGIC); - // https://github.com/varnishcache/varnish-cache/pull/4142#issuecomment-2593091097 + // https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4142#issuecomment-57363 ASSERT_CLI(); Lck_Lock(vdire->mtx); @@ -461,7 +461,7 @@ vdire_start_event(struct vdire *vdire, const struct vcltemp *temp) Lck_AssertHeld(vdire->mtx); - // https://github.com/varnishcache/varnish-cache/pull/4142#issuecomment-2593091097 + // https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4142#issuecomment-57363 ASSERT_CLI(); AZ(vdire->checkpoint); diff --git a/bin/varnishtest/tests/s00010.vtc b/bin/varnishtest/tests/s00010.vtc index 65db8d5777..65339cd81d 100644 --- a/bin/varnishtest/tests/s00010.vtc +++ b/bin/varnishtest/tests/s00010.vtc @@ -1,6 +1,6 @@ varnishtest "client h1 send timeouts - tcp" -# XXX See https://github.com/varnishcache/varnish-cache/pull/2980#issuecomment-486214661 +# XXX See https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2980#issuecomment-52170 feature cmd {test $(uname) != "SunOS" && test $(uname) != "Darwin"} barrier b1 cond 2 -cyclic diff --git a/doc/changes.rst b/doc/changes.rst index 7e89c785f5..7c2a25d531 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -53,17 +53,17 @@ Vinyl-Cache NEXT (2026-03-15) Varnish-Cache 8.0.0 (2025-09-15) ================================ -.. _4388: https://github.com/varnishcache/varnish-cache/pull/4388 +.. _4388: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4388 * ``varnishncsa`` can log VCL set headers again using the ``%{X[:first|last]}i`` and ``%{X[:first|last]}o`` formats. (`4388`_) -.. _4336: https://github.com/varnishcache/varnish-cache/pull/4336 +.. _4336: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4336 * A regression has been fixed which prevented vcl controlled custom Range requests with ``http_range_support`` enabled. (`4336`_) -.. _4245: https://github.com/varnishcache/varnish-cache/pull/4245 +.. _4245: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4245 * The ``Content-Length`` response header is now also sent in response to all ``HEAD`` requests. (`4245`_) @@ -238,7 +238,7 @@ Varnish-Cache 8.0.0 (2025-09-15) * ``http_req_overflow_status`` can now also be set to 500. -.. _4261: https://github.com/varnishcache/varnish-cache/pull/4261 +.. _4261: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4261 * An optimization was added to make startups faster when loading a persistent storage with a long list of bans. (4261_) @@ -246,7 +246,7 @@ Varnish-Cache 8.0.0 (2025-09-15) * gzip buffers are now allocated from transient stevedore memory instead of a regular heap allocation. -.. _4308: https://github.com/varnishcache/varnish-cache/pull/4308 +.. _4308: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4308 * ``hdr_t`` type is now a structured type. (4308_) @@ -394,15 +394,15 @@ Varnish-Cache 7.7 (2025-03-17) * ``req.hash`` is now also readable from ``vcl_synth`` and ``vcl_pipe``. -.. _4142: https://github.com/varnishcache/varnish-cache/pull/4142 -.. _4259: https://github.com/varnishcache/varnish-cache/pull/4259 +.. _4142: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4142 +.. _4259: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4259 * Internal handling of iterations on directors (like the cli command ``backend.list`` command) has been improved to better interoperate with concurrent director creation and destruction operations, avoiding most deadlocks in this area (`4142`_, some cases remain for now, see `4259`_). -.. _4253: https://github.com/varnishcache/varnish-cache/pull/4253 +.. _4253: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4253 * The new ``ban_any_variant`` parameter allows to configure the maximum number of possibly non matching variants evaluated against the ban list during @@ -416,7 +416,7 @@ Varnish-Cache 7.7 (2025-03-17) semantics of ban expressions with regards to variants. ``0`` will become the new default in a future release of Varnish-Cache. (`4253`_) -.. _3528: https://github.com/varnishcache/varnish-cache/pull/3528 +.. _3528: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3528 * ``varnishncsa`` now handles headers unset and changed from VCL more consistently: request headers are logged as they were received from the client @@ -462,7 +462,7 @@ Varnish-Cache 7.7 (2025-03-17) * Connection pools are now cleaned up asynchronously. -.. _4233: https://github.com/varnishcache/varnish-cache/pull/4233 +.. _4233: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4233 * A concurrency issue in the backend connection queuing feature as configured through the ``backend_wait_*`` parameters and ``wait_*`` backend attributes @@ -531,7 +531,7 @@ Varnish Cache 7.6.1 (2024-11-08) for VSM mlock() errors. (4193_) .. _4183: https://github.com/varnishcache/varnish-cache/issues/4183 -.. _4154: https://github.com/varnishcache/varnish-cache/pull/4154 +.. _4154: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4154 .. _4204: https://github.com/varnishcache/varnish-cache/issues/4204 .. _4193: https://github.com/varnishcache/varnish-cache/issues/4193 @@ -938,10 +938,10 @@ Varnish Cache 7.5.0 (2024-03-18) .. _3995: https://github.com/varnishcache/varnish-cache/issues/3995 .. _3996: https://github.com/varnishcache/varnish-cache/issues/3996 .. _4022: https://github.com/varnishcache/varnish-cache/issues/4022 -.. _3563: https://github.com/varnishcache/varnish-cache/pull/3563 -.. _3997: https://github.com/varnishcache/varnish-cache/pull/3997 -.. _3998: https://github.com/varnishcache/varnish-cache/pull/3998 -.. _3999: https://github.com/varnishcache/varnish-cache/pull/3999 +.. _3563: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3563 +.. _3997: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3997 +.. _3998: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3998 +.. _3999: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3999 .. _VSV00014: https://varnish-cache.org/security/VSV00014.html ================================ @@ -1097,9 +1097,9 @@ Varnish Cache 7.4.0 (2023-09-15) other implementations, this has been fixed (3908_). .. _3905: https://github.com/varnishcache/varnish-cache/issues/3905 -.. _3908: https://github.com/varnishcache/varnish-cache/pull/3908 +.. _3908: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3908 .. _3911: https://github.com/varnishcache/varnish-cache/issues/3911 -.. _3914: https://github.com/varnishcache/varnish-cache/pull/3914 +.. _3914: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3914 .. _3925: https://github.com/varnishcache/varnish-cache/issues/3925 .. _3938: https://github.com/varnishcache/varnish-cache/issues/3938 .. _3940: https://github.com/varnishcache/varnish-cache/issues/3940 @@ -1358,7 +1358,7 @@ Varnish Cache 7.2.0 (2022-09-15) for requests coming back from the waiting list, it was fixed. (3841_) .. _3830: https://github.com/varnishcache/varnish-cache/issues/3830 -.. _3841: https://github.com/varnishcache/varnish-cache/pull/3841 +.. _3841: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3841 .. _3846: https://github.com/varnishcache/varnish-cache/issues/3846 .. _VSV00009: https://varnish-cache.org/security/VSV00009.html @@ -1582,8 +1582,8 @@ Varnish Cache 7.0.1 (2021-11-23) .. _3719: https://github.com/varnishcache/varnish-cache/issues/3719 .. _3721: https://github.com/varnishcache/varnish-cache/issues/3726 .. _3734: https://github.com/varnishcache/varnish-cache/issues/3734 -.. _3737: https://github.com/varnishcache/varnish-cache/pull/3737 -.. _3732: https://github.com/varnishcache/varnish-cache/pull/3732 +.. _3737: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3737 +.. _3732: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3732 ================================ Varnish Cache 7.0.0 (2021-09-15) @@ -2872,22 +2872,22 @@ Fixed bugs .. _2418: https://github.com/varnishcache/varnish-cache/issues/2418 .. _2589: https://github.com/varnishcache/varnish-cache/issues/2589 -.. _2741: https://github.com/varnishcache/varnish-cache/pull/2741 +.. _2741: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2741 .. _2743: https://github.com/varnishcache/varnish-cache/issues/2743 .. _2780: https://github.com/varnishcache/varnish-cache/issues/2780 .. _2782: https://github.com/varnishcache/varnish-cache/issues/2782 -.. _2783: https://github.com/varnishcache/varnish-cache/pull/2783 +.. _2783: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2783 .. _2787: https://github.com/varnishcache/varnish-cache/issues/2787 .. _2788: https://github.com/varnishcache/varnish-cache/issues/2788 .. _2790: https://github.com/varnishcache/varnish-cache/issues/2790 -.. _2792: https://github.com/varnishcache/varnish-cache/pull/2792 +.. _2792: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2792 .. _2809: https://github.com/varnishcache/varnish-cache/issues/2809 -.. _2813: https://github.com/varnishcache/varnish-cache/pull/2813 +.. _2813: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2813 .. _2815: https://github.com/varnishcache/varnish-cache/issues/2815 .. _2820: https://github.com/varnishcache/varnish-cache/issues/2820 .. _2823: https://github.com/varnishcache/varnish-cache/issues/2823 .. _2831: https://github.com/varnishcache/varnish-cache/issues/2831 -.. _2837: https://github.com/varnishcache/varnish-cache/pull/2837 +.. _2837: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2837 .. _2840: https://github.com/varnishcache/varnish-cache/issues/2840 .. _VIP16: https://github.com/varnishcache/varnish-cache/wiki/VIP16%3A-Retire-parameters-aliases @@ -2940,7 +2940,7 @@ C APIs (for vmod and utility authors) * Improved support for the VCL STRANDS type, VMOD blob refactored to use STRANDS (2745_) -.. _2718: https://github.com/varnishcache/varnish-cache/pull/2718 +.. _2718: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2718 .. _2745: https://github.com/varnishcache/varnish-cache/issues/2745 .. _2708: https://github.com/varnishcache/varnish-cache/issues/2708 @@ -2963,8 +2963,8 @@ Fixed bugs .. _2749: https://github.com/varnishcache/varnish-cache/issues/2749 .. _2753: https://github.com/varnishcache/varnish-cache/issues/2753 .. _2754: https://github.com/varnishcache/varnish-cache/issues/2754 -.. _2759: https://github.com/varnishcache/varnish-cache/pull/2759 -.. _2760: https://github.com/varnishcache/varnish-cache/pull/2760 +.. _2759: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2759 +.. _2760: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2760 .. _2761: https://github.com/varnishcache/varnish-cache/issues/2761 .. _2763: https://github.com/varnishcache/varnish-cache/issues/2763 .. _2773: https://github.com/varnishcache/varnish-cache/issues/2773 @@ -2978,8 +2978,8 @@ Varnish Cache 6.0.1 (2018-08-29) * Importing the same VMOD multiple times is now allowed, if the file_id is identical. -.. _2705: https://github.com/varnishcache/varnish-cache/pull/2705 -.. _2737: https://github.com/varnishcache/varnish-cache/pull/2737 +.. _2705: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2705 +.. _2737: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2737 varnishstat ----------- @@ -3061,8 +3061,8 @@ Fixed bugs .. _2631: https://github.com/varnishcache/varnish-cache/issues/2631 .. _2647: https://github.com/varnishcache/varnish-cache/issues/2647 .. _2649: https://github.com/varnishcache/varnish-cache/issues/2649 -.. _2650: https://github.com/varnishcache/varnish-cache/pull/2650 -.. _2651: https://github.com/varnishcache/varnish-cache/pull/2651 +.. _2650: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2650 +.. _2651: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2651 .. _2661: https://github.com/varnishcache/varnish-cache/issues/2661 .. _2678: https://github.com/varnishcache/varnish-cache/issues/2678 .. _2679: https://github.com/varnishcache/varnish-cache/issues/2679 @@ -3079,7 +3079,7 @@ Fixed bugs .. _2716: https://github.com/varnishcache/varnish-cache/issues/2716 .. _2719: https://github.com/varnishcache/varnish-cache/issues/2719 .. _2722: https://github.com/varnishcache/varnish-cache/issues/2722 -.. _2726: https://github.com/varnishcache/varnish-cache/pull/2726 +.. _2726: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2726 .. _2727: https://github.com/varnishcache/varnish-cache/issues/2727 .. _2731: https://github.com/varnishcache/varnish-cache/issues/2731 @@ -3342,7 +3342,7 @@ Fixed bugs which may influence VCL behaviour * After reusing a backend connection fails once, a fresh connection will be opened (2135_). -.. _2135: https://github.com/varnishcache/varnish-cache/pull/2135 +.. _2135: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2135 Fixed bugs ---------- @@ -3404,7 +3404,7 @@ Fixed bugs * H2: Handle failed write(2) in h2_ou_session. (2607_) .. _1772: https://github.com/varnishcache/varnish-cache/issues/1772 -.. _2135: https://github.com/varnishcache/varnish-cache/pull/2135 +.. _2135: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2135 .. _2268: https://github.com/varnishcache/varnish-cache/issues/2268 .. _2305: https://github.com/varnishcache/varnish-cache/issues/2305 .. _2319: https://github.com/varnishcache/varnish-cache/issues/2319 @@ -3419,17 +3419,17 @@ Fixed bugs .. _2505: https://github.com/varnishcache/varnish-cache/issues/2505 .. _2506: https://github.com/varnishcache/varnish-cache/issues/2506 .. _2518: https://github.com/varnishcache/varnish-cache/issues/2518 -.. _2519: https://github.com/varnishcache/varnish-cache/pull/2519 +.. _2519: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2519 .. _2527: https://github.com/varnishcache/varnish-cache/issues/2527 .. _2535: https://github.com/varnishcache/varnish-cache/issues/2535 .. _2539: https://github.com/varnishcache/varnish-cache/issues/2539 .. _2541: https://github.com/varnishcache/varnish-cache/issues/2541 -.. _2545: https://github.com/varnishcache/varnish-cache/pull/2545 +.. _2545: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2545 .. _2546: https://github.com/varnishcache/varnish-cache/issues/2546 .. _2551: https://github.com/varnishcache/varnish-cache/issues/2551 -.. _2554: https://github.com/varnishcache/varnish-cache/pull/2554 +.. _2554: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2554 .. _2556: https://github.com/varnishcache/varnish-cache/issues/2556 -.. _2558: https://github.com/varnishcache/varnish-cache/pull/2558 +.. _2558: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2558 .. _2563: https://github.com/varnishcache/varnish-cache/issues/2563 .. _2570: https://github.com/varnishcache/varnish-cache/issues/2570 .. _2574: https://github.com/varnishcache/varnish-cache/issues/2574 @@ -3447,7 +3447,7 @@ Bugs fixed * 2429_ - Avoid buffer read overflow on vcl_backend_error and -sfile * 2492_ - Use the idle read timeout only on empty requests. -.. _2429: https://github.com/varnishcache/varnish-cache/pull/2429 +.. _2429: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2429 .. _2492: https://github.com/varnishcache/varnish-cache/issues/2492 ================================ @@ -3456,7 +3456,7 @@ Varnish Cache 5.2.0 (2017-09-15) * The ``cli_buffer`` parameter has been deprecated (2382_) -.. _2382: https://github.com/varnishcache/varnish-cache/pull/2382 +.. _2382: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2382 ================================== Varnish Cache 5.2-RC1 (2017-09-04) @@ -3836,7 +3836,7 @@ Changes since 4.1.8: * Move a cli buffer to VSB (from stack). * Use a separate stack for signals. -.. _2422: https://github.com/varnishcache/varnish-cache/pull/2422 +.. _2422: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2422 Bugs fixed ---------- @@ -3852,11 +3852,11 @@ Bugs fixed .. _2337: https://github.com/varnishcache/varnish-cache/issues/2337 .. _2366: https://github.com/varnishcache/varnish-cache/issues/2366 -.. _2372: https://github.com/varnishcache/varnish-cache/pull/2372 +.. _2372: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2372 .. _2373: https://github.com/varnishcache/varnish-cache/issues/2373 .. _2380: https://github.com/varnishcache/varnish-cache/issues/2380 .. _2390: https://github.com/varnishcache/varnish-cache/issues/2390 -.. _2429: https://github.com/varnishcache/varnish-cache/pull/2429 +.. _2429: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2429 .. _2492: https://github.com/varnishcache/varnish-cache/issues/2492 ================================ @@ -3947,11 +3947,11 @@ Bugs fixed * 2313_ - Cannot link to varnishapi, symbols missing .. _2200: https://github.com/varnishcache/varnish-cache/issues/2200 -.. _2216: https://github.com/varnishcache/varnish-cache/pull/2216 +.. _2216: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2216 .. _2233: https://github.com/varnishcache/varnish-cache/issues/2233 .. _2241: https://github.com/varnishcache/varnish-cache/issues/2241 .. _2270: https://github.com/varnishcache/varnish-cache/issues/2270 -.. _2273: https://github.com/varnishcache/varnish-cache/pull/2273 +.. _2273: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2273 .. _2275: https://github.com/varnishcache/varnish-cache/issues/2275 .. _2295: https://github.com/varnishcache/varnish-cache/issues/2295 .. _2301: https://github.com/varnishcache/varnish-cache/issues/2301 @@ -4012,7 +4012,7 @@ Bugs fixed .. _2148: https://github.com/varnishcache/varnish-cache/issues/2148 .. _2168: https://github.com/varnishcache/varnish-cache/issues/2168 .. _2178: https://github.com/varnishcache/varnish-cache/issues/2178 -.. _2188: https://github.com/varnishcache/varnish-cache/pull/2188 +.. _2188: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/2188 .. _2190: https://github.com/varnishcache/varnish-cache/issues/2190 .. _2197: https://github.com/varnishcache/varnish-cache/issues/2197 @@ -4137,7 +4137,7 @@ Varnish Cache 4.1.3-beta1 (2016-06-15) * [varnishtest] New synchronization primitive barriers added, improving coordination when test cases call external programs. -.. _1905: https://github.com/varnishcache/varnish-cache/pull/1905 +.. _1905: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/1905 Bugs fixed ---------- From 2d5312caf8e70a35366ba85c1e09fa3c46e3f21a Mon Sep 17 00:00:00 2001 From: Thibaut Artis Date: Tue, 17 Feb 2026 18:08:01 +0100 Subject: [PATCH 009/196] vcc: Fix VCL_BOOL translation When translating VCL-to-C, VCL_BOOL values are translated verbatim, the stdbool.h file is not included in vgc.c. On Debian this causes the following error: ``` **** v1 CLI RX|Message from C-compiler: **** v1 CLI RX|vgc.c: In function 'VGC_function_vcl_init': **** v1 CLI RX|vgc.c:4402:26: error: 'false' undeclared (first use in this function) **** v1 CLI RX| 4402 | .hidevclname = false, **** v1 CLI RX| | ^~~~~ **** v1 CLI RX|vgc.c:702:1: note: 'false' is defined in header ''; this is probably fixable by adding '#include ' **** v1 CLI RX| 701 | #include // NULL, size_t **** v1 CLI RX| +++ |+#include **** v1 CLI RX| 702 | #include // [u]int%d_t **** v1 CLI RX|vgc.c:4402:26: note: each undeclared identifier is reported only once for each function it appears in **** v1 CLI RX| 4402 | .hidevclname = false, **** v1 CLI RX|[1 lines truncated] **** v1 CLI RX|Running C-compiler failed, exited with 1 **** v1 CLI RX|VCL compilation failed ``` This commit fixes this by translating the boolean values (true/false) to int values (0/1). Since the strings are already checked to be valid identifiers we only check for the first letter in order to discriminate true from false. --- bin/varnishtest/tests/v00076.vtc | 19 +++++++++++++++++++ lib/libvcc/vcc_expr.c | 11 +++++++++-- vmod/vmod_debug.c | 8 ++++++++ vmod/vmod_debug.vcc | 4 ++++ 4 files changed, 40 insertions(+), 2 deletions(-) create mode 100644 bin/varnishtest/tests/v00076.vtc diff --git a/bin/varnishtest/tests/v00076.vtc b/bin/varnishtest/tests/v00076.vtc new file mode 100644 index 0000000000..628909ec50 --- /dev/null +++ b/bin/varnishtest/tests/v00076.vtc @@ -0,0 +1,19 @@ +varnishtest "Test boolean parameters work without stdbool.h in vgc.c" + +server s1 { + rxreq + txresp +} -start + +varnish v1 -vcl+backend { + import debug; + + sub vcl_init { + debug.test_default_bool(false); + } +} -start + +client c1 { + txreq + rxresp +} -run diff --git a/lib/libvcc/vcc_expr.c b/lib/libvcc/vcc_expr.c index 090a7b5e5d..bcd2231ab5 100644 --- a/lib/libvcc/vcc_expr.c +++ b/lib/libvcc/vcc_expr.c @@ -652,8 +652,15 @@ vcc_func(struct vcc *tl, struct expr **e, const void *priv, } if (fa->result == NULL && fa->type == ENUM && fa->val != NULL) fa->result = vcc_do_enum(tl, cfunc, strlen(fa->val), fa->val); - if (fa->result == NULL && fa->val != NULL) - fa->result = vcc_mk_expr(fa->type, "%s", fa->val); + if (fa->result == NULL && fa->val != NULL) { + if (fa->type == BOOL) { + if (fa->val[0] == 'f') + fa->result = vcc_mk_expr(fa->type, "0"); + else if (fa->val[0] == 't') + fa->result = vcc_mk_expr(fa->type, "1"); + } else + fa->result = vcc_mk_expr(fa->type, "%s", fa->val); + } if (fa->result != NULL && sa != NULL) { if (fa->cname) bprintf(ssa, "\v1.%s = \v2,\n", fa->cname); diff --git a/vmod/vmod_debug.c b/vmod/vmod_debug.c index 4860da47e9..9c03e26114 100644 --- a/vmod/vmod_debug.c +++ b/vmod/vmod_debug.c @@ -187,6 +187,14 @@ xyzzy_test_priv_top(VRT_CTX, struct vmod_priv *priv, VCL_STRING s) return (priv->priv); } +VCL_VOID v_matchproto_(td_debug_test_default_bool) +xyzzy_test_default_bool(VRT_CTX, VCL_BOOL test) +{ + + CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); + assert(test == 0 || test == 1); +} + VCL_VOID v_matchproto_(td_debug_test_priv_vcl) xyzzy_test_priv_vcl(VRT_CTX, struct vmod_priv *priv) { diff --git a/vmod/vmod_debug.vcc b/vmod/vmod_debug.vcc index d752c1ebad..861ccbcb00 100644 --- a/vmod/vmod_debug.vcc +++ b/vmod/vmod_debug.vcc @@ -69,6 +69,10 @@ $Function STRING test_priv_top(PRIV_TOP, STRING) Test function for TOP private pointers +$Function VOID test_default_bool(BOOL test=true) + +Test function for default bool parameters + $Object obj(STRING string="default", ENUM { one, two, three } number=one) Test object From 8983e2d707ef8cc4acb2f22c76334ed94e9ad46b Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 18 Feb 2026 19:42:23 +0100 Subject: [PATCH 010/196] Fix rst syntax in changes.rst exposed by pandoc --- doc/changes.rst | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/doc/changes.rst b/doc/changes.rst index 7c2a25d531..d88a6368c5 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -742,11 +742,10 @@ Varnish Cache 7.5.0 (2024-03-18) Cache evictions of superseded objects are logged as ``ExpKill`` messages starting with ``VBF_Superseded``. - .. _Varnish-Modules #222: https://github.com/varnish/varnish-modules/issues/222 - * The implementation of ``PRIV_TASK`` and ``PRIV_TOP`` VMOD function/method arguments has been fixed to also work with - ``std.rollback()`` (`Varnish-Modules #222`_) + ``std.rollback()`` (`Varnish-Modules #222 + `_) * Transports are now responsible for calling ``VDP_Close()`` in all cases. @@ -2049,7 +2048,7 @@ Varnish Cache 6.6.0 (2021-03-15) to be literal, whereas before they could be taken from some other variable or function returning ``VCL_STRING``. - Note that these functions never actually handled _dynamic_ regexen, + Note that these functions never actually handled *dynamic* regexen, the string passed with the first call was compiled to a regex, which was then used for the lifetime of the respective VCL. @@ -2855,14 +2854,14 @@ Fixed bugs * Fix warmup/rampup of the shard director (2823_) -* Fix VRT_priv_task for calls from vcl_pipe {} (2820_) +* Fix ``VRT_priv_task`` for calls from vcl_pipe {} (2820_) * Fix assigning == (2809_) * Fix vmod object constructor documentation in the ``vmodtool.py`` - generated RST files -* Fix some stats metrics (vsc) which were wrongly marked as _gauge_ +* Fix some stats metrics (vsc) which were wrongly marked as *gauge* * Fix ``varnishd -I`` (2782_) @@ -2933,7 +2932,7 @@ C APIs (for vmod and utility authors) * libvarnishapi so version bumped to 2.0.0 (2718_) * For VMOD methods/functions with PRIV_TASK or PRIV_TOP arguments, the - struct vrt_priv is allocated on the appropriate workspace. In the + ``struct vrt_priv`` is allocated on the appropriate workspace. In the out-of-workspace condition, VCL failure is invoked, and the VMOD method/function is not called. (2708_) @@ -3286,7 +3285,7 @@ C APIs (for vmod and utility authors) * Rules for including API headers have been changed: * many headers can now only be included once * some headers require specific include ordering - * only ``cache.h`` _or_ ``vrt.h`` can be included + * only ``cache.h`` *or* ``vrt.h`` can be included * Signatures of functions in the VLU API for bytestream into text serialization have been changed From 839ec174abbebaa1b935a5e77c940fdd2dcc57ed Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 18 Feb 2026 20:34:13 +0100 Subject: [PATCH 011/196] Fix links to changes.rst sed -i 's:/github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst:/code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst:g' $(git grep -l github.com/varnishcache/varnish-cache) It is a bit annoying that forgejo does not render RST, so the document is essentially displayed as raw text. Because changes.rst is the basis for release docs and those are going to stay rst in sphinx, we can not sensibly migrate. We could check in an md copy, but that is also not nice... --- doc/sphinx/whats-new/changes-6.2.rst | 2 +- doc/sphinx/whats-new/changes-6.3.rst | 2 +- doc/sphinx/whats-new/changes-6.4.rst | 2 +- doc/sphinx/whats-new/changes-6.5.rst | 2 +- doc/sphinx/whats-new/changes-6.6.rst | 2 +- doc/sphinx/whats-new/changes-7.0.rst | 2 +- doc/sphinx/whats-new/changes-7.1.rst | 2 +- doc/sphinx/whats-new/changes-7.2.rst | 2 +- doc/sphinx/whats-new/changes-7.3.rst | 2 +- doc/sphinx/whats-new/changes-7.4.rst | 2 +- doc/sphinx/whats-new/changes-7.5.rst | 2 +- doc/sphinx/whats-new/changes-7.6.rst | 2 +- doc/sphinx/whats-new/changes-7.7.rst | 2 +- doc/sphinx/whats-new/changes-8.0.rst | 2 +- doc/sphinx/whats-new/upgrading-6.0.rst | 6 +++--- doc/sphinx/whats-new/upgrading-6.2.rst | 2 +- doc/sphinx/whats-new/upgrading-8.0.rst | 2 +- 17 files changed, 19 insertions(+), 19 deletions(-) diff --git a/doc/sphinx/whats-new/changes-6.2.rst b/doc/sphinx/whats-new/changes-6.2.rst index 683466edbb..348c937d43 100644 --- a/doc/sphinx/whats-new/changes-6.2.rst +++ b/doc/sphinx/whats-new/changes-6.2.rst @@ -16,7 +16,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== diff --git a/doc/sphinx/whats-new/changes-6.3.rst b/doc/sphinx/whats-new/changes-6.3.rst index b423764625..d2043eb971 100644 --- a/doc/sphinx/whats-new/changes-6.3.rst +++ b/doc/sphinx/whats-new/changes-6.3.rst @@ -16,7 +16,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== diff --git a/doc/sphinx/whats-new/changes-6.4.rst b/doc/sphinx/whats-new/changes-6.4.rst index 971871243f..b894dd2ecf 100644 --- a/doc/sphinx/whats-new/changes-6.4.rst +++ b/doc/sphinx/whats-new/changes-6.4.rst @@ -16,7 +16,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== diff --git a/doc/sphinx/whats-new/changes-6.5.rst b/doc/sphinx/whats-new/changes-6.5.rst index 42f841e0c6..025ea8a478 100644 --- a/doc/sphinx/whats-new/changes-6.5.rst +++ b/doc/sphinx/whats-new/changes-6.5.rst @@ -16,7 +16,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== diff --git a/doc/sphinx/whats-new/changes-6.6.rst b/doc/sphinx/whats-new/changes-6.6.rst index 4dba423a31..d5acf47780 100644 --- a/doc/sphinx/whats-new/changes-6.6.rst +++ b/doc/sphinx/whats-new/changes-6.6.rst @@ -16,7 +16,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== diff --git a/doc/sphinx/whats-new/changes-7.0.rst b/doc/sphinx/whats-new/changes-7.0.rst index 625d7b08c5..a281223eb9 100644 --- a/doc/sphinx/whats-new/changes-7.0.rst +++ b/doc/sphinx/whats-new/changes-7.0.rst @@ -16,7 +16,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst PCRE2 ===== diff --git a/doc/sphinx/whats-new/changes-7.1.rst b/doc/sphinx/whats-new/changes-7.1.rst index 24ac45e184..b14076f279 100644 --- a/doc/sphinx/whats-new/changes-7.1.rst +++ b/doc/sphinx/whats-new/changes-7.1.rst @@ -11,7 +11,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== diff --git a/doc/sphinx/whats-new/changes-7.2.rst b/doc/sphinx/whats-new/changes-7.2.rst index d46e26ad1a..63c0ada8d6 100644 --- a/doc/sphinx/whats-new/changes-7.2.rst +++ b/doc/sphinx/whats-new/changes-7.2.rst @@ -11,7 +11,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== diff --git a/doc/sphinx/whats-new/changes-7.3.rst b/doc/sphinx/whats-new/changes-7.3.rst index 164952620e..2e84a228fd 100644 --- a/doc/sphinx/whats-new/changes-7.3.rst +++ b/doc/sphinx/whats-new/changes-7.3.rst @@ -11,7 +11,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== diff --git a/doc/sphinx/whats-new/changes-7.4.rst b/doc/sphinx/whats-new/changes-7.4.rst index 55ad2d8904..0a7407ce57 100644 --- a/doc/sphinx/whats-new/changes-7.4.rst +++ b/doc/sphinx/whats-new/changes-7.4.rst @@ -11,7 +11,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== diff --git a/doc/sphinx/whats-new/changes-7.5.rst b/doc/sphinx/whats-new/changes-7.5.rst index 8077709125..5aef7a0e26 100644 --- a/doc/sphinx/whats-new/changes-7.5.rst +++ b/doc/sphinx/whats-new/changes-7.5.rst @@ -11,7 +11,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst Security ======== diff --git a/doc/sphinx/whats-new/changes-7.6.rst b/doc/sphinx/whats-new/changes-7.6.rst index 885b911f8e..d81880ca3d 100644 --- a/doc/sphinx/whats-new/changes-7.6.rst +++ b/doc/sphinx/whats-new/changes-7.6.rst @@ -11,7 +11,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst Changes applying to most varnish-cache programs =============================================== diff --git a/doc/sphinx/whats-new/changes-7.7.rst b/doc/sphinx/whats-new/changes-7.7.rst index bf7777d241..332b7fea7d 100644 --- a/doc/sphinx/whats-new/changes-7.7.rst +++ b/doc/sphinx/whats-new/changes-7.7.rst @@ -15,7 +15,7 @@ A more detailed and technical account of changes in Varnish-Cache, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst Security ======== diff --git a/doc/sphinx/whats-new/changes-8.0.rst b/doc/sphinx/whats-new/changes-8.0.rst index c62714c9f7..6149203ee1 100644 --- a/doc/sphinx/whats-new/changes-8.0.rst +++ b/doc/sphinx/whats-new/changes-8.0.rst @@ -11,7 +11,7 @@ A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== diff --git a/doc/sphinx/whats-new/upgrading-6.0.rst b/doc/sphinx/whats-new/upgrading-6.0.rst index 07b1ed721f..96b6329efd 100644 --- a/doc/sphinx/whats-new/upgrading-6.0.rst +++ b/doc/sphinx/whats-new/upgrading-6.0.rst @@ -485,7 +485,7 @@ sharding of requests to backends will change once and only once. If you have been using other values of ``alg`` for ``.key()`` and need to preserve the previous behavior, see the -`change log `_ +`change log `_ for advice on how to do so. With the ``resolve=LAZY`` argument of the ``.backend()`` method, the @@ -834,7 +834,7 @@ Other changes * The VRT API version has been bumped to 7.0, and comprises a variety of new additions and changes. See ``vrt.h`` and the - `change log `_ + `change log `_ for details. * There are new rules about including API headers -- some may only @@ -852,7 +852,7 @@ Other changes strictly 64 bit (rather than leave it to whatever your platform defines as ``long``). But you may not get that full precision, for reasons discussed in the - `change log `_. + `change log `_. * As part of VRT version 7.0, the ``path`` field has been added to to ``struct vrt_backend``, which a VMOD can use with diff --git a/doc/sphinx/whats-new/upgrading-6.2.rst b/doc/sphinx/whats-new/upgrading-6.2.rst index e01f32b250..3b0edf36cc 100644 --- a/doc/sphinx/whats-new/upgrading-6.2.rst +++ b/doc/sphinx/whats-new/upgrading-6.2.rst @@ -184,7 +184,7 @@ See ``vrt.h``, the `change log`_ and :ref:`whatsnew_changes_director_api_2019_03` in :ref:`whatsnew_changes_2019_03` for details. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst The vmodtool has been changed significantly to avoid name clashes in the C identifiers declared in ``vcc_if.h``. This may necessitate diff --git a/doc/sphinx/whats-new/upgrading-8.0.rst b/doc/sphinx/whats-new/upgrading-8.0.rst index e6a8b72abf..dc45da4af0 100644 --- a/doc/sphinx/whats-new/upgrading-8.0.rst +++ b/doc/sphinx/whats-new/upgrading-8.0.rst @@ -9,7 +9,7 @@ This document only lists breaking changes that you should be aware of when upgrading from Varnish-Cache 7.x to 8.0. For a complete list of changes, please refer to the `change log`_ or :ref:`whatsnew_changes_8.0`. -.. _change log: https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst varnishd ======== From 9efc921b15d2a9bebe6744a2fcde1b72a4444df9 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 18 Feb 2026 20:39:01 +0100 Subject: [PATCH 012/196] Update vtest url --- doc/sphinx/phk/trialerror.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/sphinx/phk/trialerror.rst b/doc/sphinx/phk/trialerror.rst index 7ab50660fa..568876c7a0 100644 --- a/doc/sphinx/phk/trialerror.rst +++ b/doc/sphinx/phk/trialerror.rst @@ -84,7 +84,7 @@ So, taking my friends advice, I sat down and wrote VTEST, which consists of two small pieces of code: Tester and Reporter. The tester is a small, 173 lines, `portable and simple shell script -`_ +`_ which runs on the computer, physical or virtual, where we want to test Varnish. From 53e1092ce90b517b7faf8a72167bb5d9eaa57e35 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 18 Feb 2026 20:40:35 +0100 Subject: [PATCH 013/196] Update remaining links sed -i 's:/github.com/varnishcache/varnish-cache:/code.vinyl-cache.org/vinyl-cache/vinyl-cache:g' $(git grep -l github.com/varnishcache/varnish-cache) --- .github/ISSUE_TEMPLATE.md | 2 +- CONTRIBUTING | 2 +- doc/changes.rst | 720 ++++++++++----------- doc/sphinx/installation/install_source.rst | 2 +- doc/sphinx/reference/vcl_step.rst | 2 +- doc/sphinx/whats-new/relnote-5.0.rst | 4 +- doc/sphinx/whats-new/upgrading-6.0.rst | 2 +- tools/coverity-run | 2 +- tools/vtest.sh | 2 +- 9 files changed, 369 insertions(+), 369 deletions(-) diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md index d5dda4693b..0090c0c568 100644 --- a/.github/ISSUE_TEMPLATE.md +++ b/.github/ISSUE_TEMPLATE.md @@ -1,6 +1,6 @@ varnishtest(1) tests + id ~ ^a --> vinyltest(1) tests id ~ ^a02 --> HTTP2 id ~ ^b --> Basic functionality tests id ~ ^c --> Complex functionality tests diff --git a/bin/vinyltest/tests/b00041.vtc b/bin/vinyltest/tests/b00041.vtc index c06ca67352..8f03e0c050 100644 --- a/bin/vinyltest/tests/b00041.vtc +++ b/bin/vinyltest/tests/b00041.vtc @@ -94,4 +94,4 @@ shell -expect {Tested} \ shell "vinyladm -n ${v1_name} help > /dev/null" -shell {VARNISH_DEFAULT_N="${v1_name}" vinyladm help > /dev/null} +shell {VINYL_DEFAULT_N="${v1_name}" vinyladm help > /dev/null} diff --git a/bin/vinyltest/tests/b00045.vtc b/bin/vinyltest/tests/b00045.vtc index 03129f0168..ad475b8790 100644 --- a/bin/vinyltest/tests/b00045.vtc +++ b/bin/vinyltest/tests/b00045.vtc @@ -18,14 +18,14 @@ shell -err -expect {Error: Could not open pid-file} { vinyld -P /dev/tty -b None -a :0 } -shell -err -expect {Error: Varnishd is already running} { +shell -err -expect {Error: vinyld is already running} { vinyld -P ${v1_name}/vinyld.pid -b None -a :0 } -shell -err -expect {Error: Varnishd is already running} { +shell -err -expect {Error: vinyld is already running} { vinyld -b None -a:0 -n ${tmpdir}/v1 -F } -shell -err -expect {Error: Varnishd is already running} { - VARNISH_DEFAULT_N="${tmpdir}/v1" vinyld -b None -a:0 -F +shell -err -expect {Error: vinyld is already running} { + VINYL_DEFAULT_N="${tmpdir}/v1" vinyld -b None -a:0 -F } diff --git a/bin/vinyltest/tests/u00003.vtc b/bin/vinyltest/tests/u00003.vtc index 8b96018e1f..c87663c9b4 100644 --- a/bin/vinyltest/tests/u00003.vtc +++ b/bin/vinyltest/tests/u00003.vtc @@ -118,10 +118,10 @@ shell -err -match "Usage: .*vinylncsa " \ shell -match {^${localhost} 100 ${localhost} 0$} \ {vinylncsa -n ${v1_name} -b -d -F "%{Host}i %b"} -# -b with VARNISH_DEFAULT_N +# -b with VINYL_DEFAULT_N shell -match {^${localhost} 100 ${localhost} 0$} \ - {VARNISH_DEFAULT_N="${v1_name}" vinylncsa -b -d -F "%{Host}i %b"} + {VINYL_DEFAULT_N="${v1_name}" vinylncsa -b -d -F "%{Host}i %b"} # -c shell -match {^${localhost} 100 ${localhost} \d+ diff --git a/bin/vinyltest/tests/u00004.vtc b/bin/vinyltest/tests/u00004.vtc index 4c026864ba..0ca0eeb04e 100644 --- a/bin/vinyltest/tests/u00004.vtc +++ b/bin/vinyltest/tests/u00004.vtc @@ -13,7 +13,7 @@ client c1 { } -run shell -expect "fetch" "vinyltop -n ${v1_name} -1" -shell -expect "fetch" {VARNISH_DEFAULT_N="${v1_name}" vinyltop -1} +shell -expect "fetch" {VINYL_DEFAULT_N="${v1_name}" vinyltop -1} process p1 "vinyltop -n ${v1_name} -d" -start delay 1 diff --git a/bin/vinyltest/tests/u00005.vtc b/bin/vinyltest/tests/u00005.vtc index 701cc35595..45513fb862 100644 --- a/bin/vinyltest/tests/u00005.vtc +++ b/bin/vinyltest/tests/u00005.vtc @@ -37,7 +37,7 @@ shell -match "^MGT" \ shell -match "Usage: .*vinylstat " \ "vinylstat -h" -shell -expect "Varnishstat -f option fields:" \ +shell -expect "Vinylstat -f option fields:" \ "vinylstat -n ${v1_name} -l" shell -expect "Copyright (c) 2006 Verdens Gang AS" \ "vinylstat -V" @@ -52,11 +52,11 @@ shell -err -expect "-t: Invalid argument: foo" \ shell -err -expect "Could not get hold of vinyld" \ "vinylstat -n /nonexistent -t 1" shell -err -expect "Could not get hold of vinyld" \ - {VARNISH_DEFAULT_N="/nonexistent" vinylstat -t 1} + {VINYL_DEFAULT_N="/nonexistent" vinylstat -t 1} shell -expect "MAIN.uptime" \ "vinylstat -n ${v1_name} -1" shell -expect "MAIN.uptime" \ - {VARNISH_DEFAULT_N="${v1_name}" vinylstat -1} + {VINYL_DEFAULT_N="${v1_name}" vinylstat -1} shell -expect "MAIN.uptime" \ "vinylstat -n ${v1_name} -x" shell -match {"MAIN.uptime":} \ diff --git a/bin/vinyltest/tests/u00006.vtc b/bin/vinyltest/tests/u00006.vtc index d55816ca0f..54bb00a896 100644 --- a/bin/vinyltest/tests/u00006.vtc +++ b/bin/vinyltest/tests/u00006.vtc @@ -132,7 +132,7 @@ shell -match "0 CLI[ ]+- Wr 200 [0-9]+ PONG" \ {vinyllog -n ${v1_name} -d -g raw -X "Wr 200 [0-9]+ [^P]"} shell -match "0 CLI[ ]+- Wr 200 [0-9]+ PONG" \ - {VARNISH_DEFAULT_N="${v1_name}" vinyllog -d -g raw -X "Wr 200 [0-9]+ [^P]"} + {VINYL_DEFAULT_N="${v1_name}" vinyllog -d -g raw -X "Wr 200 [0-9]+ [^P]"} client c1 { txreq -url /foo diff --git a/bin/vinyltest/tests/u00009.vtc b/bin/vinyltest/tests/u00009.vtc index 14c4458e7d..7a825f9779 100644 --- a/bin/vinyltest/tests/u00009.vtc +++ b/bin/vinyltest/tests/u00009.vtc @@ -9,7 +9,7 @@ vinyl v1 -vcl+backend {} -start process p1 -dump {vinylhist -n ${v1_name}} -start process p2 -dump {vinylhist -n ${v1_name} -P b:BereqAcct::5:-1:1} -start -process p3 -dump {VARNISH_DEFAULT_N="${v1_name}" vinylhist -P BerespBodytime -B 2} -start +process p3 -dump {VINYL_DEFAULT_N="${v1_name}" vinylhist -P BerespBodytime -B 2} -start process p1 -expect-text 24 0 {1e2} process p2 -expect-text 24 0 {1e-1} diff --git a/bin/vinyltest/vtc_vinyl.c b/bin/vinyltest/vtc_vinyl.c index 2031b99409..9cc67fc439 100644 --- a/bin/vinyltest/vtc_vinyl.c +++ b/bin/vinyltest/vtc_vinyl.c @@ -57,7 +57,7 @@ struct vinyl { unsigned magic; -#define VARNISH_MAGIC 0x208cd8e3 +#define VINYL_MAGIC 0x208cd8e4 char *me; char *name; struct vtclog *vl; @@ -232,7 +232,7 @@ wait_running(const struct vinyl *v) } /********************************************************************** - * Varnishlog gatherer thread + * Vinyllog gatherer thread */ static void * @@ -249,7 +249,7 @@ vinyllog_thread(void *priv) int type, i, opt; struct vsb *vsb = NULL; - CAST_OBJ_NOTNULL(v, priv, VARNISH_MAGIC); + CAST_OBJ_NOTNULL(v, priv, VINYL_MAGIC); vsl = VSL_New(); AN(vsl); @@ -347,7 +347,7 @@ vinyl_new(const char *name) struct vsb *vsb; char buf[1024]; - ALLOC_OBJ(v, VARNISH_MAGIC); + ALLOC_OBJ(v, VINYL_MAGIC); AN(v); REPLACE(v->name, name); @@ -381,7 +381,7 @@ static void vinyl_delete(struct vinyl *v) { - CHECK_OBJ_NOTNULL(v, VARNISH_MAGIC); + CHECK_OBJ_NOTNULL(v, VINYL_MAGIC); vtc_logclose(v->vl); free(v->name); free(v->jail); @@ -406,7 +406,7 @@ vinyl_delete(struct vinyl *v) } /********************************************************************** - * Varnish listener + * Vinyl listener */ static void * @@ -414,12 +414,12 @@ vinyl_thread(void *priv) { struct vinyl *v; - CAST_OBJ_NOTNULL(v, priv, VARNISH_MAGIC); + CAST_OBJ_NOTNULL(v, priv, VINYL_MAGIC); return (vtc_record(v->vl, v->fds[0], NULL)); } /********************************************************************** - * Launch a Varnish + * Launch a Vinyl */ static void @@ -584,9 +584,9 @@ vinyl_launch(struct vinyl *v) PTOK(pthread_create(&v->tp_vsl, NULL, vinyllog_thread, v)); } -#define VARNISH_LAUNCH(v) \ +#define VINYL_LAUNCH(v) \ do { \ - CHECK_OBJ_NOTNULL(v, VARNISH_MAGIC); \ + CHECK_OBJ_NOTNULL(v, VINYL_MAGIC); \ if (v->cli_fd < 0) \ vinyl_launch(v); \ if (vtc_error) \ @@ -594,7 +594,7 @@ vinyl_launch(struct vinyl *v) } while (0) /********************************************************************** - * Start a Varnish + * Start a Vinyl */ static void @@ -663,7 +663,7 @@ vinyl_start(struct vinyl *v) enum VCLI_status_e u; char *resp = NULL; - VARNISH_LAUNCH(v); + VINYL_LAUNCH(v); vtc_log(v->vl, 2, "Start"); u = vinyl_ask_cli(v, "start", &resp); if (vtc_error) @@ -695,14 +695,14 @@ vinyl_start(struct vinyl *v) } /********************************************************************** - * Stop a Varnish + * Stop a Vinyl */ static void vinyl_stop(struct vinyl *v) { - VARNISH_LAUNCH(v); + VINYL_LAUNCH(v); vtc_log(v->vl, 2, "Stop"); (void)vinyl_ask_cli(v, "stop", NULL); wait_stopped(v); @@ -737,7 +737,7 @@ vinyl_cleanup(struct vinyl *v) } /********************************************************************** - * Wait for a Varnish + * Wait for a Vinyl */ static void @@ -775,7 +775,7 @@ vinyl_cli_json(struct vinyl *v, const char *cli) const char *errptr; struct vjsn *vj; - VARNISH_LAUNCH(v); + VINYL_LAUNCH(v); u = vinyl_ask_cli(v, cli, &resp); vtc_log(v->vl, 2, "CLI %03u <%s>", u, cli); if (u != CLIS_OK) @@ -802,7 +802,7 @@ vinyl_cli(struct vinyl *v, const char *cli, unsigned exp, const char *re, char *resp = NULL, errbuf[VRE_ERROR_LEN]; int err, erroff; - VARNISH_LAUNCH(v); + VINYL_LAUNCH(v); if (re != NULL) { vre = VRE_compile(re, 0, &err, &erroff, 1); if (vre == NULL) { @@ -847,7 +847,7 @@ vinyl_vcl(struct vinyl *v, const char *vcl, int fail, char **resp) struct vsb *vsb; enum VCLI_status_e u; - VARNISH_LAUNCH(v); + VINYL_LAUNCH(v); vsb = VSB_new_auto(); AN(vsb); @@ -883,7 +883,7 @@ vinyl_vclbackend(struct vinyl *v, const char *vcl) struct vsb *vsb, *vsb2; enum VCLI_status_e u; - VARNISH_LAUNCH(v); + VINYL_LAUNCH(v); vsb = VSB_new_auto(); AN(vsb); @@ -953,7 +953,7 @@ vinyl_vsc(struct vinyl *v, const char *arg) { struct dump_priv dp; - VARNISH_LAUNCH(v); + VINYL_LAUNCH(v); memset(&dp, 0, sizeof dp); dp.v = v; dp.arg = arg; @@ -1027,7 +1027,7 @@ vinyl_expect(struct vinyl *v, char * const *av) uintmax_t u; char *l, *p; - VARNISH_LAUNCH(v); + VINYL_LAUNCH(v); ZERO_OBJ(&sp, sizeof sp); l = av[0]; not = (*l == '!'); @@ -1096,7 +1096,7 @@ vsl_catchup(struct vinyl *v) { int vsl_idle; - VARNISH_LAUNCH(v); + VINYL_LAUNCH(v); vsl_idle = v->vsl_idle; while (!vtc_error && vsl_idle == v->vsl_idle) VTIM_sleep(0.1); @@ -1106,7 +1106,7 @@ vsl_catchup(struct vinyl *v) * * Define and interact with vinyl instances. * - * To define a Varnish server, you'll use this syntax:: + * To define a ``vinyld``, you'll use this syntax:: * * vinyl vNAME [-arg STRING] [-vcl STRING] [-vcl+backend STRING] * [-errvcl STRING STRING] [-jail STRING] [-proto PROXY] @@ -1124,7 +1124,7 @@ vsl_catchup(struct vinyl *v) * Arguments: * * vNAME - * Identify the Varnish server with a string, it must starts with 'v'. + * Identify the ``vinyld`` server with a string, it must starts with 'v'. * * \-arg STRING * Pass an argument to vinyld, for example "-h simple_list". @@ -1137,7 +1137,7 @@ vsl_catchup(struct vinyl *v) * using the ``-D`` option for vinyltest. * * \-vcl STRING - * Specify the VCL to load on this Varnish instance. You'll probably + * Specify the VCL to load on this ``vinyld`` instance. You'll probably * want to use multi-lines strings for this ({...}). * * \-vcl+backend STRING @@ -1145,17 +1145,17 @@ vsl_catchup(struct vinyl *v) * known backends (ie. already defined). * * \-errvcl STRING1 STRING2 - * Load STRING2 as VCL, expecting it to fail, and Varnish to send an + * Load STRING2 as VCL, expecting it to fail, and ``vinyld`` to send an * error string matching STRING1 * * \-jail STRING * Look at ``man vinyld`` (-j) for more information. * * \-proto PROXY - * Have Varnish use the proxy protocol. Note that PROXY here is the + * Have ``vinyld`` use the proxy protocol. Note that PROXY here is the * actual string. * - * You can decide to start the Varnish instance and/or wait for several events:: + * You can decide to start the ``vinyld`` instance and/or wait for several events:: * * vinyl vNAME [-start] [-wait] [-wait-running] [-wait-stopped] * @@ -1178,19 +1178,19 @@ vsl_catchup(struct vinyl *v) * Wait for that instance to terminate. * * \-wait-running - * Wait for the Varnish child process to be started. + * Wait for the ``vinyld`` child process to be started. * * \-wait-stopped - * Wait for the Varnish child process to stop. + * Wait for the ``vinyld`` child process to stop. * * \-cleanup - * Once Varnish is stopped, clean everything after it. This is only used + * Once ``vinyld`` is stopped, clean everything after it. This is only used * in very few tests and you should never need it. * * \-expectexit NUMBER * Expect vinyld to exit(3) with this value * - * Once Varnish is started, you can talk to it (as you would through + * Once ``vinyld`` is started, you can talk to it (as you would through * ``vinyladm``) with these additional switches:: * * vinyl vNAME [-cli STRING] [-cliok STRING] [-clierr STRING] @@ -1418,14 +1418,4 @@ cmd_vinyl(CMD_ARGS) } } -#ifdef VTEST_WITH_VTC_VARNISH - -void -cmd_varnish(CMD_ARGS) -{ - cmd_vinyl(av, priv, vl); -} - -#endif - #endif /* VTEST_WITH_VTC_VINYL */ diff --git a/lib/libvinyl/vin.c b/lib/libvinyl/vin.c index 691a87831c..e9ff307904 100644 --- a/lib/libvinyl/vin.c +++ b/lib/libvinyl/vin.c @@ -72,11 +72,11 @@ VIN_n_Arg(const char *n_arg) void VIN_DumpDefaults(void) { - printf(" The default is taken from the ``VARNISH_DEFAULT_N`` " + printf(" The default is taken from the ``VINYL_DEFAULT_N`` " "environment variable.\n\n"); printf(" Relative paths will be appended to ``%s``.\n\n", VARNISH_STATE_DIR); - printf(" If neither ``VARNISH_DEFAULT_N`` nor ``-n`` are " + printf(" If neither ``VINYL_DEFAULT_N`` nor ``-n`` are " "present, the value is ``%s``.\n\n", VARNISH_STATE_DIR "/" VARNISH_DEFAULT_REL_NAME); printf(" Note: These defaults may be distribution specific.\n\n"); diff --git a/lib/libvinylapi/vsm.c b/lib/libvinylapi/vsm.c index 721d3a5546..72458ea072 100644 --- a/lib/libvinylapi/vsm.c +++ b/lib/libvinylapi/vsm.c @@ -795,7 +795,7 @@ VSM_Attach(struct vsm *vd, int progress) t0 = VTIM_mono() + vd->patience; if (vd->wdname == NULL) { - def = getenv("VARNISH_DEFAULT_N"); + def = getenv("VINYL_DEFAULT_N"); if (def == NULL) def = ""; /* Use default (hostname) */ i = VSM_Arg(vd, 'n', def); diff --git a/lib/libvsc/VSC_main.vsc b/lib/libvsc/VSC_main.vsc index f1231edfc6..36e54e49d7 100644 --- a/lib/libvsc/VSC_main.vsc +++ b/lib/libvsc/VSC_main.vsc @@ -127,19 +127,19 @@ :group: wrk :oneliner: Cache hits for pass. - Count of hits for pass. A cache hit for pass indicates that Varnish - is going to pass the request to the backend and this decision has - been cached in it self. This counts how many times the cached - decision is being used. + Count of hits for pass. A cache hit for pass indicates that + Vinyl Cache is going to pass the request to the backend and + this decision has been cached in it self. This counts how + many times the cached decision is being used. .. vinyl_vsc:: cache_hitmiss :group: wrk :oneliner: Cache hits for miss. - Count of hits for miss. A cache hit for miss indicates that Varnish - is going to proceed as for a cache miss without request coalescing, - and this decision has been cached. This counts how many times the - cached decision is being used. + Count of hits for miss. A cache hit for miss indicates that + Vinyl Cache is going to proceed as for a cache miss without + request coalescing, and this decision has been cached. This + counts how many times the cached decision is being used. .. vinyl_vsc:: cache_miss :group: wrk @@ -1003,9 +1003,9 @@ .. vinyl_vsc:: n_test_gunzip :oneliner: Test gunzip operations - Those operations occur when Varnish receives a compressed object - from a backend. They are done to verify the gzip stream while it's - inserted in storage. + Those operations occur when Vinyl Cache receives a compressed + object from a backend. They are done to verify the gzip + stream while it's inserted in storage. .. vinyl_vsc:: http1_iovs_flush diff --git a/man/Makefile.am b/man/Makefile.am index 411eb875f3..567d3e851b 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -1,8 +1,8 @@ # dist_man_MANS = \ - varnish-cli.7 \ - varnish-counters.7 \ + vinyl-cli.7 \ + vinyl-counters.7 \ vcl.7 \ vcl-backend.7 \ vcl-probe.7 \ @@ -16,7 +16,7 @@ dist_man_MANS = \ vinyllog.1 \ vinylncsa.1 \ vinylstat.1 \ - varnishtest.1 \ + vinyltest.1 \ vtc.7 \ vinyltop.1 \ vmod_cookie.3 \ @@ -41,11 +41,11 @@ BUILD_MAN = $(AM_V_GEN) $(RST2MAN) $(RST2ANY_FLAGS) # to $(srcdir) are created for sphinx builds that don't support # VPATH. -varnish-cli.7: $(top_builddir)/doc/sphinx/reference/varnish-cli.rst \ +vinyl-cli.7: $(top_builddir)/doc/sphinx/reference/varnish-cli.rst \ $(top_builddir)/doc/sphinx/include/cli.rst $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnish-cli.rst $@ -varnish-counters.7: $(top_builddir)/doc/sphinx/reference/varnish-counters.rst \ +vinyl-counters.7: $(top_builddir)/doc/sphinx/reference/varnish-counters.rst \ $(top_builddir)/doc/sphinx/include/counters.rst $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnish-counters.rst $@ @@ -101,7 +101,7 @@ vinylstat.1: $(top_builddir)/doc/sphinx/reference/varnishstat.rst \ $(top_builddir)/doc/sphinx/include/vinylstat_bindings.rst $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnishstat.rst $@ -varnishtest.1: $(top_builddir)/doc/sphinx/reference/varnishtest.rst +vinyltest.1: $(top_builddir)/doc/sphinx/reference/varnishtest.rst $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnishtest.rst $@ vtc.7: $(top_builddir)/doc/sphinx/reference/vtc.rst \ From 10de3fc2d37b69357773256d4598877b82df51d1 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 10:55:37 +0000 Subject: [PATCH 094/196] s/varnish/vinyl/ on vinylncsa -F arguments --- bin/vinylncsa/vinylncsa.c | 14 +++++++------- bin/vinyltest/tests/e00003.vtc | 8 ++++---- bin/vinyltest/tests/u00002.vtc | 2 +- bin/vinyltest/tests/u00003.vtc | 8 ++++---- 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/bin/vinylncsa/vinylncsa.c b/bin/vinylncsa/vinylncsa.c index abc6ba0228..8cd17ae187 100644 --- a/bin/vinylncsa/vinylncsa.c +++ b/bin/vinylncsa/vinylncsa.c @@ -86,7 +86,7 @@ enum e_frag { F_O, /* %O Bytes sent */ F_tstart, /* Time start */ F_tend, /* Time end */ - F_ttfb, /* %{Varnish:time_firstbyte}x */ + F_ttfb, /* %{Vinyl:time_firstbyte}x */ F_host, /* Host header */ F_auth, /* Authorization header */ F__MAX, @@ -674,23 +674,23 @@ parse_x_format(char *buf) long lval; int slt; - if (!strcmp(buf, "Varnish:time_firstbyte")) { + if (!strcmp(buf, "Vinyl:time_firstbyte")) { addf_fragment(&CTX.frag[F_ttfb], CTX.missing_int); return; } - if (!strcmp(buf, "Varnish:hitmiss")) { + if (!strcmp(buf, "Vinyl:hitmiss")) { addf_strptr(&CTX.hitmiss); return; } - if (!strcmp(buf, "Varnish:handling")) { + if (!strcmp(buf, "Vinyl:handling")) { addf_strptr(&CTX.handling); return; } - if (!strcmp(buf, "Varnish:side")) { + if (!strcmp(buf, "Vinyl:side")) { addf_strptr(&CTX.side); return; } - if (!strcmp(buf, "Varnish:vxid")) { + if (!strcmp(buf, "Vinyl:vxid")) { addf_int64(&CTX.vxid); return; } @@ -743,7 +743,7 @@ parse_x_format(char *buf) addf_vsl((enum VSL_tag_e)slt, lval, r); return; } - if (!strcmp(buf, "Varnish:default_format")) { + if (!strcmp(buf, "Vinyl:default_format")) { parse_format(FORMAT); return; } diff --git a/bin/vinyltest/tests/e00003.vtc b/bin/vinyltest/tests/e00003.vtc index 7fb8873efc..cc95919e22 100644 --- a/bin/vinyltest/tests/e00003.vtc +++ b/bin/vinyltest/tests/e00003.vtc @@ -106,7 +106,7 @@ logexpect l5 -wait shell { vinylncsa -n ${v1_name} -d \ - -F '%{Varnish:vxid}x %{Varnish:side}x %{VSL:Begin[3]}x' | + -F '%{Vinyl:vxid}x %{Vinyl:side}x %{VSL:Begin[3]}x' | sort > ncsa.txt cat >expected.txt <<-EOF @@ -118,7 +118,7 @@ shell { shell { vinylncsa -n ${v1_name} -d -b \ - -F '%{Varnish:vxid}x %{Varnish:side}x %{VSL:Begin[3]}x' | + -F '%{Vinyl:vxid}x %{Vinyl:side}x %{VSL:Begin[3]}x' | sort > ncsa.txt cat >expected.txt <<-EOF @@ -130,7 +130,7 @@ shell { shell { vinylncsa -n ${v1_name} -d -E \ - -F '%{Varnish:vxid}x %{Varnish:side}x %{VSL:Begin[3]}x' | + -F '%{Vinyl:vxid}x %{Vinyl:side}x %{VSL:Begin[3]}x' | sort > ncsa.txt cat >expected.txt <<-EOF @@ -146,7 +146,7 @@ shell { shell { vinylncsa -n ${v1_name} -d -b -E \ - -F '%{Varnish:vxid}x %{Varnish:side}x %{VSL:Begin[3]}x' | + -F '%{Vinyl:vxid}x %{Vinyl:side}x %{VSL:Begin[3]}x' | sort > ncsa.txt cat >expected.txt <<-EOF diff --git a/bin/vinyltest/tests/u00002.vtc b/bin/vinyltest/tests/u00002.vtc index 9940f09c39..9549d06200 100644 --- a/bin/vinyltest/tests/u00002.vtc +++ b/bin/vinyltest/tests/u00002.vtc @@ -99,6 +99,6 @@ hit /hit pass /pass synth /synth EOF - vinylncsa -d -n ${v1_name} -F "%{Varnish:handling}x %U" >have + vinylncsa -d -n ${v1_name} -F "%{Vinyl:handling}x %U" >have diff -u expect have } diff --git a/bin/vinyltest/tests/u00003.vtc b/bin/vinyltest/tests/u00003.vtc index c87663c9b4..5a6cd8e895 100644 --- a/bin/vinyltest/tests/u00003.vtc +++ b/bin/vinyltest/tests/u00003.vtc @@ -143,9 +143,9 @@ shell -match {^100 \d+ HTTP/1.1 (?:\d+.\d+.\d+.\d+|[a-f0-9:]+) \d+ - - GET 0 \d+ shell -match {^\d+.\d{6} miss miss c 1001 quuz \d+.\d{6} miss synth c 1003\s \d+.\d{6} miss pipe c 1005\s$} \ - {vinylncsa -n ${v1_name} -d -F "%{Varnish:time_firstbyte}x \ -%{Varnish:hitmiss}x %{Varnish:handling}x %{Varnish:side}x \ -%{Varnish:vxid}x %{VCL_Log:quux}x"} + {vinylncsa -n ${v1_name} -d -F "%{Vinyl:time_firstbyte}x \ +%{Vinyl:hitmiss}x %{Vinyl:handling}x %{Vinyl:side}x \ +%{Vinyl:vxid}x %{VCL_Log:quux}x"} # %{VSL:..}x shell -match {^req (\d+) rxreq \1 \d{10}\.\d{6} (\d+\.\d{6}) \d+\.\d{6} \2 - - @@ -192,7 +192,7 @@ shell { vinylncsa -n ${v1_name} -d -k 1 -F "%{User-Agent}i" ) >def_then_ua.txt vinylncsa -n ${v1_name} -d -k 1 >def_with_ua.txt \ - -F "%{Varnish:default_format}x\n%{User-Agent}i" + -F "%{Vinyl:default_format}x\n%{User-Agent}i" diff -u def_then_ua.txt def_with_ua.txt } From cece540573b3c4c500cc270db962e96f27b053ef Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 11:16:56 +0000 Subject: [PATCH 095/196] Rename varnish.m4 to vinyl.m4 (unchanged contents) --- varnish.m4 => vinyl.m4 | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename varnish.m4 => vinyl.m4 (100%) diff --git a/varnish.m4 b/vinyl.m4 similarity index 100% rename from varnish.m4 rename to vinyl.m4 From 8914353e37097641312041c852c81ab0eb82095a Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 13:38:55 +0000 Subject: [PATCH 096/196] s/VARNISH/VINYL/ in a lot of macros (C and autocrap) --- bin/vinyld/Makefile.am | 6 +- bin/vinyld/flint.sh | 6 +- bin/vinyld/mgt/mgt_jail_unix.c | 10 +- bin/vinyllog/flint.sh | 2 +- configure.ac | 18 +- doc/changes.rst | 6 +- doc/sphinx/installation/platformnotes.rst | 2 +- doc/sphinx/reference/vmod.rst | 4 +- doc/sphinx/whats-new/changes-6.0.rst | 2 +- doc/sphinx/whats-new/changes-6.5.rst | 2 +- doc/sphinx/whats-new/changes-7.6.rst | 2 +- doc/sphinx/whats-new/changes-7.7.rst | 2 +- include/tbl/params.h | 4 +- include/vqueue.h | 6 +- lib/libvinyl/Makefile.am | 2 +- lib/libvinyl/flint.lnt | 2 +- lib/libvinyl/vin.c | 12 +- lib/libvinylapi/Makefile.am | 4 +- lib/libvinylapi/libvinylapi.map | 4 +- varnish-legacy.m4 | 26 +-- vinyl.m4 | 198 +++++++++++----------- 21 files changed, 160 insertions(+), 160 deletions(-) diff --git a/bin/vinyld/Makefile.am b/bin/vinyld/Makefile.am index 99dbe617de..fa2baee9de 100644 --- a/bin/vinyld/Makefile.am +++ b/bin/vinyld/Makefile.am @@ -180,9 +180,9 @@ vcldir=$(datarootdir)/$(PACKAGE)/vcl vinyld_CFLAGS = \ -DNOT_IN_A_VMOD \ - -DVARNISH_STATE_DIR='"${VARNISH_STATE_DIR}"' \ - -DVARNISH_VMOD_DIR='"${vmoddir}"' \ - -DVARNISH_VCL_DIR='"${pkgsysconfdir}:${vcldir}"' + -DVINYL_STATE_DIR='"${VINYL_STATE_DIR}"' \ + -DVINYL_VMOD_DIR='"${vmoddir}"' \ + -DVINYL_VCL_DIR='"${pkgsysconfdir}:${vcldir}"' vinyld_LDFLAGS = -export-dynamic diff --git a/bin/vinyld/flint.sh b/bin/vinyld/flint.sh index f7c45e3f34..9b594b6471 100644 --- a/bin/vinyld/flint.sh +++ b/bin/vinyld/flint.sh @@ -8,9 +8,9 @@ FLOPS=' -I../../lib/libvgz -I../../lib/libvsc -DNOT_IN_A_VMOD - -DVARNISH_STATE_DIR="foo" - -DVARNISH_VMOD_DIR="foo" - -DVARNISH_VCL_DIR="foo" + -DVINYL_STATE_DIR="foo" + -DVINYL_VMOD_DIR="foo" + -DVINYL_VCL_DIR="foo" -DWITH_PERSISTENT_STORAGE acceptor/*.c cache/*.c diff --git a/bin/vinyld/mgt/mgt_jail_unix.c b/bin/vinyld/mgt/mgt_jail_unix.c index 01c6f5e020..a9b32dc686 100644 --- a/bin/vinyld/mgt/mgt_jail_unix.c +++ b/bin/vinyld/mgt/mgt_jail_unix.c @@ -56,8 +56,8 @@ static const char *vju_wrkuser; static gid_t vju_cc_gid; static int vju_cc_gid_set; -#ifndef VARNISH_USER -#define VARNISH_USER "varnish" +#ifndef VINYL_USER +#define VINYL_USER "varnish" #endif #ifndef VCACHE_USER @@ -130,7 +130,7 @@ vju_init(char **args) /* Autoconfig */ if (geteuid() != 0) return (1); - if (vju_getuid(VARNISH_USER)) + if (vju_getuid(VINYL_USER)) return (1); } else { @@ -160,8 +160,8 @@ vju_init(char **args) *args); } - if (vju_user == NULL && vju_getuid(VARNISH_USER)) - JERR("user", VARNISH_USER); + if (vju_user == NULL && vju_getuid(VINYL_USER)) + JERR("user", VINYL_USER); } AN(vju_user); diff --git a/bin/vinyllog/flint.sh b/bin/vinyllog/flint.sh index 3c6c9ef691..306c748f67 100644 --- a/bin/vinyllog/flint.sh +++ b/bin/vinyllog/flint.sh @@ -5,7 +5,7 @@ # See LICENSE file for full text of license FLOPS=' - -DVARNISH_STATE_DIR=\"foo\" + -DVINYL_STATE_DIR=\"foo\" *.c ../../lib/libvinylapi/flint.lnt ../../lib/libvinylapi/*.c diff --git a/configure.ac b/configure.ac index 10da83fce3..fef8c7410b 100644 --- a/configure.ac +++ b/configure.ac @@ -89,16 +89,16 @@ AM_MISSING_PROG([DOT], [dot]) AC_CHECK_PROGS([DOT], [dot]) # Define VMOD flags -_VARNISH_VMOD_LDFLAGS +_VINYL_VMOD_LDFLAGS # Check for python. -_VARNISH_CHECK_PYTHON +_VINYL_CHECK_PYTHON # Check for libraries. -_VARNISH_SEARCH_LIBS(pthread, pthread_create, [thr pthread c_r]) -_VARNISH_CHECK_LIB(dl, dlopen) -_VARNISH_CHECK_LIB(socket, socket) -_VARNISH_CHECK_LIB(nsl, getaddrinfo) +_VINYL_SEARCH_LIBS(pthread, pthread_create, [thr pthread c_r]) +_VINYL_CHECK_LIB(dl, dlopen) +_VINYL_CHECK_LIB(socket, socket) +_VINYL_CHECK_LIB(nsl, getaddrinfo) AC_SUBST(NET_LIBS, "${SOCKET_LIBS} ${NSL_LIBS}") @@ -641,11 +641,11 @@ fi # Run-time directory if test "${localstatedir}" = '${prefix}/var' ; then - VARNISH_STATE_DIR='/var/run' + VINYL_STATE_DIR='/var/run' else - VARNISH_STATE_DIR='${localstatedir}/varnish' + VINYL_STATE_DIR='${localstatedir}/varnish' fi -AC_SUBST(VARNISH_STATE_DIR) +AC_SUBST(VINYL_STATE_DIR) # Default configuration directory. pkgsysconfdir='${sysconfdir}/varnish' diff --git a/doc/changes.rst b/doc/changes.rst index 97c480653d..b2bb30544c 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -332,7 +332,7 @@ Varnish-Cache 7.7 (2025-03-17) * Pressing the ``0`` key in ``varnishstat`` interactive (curses) mode now resets averages. -* ``varnishtest`` has been changed to always set a ``VARNISH_DEFAULT_N`` +* ``varnishtest`` has been changed to always set a ``VINYL_DEFAULT_N`` environment variable to ensure that ``varnish`` invoked from ``varnishtest`` always has a valid workdir. @@ -694,7 +694,7 @@ Varnish Cache 7.6.0 (2024-09-13) VMODs for temporary files. The `VMOD developer documentation`_ has details. -* The environment variable ``VARNISH_DEFAULT_N`` now provides the +* The environment variable ``VINYL_DEFAULT_N`` now provides the default "varnish name" / "workdir" as otherwise specified by he ``-n`` argument to ``varnishd`` and ``varnish*`` utilities except ``varnishtest``. @@ -2385,7 +2385,7 @@ Varnish Cache 6.5.0 (2020-09-15) * Fixed the backend probe ``.timeout`` handling for "dripping" responses (3402_) -* New ``VARNISH_VMODS_GENERATED()`` macro in ``varnish.m4``. +* New ``VINYL_VMODS_GENERATED()`` macro in ``varnish.m4``. * Prevent pooling of a ``Connection: close`` backend response. diff --git a/doc/sphinx/installation/platformnotes.rst b/doc/sphinx/installation/platformnotes.rst index 3c645befcf..f103d44efa 100644 --- a/doc/sphinx/installation/platformnotes.rst +++ b/doc/sphinx/installation/platformnotes.rst @@ -23,7 +23,7 @@ as the *workdir*. To ensure ``tmpfs`` is used, check the following: Determine the *workdir*. If you use a specific ``-n`` option to ``varnishd`` or -set the ``VARNISH_DEFAULT_N`` variable, it is that value. Otherwise run +set the ``VINYL_DEFAULT_N`` variable, it is that value. Otherwise run ``varnishd -x options``, which outputs the *workdir* default. Run ``df *workdir*``. If it reports ``tmpfs`` as the file system in the first diff --git a/doc/sphinx/reference/vmod.rst b/doc/sphinx/reference/vmod.rst index 774eee484e..f7567509f5 100644 --- a/doc/sphinx/reference/vmod.rst +++ b/doc/sphinx/reference/vmod.rst @@ -867,10 +867,10 @@ Statistics Counters Starting in Varnish 6.0, VMODs can define their own counters that appear in *varnishstat*. -If you're using autotools, see the ``VARNISH_COUNTERS`` macro in +If you're using autotools, see the ``VINYL_COUNTERS`` macro in varnish.m4 for documentation on getting your build set up. -Counters are defined in a .vsc file. The ``VARNISH_COUNTERS`` macro +Counters are defined in a .vsc file. The ``VINYL_COUNTERS`` macro calls *vsctool.py* to turn a *foo.vsc* file into *VSC_foo.c* and *VSC_foo.h* files, just like *vmodtool.py* turns *foo.vcc* into *vcc_foo_if.c* and *vcc_foo_if.h* files. Similarly to the VCC files, the diff --git a/doc/sphinx/whats-new/changes-6.0.rst b/doc/sphinx/whats-new/changes-6.0.rst index ab147944b1..9eaa4145cc 100644 --- a/doc/sphinx/whats-new/changes-6.0.rst +++ b/doc/sphinx/whats-new/changes-6.0.rst @@ -74,7 +74,7 @@ The counters are described in a ``.vsc`` file which is processed with a new python script which does a lot of magic etc. There is a tiny example in ``vmod_debug`` in the source tree. If you're using autotools, a new -``VARNISH_COUNTERS`` macro helps you set everything up, +``VINYL_COUNTERS`` macro helps you set everything up, and is documented in ``varnish.m4``. This took a major retooling of the stats counters in general, and diff --git a/doc/sphinx/whats-new/changes-6.5.rst b/doc/sphinx/whats-new/changes-6.5.rst index 025ea8a478..56d78ad4ef 100644 --- a/doc/sphinx/whats-new/changes-6.5.rst +++ b/doc/sphinx/whats-new/changes-6.5.rst @@ -169,7 +169,7 @@ Build System ~~~~~~~~~~~~ VMOD authors who would like to generate VCC files can now use the -``VARNISH_VMODS_GENERATED()`` macro from ``varnish.m4`` for autotools +``VINYL_VMODS_GENERATED()`` macro from ``varnish.m4`` for autotools builds. .. _whatsnew_changes_6.5_workspace: diff --git a/doc/sphinx/whats-new/changes-7.6.rst b/doc/sphinx/whats-new/changes-7.6.rst index d81880ca3d..54b44ac8c1 100644 --- a/doc/sphinx/whats-new/changes-7.6.rst +++ b/doc/sphinx/whats-new/changes-7.6.rst @@ -16,7 +16,7 @@ merged, may be found in the `change log`_. Changes applying to most varnish-cache programs =============================================== -The environment variable ``VARNISH_DEFAULT_N`` now provides the default "varnish +The environment variable ``VINYL_DEFAULT_N`` now provides the default "varnish name" / "workdir" as otherwise specified by he ``-n`` argument to ``varnishd`` and ``varnish*`` utilities except ``varnishtest``. diff --git a/doc/sphinx/whats-new/changes-7.7.rst b/doc/sphinx/whats-new/changes-7.7.rst index 332b7fea7d..d578ceff71 100644 --- a/doc/sphinx/whats-new/changes-7.7.rst +++ b/doc/sphinx/whats-new/changes-7.7.rst @@ -202,7 +202,7 @@ varnishtest ``varnishtest`` can now send arbitrary http/2 settings frames and arbitrary PROXY2 tlvs. -``varnishtest`` has been changed to always set a ``VARNISH_DEFAULT_N`` +``varnishtest`` has been changed to always set a ``VINYL_DEFAULT_N`` environment variable to ensure that ``varnish`` invoked from ``varnishtest`` always has a valid workdir. diff --git a/include/tbl/params.h b/include/tbl/params.h index 6668de8646..f293795888 100644 --- a/include/tbl/params.h +++ b/include/tbl/params.h @@ -1846,7 +1846,7 @@ PARAM_STRING( /* name */ vcl_path, /* tweak */ tweak_string, /* priv */ &mgt_vcl_path, - /* def */ VARNISH_VCL_DIR, + /* def */ VINYL_VCL_DIR, /* descr */ "Directory (or colon separated list of directories) " "from which relative VCL filenames (vcl.load and " @@ -1866,7 +1866,7 @@ PARAM_STRING( /* name */ vmod_path, /* tweak */ tweak_string, /* priv */ &mgt_vmod_path, - /* def */ VARNISH_VMOD_DIR, + /* def */ VINYL_VMOD_DIR, /* descr */ "Directory (or colon separated list of directories) " "where VMODs are to be found.", diff --git a/include/vqueue.h b/include/vqueue.h index 58dcb41ceb..cfb0bfd716 100644 --- a/include/vqueue.h +++ b/include/vqueue.h @@ -32,8 +32,8 @@ * $FreeBSD: head/sys/sys/queue.h 251887 2013-06-18 02:57:56Z lstewart $ */ -#ifndef VARNISH_QUEUE_H -#define VARNISH_QUEUE_H +#ifndef VINYL_QUEUE_H +#define VINYL_QUEUE_H /* * This file defines four types of data structures: singly-linked lists, @@ -573,4 +573,4 @@ struct { \ (head2)->vtqh_last = &(head2)->vtqh_first; \ } while (0) -#endif /* !VARNISH_QUEUE_H */ +#endif /* !VINYL_QUEUE_H */ diff --git a/lib/libvinyl/Makefile.am b/lib/libvinyl/Makefile.am index 3ac999ca07..109ff451fd 100644 --- a/lib/libvinyl/Makefile.am +++ b/lib/libvinyl/Makefile.am @@ -11,7 +11,7 @@ AM_LDFLAGS = $(AM_LT_LDFLAGS) noinst_LTLIBRARIES = libvinyl.la libvinyl_la_CFLAGS = \ - -DVARNISH_STATE_DIR='"${VARNISH_STATE_DIR}"' \ + -DVINYL_STATE_DIR='"${VINYL_STATE_DIR}"' \ $(AM_CFLAGS) libvinyl_la_SOURCES = \ diff --git a/lib/libvinyl/flint.lnt b/lib/libvinyl/flint.lnt index 83e75c3cc6..9caff49249 100644 --- a/lib/libvinyl/flint.lnt +++ b/lib/libvinyl/flint.lnt @@ -10,7 +10,7 @@ -efunc(662, be32dec_vect) // Possible creation of out-of-bounds pointer -efunc(670, VSHA256_Update) // Possible access beyond array for function '___', --dVARNISH_STATE_DIR="foo" +-dVINYL_STATE_DIR="foo" --emacro((835),VBH_NOIDX) --emacro((835),O_CLOEXEC) diff --git a/lib/libvinyl/vin.c b/lib/libvinyl/vin.c index e9ff307904..b7fd7716ae 100644 --- a/lib/libvinyl/vin.c +++ b/lib/libvinyl/vin.c @@ -42,7 +42,7 @@ #include "vin.h" #include "vsb.h" -#define VARNISH_DEFAULT_REL_NAME "varnishd" +#define VINYL_DEFAULT_REL_NAME "varnishd" char * VIN_n_Arg(const char *n_arg) @@ -53,12 +53,12 @@ VIN_n_Arg(const char *n_arg) vsb = VSB_new_auto(); AN(vsb); if (n_arg == NULL || n_arg[0] == '\0') { - VSB_cat(vsb, VARNISH_STATE_DIR); - VSB_cat(vsb, "/" VARNISH_DEFAULT_REL_NAME); + VSB_cat(vsb, VINYL_STATE_DIR); + VSB_cat(vsb, "/" VINYL_DEFAULT_REL_NAME); } else if (n_arg[0] == '/') { VSB_cat(vsb, n_arg); } else { - VSB_cat(vsb, VARNISH_STATE_DIR); + VSB_cat(vsb, VINYL_STATE_DIR); VSB_cat(vsb, "/"); VSB_cat(vsb, n_arg); } @@ -75,9 +75,9 @@ VIN_DumpDefaults(void) printf(" The default is taken from the ``VINYL_DEFAULT_N`` " "environment variable.\n\n"); printf(" Relative paths will be appended to ``%s``.\n\n", - VARNISH_STATE_DIR); + VINYL_STATE_DIR); printf(" If neither ``VINYL_DEFAULT_N`` nor ``-n`` are " "present, the value is ``%s``.\n\n", - VARNISH_STATE_DIR "/" VARNISH_DEFAULT_REL_NAME); + VINYL_STATE_DIR "/" VINYL_DEFAULT_REL_NAME); printf(" Note: These defaults may be distribution specific.\n\n"); } diff --git a/lib/libvinylapi/Makefile.am b/lib/libvinylapi/Makefile.am index 5cb523508a..2fe336df4c 100644 --- a/lib/libvinylapi/Makefile.am +++ b/lib/libvinylapi/Makefile.am @@ -35,7 +35,7 @@ libvinylapi_la_SOURCES += daemon.c endif libvinylapi_la_CFLAGS = \ - -DVARNISH_STATE_DIR='"${VARNISH_STATE_DIR}"' + -DVINYL_STATE_DIR='"${VINYL_STATE_DIR}"' libvinylapi_la_LIBADD = \ $(top_builddir)/lib/libvinyl/libvinyl.la \ @@ -77,7 +77,7 @@ vxp_test_SOURCES = \ $(libvinylapi_la_SOURCES) \ vxp_test.c vxp_test_CFLAGS = \ - -DVARNISH_STATE_DIR='"${VARNISH_STATE_DIR}"' \ + -DVINYL_STATE_DIR='"${VINYL_STATE_DIR}"' \ -DVXP_DEBUG vxp_test_LDADD = \ $(top_builddir)/lib/libvinyl/libvinyl.la \ diff --git a/lib/libvinylapi/libvinylapi.map b/lib/libvinylapi/libvinylapi.map index 7fe8deb3c1..9acf958141 100644 --- a/lib/libvinylapi/libvinylapi.map +++ b/lib/libvinylapi/libvinylapi.map @@ -28,7 +28,7 @@ * SUCH DAMAGE. */ -LIBVARNISHAPI_3.0 { /* 2021-09-15 release */ +LIBVINYLAPI_3.0 { /* 2021-09-15 release */ global: # vas.c VAS_errtxt; @@ -163,7 +163,7 @@ LIBVARNISHAPI_3.0 { /* 2021-09-15 release */ *; }; -LIBVARNISHAPI_3.1 { /* 2023-09-15 release */ +LIBVINYLAPI_3.1 { /* 2023-09-15 release */ global: # venc.c VENC_Encode_Base64; diff --git a/varnish-legacy.m4 b/varnish-legacy.m4 index 54ef004829..3ea2cc8613 100644 --- a/varnish-legacy.m4 +++ b/varnish-legacy.m4 @@ -52,13 +52,13 @@ AS_VAR_IF([$1], [""], [$5], [$4])dnl ]) ]) -# VARNISH_VMOD_INCLUDE_DIR([]) +# VINYL_VMOD_INCLUDE_DIR([]) # ---------------------------- -AC_DEFUN([VARNISH_VMOD_INCLUDES], +AC_DEFUN([VINYL_VMOD_INCLUDES], [ m4_pattern_forbid([^_?VARNISH[A-Z_]+$]) -m4_pattern_allow([^VARNISH_VMOD(_INCLUDE_DIR|TOOL)$]) +m4_pattern_allow([^VINYL_VMOD(_INCLUDE_DIR|TOOL)$]) # Check for pkg-config PKG_CHECK_EXISTS([varnishapi],[],[ if test -z "$PKG_CONFIG"; then @@ -77,42 +77,42 @@ variable if you installed software in a non-standard prefix.]) fi ]) -VARNISH_PKG_GET_VAR([VAPI_INCLUDE_DIR], [pkgincludedir]) +VINYL_PKG_GET_VAR([VAPI_INCLUDE_DIR], [pkgincludedir]) _CPPFLAGS="$CPPFLAGS" VMOD_INCLUDES="-I$VAPI_INCLUDE_DIR" CPPFLAGS="$VMOD_INCLUDES $CPPFLAGS" AC_CHECK_HEADERS([vsha256.h cache/cache.h]) CPPFLAGS="$_CPPFLAGS" AC_SUBST([VMOD_INCLUDES]) -])# VARNISH_VMOD_INCLUDE_DIR +])# VINYL_VMOD_INCLUDE_DIR -# VARNISH_VMOD_DIR([]) +# VINYL_VMOD_DIR([]) # -------------------- -AC_DEFUN([VARNISH_VMOD_DIR], +AC_DEFUN([VINYL_VMOD_DIR], [ -VARNISH_PKG_GET_VAR([VMOD_DIR], [vmoddir]) +VINYL_PKG_GET_VAR([VMOD_DIR], [vmoddir]) AC_SUBST([VMOD_DIR]) ]) -# VARNISH_VMODTOOL([]) +# VINYL_VMODTOOL([]) # -------------------- -AC_DEFUN([VARNISH_VMODTOOL], +AC_DEFUN([VINYL_VMODTOOL], [ AC_CHECK_PROGS(PYTHON, [python3.10 python3.9 python3.8 python3.7 python3.6 dnl python3.5 python3.4 python3 python, "no"]) if test "x$PYTHON" = "xno"; then AC_MSG_ERROR([Python >= 3.4 is needed to build, please install python.]) fi -VARNISH_PKG_GET_VAR([VMODTOOL], [vmodtool]) +VINYL_PKG_GET_VAR([VMODTOOL], [vmodtool]) AC_SUBST([VMODTOOL]) ]) -# VARNISH_PKG_GET_VAR([VARIABLE, PC_VAR_NAME]) +# VINYL_PKG_GET_VAR([VARIABLE, PC_VAR_NAME]) # ------------------------------- -AC_DEFUN([VARNISH_PKG_GET_VAR], +AC_DEFUN([VINYL_PKG_GET_VAR], [ # Uses internal function for now.. pkg_failed=no diff --git a/vinyl.m4 b/vinyl.m4 index e5f8f5447c..c6d249db69 100644 --- a/vinyl.m4 +++ b/vinyl.m4 @@ -44,9 +44,9 @@ # any time. Public macros starting with VARNISH_ are documented and will # maintain backwards compatibility with older versions of Varnish Cache. -# _VARNISH_CHECK_LIB(LIB, FUNC) +# _VINYL_CHECK_LIB(LIB, FUNC) # ----------------------------- -AC_DEFUN([_VARNISH_CHECK_LIB], [ +AC_DEFUN([_VINYL_CHECK_LIB], [ save_LIBS="${LIBS}" LIBS="" AC_CHECK_LIB([$1], [$2]) @@ -54,9 +54,9 @@ AC_DEFUN([_VARNISH_CHECK_LIB], [ LIBS="${save_LIBS}" ]) -# _VARNISH_SEARCH_LIBS(VAR, FUNC, LIBS) +# _VINYL_SEARCH_LIBS(VAR, FUNC, LIBS) # ------------------------------------- -AC_DEFUN([_VARNISH_SEARCH_LIBS], [ +AC_DEFUN([_VINYL_SEARCH_LIBS], [ save_LIBS="${LIBS}" LIBS="" AC_SEARCH_LIBS([$2], [$3]) @@ -64,37 +64,37 @@ AC_DEFUN([_VARNISH_SEARCH_LIBS], [ LIBS="${save_LIBS}" ]) -# _VARNISH_PKG_CONFIG +# _VINYL_PKG_CONFIG # -------------------- -AC_DEFUN([_VARNISH_PKG_CONFIG], [ +AC_DEFUN([_VINYL_PKG_CONFIG], [ PKG_PROG_PKG_CONFIG([0.21]) - PKG_CHECK_MODULES([VARNISHAPI], [varnishapi]) - AC_SUBST([VARNISH_VERSION], [$($PKG_CONFIG --modversion varnishapi)]) + PKG_CHECK_MODULES([VINYLAPI], [varnishapi]) + AC_SUBST([VINYL_VERSION], [$($PKG_CONFIG --modversion varnishapi)]) - PKG_CHECK_VAR([VARNISHAPI_PREFIX], [varnishapi], [prefix]) - PKG_CHECK_VAR([VARNISHAPI_DATAROOTDIR], [varnishapi], [datarootdir]) - PKG_CHECK_VAR([VARNISHAPI_LIBDIR], [varnishapi], [libdir]) - PKG_CHECK_VAR([VARNISHAPI_BINDIR], [varnishapi], [bindir]) - PKG_CHECK_VAR([VARNISHAPI_SBINDIR], [varnishapi], [sbindir]) - PKG_CHECK_VAR([VARNISHAPI_VCLDIR], [varnishapi], [vcldir]) - PKG_CHECK_VAR([VARNISHAPI_VMODDIR], [varnishapi], [vmoddir]) + PKG_CHECK_VAR([VINYLAPI_PREFIX], [varnishapi], [prefix]) + PKG_CHECK_VAR([VINYLAPI_DATAROOTDIR], [varnishapi], [datarootdir]) + PKG_CHECK_VAR([VINYLAPI_LIBDIR], [varnishapi], [libdir]) + PKG_CHECK_VAR([VINYLAPI_BINDIR], [varnishapi], [bindir]) + PKG_CHECK_VAR([VINYLAPI_SBINDIR], [varnishapi], [sbindir]) + PKG_CHECK_VAR([VINYLAPI_VCLDIR], [varnishapi], [vcldir]) + PKG_CHECK_VAR([VINYLAPI_VMODDIR], [varnishapi], [vmoddir]) PKG_CHECK_VAR([VMODTOOL], [varnishapi], [vmodtool]) PKG_CHECK_VAR([VSCTOOL], [varnishapi], [vsctool]) - AC_SUBST([VARNISH_LIBRARY_PATH], - [$VARNISHAPI_LIBDIR:$VARNISHAPI_LIBDIR/varnish]) + AC_SUBST([VINYL_LIBRARY_PATH], + [$VINYLAPI_LIBDIR:$VINYLAPI_LIBDIR/varnish]) - AC_SUBST([VARNISH_TEST_PATH], - [$VARNISHAPI_SBINDIR:$VARNISHAPI_BINDIR:$PATH]) + AC_SUBST([VINYL_TEST_PATH], + [$VINYLAPI_SBINDIR:$VINYLAPI_BINDIR:$PATH]) dnl Inherit Varnish's prefix if undefined dnl Also the libdir for multi-lib systems if test "$prefix" = NONE then - ac_default_prefix=$VARNISHAPI_PREFIX - libdir=$VARNISHAPI_LIBDIR + ac_default_prefix=$VINYLAPI_PREFIX + libdir=$VINYLAPI_LIBDIR fi dnl Define the VCL directory for automake @@ -106,14 +106,14 @@ AC_DEFUN([_VARNISH_PKG_CONFIG], [ AC_SUBST([pkgvcldir], [\${vcldir}/\${PACKAGE}]) ]) -# _VARNISH_CHECK_DEVEL +# _VINYL_CHECK_DEVEL # -------------------- -AC_DEFUN([_VARNISH_CHECK_DEVEL], [ +AC_DEFUN([_VINYL_CHECK_DEVEL], [ - AC_REQUIRE([_VARNISH_PKG_CONFIG]) + AC_REQUIRE([_VINYL_PKG_CONFIG]) [_orig_cppflags=$CPPFLAGS] - [CPPFLAGS=$VARNISHAPI_CFLAGS] + [CPPFLAGS=$VINYLAPI_CFLAGS] AC_CHECK_HEADERS([vsha256.h cache/cache.h], [], [AC_MSG_ERROR([Missing Varnish development files.])]) @@ -121,9 +121,9 @@ AC_DEFUN([_VARNISH_CHECK_DEVEL], [ [CPPFLAGS=$_orig_cppflags] ]) -# _VARNISH_CHECK_PYTHON +# _VINYL_CHECK_PYTHON # --------------------- -AC_DEFUN([_VARNISH_CHECK_PYTHON], [ +AC_DEFUN([_VINYL_CHECK_PYTHON], [ m4_define_default([_AM_PYTHON_INTERPRETER_LIST], [python3 python3.10 python3.9 python3.8 python3.7 python3.6 dnl python3.5 python3.4 python]) @@ -133,28 +133,28 @@ AC_DEFUN([_VARNISH_CHECK_PYTHON], [ ]) -# _VARNISH_VMOD_LDFLAGS +# _VINYL_VMOD_LDFLAGS # --------------------- -AC_DEFUN([_VARNISH_VMOD_LDFLAGS], [ +AC_DEFUN([_VINYL_VMOD_LDFLAGS], [ AC_SUBST([VMOD_LDFLAGS], "-module -export-dynamic -avoid-version -shared") ]) -# _VARNISH_VMOD_CONFIG +# _VINYL_VMOD_CONFIG # -------------------- -AC_DEFUN([_VARNISH_VMOD_CONFIG], [ +AC_DEFUN([_VINYL_VMOD_CONFIG], [ dnl Check the VMOD toolchain AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS]) AC_REQUIRE([AC_LANG_C]) AC_REQUIRE([AC_PROG_CC]) AC_REQUIRE([AC_PROG_CC_C99]) - AC_REQUIRE([_VARNISH_PKG_CONFIG]) - AC_REQUIRE([_VARNISH_CHECK_DEVEL]) - AC_REQUIRE([_VARNISH_CHECK_PYTHON]) - AC_REQUIRE([_VARNISH_VMOD_LDFLAGS]) + AC_REQUIRE([_VINYL_PKG_CONFIG]) + AC_REQUIRE([_VINYL_CHECK_DEVEL]) + AC_REQUIRE([_VINYL_CHECK_PYTHON]) + AC_REQUIRE([_VINYL_VMOD_LDFLAGS]) AC_REQUIRE([AC_PROG_CPP]) AC_REQUIRE([AC_PROG_CPP_WERROR]) @@ -164,10 +164,10 @@ AC_DEFUN([_VARNISH_VMOD_CONFIG], [ ]) dnl Expose the location of the std and directors VMODs - AC_SUBST([VARNISHAPI_VMODDIR]) + AC_SUBST([VINYLAPI_VMODDIR]) dnl Expose Varnish's aclocal directory to automake - AC_SUBST([VARNISHAPI_DATAROOTDIR]) + AC_SUBST([VINYLAPI_DATAROOTDIR]) dnl Define the VMOD directory for libtool vmoddir=$($PKG_CONFIG --define-variable=libdir=$libdir \ @@ -185,14 +185,14 @@ AC_DEFUN([_VARNISH_VMOD_CONFIG], [ AC_SUBST([AM_V_VMODTOOL]) dnl Substitute an alias for compatibility reasons - AC_SUBST([VMOD_TEST_PATH], [$VARNISH_TEST_PATH]) + AC_SUBST([VMOD_TEST_PATH], [$VINYL_TEST_PATH]) ]) -# _VARNISH_VMOD(NAME, MODE) +# _VINYL_VMOD(NAME, MODE) # ------------------------- -AC_DEFUN([_VARNISH_VMOD], [ +AC_DEFUN([_VINYL_VMOD], [ - AC_REQUIRE([_VARNISH_VMOD_CONFIG]) + AC_REQUIRE([_VINYL_VMOD_CONFIG]) VMOD_FILE="\$(abs_builddir)/.libs/libvmod_$1.so" AC_SUBST(m4_toupper(VMOD_$1_FILE), [$VMOD_FILE]) @@ -238,7 +238,7 @@ clean-vmod-$1: m4_popdef([VCC_SRC])dnl ]) -# VARNISH_VMODS(NAMES) +# VINYL_VMODS(NAMES) # -------------------- # Since: Varnish 4.1.4 # @@ -250,15 +250,15 @@ clean-vmod-$1: # to build the modules: # # - VMOD_LDFLAGS (the recommended flags to link VMODs) -# - VMOD_TEST_PATH (an alias for VARNISH_TEST_PATH) +# - VMOD_TEST_PATH (an alias for VINYL_TEST_PATH) # - VMODTOOL (to generate a VMOD's interface) # - vmoddir (the install prefix for VMODs) # - vmod_*_vcldir (the install prefix for the VMODs VCL files) # # Configuring your VMOD build with libtool can be as simple as: # -# AM_CFLAGS = $(VARNISHAPI_CFLAGS) -# AM_LDFLAGS = $(VARNISHAPI_LIBS) $(VMOD_LDFLAGS) +# AM_CFLAGS = $(VINYLAPI_CFLAGS) +# AM_LDFLAGS = $(VINYLAPI_LIBS) $(VMOD_LDFLAGS) # # vmod_LTLIBRARIES = libvmod_foo.la # @@ -270,7 +270,7 @@ clean-vmod-$1: # # For example, if you define the following in configure.ac: # -# VARNISH_VMODS([foo bar]) +# VINYL_VMODS([foo bar]) # # Two build rules will be available for use in Makefile.am for vmod-foo # and vmod-bar: @@ -305,14 +305,14 @@ clean-vmod-$1: # # Two notable variables are exposed from Varnish's pkg-config: # -# - VARNISHAPI_VMODDIR (locate vmod-std and vmod-directors in your tests) -# - VARNISHAPI_DATAROOTDIR (for when aclocal is called from a Makefile) +# - VINYLAPI_VMODDIR (locate vmod-std and vmod-directors in your tests) +# - VINYLAPI_DATAROOTDIR (for when aclocal is called from a Makefile) # # For example in your root Makefile.am: # -# ACLOCAL_AMFLAGS = -I m4 -I ${VARNISHAPI_DATAROOTDIR}/aclocal +# ACLOCAL_AMFLAGS = -I m4 -I ${VINYLAPI_DATAROOTDIR}/aclocal # -# The VARNISH_VERSION variable will be set even if the VARNISH_PREREQ macro +# The VINYL_VERSION variable will be set even if the VINYL_PREREQ macro # wasn't called. Although many things are set up to facilitate out-of-tree # VMOD maintenance, initialization of autoconf, automake and libtool is # still the maintainer's responsibility. It cannot be avoided. @@ -322,8 +322,8 @@ clean-vmod-$1: # is a minimal setup: # # AM_TESTS_ENVIRONMENT = \ -# PATH="$(VARNISH_TEST_PATH):$(PATH)" \ -# LD_LIBRARY_PATH="$(VARNISH_LIBRARY_PATH)" +# PATH="$(VINYL_TEST_PATH):$(PATH)" \ +# LD_LIBRARY_PATH="$(VINYL_LIBRARY_PATH)" # TEST_EXTENSIONS = .vtc # VTC_LOG_COMPILER = varnishtest -v # AM_VTC_LOG_FLAGS = -Dvmod_foo="$(VMOD_FOO)" -Dvmod_bar="$(VMOD_BAR)" @@ -374,39 +374,39 @@ clean-vmod-$1: # # Now, you can focus on writing this VMOD of yours. # -AC_DEFUN([VARNISH_VMODS], [ +AC_DEFUN([VINYL_VMODS], [ m4_foreach([_vmod_name], m4_split(m4_normalize([$1])), - [_VARNISH_VMOD(_vmod_name, [static])]) + [_VINYL_VMOD(_vmod_name, [static])]) ]) -# VARNISH_VMODS_GENERATED(NAMES) +# VINYL_VMODS_GENERATED(NAMES) # ------------------------------ # Since: Varnish 6.5.0 # # Varnish 6.5 adds the possibility to transparently work with a generated VCC # file. The VCC file would then be created in the build directory, which is -# incompatible with how the VARNISH_VMODS macro operates. +# incompatible with how the VINYL_VMODS macro operates. # # If that VCC file only needs to be generated once and is distributed, builds # from the dist archive will have the VCC file in the source directory. # # With Varnish's ability to run VMODTOOL in a VPATH build both scenarios are -# taken care of. This macro works otherwise exactly like VARNISH_VMODS. +# taken care of. This macro works otherwise exactly like VINYL_VMODS. # -AC_DEFUN([VARNISH_VMODS_GENERATED], [ +AC_DEFUN([VINYL_VMODS_GENERATED], [ m4_foreach([_vmod_name], m4_split(m4_normalize([$1])), - [_VARNISH_VMOD(_vmod_name, [generated])]) + [_VINYL_VMOD(_vmod_name, [generated])]) ]) -# _VARNISH_VSC_CONFIG +# _VINYL_VSC_CONFIG # -------------------- -AC_DEFUN([_VARNISH_VSC_CONFIG], [ +AC_DEFUN([_VINYL_VSC_CONFIG], [ - AC_REQUIRE([_VARNISH_PKG_CONFIG]) - AC_REQUIRE([_VARNISH_CHECK_DEVEL]) - AC_REQUIRE([_VARNISH_CHECK_PYTHON]) + AC_REQUIRE([_VINYL_PKG_CONFIG]) + AC_REQUIRE([_VINYL_CHECK_DEVEL]) + AC_REQUIRE([_VINYL_CHECK_PYTHON]) dnl Define an automake silent execution for vmodtool [am__v_VSCTOOL_0='@echo " VSCTOOL " $''@;'] @@ -419,11 +419,11 @@ AC_DEFUN([_VARNISH_VSC_CONFIG], [ AC_SUBST([AM_V_VSCTOOL]) ]) -# _VARNISH_COUNTER(NAME) +# _VINYL_COUNTER(NAME) # ---------------------- -AC_DEFUN([_VARNISH_COUNTER], [ +AC_DEFUN([_VINYL_COUNTER], [ - AC_REQUIRE([_VARNISH_VSC_CONFIG]) + AC_REQUIRE([_VINYL_VSC_CONFIG]) VSC_RULES=" @@ -449,7 +449,7 @@ clean-vsc-$1: AM_SUBST_NOTMAKE(m4_toupper(BUILD_VSC_$1)) ]) -# VARNISH_COUNTERS(NAMES) +# VINYL_COUNTERS(NAMES) # ----------------------- # Since: Varnish 6.0.0 # @@ -458,7 +458,7 @@ clean-vsc-$1: # to declare sets of counters, but does not associate them automatically # with their respective VMODs: # -# VARNISH_COUNTERS([foo bar]) +# VINYL_COUNTERS([foo bar]) # # Two build rules will be available for use in Makefile.am for the counters # foo and bar: @@ -495,15 +495,15 @@ clean-vsc-$1: # # That should be all you need to do to start implementing custom counters. # -AC_DEFUN([VARNISH_COUNTERS], [ +AC_DEFUN([VINYL_COUNTERS], [ m4_foreach([_vsc_name], m4_split(m4_normalize([$1])), - [_VARNISH_COUNTER(_vsc_name)]) + [_VINYL_COUNTER(_vsc_name)]) ]) -# _VARNISH_UTILITY(NAME) +# _VINYL_UTILITY(NAME) # ---------------------- -AC_DEFUN([_VARNISH_UTILITY], [ +AC_DEFUN([_VINYL_UTILITY], [ VUT_RULES=" @@ -529,7 +529,7 @@ clean-vut-$1: ]) -# VARNISH_UTILITIES(NAMES) +# VINYL_UTILITIES(NAMES) # ------------------------ # Since: Varnish 5.2.0 # @@ -544,7 +544,7 @@ clean-vut-$1: # # For example, if you define the following in configure.ac: # -# VARNISH_UTILITIES([foo bar]) +# VINYL_UTILITIES([foo bar]) # # Two build rules will be available for use in Makefile.am for the programs # foo and bar: @@ -612,21 +612,21 @@ clean-vut-$1: # when the source directory is different from the build directory. It is the # maintainer's responsibility to build the actual manuals. # -AC_DEFUN([VARNISH_UTILITIES], [ +AC_DEFUN([VINYL_UTILITIES], [ m4_foreach([_vut_name], m4_split(m4_normalize([$1])), - [_VARNISH_UTILITY(_vut_name)]) + [_VINYL_UTILITY(_vut_name)]) ]) -# VARNISH_PREREQ(MINIMUM-VERSION, [MAXIMUM-VERSION]) +# VINYL_PREREQ(MINIMUM-VERSION, [MAXIMUM-VERSION]) # -------------------------------------------------- # Since: Varnish 4.1.4 # # Since Varnish 5.1.0: -# - VARNISH_TEST_PATH added -# - VARNISH_LIBRARY_PATH added -# - VARNISHAPI_LIBDIR added -# - VARNISHAPI_VCLDIR added +# - VINYL_TEST_PATH added +# - VINYL_LIBRARY_PATH added +# - VINYLAPI_LIBDIR added +# - VINYLAPI_VCLDIR added # - vcldir added # - pkgvcldir added # @@ -640,22 +640,22 @@ AC_DEFUN([VARNISH_UTILITIES], [ # Once the requirements are met, the following variables can be used in # Makefiles: # -# - VARNISH_TEST_PATH (for the test suite environment) -# - VARNISH_LIBRARY_PATH (for both public and private libraries) -# - VARNISH_VERSION (also available in autoconf) +# - VINYL_TEST_PATH (for the test suite environment) +# - VINYL_LIBRARY_PATH (for both public and private libraries) +# - VINYL_VERSION (also available in autoconf) # # The following variables are available in autoconf, read from the varnish # pkg-config: # -# - VARNISHAPI_CFLAGS -# - VARNISHAPI_LIBS -# - VARNISHAPI_PREFIX -# - VARNISHAPI_DATAROOTDIR -# - VARNISHAPI_LIBDIR -# - VARNISHAPI_BINDIR -# - VARNISHAPI_SBINDIR -# - VARNISHAPI_VCLDIR -# - VARNISHAPI_VMODDIR +# - VINYLAPI_CFLAGS +# - VINYLAPI_LIBS +# - VINYLAPI_PREFIX +# - VINYLAPI_DATAROOTDIR +# - VINYLAPI_LIBDIR +# - VINYLAPI_BINDIR +# - VINYLAPI_SBINDIR +# - VINYLAPI_VCLDIR +# - VINYLAPI_VMODDIR # - VMODTOOL # - VSCTOOL # @@ -672,17 +672,17 @@ AC_DEFUN([VARNISH_UTILITIES], [ # This provides a namespace facility for installed VCL files needing including # other VCL files, which can be overridden if the package name is not desired. # -AC_DEFUN([VARNISH_PREREQ], [ - AC_REQUIRE([_VARNISH_PKG_CONFIG]) +AC_DEFUN([VINYL_PREREQ], [ + AC_REQUIRE([_VINYL_PKG_CONFIG]) AC_MSG_CHECKING([for Varnish]) - AC_MSG_RESULT([$VARNISH_VERSION]) + AC_MSG_RESULT([$VINYL_VERSION]) - AS_VERSION_COMPARE([$VARNISH_VERSION], [$1], [ + AS_VERSION_COMPARE([$VINYL_VERSION], [$1], [ AC_MSG_ERROR([Varnish version $1 or higher is required.]) ]) test $# -gt 1 && - AS_VERSION_COMPARE([$2], [$VARNISH_VERSION], [ + AS_VERSION_COMPARE([$2], [$VINYL_VERSION], [ AC_MSG_ERROR([Varnish version below $2 is required.]) ]) ]) From ab540b86a306a24b988e3b1e441e9408f8689801 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 13:47:19 +0000 Subject: [PATCH 097/196] Rename varnish-legacy.m4 -> vinyl-legacy.m4 and fix Makefile.am --- Makefile.am | 6 +++--- varnish-legacy.m4 => vinyl-legacy.m4 | 0 2 files changed, 3 insertions(+), 3 deletions(-) rename varnish-legacy.m4 => vinyl-legacy.m4 (100%) diff --git a/Makefile.am b/Makefile.am index 8521e19389..6d784d44ce 100644 --- a/Makefile.am +++ b/Makefile.am @@ -8,7 +8,7 @@ pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = varnishapi.pc m4dir = $(datadir)/aclocal -m4_DATA = varnish.m4 varnish-legacy.m4 +m4_DATA = vinyl.m4 vinyl-legacy.m4 CLEANFILES = \ cscope.in.out \ @@ -24,8 +24,8 @@ EXTRA_DIST = \ LICENSE \ autogen.sh \ varnishapi.pc.in \ - varnish.m4 \ - varnish-legacy.m4 \ + vinyl.m4 \ + vinyl-legacy.m4 \ vsc.am \ vtc.am \ wflags.py diff --git a/varnish-legacy.m4 b/vinyl-legacy.m4 similarity index 100% rename from varnish-legacy.m4 rename to vinyl-legacy.m4 From 00ef4ed799382b848c750b6a801a7a0d3b3065f6 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 14:52:24 +0000 Subject: [PATCH 098/196] s/varnishapi/vinylapi/ --- Makefile.am | 4 +-- bin/vinyltest/tests/r01804.vtc | 2 +- configure.ac | 4 +-- vinyl-legacy.m4 | 6 ++--- vinyl.m4 | 26 +++++++++---------- ...talled.pc.in => vinylapi-uninstalled.pc.in | 6 ++--- varnishapi.pc.in => vinylapi.pc.in | 6 ++--- 7 files changed, 27 insertions(+), 27 deletions(-) rename varnishapi-uninstalled.pc.in => vinylapi-uninstalled.pc.in (83%) rename varnishapi.pc.in => vinylapi.pc.in (86%) diff --git a/Makefile.am b/Makefile.am index 6d784d44ce..efbf99e6d3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -5,7 +5,7 @@ SUBDIRS = include lib bin vmod etc doc man contrib TESTS = tools/magic_check.sh pkgconfigdir = $(libdir)/pkgconfig -pkgconfig_DATA = varnishapi.pc +pkgconfig_DATA = vinylapi.pc m4dir = $(datadir)/aclocal m4_DATA = vinyl.m4 vinyl-legacy.m4 @@ -23,7 +23,7 @@ EXTRA_DIST = \ README.Packaging \ LICENSE \ autogen.sh \ - varnishapi.pc.in \ + vinylapi.pc.in \ vinyl.m4 \ vinyl-legacy.m4 \ vsc.am \ diff --git a/bin/vinyltest/tests/r01804.vtc b/bin/vinyltest/tests/r01804.vtc index 4658c2243e..45104c7f70 100644 --- a/bin/vinyltest/tests/r01804.vtc +++ b/bin/vinyltest/tests/r01804.vtc @@ -1,4 +1,4 @@ -vtest "#1804: varnishapi transaction grouping fails for PROXY" +vtest "#1804: vinylapi transaction grouping fails for PROXY" server s1 { rxreq diff --git a/configure.ac b/configure.ac index fef8c7410b..9bb9b84695 100644 --- a/configure.ac +++ b/configure.ac @@ -938,8 +938,8 @@ AC_CONFIG_FILES([ lib/libvcc/Makefile lib/libvgz/Makefile man/Makefile - varnishapi.pc - varnishapi-uninstalled.pc + vinylapi.pc + vinylapi-uninstalled.pc vmod/Makefile ]) diff --git a/vinyl-legacy.m4 b/vinyl-legacy.m4 index 3ea2cc8613..3004f0b4f4 100644 --- a/vinyl-legacy.m4 +++ b/vinyl-legacy.m4 @@ -60,7 +60,7 @@ AC_DEFUN([VINYL_VMOD_INCLUDES], m4_pattern_forbid([^_?VARNISH[A-Z_]+$]) m4_pattern_allow([^VINYL_VMOD(_INCLUDE_DIR|TOOL)$]) # Check for pkg-config -PKG_CHECK_EXISTS([varnishapi],[],[ +PKG_CHECK_EXISTS([vinylapi],[],[ if test -z "$PKG_CONFIG"; then AC_MSG_FAILURE( [The pkg-config script could not be found or is too old. Make sure it @@ -70,7 +70,7 @@ path to pkg-config. To get pkg-config, see .]) else AC_MSG_FAILURE( -[pkg-config was unable to locate the varnishapi configuration data. +[pkg-config was unable to locate the vinylapi configuration data. Please check config.log or adjust the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.]) @@ -116,7 +116,7 @@ AC_DEFUN([VINYL_PKG_GET_VAR], [ # Uses internal function for now.. pkg_failed=no -_PKG_CONFIG([$1], [variable=][$2], [varnishapi]) +_PKG_CONFIG([$1], [variable=][$2], [vinylapi]) if test "$pkg_failed" = "yes"; then AC_MSG_FAILURE([$2][ not defined, too old Varnish?]) fi diff --git a/vinyl.m4 b/vinyl.m4 index c6d249db69..488600debf 100644 --- a/vinyl.m4 +++ b/vinyl.m4 @@ -69,19 +69,19 @@ AC_DEFUN([_VINYL_SEARCH_LIBS], [ AC_DEFUN([_VINYL_PKG_CONFIG], [ PKG_PROG_PKG_CONFIG([0.21]) - PKG_CHECK_MODULES([VINYLAPI], [varnishapi]) - AC_SUBST([VINYL_VERSION], [$($PKG_CONFIG --modversion varnishapi)]) + PKG_CHECK_MODULES([VINYLAPI], [vinylapi]) + AC_SUBST([VINYL_VERSION], [$($PKG_CONFIG --modversion vinylapi)]) - PKG_CHECK_VAR([VINYLAPI_PREFIX], [varnishapi], [prefix]) - PKG_CHECK_VAR([VINYLAPI_DATAROOTDIR], [varnishapi], [datarootdir]) - PKG_CHECK_VAR([VINYLAPI_LIBDIR], [varnishapi], [libdir]) - PKG_CHECK_VAR([VINYLAPI_BINDIR], [varnishapi], [bindir]) - PKG_CHECK_VAR([VINYLAPI_SBINDIR], [varnishapi], [sbindir]) - PKG_CHECK_VAR([VINYLAPI_VCLDIR], [varnishapi], [vcldir]) - PKG_CHECK_VAR([VINYLAPI_VMODDIR], [varnishapi], [vmoddir]) + PKG_CHECK_VAR([VINYLAPI_PREFIX], [vinylapi], [prefix]) + PKG_CHECK_VAR([VINYLAPI_DATAROOTDIR], [vinylapi], [datarootdir]) + PKG_CHECK_VAR([VINYLAPI_LIBDIR], [vinylapi], [libdir]) + PKG_CHECK_VAR([VINYLAPI_BINDIR], [vinylapi], [bindir]) + PKG_CHECK_VAR([VINYLAPI_SBINDIR], [vinylapi], [sbindir]) + PKG_CHECK_VAR([VINYLAPI_VCLDIR], [vinylapi], [vcldir]) + PKG_CHECK_VAR([VINYLAPI_VMODDIR], [vinylapi], [vmoddir]) - PKG_CHECK_VAR([VMODTOOL], [varnishapi], [vmodtool]) - PKG_CHECK_VAR([VSCTOOL], [varnishapi], [vsctool]) + PKG_CHECK_VAR([VMODTOOL], [vinylapi], [vmodtool]) + PKG_CHECK_VAR([VSCTOOL], [vinylapi], [vsctool]) AC_SUBST([VINYL_LIBRARY_PATH], [$VINYLAPI_LIBDIR:$VINYLAPI_LIBDIR/varnish]) @@ -99,7 +99,7 @@ AC_DEFUN([_VINYL_PKG_CONFIG], [ dnl Define the VCL directory for automake vcldir=$($PKG_CONFIG --define-variable=datadir=$datadir \ - --variable=vcldir varnishapi) + --variable=vcldir vinylapi) AC_SUBST([vcldir]) dnl Define the VCL directory for this package @@ -171,7 +171,7 @@ AC_DEFUN([_VINYL_VMOD_CONFIG], [ dnl Define the VMOD directory for libtool vmoddir=$($PKG_CONFIG --define-variable=libdir=$libdir \ - --variable=vmoddir varnishapi) + --variable=vmoddir vinylapi) AC_SUBST([vmoddir]) dnl Define an automake silent execution for vmodtool diff --git a/varnishapi-uninstalled.pc.in b/vinylapi-uninstalled.pc.in similarity index 83% rename from varnishapi-uninstalled.pc.in rename to vinylapi-uninstalled.pc.in index d2522892f4..5c7b095709 100644 --- a/varnishapi-uninstalled.pc.in +++ b/vinylapi-uninstalled.pc.in @@ -12,8 +12,8 @@ vmoddir=${libdir}/@PACKAGE@/vmods builddir=@abs_top_builddir@ srcdir=@abs_top_srcdir@ -Name: VarnishAPI -Description: Varnish API +Name: VinylAPI +Description: Vinyl Cache API Version: @PACKAGE_VERSION@ Cflags: -I${includedir}/@PACKAGE@ -Libs: -L${libdir} -lvarnishapi +Libs: -L${libdir} -lvinylapi diff --git a/varnishapi.pc.in b/vinylapi.pc.in similarity index 86% rename from varnishapi.pc.in rename to vinylapi.pc.in index 04fe45602a..b5bb368b46 100644 --- a/varnishapi.pc.in +++ b/vinylapi.pc.in @@ -15,8 +15,8 @@ vmoddir=${libdir}/@PACKAGE@/vmods vmodtool=${pkgdatadir}/vmodtool.py vsctool=${pkgdatadir}/vsctool.py -Name: VarnishAPI -Description: Varnish API +Name: VinylAPI +Description: Vinyl Cache API Version: @PACKAGE_VERSION@ Cflags: -I${pkgincludedir} -Libs: -L${libdir} -lvarnishapi +Libs: -L${libdir} -lvinylapi From fb14260bb14a0a5a2fa6f22ae71c494d2aab74f7 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 15:10:21 +0000 Subject: [PATCH 099/196] Change the official project name in AC_INIT() --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 9bb9b84695..86da6fc59b 100644 --- a/configure.ac +++ b/configure.ac @@ -3,7 +3,7 @@ AC_COPYRIGHT([Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2025 Varnish Software Copyright 2010-2025 UPLEX - Nils Goroll Systemoptimierung]) AC_REVISION([$Id$]) -AC_INIT([Varnish], [trunk], [varnish-dev@varnish-cache.org]) +AC_INIT([Vinyl Cache], [trunk], [vinyl-dev@vinyl-cache.org], [vinyl-cache]) AC_CONFIG_SRCDIR(include/miniobj.h) if ! test -f "${srcdir}/bin/vinyltest/vtest2/src/vtc_main.c" ; then AC_MSG_ERROR([vtest2 seems to be missing, use "git clone --recursive" or "git submodule update --init"]) From 828f08ce078385937e9d77ad87af2c0eb3221798 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 16:09:55 +0000 Subject: [PATCH 100/196] Update .gitignore --- .gitignore | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.gitignore b/.gitignore index ae1c69c779..32e2bbfc3f 100644 --- a/.gitignore +++ b/.gitignore @@ -38,14 +38,14 @@ _* /m4/lt~obsolete.m4 /missing /stamp-h1 -/varnishapi.pc -/varnishapi-uninstalled.pc +/vinylapi.pc +/vinylapi-uninstalled.pc TAGS tags cscope.*out .dirstamp -# Default vcl made from bin/varnishd/default.vcl +# Default vcl made from bin/vinyld/default.vcl /bin/vinyld/builtin_vcl.c /etc/builtin.vcl From c6177579f67c9df8164c28cf8e0594de762e81e0 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 17:00:32 +0000 Subject: [PATCH 101/196] Start s/varnish/vinyl/'ing documentation --- INSTALL | 2 +- README.Packaging | 2 +- doc/README.WRITING_RST.rst | 10 +-- doc/changes.rst | 12 ++-- doc/sphinx/dev-guide/homepage_contrib.rst | 8 +-- doc/sphinx/dev-guide/index.rst | 16 ++--- doc/sphinx/index.rst | 2 +- doc/sphinx/installation/help.rst | 22 +++---- doc/sphinx/installation/install_debian.rst | 2 +- doc/sphinx/installation/install_source.rst | 2 +- doc/sphinx/reference/vcl.rst | 2 +- doc/sphinx/reference/vmod.rst | 52 +++++++-------- doc/sphinx/tutorial/backend_servers.rst | 30 ++++----- doc/sphinx/tutorial/introduction.rst | 77 +++++++++++----------- doc/sphinx/tutorial/starting_varnish.rst | 38 +++++------ doc/sphinx/whats-new/changes-6.6.rst | 2 +- etc/example.vcl | 4 +- 17 files changed, 141 insertions(+), 142 deletions(-) diff --git a/INSTALL b/INSTALL index b170fb7850..196bf5936f 100644 --- a/INSTALL +++ b/INSTALL @@ -1,6 +1,6 @@ Installation Instructions -See https://varnish-cache.org/docs/trunk/installation/install_source.html +See https://vinyl-cache.org/docs/trunk/installation/install_source.html for complete and up to date install instructions. This file only mentions the basic steps: diff --git a/README.Packaging b/README.Packaging index 695dd46f9c..b15c3efc1b 100644 --- a/README.Packaging +++ b/README.Packaging @@ -24,4 +24,4 @@ Third-party packages -------------------- Varnish Cache is built and packaged in many different operating systems and -distributions. Please see https://varnish-cache.org/ for more information. +distributions. Please see https://vinyl-cache.org/ for more information. diff --git a/doc/README.WRITING_RST.rst b/doc/README.WRITING_RST.rst index 0df908231b..d35928cb42 100644 --- a/doc/README.WRITING_RST.rst +++ b/doc/README.WRITING_RST.rst @@ -3,8 +3,8 @@ SPDX-License-Identifier: BSD-2-Clause See LICENSE file for full text of license -THINGS TO CONSIDER WHEN WRITING VARNISH RST DOCUMENTATION -========================================================= +THINGS TO CONSIDER WHEN WRITING VINYL CACHE RST DOCUMENTATION +============================================================= Inline Markup ------------- @@ -20,7 +20,7 @@ not follow the style: .. _Reference: http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#character-level-inline-markup - * exception: Links to manpages outside varnish as `man(section)` + * exception: Links to manpages outside vinyl as `man(section)` * use code blocks for:: @@ -77,7 +77,7 @@ While RST supports a great deal of flexibility for adornments of titles and section headers, we should adhere to a consistent style to avoid breaking the document structure unintentionally. -Within the Varnish-Cache project, we should use these characters: +Within the Vinyl-Cache project, we should use these characters: * Over and underline ``=`` for document titles @@ -100,7 +100,7 @@ This README was initially started by Nils Goroll. COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinyl Cache itself. See LICENCE for details. * Copyright 2015,2016,2019,2024 UPLEX - Nils Goroll diff --git a/doc/changes.rst b/doc/changes.rst index b2bb30544c..fd4fc6cf6b 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -114,7 +114,7 @@ Varnish-Cache 8.0.0 (2025-09-15) is unwanted, the worker process can still be terminated externally. .. _4380: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4380 -.. _VSV17: https://varnish-cache.org/security/VSV00017.html +.. _VSV17: https://vinyl-cache.org/security/VSV00017.html * The `reverse rapid reset` vector, also known as `HTTP/2 Made You Reset Attack`, has been addressed (`VSV17`_, `4380`_). @@ -224,7 +224,7 @@ Varnish-Cache 8.0.0 (2025-09-15) * Deprecated aliases for parameters can no longer be set read only, it should instead be done directly on the parameters they point to. -.. _VSV00016: https://varnish-cache.org/security/VSV00016.html +.. _VSV00016: https://vinyl-cache.org/security/VSV00016.html * We now check for CRLF after chunked body in HTTP/1. (VSV00016_) @@ -282,7 +282,7 @@ Varnish-Cache 8.0.0 (2025-09-15) Varnish-Cache 7.7 (2025-03-17) ============================== -.. _VSV00015: https://varnish-cache.org/security/VSV00015.html +.. _VSV00015: https://vinyl-cache.org/security/VSV00015.html * The client connection is now always closed when a malformed request is received. (VSV00015_) @@ -950,7 +950,7 @@ Varnish Cache 7.5.0 (2024-03-18) .. _3997: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3997 .. _3998: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3998 .. _3999: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3999 -.. _VSV00014: https://varnish-cache.org/security/VSV00014.html +.. _VSV00014: https://vinyl-cache.org/security/VSV00014.html ================================ Varnish Cache 7.4.0 (2023-09-15) @@ -1368,7 +1368,7 @@ Varnish Cache 7.2.0 (2022-09-15) .. _3830: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/3830 .. _3841: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/3841 .. _3846: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/3846 -.. _VSV00009: https://varnish-cache.org/security/VSV00009.html +.. _VSV00009: https://vinyl-cache.org/security/VSV00009.html ================================ Varnish Cache 7.1.0 (2022-03-15) @@ -2103,7 +2103,7 @@ Varnish Cache 6.6.0 (2021-03-15) See `VMOD - Varnish Modules`_ in the Reference Manual. -.. _VMOD - Varnish Modules: https://varnish-cache.org/docs/trunk/reference/vmod.html +.. _VMOD - Varnish Modules: https://vinyl-cache.org/docs/trunk/reference/vmod.html VMOD functions can also return the ``VCL_SUB`` data type for calls from VCL as in ``call vmod.returning_sub();``. diff --git a/doc/sphinx/dev-guide/homepage_contrib.rst b/doc/sphinx/dev-guide/homepage_contrib.rst index 59d63fa9a5..8bb3cf2808 100644 --- a/doc/sphinx/dev-guide/homepage_contrib.rst +++ b/doc/sphinx/dev-guide/homepage_contrib.rst @@ -5,11 +5,11 @@ .. _homepage_contrib: -How to contribute content to varnish-cache.org -============================================== +How to contribute content to vinyl-cache.org +============================================ This is where we walk you through the mechanics of adding content to -varnish-cache.org (see phk's note :ref:`homepage_dogfood` for an +vinyl-cache.org (see phk's note :ref:`homepage_dogfood` for an insight into the innards of site). Git Repository @@ -28,7 +28,7 @@ Sphinx and RST The web site sources are written in `RST `_ -- reStructuredText, the documentation format originally conceived for Python (and also used in -the Varnish distribution, as well as for formatting VMOD +the Vinly Cache distribution, as well as for formatting VMOD docs). `Sphinx `_ is used to render web pages from the RST sources. diff --git a/doc/sphinx/dev-guide/index.rst b/doc/sphinx/dev-guide/index.rst index 7c4158fa61..b5da507732 100644 --- a/doc/sphinx/dev-guide/index.rst +++ b/doc/sphinx/dev-guide/index.rst @@ -5,11 +5,11 @@ .. _dev-guide-index: -The Varnish Developers Guide -============================ +The Vinyl cache Developers Guide +================================ This is the deliberately short and to the point list of things -Varnish Developers should know. +Vinyl Cache Developers should know. Behaviour --------- @@ -53,7 +53,7 @@ Bugs, issues, feature requests & VIPs Bugs, issues and feature requests start out as github issues. -Monday at 15:00-16:00 (EU time) we "bug-wash" on IRC (#varnish-hacking +Monday at 15:00-16:00 (EU time) we "bug-wash" on IRC (#vinyl-hacking on irc.linpro.no) to decide who and how issues are dealt with. Issues we cannot do anything about are closed. @@ -61,7 +61,7 @@ Issues we cannot do anything about are closed. If feature-requests make sense, they get moved to a wiki/VIP page until somebody implements them. -Varnishtest cases for bugs is the norm, not the exception. +Vinyltest cases for bugs is the norm, not the exception. Architectural stuff ------------------- @@ -92,11 +92,11 @@ Various policies .. toctree:: :maxdepth: 1 - Varnish Cache organization and day-to-day operation + Vinyl Cache organization and day-to-day operation policy_vmods -The varnish-cache.org homepage ------------------------------- +The vinyl-cache.org homepage +---------------------------- .. toctree:: :maxdepth: 1 diff --git a/doc/sphinx/index.rst b/doc/sphinx/index.rst index 49a4b48074..083d407f7c 100644 --- a/doc/sphinx/index.rst +++ b/doc/sphinx/index.rst @@ -34,7 +34,7 @@ Conventions used in this manual include: `/usr/local/`, `varnishadm`, `sess_timeout` A utility, Varnish configurable parameter or path. - https://www.varnish-cache.org/ + https://www.vinyl-cache.org/ A hyperlink. Longer listings like example command output and VCL look like this:: diff --git a/doc/sphinx/installation/help.rst b/doc/sphinx/installation/help.rst index d58591e024..ee02aa3e61 100644 --- a/doc/sphinx/installation/help.rst +++ b/doc/sphinx/installation/help.rst @@ -7,13 +7,13 @@ Getting help %%%%%%%%%%%% -Getting hold of the gang behind Varnish is pretty straight forward, +Getting hold of the gang behind Vinyl Cache is pretty straight forward, we try to help out as much as time permits and have tried to streamline this process as much as possible. But before you grab hold of us, spend a moment composing your thoughts and formulate your question. From our perspective there -is nothing as pointless as simply telling us "Varnish does not work +is nothing as pointless as simply telling us "Vinyl Cache does not work for me" with no further information. This does not give us any relevant information to use when trying to figure out whats wrong. @@ -26,7 +26,7 @@ IRC Channel The most immediate way to get hold of us is to join our IRC channel: - `#varnish on server irc.linpro.no` + `#vinyl on server irc.linpro.no` The main timezone of the channel is Europe work hours. @@ -47,14 +47,14 @@ Mailing Lists Subscribing or unsubscribing to our mailing lists is handled through mailman_. -If you are going to use Varnish, subscribing to our `varnish-announce` +If you are going to use Vinyl Cache, subscribing to our `vinyl-announce` mailing list is a very good idea. The typical pattern is that -people spend some time getting Varnish running, and then more or less +people spend some time getting Vinyl Cache running, and then more or less forget about it. Therefore the announce list is a good way to be reminded about new releases, bugs or potential (security) vulnerabilities. -The `varnish-misc` mailing list is for general banter, questions, -suggestions, ideas and so on. If you are new to Varnish it may pay +The `vinyl-misc` mailing list is for general banter, questions, +suggestions, ideas and so on. If you are new to Vinyl Cache it may pay off to subscribe to it, simply to have an ear to the telegraph-pole and potentially learn some smart tricks. This is also a good place to ask for help with more complex issues, that may require file-chunks, references to files and/or long @@ -65,7 +65,7 @@ thread changes, please change the subject to match, some of us deal with hundreds of emails per day, after spam-filters, and we need all the help we can get to pick the interesting ones. -The `varnish-dev` mailing list is used by the developers and is +The `vinyl-dev` mailing list is used by the developers and is usually quite focused on source-code and such. Everybody on the `-dev` list is also on `-misc`, so cross-posting only serves to annoy those people. @@ -74,7 +74,7 @@ Trouble Tickets =============== Our bugtracker lives on GitHub, but please do not open a trouble -ticket, unless you have spotted an actual bug in Varnish. Ask on +ticket, unless you have spotted an actual bug in Vinyl Cache. Ask on IRC first if you are in doubt. The reason for this policy, is to avoid bugs being drowned in a @@ -90,7 +90,7 @@ Commercial Support ================== If you need commercial support, there are companies which offer that -and you can find a `list on our homepage. `_. +and you can find a `list on our homepage. `_. -.. _mailman: https://www.varnish-cache.org/lists/mailman/listinfo +.. _mailman: https://www.vinyl-cache.org/lists/mailman/listinfo .. _pastebin: https://gist.github.com/ diff --git a/doc/sphinx/installation/install_debian.rst b/doc/sphinx/installation/install_debian.rst index f1e9549d2b..a5de62473a 100644 --- a/doc/sphinx/installation/install_debian.rst +++ b/doc/sphinx/installation/install_debian.rst @@ -13,7 +13,7 @@ From package Type:: - sudo apt-get install varnish + sudo apt-get install vinyl Official packages of 6 diff --git a/doc/sphinx/installation/install_source.rst b/doc/sphinx/installation/install_source.rst index 994904a756..393a650d91 100644 --- a/doc/sphinx/installation/install_source.rst +++ b/doc/sphinx/installation/install_source.rst @@ -16,7 +16,7 @@ Getting hold of the source -------------------------- Download the appropriate release tarball, which you can find on -https://varnish-cache.org/releases/ . +https://vinyl-cache.org/releases/ . Alternatively, if you want to hack on Varnish, you should clone our git repository by doing. diff --git a/doc/sphinx/reference/vcl.rst b/doc/sphinx/reference/vcl.rst index f3f779a0de..f3f59347a6 100644 --- a/doc/sphinx/reference/vcl.rst +++ b/doc/sphinx/reference/vcl.rst @@ -52,7 +52,7 @@ To illustrate, ``e1xam_p-le`` is a valid identifier, ``1try`` and Character Sets -------------- -.. _VMODs: https://varnish-cache.org/docs/trunk/reference/vmod.html +.. _VMODs: https://vinyl-cache.org/docs/trunk/reference/vmod.html While identifiers can only consist of this subset of ASCII, **strings** can contain any bytes except *NUL* (zero, 0), which marks the end of the string. The diff --git a/doc/sphinx/reference/vmod.rst b/doc/sphinx/reference/vmod.rst index f7567509f5..ee2d7e6261 100644 --- a/doc/sphinx/reference/vmod.rst +++ b/doc/sphinx/reference/vmod.rst @@ -5,9 +5,9 @@ .. _ref-vmod: -%%%%%%%%%%%%%%%%%%%%%% -VMOD - Varnish Modules -%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%%%%%% +VMOD - Vinyl Cache Modules +%%%%%%%%%%%%%%%%%%%%%%%%%% For all you can do in VCL, there are things you cannot do. Look an IP number up in a database file for instance. @@ -26,7 +26,7 @@ For instance:: set resp.http.foo = std.toupper(req.url); } -The "std" vmod is one you get with Varnish, it will always be there +The "std" vmod is one you get with Vinyl Cache, it will always be there and we will put "boutique" functions in it, such as the "toupper" function shown above. The full contents of the "std" module is documented in vmod_std(3). @@ -34,16 +34,16 @@ documented in vmod_std(3). This part of the manual is about how you go about writing your own VMOD, how the language interface between C and VCC works, where you can find contributed VMODs etc. This explanation will use the "std" -VMOD as example, having a Varnish source tree handy may be a good +VMOD as example, having a Vinyl Cache source tree handy may be a good idea. VMOD Directory ============== The VMOD directory is an up-to-date compilation of maintained -extensions written for Varnish Cache: +extensions written for Vinyl Cache: - https://www.varnish-cache.org/vmods + https://www.vinyl-cache.org/vmods Getting started writing VMODs ============================= @@ -73,7 +73,7 @@ The std VMODs vmod.vcc file looks somewhat like this:: $ABI strict $Version my.version - $Module std 3 "Varnish Standard Module" + $Module std 3 "Vinyl Standard Module" $Event event_function $Function STRING toupper(STRANDS s) $Function STRING tolower(STRANDS s) @@ -81,11 +81,11 @@ The std VMODs vmod.vcc file looks somewhat like this:: The ``$ABI`` line is optional. Possible values are ``strict`` (default) and ``vrt``. It allows to specify that a vmod is integrating -with the blessed ``vrt`` interface provided by ``varnishd`` or go +with the blessed ``vrt`` interface provided by ``vinyld`` or go deeper in the stack. -As a rule of thumb you, if the VMOD uses more than the VRT (Varnish -RunTime), in which case it needs to be built for the exact Varnish +As a rule of thumb you, if the VMOD uses more than the VRT (Vinyl +RunTime), in which case it needs to be built for the exact Vinyl Cache version, use ``strict``. If it complies to the VRT and only needs to be rebuilt when breaking changes are introduced to the VRT API, use ``vrt``. @@ -220,7 +220,7 @@ the ``:`` syntax. See :ref:`ref-vmod-symbols` for details. Objects and methods ------------------- -Varnish also supports a simple object model for vmods. Objects and +Vinyl Cache also supports a simple object model for vmods. Objects and methods are declared in the vcc file as:: $Object class(...) @@ -249,14 +249,14 @@ meaning of such a method is up to the vmod author:: $Method .foo(...) Object instances are represented as pointers to vmod-implemented C -structs. Varnish only provides space to store the address of object +structs. Vinyl Cache only provides space to store the address of object instances and ensures that the right object address gets passed to C functions implementing methods. * Objects' scope and lifetime are the vcl * Objects can only be created in ``vcl_init {}`` and have - their destructors called by varnish after ``vcl_fini {}`` + their destructors called by Vinyl Cache after ``vcl_fini {}`` has completed. vmod authors are advised to understand the prototypes in the @@ -283,7 +283,7 @@ vmod authors are advised to understand the prototypes in the * Methods gain the pointer to the object as an argument after the ``VRT_CTX``. -As varnish is in no way involved in managing object instances other +As Vinyl Cache is in no way involved in managing object instances other than passing their addresses, vmods need to implement all aspects of managing instances, in particular their memory management. As the lifetime of object instances is the vcl, they will usually be @@ -827,11 +827,11 @@ structure like a ``PRIV_VCL`` or a VMOD object to keep track of the reference and later release it. You also have to provide a description, it will be printed to the user if they try to warm up a cooling VCL:: - $ varnishadm vcl.list + $ vinyladm vcl.list available auto/cooling 0 vcl1 active auto/warm 0 vcl2 - $ varnishadm vcl.state vcl1 warm + $ vinyladm vcl.state vcl1 warm Command failed with error code 300 Failed Message: @@ -840,13 +840,13 @@ to the user if they try to warm up a cooling VCL:: In the case where properly releasing resources may take some time, you can opt for an asynchronous worker, either by spawning a thread and tracking it, or -by using Varnish's worker pools. +by using Vinyl Cache's worker pools. When to lock, and when not to lock ================================== -Varnish is heavily multithreaded, so by default VMODs must implement +Vinyl Cache is heavily multithreaded, so by default VMODs must implement their own locking to protect shared resources. When a VCL is loaded or unloaded, the event and priv->free are @@ -865,10 +865,10 @@ Statistics Counters =================== Starting in Varnish 6.0, VMODs can define their own counters that appear -in *varnishstat*. +in *vinylstat*. If you're using autotools, see the ``VINYL_COUNTERS`` macro in -varnish.m4 for documentation on getting your build set up. +vinyl.m4 for documentation on getting your build set up. Counters are defined in a .vsc file. The ``VINYL_COUNTERS`` macro calls *vsctool.py* to turn a *foo.vsc* file into *VSC_foo.c* and @@ -908,7 +908,7 @@ ctype only be ``uint64_t`` and does not need to be specified. level - The verbosity level of this counter. *varnishstat* will only + The verbosity level of this counter. *vinylstat* will only show counters with a higher verbosity level than the one currently configured. Can be one of ``info``, ``diag``, or ``debug``. @@ -935,8 +935,8 @@ your counters. Temporary Files =============== -``varnishd`` creates a directory named ``worker_tmpdir`` under the -varnish working directory (see ``varnishd -n`` argument) for +``vinyld`` creates a directory named ``worker_tmpdir`` under the +Vinyl Cache working directory (see ``vinyld -n`` argument) for read/write access by the worker process. From the perspective of VMODs, the relative path is always @@ -946,7 +946,7 @@ This directory is intended (though not limited) to provide a place for VMODs to create temporary files using ``mkstemp()`` and related libc functions. VMODs are responsible for cleaning up files which are no longer required, and they will ultimately be removed when the -``varnishd`` worker process restarts. There is no isolation between +``vinyld`` worker process restarts. There is no isolation between VMODs (as is the case anyway). A simple example for how to use it:: @@ -1043,7 +1043,7 @@ Retrieving version information using the CLI The ``debug.vmod`` CLI command outputs the version information, for example (edited for readability, the original output is on a single line):: - $ varnishadm debug.vmod + $ vinyladm debug.vmod 1 dynamic (path=".../vmods/libvmod_dynamic.so", version="libvmod-dynamic trunk", vcs="1e4179430404aaf170530af7514fbecb1f38f8af") diff --git a/doc/sphinx/tutorial/backend_servers.rst b/doc/sphinx/tutorial/backend_servers.rst index f7b84ac173..d0880960e6 100644 --- a/doc/sphinx/tutorial/backend_servers.rst +++ b/doc/sphinx/tutorial/backend_servers.rst @@ -8,14 +8,14 @@ Backend servers --------------- -Varnish has a concept of `backend` or origin servers. A backend -server is the server providing the content Varnish will accelerate via the cache. +Vinyl Cache has a concept of `backend` or origin servers. A backend +server is the server providing the content Vinyl Cache will accelerate via the cache. -Our first task is to tell Varnish where it can find its content. Start -your favorite text editor and open the Varnish default configuration +Our first task is to tell Vinyl Cache where it can find its content. Start +your favorite text editor and open the Vinyl Cache default configuration file. If you installed from source this is -`/usr/local/etc/varnish/default.vcl`, if you installed from a package it -is probably `/etc/varnish/default.vcl`. +`/usr/local/etc/vinyl/default.vcl`, if you installed from a package it +is probably `/etc/vinyl/default.vcl`. If you've been following the tutorial there is probably a section of the configuration that looks like this:: @@ -23,16 +23,16 @@ the configuration that looks like this:: vcl 4.0; backend default { - .host = "www.varnish-cache.org"; + .host = "www.vinyl-cache.org"; .port = "80"; } -This means we set up a backend in Varnish that fetches content from -the host www.varnish-cache.org on port 80. +This means we set up a backend in Vinyl Cache that fetches content from +the host www.vinyl-cache.org on port 80. -Since you probably don't want to be mirroring varnish-cache.org we -need to get Varnish to fetch content from your own origin -server. We've already bound Varnish to the public port 80 on the +Since you probably don't want to be mirroring vinyl-cache.org we +need to get Vinyl Cache to fetch content from your own origin +server. We've already bound Vinyl Cache to the public port 80 on the server so now we need to tie it to the origin. For this example, let's pretend the origin server is running on @@ -46,10 +46,10 @@ localhost, port 8080.:: } -Varnish can have several backends defined and can even join several backends -together into clusters of backends for load balancing purposes, having Varnish +Vinyl Cache can have several backends defined and can even join several backends +together into clusters of backends for load balancing purposes, having Vinyl Cache pick one backend based on different algorithms. -Next, let's have a look at some of what makes Varnish unique and what you can do with it. +Next, let's have a look at some of what makes Vinyl Cache unique and what you can do with it. diff --git a/doc/sphinx/tutorial/introduction.rst b/doc/sphinx/tutorial/introduction.rst index 11b13f68ba..d34811d3e0 100644 --- a/doc/sphinx/tutorial/introduction.rst +++ b/doc/sphinx/tutorial/introduction.rst @@ -5,20 +5,20 @@ .. _tutorial-intro: -Varnish: The beef in the sandwich ---------------------------------- +Vinyl Cache: The beef in the sandwich +------------------------------------- You may have heard the term "web-delivery-sandwich" used in relation to -Varnish, and it is a pretty apt metafor:: +Vinyl Cache, and it is a pretty apt metafor:: ┌─────────┐ │ browser │ - └─────────┘ ┌─────────┐ - \ ┌─────────┐│ - ┌─────┐ ╔═════════╗ ┌─────┐ ┌─────────┐ ┌─────────┐│┘ - │ app │ --- ║ Network ║ -- │ TLS │ -- │ Varnish │ -- │ Backend │┘ - └─────┘ ╚═════════╝ └─────┘ └─────────┘ └─────────┘ + └─────────┘ ┌─────────┐ + \ ┌─────────┐│ + ┌─────┐ ╔═════════╗ ┌─────┐ ┌─────────────┐ ┌─────────┐│┘ + │ app │ --- ║ Network ║ -- │ TLS │ -- │ Vinyl Cache │ -- │ Backend │┘ + └─────┘ ╚═════════╝ └─────┘ └─────────────┘ └─────────┘ / ┌────────────┐ │ API-client │ @@ -32,17 +32,17 @@ The bottom layer of the sandwich are your webservers, CDNs, API-servers, business backend systems and all the other sources for your web-content. -Varnish goes in the middle, where it provides caching, policy, +Vinyl Cache goes in the middle, where it provides caching, policy, analytics, visibility and mitigation for your webtraffic. -How Varnish works ------------------ +How Vinyl Cache works +--------------------- -For each and every request, Varnish runs through the 'VCL' program +For each and every request, Vinyl Cache runs through the 'VCL' program to decide what should happen: Which backend has this content, how long time can we cache it, is it accessible for this request, should it be redirected elsewhere and so on. If that particular backend -is down, varnish can find another or substitute different content +is down, Vinyl Cache can find another or substitute different content until it comes back up. Your first VCL program will probably be trivial, for instance just @@ -56,11 +56,11 @@ splitting the traffic between two different backend servers:: } } -When you load the VCL program into Varnish, it is compiled into -a C-program which is compiled into a shared library, which varnish +When you load the VCL program into Vinyl Cache, it is compiled into +a C-program which is compiled into a shared library, which Vinyl Cache then loads and calls into, therefore VCL code is *fast*. -Everything Varnish does is recorded in 'VSL' log records which can +Everything Vinyl Cache does is recorded in 'VSL' log records which can be examined and monitored in real time or recorded for later use in native or NCSA format, and when we say 'everything' we mean *everything*:: @@ -74,7 +74,7 @@ in native or NCSA format, and when we say 'everything' we mean - ReqMethod GET - ReqURL /vmods/ - ReqProtocol HTTP/1.1 - - ReqHeader Host: varnish-cache.org + - ReqHeader Host: vinyl-cache.org - ReqHeader Accept: text/html, application/rss+xml, […] - ReqHeader Accept-Encoding: gzip,deflate - ReqHeader Connection: close @@ -87,19 +87,18 @@ in native or NCSA format, and when we say 'everything' we mean These `VSL` log records are written to a circular buffer in shared memory, from where other programs can subscribe to them via a supported -API. One such program is `varnishncsa` which produces NCSA-style log -records:: +API. One such program is `vinylncsa` which produces NCSA-style log records:: 192.0.2.24 - - [08/Feb/2021:12:42:35 +0000] "GET http://vmods/ HTTP/1.1" 200 0 […] -Varnish is also engineered for uptime, it is not necessary to restart -varnish to change the VCL program, in fact, multiple VCL programs can be +Vinyl Cache is also engineered for uptime, it is not necessary to restart +Vinyl Cache to change the VCL program, in fact, multiple VCL programs can be loaded at the same time and you can switch between them instantly. -Caching with Varnish --------------------- +Caching with Vinyl Cache +------------------------ -When Varnish receives a request, VCL can decide to look for a +When Vinyl Cache receives a request, VCL can decide to look for a reusable answer in the cache, if there is one, that becomes one less request to put load on your backend applications database. Cache-hits take less than a millisecond, often mere microseconds, @@ -109,37 +108,37 @@ If there is nothing usable in the cache, the answer from the backend can, again under VCL control, be put in the cache for some amount of time, so future requests for the same object can find it there. -Varnish understands the `Cache-Control` HTTP header if your backend +Vinyl Cache understands the `Cache-Control` HTTP header if your backend server sends one, but ultimately the VCL program makes the decision to cache and how long, and if you want to send a different `Cache-Control` header to the clients, VCL can do that too. -Content Composition with Varnish --------------------------------- +Content Composition with Vinyl Cache +------------------------------------ -Varnish supports `ESI - Edge Side Includes` which makes it possible +Vinyl Cache supports `ESI - Edge Side Includes` which makes it possible to send responses to clients which are composed of different bits from different backends, with the very important footnote that the different bits can have very different caching policies. -With ESI a backend can tell varnish to edit the content of another +With ESI a backend can tell Vinyl Cache to edit the content of another object into a HTML page::

Todays Top News

The `/topnews` request will be handled like every other request in -Varnish, VCL will decide if it can be cached, which backend should +Vinyl Cache, VCL will decide if it can be cached, which backend should supply it and so on, so even if the whole object in the example can not be cached, for instance if the page is dynamic content for a logged-in user, the `/topnews` object can be cached and can be shared from the cache, between all users. -Content Policy with Varnish ---------------------------- +Content Policy with Vinyl Cache +------------------------------- Because VCL is in full control of every request, and because VCL -can be changed instantly on the fly, Varnish is a great tool to +can be changed instantly on the fly, Vinyl Cache is a great tool to implement both reactive and prescriptive content-policies. Prescriptive content-policies can be everything from complying @@ -148,7 +147,7 @@ native language content to different clients to closing access to employee web-mail in compliance with "Right to disconnect" laws. -Varnish, and VCL is particular, are well suited to sort requests +Vinyl Cache, and VCL is particular, are well suited to sort requests and collect metrics for real-time A/B testing or during migrations to a new backend system. @@ -157,16 +156,16 @@ an infected backend or fixing the URL from the QR code on the new product, to extending caching times while the backend rebuilds the database. -Varnish is general purpose --------------------------- +Vinyl Cache is general purpose +------------------------------ -Varnish is written to run on modern UNIX-like operating systems: +Vinyl Cache is written to run on modern UNIX-like operating systems: Linux, FreeBSD, OS/X, OpenBSD, NetBSD, Solaris, OmniOs, SmartOS etc. -Varnish runs on any CPU architecture: i386, amd64, arm32, arm64, +Vinyl Cache runs on any CPU architecture: i386, amd64, arm32, arm64, mips, power, riscV, s390 - you name it. -Varnish can be deployed on dedicated hardware, in VMs, jails, +Vinyl Cache can be deployed on dedicated hardware, in VMs, jails, Containers, Cloud, as a service or any other way you may care for. Unfortunately the `sudo make me a sandwich`_ feature is not ready yet, diff --git a/doc/sphinx/tutorial/starting_varnish.rst b/doc/sphinx/tutorial/starting_varnish.rst index 9aa5aeb86f..4f490b6300 100644 --- a/doc/sphinx/tutorial/starting_varnish.rst +++ b/doc/sphinx/tutorial/starting_varnish.rst @@ -3,35 +3,35 @@ SPDX-License-Identifier: BSD-2-Clause See LICENSE file for full text of license -.. _tutorial-starting_varnish: +.. _tutorial-starting_vinyl: -Starting Varnish ----------------- +Starting Vinyl Cache +-------------------- -This tutorial will assume that you are running Varnish on Ubuntu, Debian, +This tutorial will assume that you are running Vinyl Cache on Ubuntu, Debian, Red Hat Enterprise Linux or CentOS. Those of you running on other platforms might have to do some mental translation exercises in order to follow this. Since you're on a "weird" platform you're probably used to it. :-) -Make sure you have Varnish successfully installed (following one of the -procedures described in "Installing Varnish" above. +Make sure you have Vinyl Cache successfully installed (following one of the +procedures described in "Installing Vinyl Cache" above. -When properly installed you start Varnish with ``service varnish start``. This -will start Varnish if it isn't already running. +When properly installed you start Vinyl Cache with ``service vinyl start``. This +will start Vinyl Cache if it isn't already running. .. XXX:What does it do if it is already running? benc -Now you have Varnish running. Let us make sure that it works +Now you have Vinyl Cache running. Let us make sure that it works properly. Use your browser to go to http://127.0.0.1:6081/ (Replace the IP -address with the IP for the machine that runs Varnish) The default +address with the IP for the machine that runs Vinyl Cache) The default configuration will try to forward requests to a web application running on the -same machine as Varnish was installed on. Varnish expects the web application +same machine as Vinyl Cache was installed on. Vinyl Cache expects the web application to be exposed over http on port 8080. -If there is no web application being served up on that location Varnish will -issue an error. Varnish Cache is very conservative about telling the +If there is no web application being served up on that location Vinyl Cache will +issue an error. Vinyl Cache is very conservative about telling the world what is wrong so whenever something is amiss it will issue the same generic "Error 503 Service Unavailable". @@ -39,7 +39,7 @@ You might have a web application running on some other port or some other machine. Let's edit the configuration and make it point to something that actually works. -Fire up your favorite editor and edit `/etc/varnish/default.vcl`. Most +Fire up your favorite editor and edit `/etc/vinyl/default.vcl`. Most of it is commented out but there is some text that is not. It will probably look like this:: @@ -51,20 +51,20 @@ probably look like this:: } We'll change it and make it point to something that works. Hopefully -http://www.varnish-cache.org/ is up. Let's use that. Replace the text with:: +http://www.vinyl-cache.org/ is up. Let's use that. Replace the text with:: vcl 4.0; backend default { - .host = "www.varnish-cache.org"; + .host = "www.vinyl-cache.org"; .port = "80"; } -Now issue ``service varnish reload`` to make Varnish reload it's +Now issue ``service vinyl reload`` to make Vinyl Cache reload it's configuration. If that succeeded visit http://127.0.0.1:6081/ in your browser and you should see some directory listing. It works! The -reason you're not seeing the Varnish official website is because your +reason you're not seeing the Vinyl Cache official website is because your client isn't sending the appropriate `Host` header in the request and it ends up showing a listing of the default webfolder on the machine -usually serving up http://www.varnish-cache.org/ . +usually serving up http://www.vinyl-cache.org/ . diff --git a/doc/sphinx/whats-new/changes-6.6.rst b/doc/sphinx/whats-new/changes-6.6.rst index d5acf47780..3275f99418 100644 --- a/doc/sphinx/whats-new/changes-6.6.rst +++ b/doc/sphinx/whats-new/changes-6.6.rst @@ -368,7 +368,7 @@ VMOD/VCL interface See `VMOD - Varnish Modules`_ in the Reference Manual. -.. _VMOD - Varnish Modules: https://varnish-cache.org/docs/trunk/reference/vmod.html +.. _VMOD - Varnish Modules: https://vinyl-cache.org/docs/trunk/reference/vmod.html VMOD functions can also return the ``VCL_SUB`` data type for calls from VCL as in ``call vmod.returning_sub();``. diff --git a/etc/example.vcl b/etc/example.vcl index a48247a93e..7c317fdb8b 100644 --- a/etc/example.vcl +++ b/etc/example.vcl @@ -1,12 +1,12 @@ # -# This is an example VCL file for Varnish. +# This is an example VCL file for Vinyl Cache # # It does not do anything by default, delegating control to the # builtin VCL. The builtin VCL is called when there is no explicit # return statement. # # See the VCL chapters in the Users Guide for a comprehensive documentation -# at https://www.varnish-cache.org/docs/. +# at https://www.vinyl-cache.org/docs/. # Marker to tell the VCL compiler that this VCL has been written with the # 4.0 or 4.1 syntax. From 252168e8bfa7f14d7a5f50ffb7b76cec3cd8e364 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 17:24:43 +0000 Subject: [PATCH 102/196] Another round of s/varnish/vinyl/ over the docs --- doc/README.WRITING_RST.rst | 2 +- doc/changes.rst | 6 +-- doc/sphinx/installation/bugs.rst | 8 ++-- doc/sphinx/phk/backends.rst | 2 +- doc/sphinx/reference/cli_protocol.rst | 4 +- doc/sphinx/reference/index.rst | 42 +++++++++---------- doc/sphinx/reference/vcl-backend.rst | 8 ++-- doc/sphinx/reference/vcl-probe.rst | 2 +- doc/sphinx/reference/vcl-step.rst | 2 +- doc/sphinx/reference/vcl-var.rst | 2 +- doc/sphinx/reference/vcl.rst | 2 +- doc/sphinx/reference/vcl_var.rst | 22 +++++----- .../{varnish-cli.rst => vinyl-cli.rst} | 10 ++--- ...arnish-counters.rst => vinyl-counters.rst} | 0 .../{varnishadm.rst => vinyladm.rst} | 10 ++--- .../reference/{varnishd.rst => vinyld.rst} | 16 +++---- .../{varnishhist.rst => vinylhist.rst} | 14 +++---- .../{varnishlog.rst => vinyllog.rst} | 12 +++--- .../{varnishncsa.rst => vinylncsa.rst} | 10 ++--- .../{varnishstat.rst => vinylstat.rst} | 14 +++---- .../{varnishtest.rst => vinyltest.rst} | 12 +++--- .../{varnishtop.rst => vinyltop.rst} | 14 +++---- doc/sphinx/reference/vsl.rst | 10 ++--- doc/sphinx/reference/vtc.rst | 2 +- doc/sphinx/tutorial/peculiarities.rst | 4 +- doc/sphinx/users-guide/command-line.rst | 4 +- doc/sphinx/users-guide/compression.rst | 2 +- .../users-guide/increasing-your-hitrate.rst | 10 ++--- doc/sphinx/users-guide/operation-logging.rst | 2 +- .../users-guide/operation-statistics.rst | 8 ++-- doc/sphinx/users-guide/run_security.rst | 34 +++++++-------- doc/sphinx/users-guide/sizing-your-cache.rst | 2 +- doc/sphinx/users-guide/troubleshooting.rst | 14 +++---- doc/sphinx/whats-new/changes-6.0.rst | 2 +- doc/sphinx/whats-new/changes-6.2.rst | 18 ++++---- doc/sphinx/whats-new/changes-6.3.rst | 10 ++--- doc/sphinx/whats-new/changes-7.5.rst | 2 +- doc/sphinx/whats-new/upgrading-5.0.rst | 2 +- doc/sphinx/whats-new/upgrading-5.1.rst | 12 +++--- doc/sphinx/whats-new/upgrading-5.2.rst | 24 +++++------ doc/sphinx/whats-new/upgrading-6.0.rst | 12 +++--- doc/sphinx/whats-new/upgrading-6.1.rst | 18 ++++---- doc/sphinx/whats-new/upgrading-6.2.rst | 2 +- include/vut_options.h | 2 +- man/Makefile.am | 40 +++++++++--------- vmod/vmod_blob.vcc | 2 +- vmod/vmod_h2.vcc | 8 ++-- vmod/vmod_proxy.vcc | 2 +- vmod/vmod_std.vcc | 2 +- vmod/vmod_unix.vcc | 2 +- 50 files changed, 233 insertions(+), 233 deletions(-) rename doc/sphinx/reference/{varnish-cli.rst => vinyl-cli.rst} (97%) rename doc/sphinx/reference/{varnish-counters.rst => vinyl-counters.rst} (100%) rename doc/sphinx/reference/{varnishadm.rst => vinyladm.rst} (93%) rename doc/sphinx/reference/{varnishd.rst => vinyld.rst} (98%) rename doc/sphinx/reference/{varnishhist.rst => vinylhist.rst} (86%) rename doc/sphinx/reference/{varnishlog.rst => vinyllog.rst} (89%) rename doc/sphinx/reference/{varnishncsa.rst => vinylncsa.rst} (98%) rename doc/sphinx/reference/{varnishstat.rst => vinylstat.rst} (92%) rename doc/sphinx/reference/{varnishtest.rst => vinyltest.rst} (97%) rename doc/sphinx/reference/{varnishtop.rst => vinyltop.rst} (88%) diff --git a/doc/README.WRITING_RST.rst b/doc/README.WRITING_RST.rst index d35928cb42..d876285525 100644 --- a/doc/README.WRITING_RST.rst +++ b/doc/README.WRITING_RST.rst @@ -44,7 +44,7 @@ of documentation: * set link targets on the top of documents ending up in man-pages following the manpage naming scheme, e.g.:: - .. _varnishd(1): + .. _vinyld(1): * set link targets for important paragraphs following the scheme ref-`doc`-`section`, for instance:: diff --git a/doc/changes.rst b/doc/changes.rst index fd4fc6cf6b..b001bd7195 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -868,13 +868,13 @@ Varnish Cache 7.5.0 (2024-03-18) quoted arguments like ``"help"`` were rejected. * The ``vcl_req_reset`` feature (controllable through the ``feature`` - parameter, see `varnishd(1)`) has been added and enabled by default + parameter, see `vinyld(1)`) has been added and enabled by default to terminate client side VCL processing early when the client is gone. *req_reset* events trigger a VCL failure and are reported to `vsl(7)` as ``Timestamp: Reset`` and accounted to ``main.req_reset`` - in `vsc` as visible through ``varnishstat(1)``. + in `vsc` as visible through ``vinylstat(1)``. In particular, this feature is used to reduce resource consumption of HTTP/2 "rapid reset" attacks (see below). @@ -915,7 +915,7 @@ Varnish Cache 7.5.0 (2024-03-18) * Sessions closed due to rapid reset rate limiting are reported as ``SessClose RAPID_RESET`` in `vsl(7)` and accounted to ``main.sc_rapid_reset`` in `vsc` as visible through - ``varnishstat(1)``. + ``vinylstat(1)``. * The ``cli_limit`` parameter default has been increased from 48KB to 64KB. diff --git a/doc/sphinx/installation/bugs.rst b/doc/sphinx/installation/bugs.rst index e8de358aac..4930c96361 100644 --- a/doc/sphinx/installation/bugs.rst +++ b/doc/sphinx/installation/bugs.rst @@ -97,7 +97,7 @@ general forms: .. (TODO: in the ws-size note above, mention which params to tweak) In your syslog it may all be joined into one single line, but if you -can reproduce the crash, do so while running :ref:`varnishd(1)` manually: +can reproduce the crash, do so while running :ref:`vinyld(1)` manually: ``varnishd -d |& tee /tmp/_catch_bug`` @@ -132,8 +132,8 @@ If one or more threads are spinning, use ``strace`` or ``ktrace`` or ``truss`` the Varnish process issues. Be aware that this may generate a lot of very repetitive data, usually one second worth of data is more than enough. -Also, run :ref:`varnishlog(1)` for a second, and collect the output -for us, and if :ref:`varnishstat(1)` shows any activity, capture that +Also, run :ref:`vinyllog(1)` for a second, and collect the output +for us, and if :ref:`vinylstat(1)` shows any activity, capture that also. When you have done this, kill the Varnish *child* process, and let @@ -147,7 +147,7 @@ Varnish does something wrong ============================ These are the easy bugs: usually all we need from you is the relevant -transactions recorded with :ref:`varnishlog(1)` and your explanation +transactions recorded with :ref:`vinyllog(1)` and your explanation of what is wrong about what Varnish does. Be aware, that often Varnish does exactly what you asked it to, rather diff --git a/doc/sphinx/phk/backends.rst b/doc/sphinx/phk/backends.rst index 049e82577d..cbef4d30f9 100644 --- a/doc/sphinx/phk/backends.rst +++ b/doc/sphinx/phk/backends.rst @@ -92,7 +92,7 @@ is a wildcard-ish scheme, where you can write things like:: (Input very much welcome) The final question is if we use shortcut notation for output from -:ref:`varnishd(1)`, and the answer is no, because we do not want the +:ref:`vinyld(1)`, and the answer is no, because we do not want the stats-counters to change name because we load another VCL and suddenly need disambiguation. diff --git a/doc/sphinx/reference/cli_protocol.rst b/doc/sphinx/reference/cli_protocol.rst index a99cb20e93..4fa9e2671c 100644 --- a/doc/sphinx/reference/cli_protocol.rst +++ b/doc/sphinx/reference/cli_protocol.rst @@ -166,6 +166,6 @@ secret file, and the challenge string. See also: --------- -* :ref:`varnishadm(1)` -* :ref:`varnishd(1)` +* :ref:`vinyladm(1)` +* :ref:`vinyld(1)` * :ref:`vcl(7)` diff --git a/doc/sphinx/reference/index.rst b/doc/sphinx/reference/index.rst index 59120b0c3e..8e02152619 100644 --- a/doc/sphinx/reference/index.rst +++ b/doc/sphinx/reference/index.rst @@ -5,9 +5,9 @@ .. _reference-index: -%%%%%%%%%%%%%%%%%%%%%%%%%%%% -The Varnish Reference Manual -%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +The Vinyl Cache Reference Manual +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% .. _reference-vcl: @@ -17,7 +17,7 @@ The VCL language .. toctree:: :maxdepth: 1 - VCL - The Varnish Configuration Language + VCL - The Vinyl Configuration Language VCL Variables VCL Steps VCL backend configuration @@ -49,8 +49,8 @@ The CLI interface .. toctree:: :maxdepth: 1 - VarnishAdm - Control program for Varnish - CLI - The commands varnish understands + VinylAdm - Control program for Vinyl Cache + CLI - The commands Vinyl Cache understands Logging and monitoring ---------------------- @@ -58,12 +58,12 @@ Logging and monitoring .. toctree:: :maxdepth: 1 - VSL - The log records Varnish generates + VSL - The log records Vinyl Cache generates VSLQ - Filter/Query expressions for VSL - VarnishLog - Logging raw VSL - VarnishNCSA - Logging in NCSA format - VarnishHist - Realtime response histogram display - VarnishTop - Realtime activity display + VinylLog - Logging raw VSL + VinylNCSA - Logging in NCSA format + VinylHist - Realtime response histogram display + VinylTop - Realtime activity display Counters and statistics ----------------------- @@ -71,25 +71,25 @@ Counters and statistics .. toctree:: :maxdepth: 1 - VSC - The statistics Varnish collects - VarnishStat - Watching and logging statistics + VSC - The statistics Vinyl Cache collects + VinylStat - Watching and logging statistics -The Varnishd program --------------------- +The Vinyld program +------------------ .. toctree:: :maxdepth: 1 - VarnishD - The program which does the actual work + VinylD - The program which does the actual work -Varnishtest ------------ +Vinyltest +--------- .. toctree:: :maxdepth: 1 VTC - Language for writing test cases - VarnishTest - execute test cases + VinylTest - execute test cases vmod_vtc.rst For Developers & DevOps @@ -100,14 +100,14 @@ For Developers & DevOps Shell tricks VMODS - Extensions to VCL - VEXT - Varnish Extensions + VEXT - Vinyl Cache Extensions VSM - Shared memory use VDIR - Backends & Directors VCLI - CLI protocol API .. Vmod_debug ? -.. Libvarnishapi +.. Libvinylapi .. VRT diff --git a/doc/sphinx/reference/vcl-backend.rst b/doc/sphinx/reference/vcl-backend.rst index 6729df72bd..adb5b623b2 100644 --- a/doc/sphinx/reference/vcl-backend.rst +++ b/doc/sphinx/reference/vcl-backend.rst @@ -104,7 +104,7 @@ These attributes control how patient `varnishd` is during backend fetches:: .first_byte_timeout = 20s; .between_bytes_timeout = 10s; -The default values comes parameters with the same names, see :ref:`varnishd(1)`. +The default values comes parameters with the same names, see :ref:`vinyld(1)`. Attribute ``.max_connections`` ------------------------------ @@ -123,7 +123,7 @@ Maximum number of transactions that can queue waiting for a backend connectio Note that this feature must be used with caution, as it can cause threads to pile up and increase response times. -Defaults to the :ref:`varnishd(1)` `backend_wait_limit` parameter. +Defaults to the :ref:`vinyld(1)` `backend_wait_limit` parameter. Attribute ``.wait_timeout`` ------------------------------ @@ -135,7 +135,7 @@ this is the time that the transaction will wait before giving up:: It is strongly advised to never set this higher than a couple of seconds. -Defaults to the :ref:`varnishd(1)` `backend_wait_timeout` parameter. +Defaults to the :ref:`vinyld(1)` `backend_wait_timeout` parameter. Attribute ``.proxy_header`` --------------------------- @@ -236,7 +236,7 @@ Please see :ref:`vcl-probe(7)`. SEE ALSO -------- -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`vcl(7)` * :ref:`vcl-probe(7)` * :ref:`vmod_directors(3)` diff --git a/doc/sphinx/reference/vcl-probe.rst b/doc/sphinx/reference/vcl-probe.rst index 858affe968..2c35b269a4 100644 --- a/doc/sphinx/reference/vcl-probe.rst +++ b/doc/sphinx/reference/vcl-probe.rst @@ -182,7 +182,7 @@ likely still be unhealthy when the backend request happens. SEE ALSO ======== -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`vcl(7)` * :ref:`vcl-backend(7)` * :ref:`vmod_directors(3)` diff --git a/doc/sphinx/reference/vcl-step.rst b/doc/sphinx/reference/vcl-step.rst index 683f48420a..3945bfd4d9 100644 --- a/doc/sphinx/reference/vcl-step.rst +++ b/doc/sphinx/reference/vcl-step.rst @@ -139,7 +139,7 @@ Common actions for the backend side SEE ALSO ======== -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`vcl(7)` COPYRIGHT diff --git a/doc/sphinx/reference/vcl-var.rst b/doc/sphinx/reference/vcl-var.rst index 4d38f523f6..40f06adf97 100644 --- a/doc/sphinx/reference/vcl-var.rst +++ b/doc/sphinx/reference/vcl-var.rst @@ -162,7 +162,7 @@ set to that value if non-negative or 0 otherwise. SEE ALSO ======== -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`vcl(7)` HISTORY diff --git a/doc/sphinx/reference/vcl.rst b/doc/sphinx/reference/vcl.rst index f3f59347a6..60852210ca 100644 --- a/doc/sphinx/reference/vcl.rst +++ b/doc/sphinx/reference/vcl.rst @@ -567,7 +567,7 @@ For examples, please see the online documentation. SEE ALSO ======== -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`vcl-backend(7)` * :ref:`vcl-probe(7)` * :ref:`vcl-step(7)` diff --git a/doc/sphinx/reference/vcl_var.rst b/doc/sphinx/reference/vcl_var.rst index 1c0d8e9ef9..e3766688b6 100644 --- a/doc/sphinx/reference/vcl_var.rst +++ b/doc/sphinx/reference/vcl_var.rst @@ -515,7 +515,7 @@ req.trace request, see :ref:`vsl(7)`. Defaults to the setting of the ``feature trace`` parameter, - see :ref:`varnishd(1)`. Does not get reset by a rollback. + see :ref:`vinyld(1)`. Does not get reset by a rollback. .. _req.transport: @@ -705,7 +705,7 @@ bereq.between_bytes_timeout Default: ``.between_bytes_timeout`` attribute from the :ref:`backend_definition`, which defaults to the - ``between_bytes_timeout`` parameter, see :ref:`varnishd(1)`. + ``between_bytes_timeout`` parameter, see :ref:`vinyld(1)`. The time in seconds to wait between each received byte from the backend. Not available in pipe mode. @@ -737,7 +737,7 @@ bereq.connect_timeout Default: ``.connect_timeout`` attribute from the :ref:`backend_definition`, which defaults to the - ``connect_timeout`` parameter, see :ref:`varnishd(1)`. + ``connect_timeout`` parameter, see :ref:`vinyld(1)`. The time in seconds to wait for a backend connection to be established. @@ -771,7 +771,7 @@ bereq.first_byte_timeout Default: ``.first_byte_timeout`` attribute from the :ref:`backend_definition`, which defaults to the - ``first_byte_timeout`` parameter, see :ref:`varnishd(1)`. + ``first_byte_timeout`` parameter, see :ref:`vinyld(1)`. The time in seconds to wait getting the first byte back from the backend. Not available in pipe mode. @@ -943,7 +943,7 @@ bereq.task_deadline Unsettable from: vcl_pipe Deadline for pipe sessions, defaults ``0s``, which falls back to the - ``pipe_task_deadline`` parameter, see :ref:`varnishd(1)` + ``pipe_task_deadline`` parameter, see :ref:`vinyld(1)` .. _bereq.time: @@ -1409,12 +1409,12 @@ beresp.transit_buffer Writable from: vcl_backend_response - Default: ``transit_buffer`` parameter, see :ref:`varnishd(1)`. + Default: ``transit_buffer`` parameter, see :ref:`vinyld(1)`. The maximum number of bytes the client can be ahead of the backend during a streaming pass if ``beresp`` is uncacheable. See also ``transit_buffer`` parameter - documentation in :ref:`varnishd(1)`. + documentation in :ref:`vinyld(1)`. .. _beresp.ttl: @@ -2048,7 +2048,7 @@ sess.idle_send_timeout Send timeout for individual pieces of data on client connections, defaults to the ``idle_send_timeout`` parameter, - see :ref:`varnishd(1)` + see :ref:`vinyld(1)` .. _sess.send_timeout: @@ -2064,7 +2064,7 @@ sess.send_timeout Unsettable from: client Total timeout for ordinary HTTP1 responses, defaults to the - ``send_timeout`` parameter, see :ref:`varnishd(1)` + ``send_timeout`` parameter, see :ref:`vinyld(1)` .. _sess.timeout_idle: @@ -2080,7 +2080,7 @@ sess.timeout_idle Unsettable from: client Idle timeout for this session, defaults to the - ``timeout_idle`` parameter, see :ref:`varnishd(1)` + ``timeout_idle`` parameter, see :ref:`vinyld(1)` .. _sess.timeout_linger: @@ -2096,7 +2096,7 @@ sess.timeout_linger Unsettable from: client Linger timeout for this session, defaults to the - ``timeout_linger`` parameter, see :ref:`varnishd(1)` + ``timeout_linger`` parameter, see :ref:`vinyld(1)` .. _sess.xid: diff --git a/doc/sphinx/reference/varnish-cli.rst b/doc/sphinx/reference/vinyl-cli.rst similarity index 97% rename from doc/sphinx/reference/varnish-cli.rst rename to doc/sphinx/reference/vinyl-cli.rst index 2cb1a9f3ba..fdd31784c1 100644 --- a/doc/sphinx/reference/varnish-cli.rst +++ b/doc/sphinx/reference/vinyl-cli.rst @@ -32,7 +32,7 @@ configuration parameters You can inspect and change the various parameters Varnish has available through the CLI. The individual parameters are - documented in the varnishd(1) man page. + documented in the vinyld(1) man page. bans Bans are filters that are applied to keep Varnish from serving @@ -45,11 +45,11 @@ process management CLI. You can also retrieve the latest stack trace if the child process has crashed. -If you invoke varnishd(1) with -T, -M or -d the CLI will be +If you invoke vinyld(1) with -T, -M or -d the CLI will be available. In debug mode (-d) the CLI will be in the foreground, with -T you can connect to it with varnishadm or telnet and with -M varnishd will connect back to a listening service *pushing* the CLI to -that service. Please see :ref:`varnishd(1)` for details. +that service. Please see :ref:`vinyld(1)` for details. .. _ref_syntax: @@ -356,7 +356,7 @@ Poul-Henning Kamp. SEE ALSO ======== -* :ref:`varnishadm(1)` -* :ref:`varnishd(1)` +* :ref:`vinyladm(1)` +* :ref:`vinyld(1)` * :ref:`vcl(7)` * For API use of the CLI: The Reference Manual. diff --git a/doc/sphinx/reference/varnish-counters.rst b/doc/sphinx/reference/vinyl-counters.rst similarity index 100% rename from doc/sphinx/reference/varnish-counters.rst rename to doc/sphinx/reference/vinyl-counters.rst diff --git a/doc/sphinx/reference/varnishadm.rst b/doc/sphinx/reference/vinyladm.rst similarity index 93% rename from doc/sphinx/reference/varnishadm.rst rename to doc/sphinx/reference/vinyladm.rst index 9d4aee9078..ac1d6d028b 100644 --- a/doc/sphinx/reference/varnishadm.rst +++ b/doc/sphinx/reference/vinyladm.rst @@ -5,7 +5,7 @@ .. role:: ref(emphasis) -.. _varnishadm(1): +.. _vinyladm(1): ========== varnishadm @@ -29,7 +29,7 @@ The `varnishadm` utility establishes a CLI connection to varnishd either using -n *workdir* or using the -T and -S arguments. If -n *workdir* is given, the location of the secret file and the address:port are looked up in shared memory. If neither is given, `varnishadm` uses the -n -defaults documented for :ref:`varnishd(1)`. +defaults documented for :ref:`vinyld(1)`. If a command is given, the command and arguments are sent over the CLI connection and the result returned on stdout. @@ -46,7 +46,7 @@ OPTIONS -n workdir Specify the varnish working directory of the instance to attach - to. See :ref:`varnishd(1)` ``-n`` option documentation for + to. See :ref:`vinyld(1)` ``-n`` option documentation for additional information and defaults. -p @@ -68,7 +68,7 @@ OPTIONS The syntax and operation of the actual CLI interface is described in the :ref:`varnish-cli(7)` manual page. Parameters are described in -:ref:`varnishd(1)` manual page. +:ref:`vinyld(1)` manual page. Additionally, a summary of commands can be obtained by issuing the *help* command, and a summary of parameters can be obtained by issuing @@ -92,7 +92,7 @@ Some ways you can use varnishadm:: SEE ALSO ======== -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`varnish-cli(7)` AUTHORS diff --git a/doc/sphinx/reference/varnishd.rst b/doc/sphinx/reference/vinyld.rst similarity index 98% rename from doc/sphinx/reference/varnishd.rst rename to doc/sphinx/reference/vinyld.rst index bc4ec89c6f..5be01f937f 100644 --- a/doc/sphinx/reference/varnishd.rst +++ b/doc/sphinx/reference/vinyld.rst @@ -5,7 +5,7 @@ .. role:: ref(emphasis) -.. _varnishd(1): +.. _vinyld(1): ======== varnishd @@ -540,7 +540,7 @@ Management Interface If the -T option was specified, `varnishd` will offer a command-line management interface on the specified address and port. The recommended way of connecting to the command-line management interface -is through :ref:`varnishadm(1)`. +is through :ref:`vinyladm(1)`. The commands available are documented in :ref:`varnish-cli(7)`. @@ -580,7 +580,7 @@ RUN TIME PARAMETERS =================== Runtime parameters can either be set during startup with the ``-p`` command -line option for ``varnishd(1)`` or through the CLI using the ``param.set`` or +line option for ``vinyld(1)`` or through the CLI using the ``param.set`` or ``param.reset`` commands. They can be locked during startup with the ``-r`` command line option. @@ -714,11 +714,11 @@ The `varnishd` master process may also OR its exit code SEE ALSO ======== -* :ref:`varnishlog(1)` -* :ref:`varnishhist(1)` -* :ref:`varnishncsa(1)` -* :ref:`varnishstat(1)` -* :ref:`varnishtop(1)` +* :ref:`vinyllog(1)` +* :ref:`vinylhist(1)` +* :ref:`vinylncsa(1)` +* :ref:`vinylstat(1)` +* :ref:`vinyltop(1)` * :ref:`varnish-cli(7)` * :ref:`vcl(7)` diff --git a/doc/sphinx/reference/varnishhist.rst b/doc/sphinx/reference/vinylhist.rst similarity index 86% rename from doc/sphinx/reference/varnishhist.rst rename to doc/sphinx/reference/vinylhist.rst index e65e8312cb..833349e4e2 100644 --- a/doc/sphinx/reference/varnishhist.rst +++ b/doc/sphinx/reference/vinylhist.rst @@ -5,7 +5,7 @@ .. role:: ref(emphasis) -.. _varnishhist(1): +.. _vinylhist(1): =========== varnishhist @@ -26,7 +26,7 @@ varnishhist |synopsis| DESCRIPTION =========== -The varnishhist utility reads varnishd(1) shared memory logs and +The varnishhist utility reads vinyld(1) shared memory logs and presents a continuously updated histogram showing the distribution of the last N requests by their processing. The value of N and the vertical scale are displayed in the top left corner. The horizontal @@ -40,11 +40,11 @@ The following options are available: SEE ALSO ======== -* :ref:`varnishd(1)` -* :ref:`varnishlog(1)` -* :ref:`varnishncsa(1)` -* :ref:`varnishstat(1)` -* :ref:`varnishtop(1)` +* :ref:`vinyld(1)` +* :ref:`vinyllog(1)` +* :ref:`vinylncsa(1)` +* :ref:`vinylstat(1)` +* :ref:`vinyltop(1)` * :ref:`vsl(7)` HISTORY diff --git a/doc/sphinx/reference/varnishlog.rst b/doc/sphinx/reference/vinyllog.rst similarity index 89% rename from doc/sphinx/reference/varnishlog.rst rename to doc/sphinx/reference/vinyllog.rst index c0a595b3d2..bcbb4ea236 100644 --- a/doc/sphinx/reference/varnishlog.rst +++ b/doc/sphinx/reference/vinyllog.rst @@ -5,7 +5,7 @@ .. role:: ref(emphasis) -.. _varnishlog(1): +.. _vinyllog(1): ========== varnishlog @@ -44,11 +44,11 @@ SIGNALS SEE ALSO ======== -* :ref:`varnishd(1)` -* :ref:`varnishhist(1)` -* :ref:`varnishncsa(1)` -* :ref:`varnishstat(1)` -* :ref:`varnishtop(1)` +* :ref:`vinyld(1)` +* :ref:`vinylhist(1)` +* :ref:`vinylncsa(1)` +* :ref:`vinylstat(1)` +* :ref:`vinyltop(1)` * :ref:`vsl(7)` * :ref:`vsl-query(7)` diff --git a/doc/sphinx/reference/varnishncsa.rst b/doc/sphinx/reference/vinylncsa.rst similarity index 98% rename from doc/sphinx/reference/varnishncsa.rst rename to doc/sphinx/reference/vinylncsa.rst index 1103f7ff9e..ca702a7773 100644 --- a/doc/sphinx/reference/varnishncsa.rst +++ b/doc/sphinx/reference/vinylncsa.rst @@ -5,7 +5,7 @@ .. role:: ref(emphasis) -.. _varnishncsa(1): +.. _vinylncsa(1): =========== varnishncsa @@ -26,7 +26,7 @@ varnishncsa |synopsis| DESCRIPTION =========== -The varnishncsa utility reads varnishd(1) shared memory logs and +The varnishncsa utility reads vinyld(1) shared memory logs and presents them in the Apache / NCSA "combined" log format. Each log line produced is based on a single Request type transaction @@ -296,9 +296,9 @@ times in VCL: SEE ALSO ======== -:ref:`varnishd(1)` -:ref:`varnishlog(1)` -:ref:`varnishstat(1)` +:ref:`vinyld(1)` +:ref:`vinyllog(1)` +:ref:`vinylstat(1)` :ref:`vsl-query(7)` :ref:`vsl(7)` diff --git a/doc/sphinx/reference/varnishstat.rst b/doc/sphinx/reference/vinylstat.rst similarity index 92% rename from doc/sphinx/reference/varnishstat.rst rename to doc/sphinx/reference/vinylstat.rst index fa2cdedb6c..258a9e2adb 100644 --- a/doc/sphinx/reference/varnishstat.rst +++ b/doc/sphinx/reference/vinylstat.rst @@ -5,7 +5,7 @@ .. role:: ref(emphasis) -.. _varnishstat(1): +.. _vinylstat(1): =========== varnishstat @@ -26,7 +26,7 @@ varnishstat |synopsis| DESCRIPTION =========== -The varnishstat utility displays statistics from a running varnishd(1) instance. +The varnishstat utility displays statistics from a running vinyld(1) instance. The following options are available: @@ -120,11 +120,11 @@ Timestamp is the time when the report was generated by varnishstat. SEE ALSO ======== -* :ref:`varnishd(1)` -* :ref:`varnishhist(1)` -* :ref:`varnishlog(1)` -* :ref:`varnishncsa(1)` -* :ref:`varnishtop(1)` +* :ref:`vinyld(1)` +* :ref:`vinylhist(1)` +* :ref:`vinyllog(1)` +* :ref:`vinylncsa(1)` +* :ref:`vinyltop(1)` * curses(3) * :ref:`varnish-counters(7)` diff --git a/doc/sphinx/reference/varnishtest.rst b/doc/sphinx/reference/vinyltest.rst similarity index 97% rename from doc/sphinx/reference/varnishtest.rst rename to doc/sphinx/reference/vinyltest.rst index d7c9d79fe1..5a1235870e 100644 --- a/doc/sphinx/reference/varnishtest.rst +++ b/doc/sphinx/reference/vinyltest.rst @@ -5,7 +5,7 @@ .. role:: ref(emphasis) -.. _varnishtest(1): +.. _vinyltest(1): =========== varnishtest @@ -180,11 +180,11 @@ SEE ALSO ======== * varnishtest source code repository with tests -* :ref:`varnishhist(1)` -* :ref:`varnishlog(1)` -* :ref:`varnishncsa(1)` -* :ref:`varnishstat(1)` -* :ref:`varnishtop(1)` +* :ref:`vinylhist(1)` +* :ref:`vinyllog(1)` +* :ref:`vinylncsa(1)` +* :ref:`vinylstat(1)` +* :ref:`vinyltop(1)` * :ref:`vcl(7)` * :ref:`vtc(7)` * :ref:`vmod_vtc(3)` diff --git a/doc/sphinx/reference/varnishtop.rst b/doc/sphinx/reference/vinyltop.rst similarity index 88% rename from doc/sphinx/reference/varnishtop.rst rename to doc/sphinx/reference/vinyltop.rst index 7f0607d854..907212deda 100644 --- a/doc/sphinx/reference/varnishtop.rst +++ b/doc/sphinx/reference/vinyltop.rst @@ -5,7 +5,7 @@ .. role:: ref(emphasis) -.. _varnishtop(1): +.. _vinyltop(1): ========== varnishtop @@ -26,7 +26,7 @@ varnishtop |synopsis| DESCRIPTION =========== -The varnishtop utility reads :ref:`varnishd(1)` shared memory logs and +The varnishtop utility reads :ref:`vinyld(1)` shared memory logs and presents a continuously updated list of the most commonly occurring log entries. With suitable filtering using the ``-I``, ``-i``, ``-X`` and ``-x`` options, it can be used to display a ranking of requested @@ -53,11 +53,11 @@ commonly used user agents:: SEE ALSO ======== -* :ref:`varnishd(1)` -* :ref:`varnishhist(1)` -* :ref:`varnishlog(1)` -* :ref:`varnishncsa(1)` -* :ref:`varnishstat(1)` +* :ref:`vinyld(1)` +* :ref:`vinylhist(1)` +* :ref:`vinyllog(1)` +* :ref:`vinylncsa(1)` +* :ref:`vinylstat(1)` HISTORY ======= diff --git a/doc/sphinx/reference/vsl.rst b/doc/sphinx/reference/vsl.rst index e3c6d0db82..10a255e713 100644 --- a/doc/sphinx/reference/vsl.rst +++ b/doc/sphinx/reference/vsl.rst @@ -21,7 +21,7 @@ OVERVIEW ======== This document describes the format and content of all the Varnish shared memory -logging tags. These tags are used by the varnishlog(1), varnishtop(1), etc. +logging tags. These tags are used by the vinyllog(1), vinyltop(1), etc. logging tools supplied with Varnish. VSL tags @@ -177,10 +177,10 @@ Martin Blix Grydeland. SEE ALSO ======== -* :ref:`varnishhist(1)` -* :ref:`varnishlog(1)` -* :ref:`varnishncsa(1)` -* :ref:`varnishtop(1)` +* :ref:`vinylhist(1)` +* :ref:`vinyllog(1)` +* :ref:`vinylncsa(1)` +* :ref:`vinyltop(1)` COPYRIGHT ========= diff --git a/doc/sphinx/reference/vtc.rst b/doc/sphinx/reference/vtc.rst index 13fd802955..16a6f5b645 100644 --- a/doc/sphinx/reference/vtc.rst +++ b/doc/sphinx/reference/vtc.rst @@ -130,7 +130,7 @@ This document has been written by Guillaume Quintard. SEE ALSO ======== -* :ref:`varnishtest(1)` +* :ref:`vinyltest(1)` * :ref:`vmod_vtc(3)` COPYRIGHT diff --git a/doc/sphinx/tutorial/peculiarities.rst b/doc/sphinx/tutorial/peculiarities.rst index 8327c29ec4..d62aa49e90 100644 --- a/doc/sphinx/tutorial/peculiarities.rst +++ b/doc/sphinx/tutorial/peculiarities.rst @@ -28,7 +28,7 @@ varnishadm ~~~~~~~~~~ Varnish Cache has an admin console. You can connect it through the -:ref:`varnishadm(1)` command. In order to connect the user needs to be +:ref:`vinyladm(1)` command. In order to connect the user needs to be able to read `/etc/varnish/secret` in order to authenticate. Once you've started the console you can do quite a few operations on @@ -47,4 +47,4 @@ Varnish does not log to disk. Instead it logs to a chunk of memory. It is actually streaming the logs. At any time you'll be able to connect to the stream and see what is going on. Varnish logs quite a bit of information. You can have a look at the logstream with the command -:ref:`varnishlog(1)`. +:ref:`vinyllog(1)`. diff --git a/doc/sphinx/users-guide/command-line.rst b/doc/sphinx/users-guide/command-line.rst index 7519d347e0..a727f2294e 100644 --- a/doc/sphinx/users-guide/command-line.rst +++ b/doc/sphinx/users-guide/command-line.rst @@ -34,7 +34,7 @@ port number or bind it to a loopback address first. Multiple '-a' arguments can be provided to service multiple endpoints. *name* is the ``local.socket`` name for VCL. *listen_address* can be an IPv4 or IPv6 address with a port, a unix domain socket path or an abstract socket. See -:ref:`varnishd(1)` for more details. +:ref:`vinyld(1)` for more details. Here are some examples:: @@ -75,4 +75,4 @@ Optional arguments ^^^^^^^^^^^^^^^^^^ For a complete list of the command line arguments please see -:ref:`varnishd(1) options `. +:ref:`vinyld(1) options `. diff --git a/doc/sphinx/users-guide/compression.rst b/doc/sphinx/users-guide/compression.rst index 5409b6d76a..bdf80aff5e 100644 --- a/doc/sphinx/users-guide/compression.rst +++ b/doc/sphinx/users-guide/compression.rst @@ -16,7 +16,7 @@ be smart and do the sensible thing. If you don't want Varnish tampering with the encoding you can disable compression all together by setting the parameter `http_gzip_support` to -false. Please see man :ref:`varnishd(1)` for details. +false. Please see man :ref:`vinyld(1)` for details. Default behaviour ~~~~~~~~~~~~~~~~~ diff --git a/doc/sphinx/users-guide/increasing-your-hitrate.rst b/doc/sphinx/users-guide/increasing-your-hitrate.rst index 9ed78362b1..b90c93a0e6 100644 --- a/doc/sphinx/users-guide/increasing-your-hitrate.rst +++ b/doc/sphinx/users-guide/increasing-your-hitrate.rst @@ -22,7 +22,7 @@ Varnish setup. Note that you need a tool to see the HTTP headers that fly between Varnish and the backend. On the Varnish server, the easiest way to do -this is to use :ref:`varnishlog(1)` and :ref:`varnishtop(1)` but +this is to use :ref:`vinyllog(1)` and :ref:`vinyltop(1)` but sometimes a client-side tool makes sense. Here are the ones we commonly use. @@ -32,18 +32,18 @@ Tool: varnishtop You can use varnishtop to identify what URLs are hitting the backend the most. ``varnishtop -i BereqURL`` is an essential command, showing you the top requests Varnish is sending to the backend. You can see some -other examples of :ref:`varnishtop(1)` usage in :ref:`users-guide-statistics`. +other examples of :ref:`vinyltop(1)` usage in :ref:`users-guide-statistics`. Tool: varnishlog ~~~~~~~~~~~~~~~~ When you have identified an URL which is frequently sent to the -backend you can use :ref:`varnishlog(1)` to have a look at the +backend you can use :ref:`vinyllog(1)` to have a look at the request. ``varnishlog -q 'ReqURL ~ "^/foo/bar"'`` will show you the requests coming from the client matching `/foo/bar`. -For more information on how :ref:`varnishlog(1)` works please see +For more information on how :ref:`vinyllog(1)` works please see :ref:`users-guide-logging` or the man page. @@ -245,7 +245,7 @@ Age ~~~ Varnish adds an 'Age' header to indicate how long the object has been -kept inside Varnish. You can grep out 'Age' from :ref:`varnishlog(1)` +kept inside Varnish. You can grep out 'Age' from :ref:`vinyllog(1)` with ``varnishlog -I RespHeader:^Age``. Pragma diff --git a/doc/sphinx/users-guide/operation-logging.rst b/doc/sphinx/users-guide/operation-logging.rst index 49854b93da..47772e28ae 100644 --- a/doc/sphinx/users-guide/operation-logging.rst +++ b/doc/sphinx/users-guide/operation-logging.rst @@ -79,4 +79,4 @@ want to know are: .. XXX:Maybe a couple of sample commands here? benc -For more information on this topic please see :ref:`varnishlog(1)`. +For more information on this topic please see :ref:`vinyllog(1)`. diff --git a/doc/sphinx/users-guide/operation-statistics.rst b/doc/sphinx/users-guide/operation-statistics.rst index 029b59681b..cc24c67d48 100644 --- a/doc/sphinx/users-guide/operation-statistics.rst +++ b/doc/sphinx/users-guide/operation-statistics.rst @@ -16,7 +16,7 @@ Varnish comes with a couple of nifty and very useful statistics generating tools varnishtop ~~~~~~~~~~ -The :ref:`varnishtop(1)` utility reads the shared memory logs and presents a +The :ref:`vinyltop(1)` utility reads the shared memory logs and presents a continuously updated list of the most commonly occurring log entries. With suitable filtering using the -I, -i, -X and -x options, it can be @@ -31,7 +31,7 @@ show the most popular Accept-Encoding header the client are sending you. varnishhist ~~~~~~~~~~~ -The :ref:`varnishhist(1)` utility reads :ref:`varnishd(1)` shared +The :ref:`vinylhist(1)` utility reads :ref:`vinyld(1)` shared memory logs and presents a continuously updated histogram showing the distribution of the last N requests by their processing. The value of N and the vertical scale are displayed in the top left @@ -43,10 +43,10 @@ varnishstat Varnish has lots of counters. We count misses, hits, information about the storage, threads created, deleted objects. Just about -everything. :ref:`varnishstat(1)` will dump these counters. This is useful when +everything. :ref:`vinylstat(1)` will dump these counters. This is useful when tuning Varnish. -There are programs that can poll :ref:`varnishstat(1)` regularly and +There are programs that can poll :ref:`vinylstat(1)` regularly and make nice graphs of these counters. One such program is Munin. Munin can be found at http://munin-monitoring.org/ . There is a plugin for munin in the Varnish source code. diff --git a/doc/sphinx/users-guide/run_security.rst b/doc/sphinx/users-guide/run_security.rst index 48afe43730..baf37d1836 100644 --- a/doc/sphinx/users-guide/run_security.rst +++ b/doc/sphinx/users-guide/run_security.rst @@ -52,7 +52,7 @@ CLI interface access The command line interface can be accessed in three ways. -:ref:`varnishd(1)` can be told to listen and offer CLI connections on +:ref:`vinyld(1)` can be told to listen and offer CLI connections on a TCP socket. You can bind the socket to pretty much anything the kernel will accept:: @@ -62,7 +62,7 @@ kernel will accept:: -T '[fe80::1]:8082' The default is ``-T localhost:0`` which will pick a random port -number, which :ref:`varnishadm(1)` can learn from the shared memory. +number, which :ref:`vinyladm(1)` can learn from the shared memory. By using a ``localhost`` address, you restrict CLI access to the local machine. @@ -80,11 +80,11 @@ and give remote users access via a secure connection to the local machine, using ssh/VPN or similar. If you use `ssh(1)` you can restrict which commands each user can -execute to just :ref:`varnishadm(1)`, or even use a wrapper scripts -around :ref:`varnishadm(1)` to allow specific CLI commands. +execute to just :ref:`vinyladm(1)`, or even use a wrapper scripts +around :ref:`vinyladm(1)` to allow specific CLI commands. -It is also possible to configure :ref:`varnishd(1)` for "reverse -mode", using the ``-M`` argument. In that case :ref:`varnishd(1)` +It is also possible to configure :ref:`vinyld(1)` for "reverse +mode", using the ``-M`` argument. In that case :ref:`vinyld(1)` will attempt to open a TCP connection to the specified address, and initiate a CLI connection to your central Varnish management facility. @@ -108,13 +108,13 @@ By default the CLI interface is protected with a simple, yet powerful The way ``-S``\ /PSK works is really simple: During startup a file is created with a random content and the file is only accessible to the -user who started :ref:`varnishd(1)` (or the superuser). +user who started :ref:`vinyld(1)` (or the superuser). To authenticate and use a CLI connection, you need to know the contents of that file, in order to answer the cryptographic challenge -:ref:`varnishd(1)` issues, see :ref:`ref_psk_auth`. +:ref:`vinyld(1)` issues, see :ref:`ref_psk_auth`. -:ref:`varnishadm(1)` uses all of this to restrict access, it will only +:ref:`vinyladm(1)` uses all of this to restrict access, it will only function, provided it can read the secret file. If you want to allow other users, local or remote, to be able to @@ -125,17 +125,17 @@ A good way to create the secret file is:: dd if=/dev/random of=/etc/varnish_secret count=1 -When you start :ref:`varnishd(1)`, you specify the filename with '-S', -and it goes without saying that the :ref:`varnishd(1)` master process +When you start :ref:`vinyld(1)`, you specify the filename with '-S', +and it goes without saying that the :ref:`vinyld(1)` master process needs to be able to read the file too. You can change the contents of the secret file while -:ref:`varnishd(1)` runs, it is read every time a CLI connection is +:ref:`vinyld(1)` runs, it is read every time a CLI connection is authenticated. -On the local system, :ref:`varnishadm(1)` can retrieve the filename +On the local system, :ref:`vinyladm(1)` can retrieve the filename from shared memory, but on remote systems, you need to give -:ref:`varnishadm(1)` a copy of the secret file, with the -S argument. +:ref:`vinyladm(1)` a copy of the secret file, with the -S argument. If you want to disable ``-S``\ /PSK authentication, use an ``-S none`` argument to varnishd:: @@ -186,7 +186,7 @@ and operating system, it will not protect your HTTP service. We do not currently have a way to restrict specific CLI commands to specific CLI connections. One way to get such an effect is to "wrap" -all CLI access in pre-approved scripts which use :ref:`varnishadm(1)` +all CLI access in pre-approved scripts which use :ref:`vinyladm(1)` to submit the sanitized CLI commands, and restrict a remote user to only those scripts, for instance using sshd(8)'s configuration. @@ -200,9 +200,9 @@ Both of these mechanisms allow execution of arbitrary code and will thus allow a person to get access to the machine, with the privileges of the child process. -If :ref:`varnishd(1)` is started as root/superuser, we sandbox the +If :ref:`vinyld(1)` is started as root/superuser, we sandbox the child process, using whatever facilities are available on the -operating system, but if :ref:`varnishd(1)` is not started as +operating system, but if :ref:`vinyld(1)` is not started as root/superuser, this is not possible. No, don't ask me why you have to be superuser to lower the privilege of a child process... diff --git a/doc/sphinx/users-guide/sizing-your-cache.rst b/doc/sphinx/users-guide/sizing-your-cache.rst index c3375e87c0..286c495a66 100644 --- a/doc/sphinx/users-guide/sizing-your-cache.rst +++ b/doc/sphinx/users-guide/sizing-your-cache.rst @@ -18,7 +18,7 @@ Deciding on cache size can be a tricky task. A few things to consider: they are cheap to serve from the backend and you have a limited amount of memory. - * Watch the `n_lru_nuked` counter with :ref:`varnishstat(1)` or some + * Watch the `n_lru_nuked` counter with :ref:`vinylstat(1)` or some other tool. If you have a lot of LRU activity then your cache is evicting objects due to space constraints and you should consider increasing the size of the cache. diff --git a/doc/sphinx/users-guide/troubleshooting.rst b/doc/sphinx/users-guide/troubleshooting.rst index 9ef1760816..c68f83f49a 100644 --- a/doc/sphinx/users-guide/troubleshooting.rst +++ b/doc/sphinx/users-guide/troubleshooting.rst @@ -11,7 +11,7 @@ Troubleshooting Varnish Sometimes Varnish misbehaves or rather behaves the way you told it to behave but not necessarily the way you want it to behave. In order for you to understand whats going on there are a couple of places you can -check. :ref:`varnishlog(1)`, ``/var/log/syslog``, +check. :ref:`vinyllog(1)`, ``/var/log/syslog``, ``/var/log/messages`` are all good places where Varnish might leave clues of whats going on. This section will guide you through basic troubleshooting in Varnish. @@ -129,7 +129,7 @@ data. in the service's ``[Service]]`` section of the unit file. Once you have the core, ``cd`` into varnish's working directory (as -given by the ``-n`` parameter (see :ref:`varnishd(1)` for defaults), +given by the ``-n`` parameter (see :ref:`vinyld(1)` for defaults), open the core with ``gdb`` and issue the command ``bt`` to get a stack trace of the thread that caused the segfault. @@ -179,21 +179,21 @@ like this:: Varnish gives me Guru meditation -------------------------------- -First find the relevant log entries in :ref:`varnishlog(1)`. That will -probably give you a clue. Since :ref:`varnishlog(1)` logs a lot of +First find the relevant log entries in :ref:`vinyllog(1)`. That will +probably give you a clue. Since :ref:`vinyllog(1)` logs a lot of data it might be hard to track the entries down. You can set -:ref:`varnishlog(1)` to log all your 503 errors by issuing the +:ref:`vinyllog(1)` to log all your 503 errors by issuing the following command:: $ varnishlog -q 'RespStatus == 503' -g request If the error happened just a short time ago the transaction might -still be in the shared memory log segment. To get :ref:`varnishlog(1)` +still be in the shared memory log segment. To get :ref:`vinyllog(1)` to process the whole shared memory log just add the '-d' parameter:: $ varnishlog -d -q 'RespStatus == 503' -g request -Please see the :ref:`vsl-query(7)` and :ref:`varnishlog(1)` man pages +Please see the :ref:`vsl-query(7)` and :ref:`vinyllog(1)` man pages for elaborations on further filtering capabilities and explanation of the various options. diff --git a/doc/sphinx/whats-new/changes-6.0.rst b/doc/sphinx/whats-new/changes-6.0.rst index 9eaa4145cc..4fd9858c63 100644 --- a/doc/sphinx/whats-new/changes-6.0.rst +++ b/doc/sphinx/whats-new/changes-6.0.rst @@ -45,7 +45,7 @@ There are new and improved VMODs: * :ref:`vmod_unix(3)` -- Unix Domain Socket information -* :ref:`vmod_vtc(3)` -- Utility functions for writing :ref:`varnishtest(1)` cases. +* :ref:`vmod_vtc(3)` -- Utility functions for writing :ref:`vinyltest(1)` cases. The ``umem`` stevedore has been brought back on Solaris and it is the default storage method there now. diff --git a/doc/sphinx/whats-new/changes-6.2.rst b/doc/sphinx/whats-new/changes-6.2.rst index 3db985cd1d..91ef4aba03 100644 --- a/doc/sphinx/whats-new/changes-6.2.rst +++ b/doc/sphinx/whats-new/changes-6.2.rst @@ -126,7 +126,7 @@ The function :ref:`directors.lookup()` has been added to :ref:`vmod_directors(3)`, only for use in ``vcl_init`` or ``vcl_fini``. -varnishlog(1), varnishncsa(1) and vsl(7) +vinyllog(1), vinylncsa(1) and vsl(7) ======================================== The performance of bundled log readers, including ``varnishlog`` and @@ -140,13 +140,13 @@ the shared memory mapping. option for rate-limiting, to limit the number of log transactions read per unit time. This can make it less likely for log reads to fall behind and fail with overrun errors under heavy loads. See -:ref:`varnishlog(1)` and :ref:`varnishncsa(1)` for details. +:ref:`vinyllog(1)` and :ref:`vinylncsa(1)` for details. Timing information is now uniformly reported in the log with microsecond precision. This affects the tags ``ExpKill`` and ``ExpRearm`` (previously with nanosecond precision). -varnishadm(1) and varnish-cli(7) +vinyladm(1) and varnish-cli(7) ================================ The output formats of the ``vcl.list`` and ``backend.list`` commands @@ -173,7 +173,7 @@ the following commands (see :ref:`varnish-cli(7)`): The ``-j`` option was already available for ``backend.list``, ``ping`` and ``help`` in previous versions. -For automated parsing of CLI responses (:ref:`varnishadm(1)` output), +For automated parsing of CLI responses (:ref:`vinyladm(1)` output), we recommend the use of JSON format. ``param.reset `` @@ -204,20 +204,20 @@ whose keep parameter is greater than 3 hours, use this expression:: See :ref:`vcl(7)` and :ref:`users-guide-purging` for details. -varnishstat(1) and varnish-counters(7) +vinylstat(1) and varnish-counters(7) ====================================== Added the ``ws_*_overflow`` and ``client_resp_500`` counters to better diagnose workspace overflow issues, see :ref:`varnish-counters(7)`. -In curses mode, :ref:`varnishstat(1)` now allows use of the ``+`` and +In curses mode, :ref:`vinylstat(1)` now allows use of the ``+`` and ``-`` keys to increase or decrease the refresh rate of the curses window. varnishtest =========== -When :ref:`varnishtest(1)` is invoked with either of the ``-L`` or +When :ref:`vinyltest(1)` is invoked with either of the ``-L`` or ``-l`` options to retain the temporary directory after tests, the ``vcl_keep`` flag for the :ref:`ref_param_debug` parameter is switched on (see `Parameters`_ above). This means that C sources and shared @@ -225,10 +225,10 @@ objects generated from VCL can also be inspected after a test. By default, the temporary directory is deleted after each test. Since around the time of the last release, we have begun the project -`VTest`_, which is adapted from :ref:`varnishtest(1)`, but is made +`VTest`_, which is adapted from :ref:`vinyltest(1)`, but is made available as a stand-alone program useful for testing various HTTP clients, servers and proxies (not just Varnish). But for the time -being, we still use :ref:`varnishtest(1)` for our own testing. +being, we still use :ref:`vinyltest(1)` for our own testing. .. _VTest: https://code.vinyl-cache.org/vtest/VTest diff --git a/doc/sphinx/whats-new/changes-6.3.rst b/doc/sphinx/whats-new/changes-6.3.rst index d2043eb971..2819104e1e 100644 --- a/doc/sphinx/whats-new/changes-6.3.rst +++ b/doc/sphinx/whats-new/changes-6.3.rst @@ -105,7 +105,7 @@ vsl-query(7) ============ The syntax for VSL queries, mainly available via the ``-q`` option with -:ref:`varnishlog(1)` and similar tools, has slightly changed. Previously +:ref:`vinyllog(1)` and similar tools, has slightly changed. Previously and end of line in a query would be treated as a simple token separator so in a script you could for example write this:: @@ -166,7 +166,7 @@ This way when you later revisit a complex query, comments may help you maintain an understanding of each individual query. This can become even more convenient when the query is stored in a file. -varnishlog(1), varnishncsa(1) and others +vinyllog(1), vinylncsa(1) and others ======================================== Our collection of log-processing tools gained the ability to specify @@ -178,18 +178,18 @@ A new ``-Q`` option allows you to read the query from a file instead. It can also be used multiple times and adds up to any ``-q`` option specified. Similar to ``-c`` or ``-b`` for client or backend transactions, -``varnishncsa(1)`` can take a ``-E`` option to include ESI transactions. +``vinylncsa(1)`` can take a ``-E`` option to include ESI transactions. ``BackendStart`` log records are no longer used, but newer versions of log utilities should still recognize deprecated records. It remains possible -to read logs written to a file with an older version of ``varnishlog(1)``, +to read logs written to a file with an older version of ``vinyllog(1)``, and that backward compatibility officially goes as far as Varnish 6.0.0 even though it *may* be possible to read logs saved from older releases. ``Debug`` records are no longer logged by default and can be removed from the :ref:`ref_param_vsl_mask` parameter to appear in the logs. Since such records are not meant for production they are only automatically enabled -by ``varnishtest(1)``. +by ``vinyltest(1)``. varnishstat =========== diff --git a/doc/sphinx/whats-new/changes-7.5.rst b/doc/sphinx/whats-new/changes-7.5.rst index 5aef7a0e26..b58772c255 100644 --- a/doc/sphinx/whats-new/changes-7.5.rst +++ b/doc/sphinx/whats-new/changes-7.5.rst @@ -67,7 +67,7 @@ All the timeout parameters that can be disabled accept the "never" value: - ``send_timeout`` - ``startup_timeout`` -The :ref:`varnishd(1)` manual advertises the ``timeout`` flag for these +The :ref:`vinyld(1)` manual advertises the ``timeout`` flag for these parameters. The following parameters address the HTTP/2 Rapid Reset attach: diff --git a/doc/sphinx/whats-new/upgrading-5.0.rst b/doc/sphinx/whats-new/upgrading-5.0.rst index 501d28b463..800fa1ebee 100644 --- a/doc/sphinx/whats-new/upgrading-5.0.rst +++ b/doc/sphinx/whats-new/upgrading-5.0.rst @@ -115,7 +115,7 @@ Changes to parameters Other changes ============= -* ``varnishstat(1)`` -f option accepts a ``glob(7)`` pattern. +* ``vinylstat(1)`` -f option accepts a ``glob(7)`` pattern. * Cache-Control and Expires headers for uncacheable requests (i.e. passes) will not be parsed. As a result, the RFC variant of the TTL VSL tag diff --git a/doc/sphinx/whats-new/upgrading-5.1.rst b/doc/sphinx/whats-new/upgrading-5.1.rst index aaf658bd5e..1594ee2788 100644 --- a/doc/sphinx/whats-new/upgrading-5.1.rst +++ b/doc/sphinx/whats-new/upgrading-5.1.rst @@ -19,7 +19,7 @@ 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 :ref:`varnishd(1)`, but here's a summary: +The details are given in :ref:`vinyld(1)`, but here's a summary: * Added ``-I clifile`` to run CLI commands at startup, before the worker process starts. See :ref:`whatsnew_clifile`. @@ -246,7 +246,7 @@ Other changes * The storage backend type umem, long in disuse, has been retired. -* ``varnishstat(1)``: +* ``vinylstat(1)``: * Added the ``cache_hitmiss`` stat to count hits on hit-for-miss objects. @@ -267,7 +267,7 @@ Other changes number of objects killed by the ban lurker to keep the number of bans below ``ban_cutoff``. -* ``varnishlog(1)``: +* ``vinyllog(1)``: * Hits on hit-for-miss and hit-for-pass objects are logged with the ``HitMiss`` and ``HitPass`` tags, respectively. In each case, @@ -281,16 +281,16 @@ Other changes for queries that search for transaction IDs in the log. See :ref:`vsl-query(7)`. -* ``varnishncsa(1)``: +* ``vinylncsa(1)``: * Clarified the meaning of the ``%r`` formatter, see NOTES in - :ref:`varnishncsa(1)`. + :ref:`vinylncsa(1)`. * Clarified the meaning of the ``%{X}i`` and ``%{X}o`` formatters when the header X appears more than once (the last occurrence is is used). -* ``varnishtest(1)``: +* ``vinyltest(1)``: * Added the ``setenv`` and ``write_body`` commands, see :ref:`vtc(7)`. diff --git a/doc/sphinx/whats-new/upgrading-5.2.rst b/doc/sphinx/whats-new/upgrading-5.2.rst index a3c40d80f2..5943005502 100644 --- a/doc/sphinx/whats-new/upgrading-5.2.rst +++ b/doc/sphinx/whats-new/upgrading-5.2.rst @@ -102,7 +102,7 @@ If the ``-i`` option is not set in the invocation of ``varnishd``, then ``server.identity`` is set to the host name (as returned by ``gethostname(3)``). Previously, ``server.identity`` defaulted to the value of the ``-n`` option (or the default instance name if ``-n`` was -not set). See :ref:`varnishd(1)`. +not set). See :ref:`vinyld(1)`. ``bereq.is_bgfetch`` -------------------- @@ -143,7 +143,7 @@ ban expression is attempted against an unset field, see Other changes ============= -* ``varnishd(1)``: +* ``vinyld(1)``: * The total size of the shared memory space for logs and counters no longer needs to be configured explicitly and therefore the @@ -165,7 +165,7 @@ Other changes * The ``-f`` option for a VCL source file now honors the ``vcl_path`` parameter if a relative file name is used, see - :ref:`varnishd(1)` and :ref:`ref_param_vcl_path`. + :ref:`vinyld(1)` and :ref:`ref_param_vcl_path`. * The ``-a`` option can now take a name, for example ``-a admin=127.0.0.1:88`` to identify an address used for @@ -174,17 +174,17 @@ Other changes and so forth). Endpoint names appear in the log output, as noted below, and may become accessible in VCL in the future. -* ``varnishstat(1)``: +* ``vinylstat(1)``: * In curses mode, the top two lines showing uptimes for the management and child processes show the text ``Not Running`` if one or both of the processes are down. * The interpretation of multiple ``-f`` options in the command line - has changed slightly, see :ref:`varnishstat(1)`. + has changed slightly, see :ref:`vinylstat(1)`. * The ``type`` and ``ident`` fields have been removed from the XML - and JSON output formats, see :ref:`varnishstat(1)`. + and JSON output formats, see :ref:`vinylstat(1)`. * The ``MAIN.s_req`` statistic has been removed, as it was identical to ``MAIN.client_req``. @@ -194,7 +194,7 @@ Other changes the internal queue is full. See :ref:`varnish-counters(7)` and :ref:`ref_param_thread_queue_limit`. -* ``varnishlog(1)``: +* ``vinyllog(1)``: * The ``Hit``, ``HitMiss`` and ``HitPass`` log records grew an additional field with the remaining TTL of the object at the time @@ -220,7 +220,7 @@ Other changes changed to include the VCL configuration name. See :ref:`vsl(7)` and :ref:`ref_param_vsl_mask`. -* ``varnishtest(1)`` and ``vtc(7)``: +* ``vinyltest(1)`` and ``vtc(7)``: * When varnishtest is invoked with ``-L`` or ``-l``, Varnish instances started by a test do not clean up their copies of VMOD @@ -230,14 +230,14 @@ Other changes * Added the feature switch ``ignore_unknown_macro`` for test cases, see :ref:`vtc(7)`. -* ``varnishncsa(1)`` +* ``vinylncsa(1)`` * Field specifiers (such as the 1 in ``Hit[1]``) are now limited to - to 255, see :ref:`varnishncsa(1)`. + to 255, see :ref:`vinylncsa(1)`. * The ``-N`` command-line option, which was previously available for - ``varnishlog(1)``, ``varnishstat(1)``, ``varnishncsa(1)`` and - ``varnishhist(1)``, is not compatible with the changed internal + ``vinyllog(1)``, ``vinylstat(1)``, ``vinylncsa(1)`` and + ``vinylhist(1)``, is not compatible with the changed internal logging API, and has been retired. * Changes for developers: diff --git a/doc/sphinx/whats-new/upgrading-6.0.rst b/doc/sphinx/whats-new/upgrading-6.0.rst index a04d234f70..7c03945935 100644 --- a/doc/sphinx/whats-new/upgrading-6.0.rst +++ b/doc/sphinx/whats-new/upgrading-6.0.rst @@ -696,13 +696,13 @@ of what you will be able to do once VIP 20 is completed. Other changes ============= -* ``varnishd(1)``: +* ``vinyld(1)``: * The ``umem`` storage allocator, which was removed as of Varnish 5.1, has been restored and is now the default on a system where ``libumem`` is available (SunOS and descendants). -* ``varnishlog(1)``: +* ``vinyllog(1)``: * Added a third field to the ``ReqStart`` log record that contains the name of the listener address over which the request was received, see @@ -734,13 +734,13 @@ Other changes They can be turned on with the ``protocol`` flag of the varnishd :ref:`ref_param_debug` parameter (``-p debug=+protocol``). -* ``varnishstat(1)`` +* ``vinylstat(1)`` * Added the counter ``cache_hit_grace`` -- how often objects in the cache were hit when their TTL had expired, but they were still in grace. -* ``varnishncsa(1)`` +* ``vinylncsa(1)`` * The ``%h`` formatter (remote host) gets its value from ``ReqStart`` for client requests and ``BackendStart`` for backend @@ -771,7 +771,7 @@ Other changes tags for log entries whose payloads may contain control or binary characters. -* ``varnishtest(1)`` and ``vtc(7)``: +* ``vinyltest(1)`` and ``vtc(7)``: * The ``client -connect`` and ``server -listen`` commands in vtc scripts now allow Unix domain sockets as addresses, recognized @@ -790,7 +790,7 @@ Other changes To test a Varnish instance listening at a UDS, just use the ``varnish -arg`` command with the appropriate settings for the - ``-a`` command line argument, see :ref:`varnishd(1)`. + ``-a`` command line argument, see :ref:`vinyld(1)`. The ``varnish -vcl+backend`` command now works to include backend definitions for server objects that are listening at UDS. Backend diff --git a/doc/sphinx/whats-new/upgrading-6.1.rst b/doc/sphinx/whats-new/upgrading-6.1.rst index cd2434085a..f607968535 100644 --- a/doc/sphinx/whats-new/upgrading-6.1.rst +++ b/doc/sphinx/whats-new/upgrading-6.1.rst @@ -159,7 +159,7 @@ is loaded, see the documentation. Other changes ============= -* ``varnishd(1)``: +* ``vinyld(1)``: * Some VCL compile-time error messages have been improved, for example when a symbol is not found or arguments to VMOD calls are @@ -179,7 +179,7 @@ Other changes ``.proxy_header=2`` (for PROXYv2) for a UDS backend with a probe, then ``PROXY LOCAL`` is sent for the probe request. -* ``varnishlog(1)`` and ``vsl(7)``: +* ``vinyllog(1)`` and ``vsl(7)``: * The contents of ``FetchError`` log entries have been improved to give better human-readable diagnostics for certain classes of @@ -206,7 +206,7 @@ Other changes filters applied to a response body (see ``beresp.filters`` discussed above). -* ``varnishadm(1)`` and ``varnish-cli(7)`` +* ``vinyladm(1)`` and ``varnish-cli(7)`` * For a number of CLI commands, you can now use the ``-j`` argument to get a JSON response, which may help in automation. These include: @@ -226,7 +226,7 @@ Other changes option for verbose output, in which detailed health states for each backend/director are displayed. -* ``varnishstat(1)`` and ``varnish-counters(7)``: +* ``vinylstat(1)`` and ``varnish-counters(7)``: * We have added a number of counters to the ``VBE.*`` group to help better diagnose error conditions with backends: @@ -287,7 +287,7 @@ Other changes * Ban statistics are now reported more accurately (they had been subject to inconsistencies due to race conditions). -* ``varnishtest(1)`` and ``vtc(7)``: +* ``vinyltest(1)`` and ``vtc(7)``: * ``varnishtest`` and the ``vtc`` test script language now support testing for haproxy as well as Varnish. The ``haproxy`` directive @@ -311,14 +311,14 @@ Other changes * Added the ``-need-bytes`` argument for the ``process`` command, see :ref:`vtc(7)`. -* ``varnishhist(1)``: +* ``vinylhist(1)``: * The ``-P min:max`` command-line parameters are now optional, - see :ref:`varnishhist(1)`. + see :ref:`vinylhist(1)`. * For all of the utilities that access the Varnish log -- - ``varnishlog(1)``, ``varnishncsa(1)``, ``varnishtop(1)`` and - ``varnishhist(1)`` -- it was already possible to set multiple ``-I`` + ``vinyllog(1)``, ``vinylncsa(1)``, ``vinyltop(1)`` and + ``vinylhist(1)`` -- it was already possible to set multiple ``-I`` and ``-X`` command-line arguments. It is now properly documented that you can use multiple include and exclude filters that apply regular expressions to selected log records. diff --git a/doc/sphinx/whats-new/upgrading-6.2.rst b/doc/sphinx/whats-new/upgrading-6.2.rst index 3b0edf36cc..eb2b3cd1eb 100644 --- a/doc/sphinx/whats-new/upgrading-6.2.rst +++ b/doc/sphinx/whats-new/upgrading-6.2.rst @@ -100,7 +100,7 @@ The ``-j`` option for JSON output has been added to a number of commands, see :ref:`whatsnew_changes_cli_json` in :ref:`whatsnew_changes_2019_03` and :ref:`varnish-cli(7)`. We recommend the use of JSON format for automated parsing of CLI -responses (:ref:`varnishadm(1)` output). +responses (:ref:`vinyladm(1)` output). .. _whatsnew_upgrading_backend_list_2019_03: diff --git a/include/vut_options.h b/include/vut_options.h index c25e8960e2..50b9837661 100644 --- a/include/vut_options.h +++ b/include/vut_options.h @@ -71,7 +71,7 @@ #define VUT_OPT_n \ VOPT("n:", "[-n ]", "varnish working directory", \ "Specify the varnish working directory of the instance " \ - "to attach to. See :ref:`varnishd(1)` ``-n`` option " \ + "to attach to. See :ref:`vinyld(1)` ``-n`` option " \ "documentation for additional information and defaults." \ ) diff --git a/man/Makefile.am b/man/Makefile.am index 567d3e851b..e6a6ae6ae6 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -41,13 +41,13 @@ BUILD_MAN = $(AM_V_GEN) $(RST2MAN) $(RST2ANY_FLAGS) # to $(srcdir) are created for sphinx builds that don't support # VPATH. -vinyl-cli.7: $(top_builddir)/doc/sphinx/reference/varnish-cli.rst \ +vinyl-cli.7: $(top_builddir)/doc/sphinx/reference/vinyl-cli.rst \ $(top_builddir)/doc/sphinx/include/cli.rst - $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnish-cli.rst $@ + $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vinyl-cli.rst $@ -vinyl-counters.7: $(top_builddir)/doc/sphinx/reference/varnish-counters.rst \ +vinyl-counters.7: $(top_builddir)/doc/sphinx/reference/vinyl-counters.rst \ $(top_builddir)/doc/sphinx/include/counters.rst - $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnish-counters.rst $@ + $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vinyl-counters.rst $@ vcl.7: $(top_builddir)/doc/sphinx/reference/vcl.rst \ $(top_builddir)/doc/sphinx/reference/vcl_var.rst \ @@ -74,51 +74,51 @@ vsl.7: $(top_builddir)/doc/sphinx/reference/vsl.rst \ vsl-query.7: $(top_builddir)/doc/sphinx/reference/vsl-query.rst $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vsl-query.rst $@ -vinyladm.1: $(top_builddir)/doc/sphinx/reference/varnishadm.rst - $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnishadm.rst $@ +vinyladm.1: $(top_builddir)/doc/sphinx/reference/vinyladm.rst + $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vinyladm.rst $@ vinyld.1: \ - $(top_builddir)/doc/sphinx/reference/varnishd.rst \ + $(top_builddir)/doc/sphinx/reference/vinyld.rst \ $(top_builddir)/doc/sphinx/include/params.rst \ $(top_builddir)/doc/sphinx/include/options.rst - $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnishd.rst $@ + $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vinyld.rst $@ vinylncsa.1: \ - $(top_builddir)/doc/sphinx/reference/varnishncsa.rst \ + $(top_builddir)/doc/sphinx/reference/vinylncsa.rst \ $(top_builddir)/doc/sphinx/include/vinylncsa_options.rst \ $(top_builddir)/doc/sphinx/include/vinylncsa_synopsis.rst - $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnishncsa.rst $@ + $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vinylncsa.rst $@ vinyllog.1: \ - $(top_builddir)/doc/sphinx/reference/varnishlog.rst \ + $(top_builddir)/doc/sphinx/reference/vinyllog.rst \ $(top_builddir)/doc/sphinx/include/vinyllog_options.rst \ $(top_builddir)/doc/sphinx/include/vinyllog_synopsis.rst - $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnishlog.rst $@ + $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vinyllog.rst $@ -vinylstat.1: $(top_builddir)/doc/sphinx/reference/varnishstat.rst \ +vinylstat.1: $(top_builddir)/doc/sphinx/reference/vinylstat.rst \ $(top_builddir)/doc/sphinx/include/vinylstat_options.rst \ $(top_builddir)/doc/sphinx/include/vinylstat_synopsis.rst \ $(top_builddir)/doc/sphinx/include/vinylstat_bindings.rst - $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnishstat.rst $@ + $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vinylstat.rst $@ -vinyltest.1: $(top_builddir)/doc/sphinx/reference/varnishtest.rst - $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnishtest.rst $@ +vinyltest.1: $(top_builddir)/doc/sphinx/reference/vinyltest.rst + $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vinyltest.rst $@ vtc.7: $(top_builddir)/doc/sphinx/reference/vtc.rst \ $(top_builddir)/doc/sphinx/include/vtc-syntax.rst $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vtc.rst $@ vinyltop.1: \ - $(top_builddir)/doc/sphinx/reference/varnishtop.rst \ + $(top_builddir)/doc/sphinx/reference/vinyltop.rst \ $(top_builddir)/doc/sphinx/include/vinyltop_options.rst \ $(top_builddir)/doc/sphinx/include/vinyltop_synopsis.rst - $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnishtop.rst $@ + $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vinyltop.rst $@ vinylhist.1: \ - $(top_builddir)/doc/sphinx/reference/varnishhist.rst \ + $(top_builddir)/doc/sphinx/reference/vinylhist.rst \ $(top_builddir)/doc/sphinx/include/vinylhist_options.rst \ $(top_builddir)/doc/sphinx/include/vinylhist_synopsis.rst - $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/varnishhist.rst $@ + $(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vinylhist.rst $@ vmod_cookie.3: $(top_builddir)/vmod/vmod_cookie.man.rst $(BUILD_MAN) $? $@ diff --git a/vmod/vmod_blob.vcc b/vmod/vmod_blob.vcc index 46899cad5e..cbbc60bb0d 100644 --- a/vmod/vmod_blob.vcc +++ b/vmod/vmod_blob.vcc @@ -427,7 +427,7 @@ need to increase the varnishd parameter ``thread_pool_stack``. SEE ALSO ======== -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`vcl(7)` * :ref:`vsl(7)` * :ref:`vmod_std(3)` diff --git a/vmod/vmod_h2.vcc b/vmod/vmod_h2.vcc index 28f821fe7f..4849cf588d 100644 --- a/vmod/vmod_h2.vcc +++ b/vmod/vmod_h2.vcc @@ -45,7 +45,7 @@ $Function DURATION rapid_reset([DURATION threshold]) $Restrict client Get and optionally set the ``h2_rapid_reset`` parameter (See -:ref:`varnishd(1)`) for this HTTP2 session only. +:ref:`vinyld(1)`) for this HTTP2 session only. Returns -1 when used outside the HTTP2 transport. Otherwise returns the previous value. @@ -58,7 +58,7 @@ $Function INT rapid_reset_limit([INT number]) $Restrict client Get and optionally set the ``h2_rapid_reset_limit`` parameter (See -:ref:`varnishd(1)`) for this HTTP2 session only. +:ref:`vinyld(1)`) for this HTTP2 session only. Returns -1 when used outside the HTTP2 transport. Otherwise returns the previous value. @@ -71,7 +71,7 @@ $Function DURATION rapid_reset_period([DURATION duration]) $Restrict client Get and optionally set the ``h2_rapid_reset_period`` parameter (See -:ref:`varnishd(1)`) for this HTTP2 session only. +:ref:`vinyld(1)`) for this HTTP2 session only. Returns -1 when used outside the HTTP2 transport. Otherwise returns the previous value. @@ -89,5 +89,5 @@ allowed to send before the session is going to be closed. SEE ALSO ======== -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`vsl(7)` diff --git a/vmod/vmod_proxy.vcc b/vmod/vmod_proxy.vcc index 46787dc067..c672717646 100644 --- a/vmod/vmod_proxy.vcc +++ b/vmod/vmod_proxy.vcc @@ -150,5 +150,5 @@ $Restrict client SEE ALSO ======== -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`vsl(7)` diff --git a/vmod/vmod_std.vcc b/vmod/vmod_std.vcc index 25593c9bbb..6ac3ce9ca1 100644 --- a/vmod/vmod_std.vcc +++ b/vmod/vmod_std.vcc @@ -712,7 +712,7 @@ relevant properties like ``beresp.status``, ``beresp.http.Date``, SEE ALSO ======== -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`vsl(7)` * `fnmatch(3)` * `strftime(3)` diff --git a/vmod/vmod_unix.vcc b/vmod/vmod_unix.vcc index 2ffb61ff8a..b0100fd693 100644 --- a/vmod/vmod_unix.vcc +++ b/vmod/vmod_unix.vcc @@ -115,7 +115,7 @@ All functions in this VMOD are subject to the following constraints: SEE ALSO ======== -* :ref:`varnishd(1)` +* :ref:`vinyld(1)` * :ref:`vcl(7)` * `getpeereid(3)` * `getsockopt(2)` From c075cd0f9442c486a2097a237c6caa5703dc5fdd Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 17:26:03 +0000 Subject: [PATCH 103/196] s/varnish/vinyl/ on INSTALL --- INSTALL | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/INSTALL b/INSTALL index 196bf5936f..2ec0a719eb 100644 --- a/INSTALL +++ b/INSTALL @@ -11,13 +11,13 @@ This file only mentions the basic steps: sh autogen.sh -* To build and install Varnish, run +* To build and install Vinyl Cache, run sh configure make make install -Varnish will store run-time state in /var/run/varnishd; you may +Vinyl Cache will store run-time state in /var/run/vinyld; you may want to tune this using configure's --localstatedir parameter. Additional configure options of interest: @@ -26,3 +26,5 @@ Additional configure options of interest: enable strict warnings (default is NO) --enable-debugging-symbols enable debugging symbols (default is NO) + +*END* From 6088c1e394e3e805e79d70653519a3270cd15b88 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Sun, 8 Mar 2026 17:41:25 +0000 Subject: [PATCH 104/196] More s/varnish/vinyl/ in various files --- doc/sphinx/tutorial/index.rst | 15 ++++++++------- ...n_port_80.rst => putting_vinyl_on_port_80.rst} | 0 .../{starting_varnish.rst => starting_vinyl.rst} | 0 3 files changed, 8 insertions(+), 7 deletions(-) rename doc/sphinx/tutorial/{putting_varnish_on_port_80.rst => putting_vinyl_on_port_80.rst} (100%) rename doc/sphinx/tutorial/{starting_varnish.rst => starting_vinyl.rst} (100%) diff --git a/doc/sphinx/tutorial/index.rst b/doc/sphinx/tutorial/index.rst index d998fb52de..ce33d45f6d 100644 --- a/doc/sphinx/tutorial/index.rst +++ b/doc/sphinx/tutorial/index.rst @@ -5,12 +5,13 @@ .. _tutorial-index: -The Varnish Tutorial -==================== +The Vinyl Cache Tutorial +======================== -This section covers the Varnish basics in a tutorial form. It will cover what Varnish is and how it -works. It also covers how to get Varnish up and running. After this section you probably would want to -continue with the users guide (:ref:`users-guide-index`). +This section covers the Vinyl Cache basics in a tutorial form. It +will cover what Vinyl Cache is and how it works. It also covers how +to get Vinyl Cache up and running. After this section you probably +would want to continue with the users guide (:ref:`users-guide-index`). If you're reading this on the web note the "Next topic" and "Previous topic" links on the right side of each page. @@ -18,8 +19,8 @@ topic" links on the right side of each page. .. toctree:: :maxdepth: 1 introduction - starting_varnish - putting_varnish_on_port_80 + starting_vinyl + putting_vinyl_on_port_80 backend_servers peculiarities.rst now_what diff --git a/doc/sphinx/tutorial/putting_varnish_on_port_80.rst b/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst similarity index 100% rename from doc/sphinx/tutorial/putting_varnish_on_port_80.rst rename to doc/sphinx/tutorial/putting_vinyl_on_port_80.rst diff --git a/doc/sphinx/tutorial/starting_varnish.rst b/doc/sphinx/tutorial/starting_vinyl.rst similarity index 100% rename from doc/sphinx/tutorial/starting_varnish.rst rename to doc/sphinx/tutorial/starting_vinyl.rst From 78561c4fa23e91dd88517965131e6007f5f21bf8 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Mon, 9 Mar 2026 09:01:45 +0000 Subject: [PATCH 105/196] s/varnish/vinyl/ sweep over documentation Retire transitional information for unsupported releases. --- Makefile.am | 2 +- autogen.des | 2 +- configure.ac | 16 +- doc/README.WRITING_RST.rst | 2 +- doc/sphinx/Makefile.am | 2 +- doc/sphinx/dev-guide/homepage_dogfood.rst | 8 +- doc/sphinx/dev-guide/who.rst | 6 +- doc/sphinx/glossary/index.rst | 10 +- doc/sphinx/index.rst | 4 +- doc/sphinx/installation/bugs.rst | 2 +- doc/sphinx/installation/install_debian.rst | 8 +- doc/sphinx/installation/install_redhat.rst | 18 +- doc/sphinx/installation/install_source.rst | 2 +- doc/sphinx/installation/platformnotes.rst | 4 +- doc/sphinx/reference/cli_protocol.rst | 30 +- doc/sphinx/reference/vcl-backend.rst | 2 +- doc/sphinx/reference/vcl.rst | 4 +- doc/sphinx/reference/vcl_step.rst | 2 +- doc/sphinx/reference/vinyl-cli.rst | 56 +- doc/sphinx/reference/vinyl-counters.rst | 14 +- doc/sphinx/reference/vinyladm.rst | 38 +- doc/sphinx/reference/vinyld.rst | 138 ++--- doc/sphinx/reference/vinylhist.rst | 20 +- doc/sphinx/reference/vinyllog.rst | 18 +- doc/sphinx/reference/vinylncsa.rst | 68 +-- doc/sphinx/reference/vinylstat.rst | 26 +- doc/sphinx/reference/vinyltest.rst | 84 +-- doc/sphinx/reference/vinyltop.rst | 24 +- doc/sphinx/reference/vmod.rst | 4 +- doc/sphinx/reference/vsm.rst | 2 +- doc/sphinx/reference/vtla.rst | 2 +- doc/sphinx/tutorial/peculiarities.rst | 8 +- .../tutorial/putting_vinyl_on_port_80.rst | 2 +- doc/sphinx/users-guide/command-line.rst | 2 +- .../users-guide/increasing-your-hitrate.rst | 14 +- doc/sphinx/users-guide/intro.rst | 6 +- doc/sphinx/users-guide/operation-logging.rst | 8 +- .../users-guide/operation-statistics.rst | 18 +- doc/sphinx/users-guide/params.rst | 4 +- doc/sphinx/users-guide/purging.rst | 2 +- doc/sphinx/users-guide/run_cli.rst | 22 +- doc/sphinx/users-guide/storage-backends.rst | 14 +- doc/sphinx/users-guide/troubleshooting.rst | 6 +- doc/sphinx/users-guide/vcl.rst | 2 +- doc/sphinx/whats-new/changes-4.1.rst | 170 ------ doc/sphinx/whats-new/changes-5.0.rst | 256 --------- doc/sphinx/whats-new/changes-5.1.rst | 367 ------------- doc/sphinx/whats-new/changes-5.2.rst | 176 ------- doc/sphinx/whats-new/changes-6.1.rst | 28 - doc/sphinx/whats-new/changes-6.2.rst | 259 --------- doc/sphinx/whats-new/changes-6.3.rst | 229 -------- doc/sphinx/whats-new/changes-6.4.rst | 209 -------- doc/sphinx/whats-new/changes-6.5.rst | 252 --------- doc/sphinx/whats-new/changes-6.6.rst | 493 ------------------ doc/sphinx/whats-new/changes-7.0.rst | 310 ----------- doc/sphinx/whats-new/changes-7.1.rst | 227 -------- doc/sphinx/whats-new/changes-7.2.rst | 169 ------ doc/sphinx/whats-new/changes-7.3.rst | 178 ------- doc/sphinx/whats-new/changes-7.4.rst | 129 ----- doc/sphinx/whats-new/changes-7.5.rst | 325 ------------ doc/sphinx/whats-new/changes-7.6.rst | 170 ------ doc/sphinx/whats-new/index.rst | 162 ------ doc/sphinx/whats-new/relnote-5.0.rst | 165 ------ doc/sphinx/whats-new/upgrading-4.0.rst | 253 --------- doc/sphinx/whats-new/upgrading-4.1.rst | 77 --- doc/sphinx/whats-new/upgrading-5.0.rst | 122 ----- doc/sphinx/whats-new/upgrading-5.1.rst | 320 ------------ doc/sphinx/whats-new/upgrading-5.2.rst | 264 ---------- doc/sphinx/whats-new/upgrading-6.0.rst | 6 +- doc/sphinx/whats-new/upgrading-6.1.rst | 398 -------------- doc/sphinx/whats-new/upgrading-6.2.rst | 202 ------- doc/sphinx/whats-new/upgrading-6.3.rst | 69 --- doc/sphinx/whats-new/upgrading-6.4.rst | 76 --- doc/sphinx/whats-new/upgrading-6.5.rst | 114 ---- doc/sphinx/whats-new/upgrading-6.6.rst | 82 --- doc/sphinx/whats-new/upgrading-7.0.rst | 341 ------------ doc/sphinx/whats-new/upgrading-7.1.rst | 137 ----- doc/sphinx/whats-new/upgrading-7.2.rst | 101 ---- doc/sphinx/whats-new/upgrading-7.3.rst | 61 --- doc/sphinx/whats-new/upgrading-7.4.rst | 30 -- doc/sphinx/whats-new/upgrading-7.5.rst | 88 ---- doc/sphinx/whats-new/upgrading-7.6.rst | 69 --- vinyl.m4 | 58 +-- 83 files changed, 395 insertions(+), 7473 deletions(-) delete mode 100644 doc/sphinx/whats-new/changes-4.1.rst delete mode 100644 doc/sphinx/whats-new/changes-5.0.rst delete mode 100644 doc/sphinx/whats-new/changes-5.1.rst delete mode 100644 doc/sphinx/whats-new/changes-5.2.rst delete mode 100644 doc/sphinx/whats-new/changes-6.1.rst delete mode 100644 doc/sphinx/whats-new/changes-6.2.rst delete mode 100644 doc/sphinx/whats-new/changes-6.3.rst delete mode 100644 doc/sphinx/whats-new/changes-6.4.rst delete mode 100644 doc/sphinx/whats-new/changes-6.5.rst delete mode 100644 doc/sphinx/whats-new/changes-6.6.rst delete mode 100644 doc/sphinx/whats-new/changes-7.0.rst delete mode 100644 doc/sphinx/whats-new/changes-7.1.rst delete mode 100644 doc/sphinx/whats-new/changes-7.2.rst delete mode 100644 doc/sphinx/whats-new/changes-7.3.rst delete mode 100644 doc/sphinx/whats-new/changes-7.4.rst delete mode 100644 doc/sphinx/whats-new/changes-7.5.rst delete mode 100644 doc/sphinx/whats-new/changes-7.6.rst delete mode 100644 doc/sphinx/whats-new/relnote-5.0.rst delete mode 100644 doc/sphinx/whats-new/upgrading-4.0.rst delete mode 100644 doc/sphinx/whats-new/upgrading-4.1.rst delete mode 100644 doc/sphinx/whats-new/upgrading-5.0.rst delete mode 100644 doc/sphinx/whats-new/upgrading-5.1.rst delete mode 100644 doc/sphinx/whats-new/upgrading-5.2.rst delete mode 100644 doc/sphinx/whats-new/upgrading-6.1.rst delete mode 100644 doc/sphinx/whats-new/upgrading-6.2.rst delete mode 100644 doc/sphinx/whats-new/upgrading-6.3.rst delete mode 100644 doc/sphinx/whats-new/upgrading-6.4.rst delete mode 100644 doc/sphinx/whats-new/upgrading-6.5.rst delete mode 100644 doc/sphinx/whats-new/upgrading-6.6.rst delete mode 100644 doc/sphinx/whats-new/upgrading-7.0.rst delete mode 100644 doc/sphinx/whats-new/upgrading-7.1.rst delete mode 100644 doc/sphinx/whats-new/upgrading-7.2.rst delete mode 100644 doc/sphinx/whats-new/upgrading-7.3.rst delete mode 100644 doc/sphinx/whats-new/upgrading-7.4.rst delete mode 100644 doc/sphinx/whats-new/upgrading-7.5.rst delete mode 100644 doc/sphinx/whats-new/upgrading-7.6.rst diff --git a/Makefile.am b/Makefile.am index efbf99e6d3..5523eeb633 100644 --- a/Makefile.am +++ b/Makefile.am @@ -44,7 +44,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS += --with-unwind endif install-data-local: - $(install_sh) -d -m 0755 $(DESTDIR)$(localstatedir)/varnish + $(install_sh) -d -m 0755 $(DESTDIR)$(localstatedir)/vinyl distclean-local: diff --git a/autogen.des b/autogen.des index 3c4a1e04be..9cb136c381 100755 --- a/autogen.des +++ b/autogen.des @@ -19,7 +19,7 @@ if [ "x$DST" != "x" ] ; then elif [ "x`uname`" = "xFreeBSD" ] ; then DST="--prefix=/usr/local --mandir=/usr/local/man" else - DST="--prefix=/opt/varnish --mandir=/opt/varnish/man" + DST="--prefix=/opt/vinyl --mandir=/opt/vinyl/man" fi PERSISTENT=--with-persistent-storage diff --git a/configure.ac b/configure.ac index 86da6fc59b..0aa8e8f01f 100644 --- a/configure.ac +++ b/configure.ac @@ -58,7 +58,7 @@ AC_ARG_WITH([rst2man], [no])]) if test "x$RST2MAN" = "xno"; then AC_MSG_ERROR( - [rst2man is needed to build Varnish, please install python3-docutils.]) + [rst2man is needed to build Vinyl Cache, please install python3-docutils.]) fi AC_ARG_WITH([sphinx-build], @@ -69,7 +69,7 @@ AC_ARG_WITH([sphinx-build], [no])]) if test "x$SPHINX" = "xno"; then AC_MSG_ERROR( - [sphinx-build is needed to build Varnish, please install python3-sphinx.]) + [sphinx-build is needed to build Vinyl Cache, please install python3-sphinx.]) fi AC_ARG_WITH([rst2html], @@ -514,14 +514,14 @@ AC_CHECK_DECL([SO_ACCEPTFILTER], AC_CHECK_DECL([SO_RCVTIMEO], [], - AC_MSG_ERROR([SO_RCVTIMEO is needed to build Varnish.]), [ + AC_MSG_ERROR([SO_RCVTIMEO is needed to build Vinyl Cache.]), [ #include #include ]) AC_CHECK_DECL([SO_SNDTIMEO], [], - AC_MSG_ERROR([SO_SNDTIMEO is needed to build Varnish.]), [ + AC_MSG_ERROR([SO_SNDTIMEO is needed to build Vinyl Cache.]), [ #include #include ]) @@ -643,12 +643,12 @@ fi if test "${localstatedir}" = '${prefix}/var' ; then VINYL_STATE_DIR='/var/run' else - VINYL_STATE_DIR='${localstatedir}/varnish' + VINYL_STATE_DIR='${localstatedir}/vinyl' fi AC_SUBST(VINYL_STATE_DIR) # Default configuration directory. -pkgsysconfdir='${sysconfdir}/varnish' +pkgsysconfdir='${sysconfdir}/vinyl' AC_SUBST(pkgsysconfdir) # VMOD variables @@ -897,7 +897,7 @@ AM_SUBST_NOTMAKE(VMOD_TESTS) AC_ARG_WITH([contrib], [AS_HELP_STRING([--with-contrib], - [Build Varnish with external contributions.])]) + [Build Vinyl Cache with external contributions.])]) AM_CONDITIONAL([WITH_CONTRIB], [test "$with_contrib" = yes]) CONTRIB_TESTS="$(cd $srcdir/contrib && echo tests/*.vtc)" @@ -906,7 +906,7 @@ AM_SUBST_NOTMAKE(CONTRIB_TESTS) AM_COND_IF([WITH_CONTRIB], [ AC_DEFINE([WITH_CONTRIB], [1], - [Define to 1 when Varnish is built with contributions.]) + [Define to 1 when Vinyl Cache is built with contributions.]) ]) # Make sure this include dir exists diff --git a/doc/README.WRITING_RST.rst b/doc/README.WRITING_RST.rst index d876285525..f65ca25909 100644 --- a/doc/README.WRITING_RST.rst +++ b/doc/README.WRITING_RST.rst @@ -49,7 +49,7 @@ of documentation: * set link targets for important paragraphs following the scheme ref-`doc`-`section`, for instance:: - .. _ref-varnishd-opt_T: + .. _ref-vinyld-opt_T: These can be referenced from other documents making up the html documentation, but not from stand-alone documents (like man-pages). diff --git a/doc/sphinx/Makefile.am b/doc/sphinx/Makefile.am index 2cd6eb3b35..84d9eecf9e 100644 --- a/doc/sphinx/Makefile.am +++ b/doc/sphinx/Makefile.am @@ -3,7 +3,7 @@ # You can set these variables from the command line. SPHINXOPTS = -SPHINXBUILD = $(SPHINX) -W -q -N +SPHINXBUILD = $(SPHINX) -W -N BUILDDIR = build ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(SPHINXOPTS) $(builddir) diff --git a/doc/sphinx/dev-guide/homepage_dogfood.rst b/doc/sphinx/dev-guide/homepage_dogfood.rst index 6c098e24ec..46e86d8779 100644 --- a/doc/sphinx/dev-guide/homepage_dogfood.rst +++ b/doc/sphinx/dev-guide/homepage_dogfood.rst @@ -43,7 +43,7 @@ can get world-class support by bugging my buddies about it, there are two equally serious reasons for the Varnish Project to run on FreeBSD: Dogfood and jails. -Varnish Cache is not "software for Linux", it is software for any +Vinyl Cache is not "software for Linux", it is software for any competent UNIX-like operating system, and FreeBSD is our primary "keep us honest about this" platform. @@ -144,14 +144,14 @@ the kinks on one of my test-machines. Once it was as I wanted it, I pushed the changes the live machine and then:: - varnishadm vcl.use backup + vinyladm vcl.use backup # The 'backup' VCL does a "pass" of all traffic to my server cd Admin git pull cd Tools sh build_j_tools.sh |& tee _.bj - varnishadm vcl.load foobar varnish-live.vcl - varnishadm vcl.use foobar + vinyladm vcl.load foobar varnish-live.vcl + vinyladm vcl.use foobar For a few minutes our website was a bit slower (because of the extra Paris-Denmark hop), but there was never any interruption. diff --git a/doc/sphinx/dev-guide/who.rst b/doc/sphinx/dev-guide/who.rst index 9e9ec67ddc..931841fa84 100644 --- a/doc/sphinx/dev-guide/who.rst +++ b/doc/sphinx/dev-guide/who.rst @@ -8,7 +8,7 @@ Who is ... ? ============ -Not quite `Twurp's Peerage `_ but a Who's Who of the Varnish Cache project. +Not quite `Twurp's Peerage `_ but a Who's Who of the Vinyl Cache project. Anders Berg ~~~~~~~~~~~ @@ -131,13 +131,13 @@ Martin was the first full-time member of the C-team at Varnish Software. He is the main responsible for the amazing revamp of the logging facilities and utilities in the 4.0 cycle and later the storage rework. Besides that he fixes lots of bugs, knows varnishtest better -than most, writes vmods and is the Varnish Cache Plus architect. +than most, writes vmods and is the Vinyl Cache Plus architect. Lasse Karstensen ~~~~~~~~~~~~~~~~ Lasse is the current release manager and stable version maintainer of -Varnish Cache. When not doing that, he maintains build infrastructure +Vinyl Cache. When not doing that, he maintains build infrastructure and runs the Varnish Software C developer team in Oslo. Geoff Simmons diff --git a/doc/sphinx/glossary/index.rst b/doc/sphinx/glossary/index.rst index 4dcf264674..2015339371 100644 --- a/doc/sphinx/glossary/index.rst +++ b/doc/sphinx/glossary/index.rst @@ -47,19 +47,19 @@ Varnish Glossary a browser, but do not forget to think about spiders, robots script-kiddies and criminals. - varnishstat + vinylstat Program which presents varnish statistics counters. - varnishlog + vinyllog Program which presents varnish transaction log in native format. - varnishtop + vinyltop Program which gives real-time "top-X" list view of transaction log. - varnishncsa + vinylncsa Program which presents varnish transaction log in "NCSA" format. - varnishhist + vinylhist Eye-candy program showing response time histogram in 1980s ASCII-art style. diff --git a/doc/sphinx/index.rst b/doc/sphinx/index.rst index 083d407f7c..0e1570fa8c 100644 --- a/doc/sphinx/index.rst +++ b/doc/sphinx/index.rst @@ -31,7 +31,7 @@ Conventions used in this manual include: A command you can run, or a shortkey you can press. Used either in the terminal or after starting one of the tools. - `/usr/local/`, `varnishadm`, `sess_timeout` + `/usr/local/`, `vinyladm`, `sess_timeout` A utility, Varnish configurable parameter or path. https://www.vinyl-cache.org/ @@ -47,7 +47,7 @@ Longer listings like example command output and VCL look like this:: .. For maintainers: .. * always write Varnish with a capital V: Varnish, Varnish Cache. -.. * Write Varnish tools as their executable name: `varnishd`, `varnishadm`. +.. * Write Varnish tools as their executable name: `vinyld`, `vinyladm`. .. * if part of a command actually runable by the reader, use double backticks: .. ``varnishd -f foo.c`` .. * wrap lines at 80 characters, ident with 4 spaces. No tabs, please. diff --git a/doc/sphinx/installation/bugs.rst b/doc/sphinx/installation/bugs.rst index 4930c96361..fc5f7842ad 100644 --- a/doc/sphinx/installation/bugs.rst +++ b/doc/sphinx/installation/bugs.rst @@ -156,6 +156,6 @@ have tripped up everybody else, take a moment to read through your VCL and see if it really does what you think it does. You can also try setting the ``vsl_mask=+VCL_trace`` parameter (or use -``varnishadm param.set vsl_mask +VCL_trace`` on a running instance), +``vinyladm param.set vsl_mask +VCL_trace`` on a running instance), that will generate log records with like and character number for each statement executed in your VCL program. diff --git a/doc/sphinx/installation/install_debian.rst b/doc/sphinx/installation/install_debian.rst index a5de62473a..f5c5688b3c 100644 --- a/doc/sphinx/installation/install_debian.rst +++ b/doc/sphinx/installation/install_debian.rst @@ -19,15 +19,15 @@ Type:: Official packages of 6 ---------------------- -Starting from Varnish Cache 5.0, we've simplified our packaging down to two: +Starting from Vinyl Cache 5.0, we've simplified our packaging down to two: the main package and a development package. -The official Varnish Cache repository is now hosted at Packagecloud.io. +The official Vinyl Cache repository is now hosted at Packagecloud.io. Note that while Packagecloud.io provides Bash Script installs, we recommend using the manual installation procedures. Instructions for installing the official repository which contains the newest -Varnish Cache 6 release are available at: +Vinyl Cache 6 release are available at: * https://packagecloud.io/varnishcache/varnish60lts/install#manual-deb @@ -39,7 +39,7 @@ Read more about this on `Release 6.0.2 `_. Official packages of 4.1 ------------------------ -To use Varnish Cache 4.1 packages from the official varnish-cache.org repos, +To use Vinyl Cache 4.1 packages from the official varnish-cache.org repos, follow the instructions available at: * https://packagecloud.io/varnishcache/varnish41/install#manual-deb diff --git a/doc/sphinx/installation/install_redhat.rst b/doc/sphinx/installation/install_redhat.rst index 2baaaeb34f..1a374a47eb 100644 --- a/doc/sphinx/installation/install_redhat.rst +++ b/doc/sphinx/installation/install_redhat.rst @@ -15,9 +15,9 @@ versions are available. We therefore recommend that you install the latest version directly from our repository, as described above. -Varnish Cache is packaged in RPMs for easy installation and upgrade on Red Hat -systems. The Varnish Cache project maintains official packages for the current -Enterprise Linux versions. Varnish Cache 6.x series are supported on el7 and el8. +Vinyl Cache is packaged in RPMs for easy installation and upgrade on Red Hat +systems. The Vinyl Cache project maintains official packages for the current +Enterprise Linux versions. Vinyl Cache 6.x series are supported on el7 and el8. We try to keep the latest version available as prebuilt RPMs (el7 and el8) on `packagecloud.io/varnishcache `_. @@ -30,15 +30,15 @@ is to disable the module before installing:: Official packages of 6 ---------------------- -Starting from Varnish Cache 5.0, we've simplified our packaging down to two: +Starting from Vinyl Cache 5.0, we've simplified our packaging down to two: the main package and a development package. -The official Varnish Cache repository is now hosted at Packagecloud.io. +The official Vinyl Cache repository is now hosted at Packagecloud.io. Note that while Packagecloud.io provides Bash Script installs, we recommend using the manual installation procedures. Instructions for installing the official repository which contains the newest -Varnish Cache 6 release are available at: +Vinyl Cache 6 release are available at: * https://packagecloud.io/varnishcache/varnish60lts/install#manual-rpm @@ -49,10 +49,10 @@ Read more about this on `Release 6.0.2 `_. External packaging ------------------ -Varnish Cache is also distributed in third party package repositories. +Vinyl Cache is also distributed in third party package repositories. .. _`Fedora EPEL`: https://fedoraproject.org/wiki/EPEL -* `Fedora EPEL`_ does community packaging of Varnish Cache. +* `Fedora EPEL`_ does community packaging of Vinyl Cache. -* RedHat has packaged versions of Varnish Cache available since Software Collections 2.1. Announcement on . +* RedHat has packaged versions of Vinyl Cache available since Software Collections 2.1. Announcement on . diff --git a/doc/sphinx/installation/install_source.rst b/doc/sphinx/installation/install_source.rst index 393a650d91..903a92c39e 100644 --- a/doc/sphinx/installation/install_source.rst +++ b/doc/sphinx/installation/install_source.rst @@ -322,6 +322,6 @@ Installing And finally, the true test of a brave heart: ``sudo make install`` -Varnish will now be installed in ``/usr/local``. The ``varnishd`` binary is in +Varnish will now be installed in ``/usr/local``. The ``vinyld`` binary is in `/usr/local/sbin/varnishd`. To make sure that the necessary links and caches of the most recent shared libraries are found, run ``sudo ldconfig``. diff --git a/doc/sphinx/installation/platformnotes.rst b/doc/sphinx/installation/platformnotes.rst index f103d44efa..fea488749a 100644 --- a/doc/sphinx/installation/platformnotes.rst +++ b/doc/sphinx/installation/platformnotes.rst @@ -22,7 +22,7 @@ as the *workdir*. To ensure ``tmpfs`` is used, check the following: -Determine the *workdir*. If you use a specific ``-n`` option to ``varnishd`` or +Determine the *workdir*. If you use a specific ``-n`` option to ``vinyld`` or set the ``VINYL_DEFAULT_N`` variable, it is that value. Otherwise run ``varnishd -x options``, which outputs the *workdir* default. @@ -66,7 +66,7 @@ On certain Linux distributions Transparent Hugepage (THP) kernel support is enabled by default. This is known to cause instabilities of Varnish. By default, Varnish tries to disable the THP feature, but does not fail if it -can't. The ``linux`` :ref:`ref-varnishd-opt_j` offers to optionally enable, +can't. The ``linux`` :ref:`ref-vinyld-opt_j` offers to optionally enable, disable or ignore THP. Alternatively, THP can be disabled system-wide. If Varnish is the only diff --git a/doc/sphinx/reference/cli_protocol.rst b/doc/sphinx/reference/cli_protocol.rst index 4fa9e2671c..6cfd99dfad 100644 --- a/doc/sphinx/reference/cli_protocol.rst +++ b/doc/sphinx/reference/cli_protocol.rst @@ -15,7 +15,7 @@ The Varnish CLI has a few bells&whistles when used as an API. First: `vcli.h` contains magic numbers. -Second: If you use `varnishadm` to connect to `varnishd` for +Second: If you use `vinyladm` to connect to `vinyld` for API purposes, use the `-p` argument to get "pass" mode. In "pass" mode, or with direct CLI connections (more below), the @@ -37,29 +37,29 @@ the CLI protocol, for more, see the `vcli.h` include file. Local and remote CLI connections -------------------------------- -The ``varnishd`` process receives the CLI commands via TCP connections +The ``vinyld`` process receives the CLI commands via TCP connections which require PSK authentication (see below), but which provide no secrecy. "No secrecy" means that if you configure these TCP connections to run across a network, anybody who can sniff packets can see your CLI -commands. If you need secrecy, use ``ssh`` to run ``varnishadm`` or +commands. If you need secrecy, use ``ssh`` to run ``vinyladm`` or to tunnel the TCP connection. -By default `varnishd` binds to ``localhost`` and ask the kernel to +By default `vinyld` binds to ``localhost`` and ask the kernel to assign a random port number. The resulting listen address is -stored in the shared memory, where the ``varnishadm`` program finds it. +stored in the shared memory, where the ``vinyladm`` program finds it. -You can configure ``varnishd`` to listen to a specific address with +You can configure ``vinyld`` to listen to a specific address with the ``-T`` argument, this will also be written to shared memory, so -``varnishadm`` keeps working:: +``vinyladm`` keeps working:: # Bind to internal network varnishd -T 192.168.10.21:3245 -You can also configure ``varnishd`` to actively open a TCP connection +You can also configure ``vinyld`` to actively open a TCP connection to another "controller" program, with the ``-M`` argument. -Finally, when run in "debug mode" with the ``-d`` argument, ``varnishd`` +Finally, when run in "debug mode" with the ``-d`` argument, ``vinyld`` will stay in the foreground and turn stdin/stdout into a CLI connection. .. _ref_psk_auth: @@ -67,19 +67,19 @@ will stay in the foreground and turn stdin/stdout into a CLI connection. Authentication CLI connections ------------------------------ -CLI connections to `varnishd` are authenticated with a "pre-shared-key" +CLI connections to `vinyld` are authenticated with a "pre-shared-key" authentication scheme, where the other end must prove they know -*the contents of* the secret file ``varnishd`` uses. +*the contents of* the secret file ``vinyld`` uses. They do not have to read the precise same file on that specific computer, they could read an entirely different file on a different computer or fetch the secret from a server. The name of the file can be configured with the ``-S`` option, and -``varnishd`` records the name in shared memory, so ``varnishadm`` +``vinyld`` records the name in shared memory, so ``vinyladm`` can find it. -As a bare minimum ``varnishd`` needs to be able to read the file, +As a bare minimum ``vinyld`` needs to be able to read the file, but other than that, it can be restricted any way you want. Since it is not the file, but only the content of it that matter, @@ -87,7 +87,7 @@ you can make the file unreadable by everybody, and instead place a copy of the file in the home directories of the authorized users. The file is read only at the moment when the `auth` CLI command is -issued and the contents is not cached in `varnishd`, so you can +issued and the contents is not cached in `vinyld`, so you can change it as often as you want. An authenticated session looks like this: @@ -107,7 +107,7 @@ An authenticated session looks like this: auth 455ce847f0073c7ab3b1465f74507b75d3dc064c1e7de3b71e00de9092fdc89a 200 279 ----------------------------- - Varnish Cache CLI 1.0 + Vinyl Cache CLI 1.0 ----------------------------- FreeBSD,13.0-CURRENT,amd64,-jnone,-sdefault,-sdefault,-hcritbit varnish-trunk revision 89a558e56390d425c52732a6c94087eec9083115 diff --git a/doc/sphinx/reference/vcl-backend.rst b/doc/sphinx/reference/vcl-backend.rst index adb5b623b2..c44cbc6a08 100644 --- a/doc/sphinx/reference/vcl-backend.rst +++ b/doc/sphinx/reference/vcl-backend.rst @@ -98,7 +98,7 @@ A host header to add to probes and regular backend requests if they have no such Timeout Attributes ------------------ -These attributes control how patient `varnishd` is during backend fetches:: +These attributes control how patient `vinyld` is during backend fetches:: .connect_timeout = 1.4s; .first_byte_timeout = 20s; diff --git a/doc/sphinx/reference/vcl.rst b/doc/sphinx/reference/vcl.rst index 60852210ca..30e889e323 100644 --- a/doc/sphinx/reference/vcl.rst +++ b/doc/sphinx/reference/vcl.rst @@ -22,7 +22,7 @@ DESCRIPTION The VCL language is a small domain-specific language designed to be used to describe request handling and document caching policies for -Varnish Cache. +Vinyl Cache. When a new configuration is loaded, the varnishd management process translates the VCL code to C and compiles it to a shared object which @@ -441,7 +441,7 @@ Symbol references Some VCL symbols are subject to reference counting, and would trigger a vcl compiler error if they were declared but not used. One way to turn these errors -into warnings is to add ``-p vcc_feature=-err_unref`` to your ``varnishd`` +into warnings is to add ``-p vcc_feature=-err_unref`` to your ``vinyld`` command line. This will disable the error globally for all symbols in every VCL that is compiled. diff --git a/doc/sphinx/reference/vcl_step.rst b/doc/sphinx/reference/vcl_step.rst index e114388298..40d79eb7bc 100644 --- a/doc/sphinx/reference/vcl_step.rst +++ b/doc/sphinx/reference/vcl_step.rst @@ -57,7 +57,7 @@ of the following keywords: | 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 in :ref:`varnish-cli(7)`. + | See the :ref:`ref_cli_vcl_label` command in :ref:`vinyl-cli(7)`. .. _vcl_pipe: diff --git a/doc/sphinx/reference/vinyl-cli.rst b/doc/sphinx/reference/vinyl-cli.rst index fdd31784c1..2a483c4abc 100644 --- a/doc/sphinx/reference/vinyl-cli.rst +++ b/doc/sphinx/reference/vinyl-cli.rst @@ -5,23 +5,23 @@ .. role:: ref(emphasis) -.. _varnish-cli(7): +.. _vinyl-cli(7): -=========== -varnish-cli -=========== +========= +vinyl-cli +========= ------------------------------- -Varnish Command Line Interface ------------------------------- +---------------------------------- +Vinyl Cache Command Line Interface +---------------------------------- :Manual section: 7 DESCRIPTION =========== -Varnish has a command line interface (CLI) which can control and change -most of the operational parameters and the configuration of Varnish, +Vinyl Cache has a command line interface (CLI) which can control and change +most of the operational parameters and the configuration of Vinyl Cache, without interrupting the running service. The CLI can be used for the following tasks: @@ -30,13 +30,13 @@ configuration You can upload, change and delete VCL files from the CLI. parameters - You can inspect and change the various parameters Varnish has + You can inspect and change the various parameters Vinyl Cache has available through the CLI. The individual parameters are documented in the vinyld(1) man page. bans - Bans are filters that are applied to keep Varnish from serving - stale content. When you issue a ban Varnish will not serve any + Bans are filters that are applied to keep Vinyl Cache from serving + stale content. When you issue a ban Vinyl Cache will not serve any *banned* object from cache, but rather re-fetch it from its backend servers. @@ -47,8 +47,8 @@ process management If you invoke vinyld(1) with -T, -M or -d the CLI will be available. In debug mode (-d) the CLI will be in the foreground, with --T you can connect to it with varnishadm or telnet and with -M -varnishd will connect back to a listening service *pushing* the CLI to +-T you can connect to it with vinyladm or telnet and with -M +``vinyld`` will connect back to a listening service *pushing* the CLI to that service. Please see :ref:`vinyld(1)` for details. .. _ref_syntax: @@ -56,7 +56,7 @@ that service. Please see :ref:`vinyld(1)` for details. Syntax ------ -The Varnish CLI is similar to another command line interface, the Bourne +The Vinyl Cache CLI is similar to another command line interface, the Bourne Shell. Commands are usually terminated with a newline, and they may take arguments. The command and its arguments are *tokenized* before parsing, and as such arguments containing spaces must be enclosed in double quotes. @@ -98,7 +98,7 @@ used. Quoting pitfalls ---------------- -Integrating with the Varnish CLI can be sometimes surprising when quoting +Integrating with the Vinyl Cache CLI can be sometimes surprising when quoting is involved. For instance in Bourne Shell the delimiter used with here documents may or may not be separated by spaces from the ``<<`` token:: @@ -109,7 +109,7 @@ documents may or may not be separated by spaces from the ``<<`` token:: hello world -With the Varnish CLI, the ``<<`` and ``EOF`` tokens must be separated by +With the Vinyl Cache CLI, the ``<<`` and ``EOF`` tokens must be separated by at least one blank:: vcl.inline boot < @@ -67,7 +67,7 @@ OPTIONS The syntax and operation of the actual CLI interface is described in -the :ref:`varnish-cli(7)` manual page. Parameters are described in +the :ref:`vinyl-cli(7)` manual page. Parameters are described in :ref:`vinyld(1)` manual page. Additionally, a summary of commands can be obtained by issuing the @@ -77,27 +77,27 @@ the *param.show* command. EXIT STATUS =========== -If a command is given, the exit status of the `varnishadm` utility is +If a command is given, the exit status of the `vinyladm` utility is zero if the command succeeded, and non-zero otherwise. EXAMPLES ======== -Some ways you can use varnishadm:: +Some ways you can use vinyladm:: - varnishadm -T localhost:999 -S /var/db/secret vcl.use foo - echo vcl.use foo | varnishadm -T localhost:999 -S /var/db/secret - echo vcl.use foo | ssh vhost varnishadm -T localhost:999 -S /var/db/secret + vinyladm -T localhost:999 -S /var/db/secret vcl.use foo + echo vcl.use foo | vinyladm -T localhost:999 -S /var/db/secret + echo vcl.use foo | ssh vhost vinyladm -T localhost:999 -S /var/db/secret SEE ALSO ======== * :ref:`vinyld(1)` -* :ref:`varnish-cli(7)` +* :ref:`vinyl-cli(7)` AUTHORS ======= -The `varnishadm` utility and this manual page were written by Cecilie +The `vinyladm` utility and this manual page were written by Cecilie Fritzvold. This man page has later been modified by Per Buer, Federico G. Schwindt and Lasse Karstensen. diff --git a/doc/sphinx/reference/vinyld.rst b/doc/sphinx/reference/vinyld.rst index 5be01f937f..5d518dcaf7 100644 --- a/doc/sphinx/reference/vinyld.rst +++ b/doc/sphinx/reference/vinyld.rst @@ -7,9 +7,9 @@ .. _vinyld(1): -======== -varnishd -======== +====== +vinyld +====== ----------------------- HTTP accelerator daemon @@ -20,7 +20,7 @@ HTTP accelerator daemon SYNOPSIS ======== -varnishd +vinyld [-a [name=][listen_address[,PROTO|,option=value,...]] [-b [host[:port]|path]] [-C] @@ -45,18 +45,18 @@ varnishd [-V] [-W waiter] -varnishd [-x parameter|vsl|cli|builtin|optstring] +vinyld [-x parameter|vsl|cli|builtin|optstring] -varnishd [-?] +vinyld [-?] DESCRIPTION =========== -The `varnishd` daemon accepts HTTP requests from clients, passes them on +The `vinyld` daemon accepts HTTP requests from clients, passes them on to a backend server and caches the returned documents to better satisfy future requests for the same document. -.. _ref-varnishd-options: +.. _ref-vinyld-options: OPTIONS ======= @@ -104,7 +104,7 @@ Basic options Accept connections on a Unix domain socket. Path must be absolute ("/path/to/listen.sock") or "@" followed by the name of an abstract - socket ("@myvarnishd"). + socket ("@myvinyld"). The user, group and mode sub-arguments may be used to specify the permissions of the socket file -- use names for user and group, and @@ -117,7 +117,7 @@ Basic options the default is 8080. If the value of ``-b`` begins with ``/``, it is interpreted as the - absolute path of a Unix domain socket to which Varnish connects. In + absolute path of a Unix domain socket to which `vinyld` connects. In that case, the value of ``-b`` must satisfy the conditions required for the ``.path`` field of a backend declaration, see :ref:`vcl(7)`. Backends with Unix socket addresses may only be used with VCL @@ -138,8 +138,8 @@ Basic options Either -b or one or more -f options must be specified, but not both, and they cannot both be left out, unless -d is used to start - `varnishd` in debugging mode. If the empty string is specified as - the sole -f option, then `varnishd` starts without starting the + `vinyld` in debugging mode. If the empty string is specified as + the sole -f option, then `vinyld` starts without starting the worker process, and the management process will accept CLI commands. You can also combine an empty -f option with an initialization script (-I option) and the child process will be started if there @@ -147,9 +147,9 @@ Basic options When used with a relative file name, config is searched in the ``vcl_path``. It is possible to set this path prior to using ``-f`` - options with a ``-p`` option. During startup, `varnishd` doesn't - complain about unsafe VCL paths: unlike the `varnish-cli(7)` that - could later be accessed remotely, starting `varnishd` requires + options with a ``-p`` option. During startup, `vinyld` doesn't + complain about unsafe VCL paths: unlike the `vinyl-cli(7)` that + could later be accessed remotely, starting `vinyld` requires local privileges. .. include:: ../include/options.rst @@ -157,7 +157,7 @@ Basic options Documentation options --------------------- -For these options, `varnishd` prints information to standard output +For these options, `vinyld` prints information to standard output and exits. When a -x option is used, it must be the only option (it outputs documentation in reStructuredText, aka RST). @@ -172,13 +172,13 @@ outputs documentation in reStructuredText, aka RST). -x vsl - Print documentation of the tags used in the Varnish shared memory + Print documentation of the tags used in the Vinyld Cache shared memory log, see :ref:`vsl(7)`. -x cli Print documentation of the command line interface, see - :ref:`varnish-cli(7)`. + :ref:`vinyl-cli(7)`. -x builtin @@ -200,7 +200,7 @@ Operations options -T Offer a management interface on the specified address and port. See - :ref:`varnish-cli(7)` for documentation of the management commands. + :ref:`vinyl-cli(7)` for documentation of the management commands. To disable the management interface use ``none``. -M @@ -215,11 +215,11 @@ Operations options -i identity - Specify the identity of the Varnish server. This can be accessed + Specify the identity of the Vinyl Cache server. This can be accessed using ``server.identity`` from VCL. The server identity is used for the ``received-by`` field of ``Via`` - headers generated by Varnish. For this reason, it must be a valid + headers generated by Vinyl Cache. For this reason, it must be a valid token as defined by the HTTP grammar. If not specified the output of ``gethostname(3)`` is used, in which @@ -233,7 +233,7 @@ Operations options -E extension Load the named extension. Extensions are modules (VMODs) which can modify - varnishd behavior outside VCL, for example by adding storage- or protocol + `vinyld` behavior outside VCL, for example by adding storage- or protocol implementations. Extensions are always also VMODs, even if they do not provide any functionality to VCL, but in most cases they will. @@ -244,7 +244,7 @@ Operations options Otherwise, for `extention` ``ext``, a ``vmod_ext.so`` is searched for in ``vmod_path``. - ``varnishd`` startup fails if loading the extension fails for any reason. + ``vinyld`` startup fails if loading the extension fails for any reason. Tuning options -------------- @@ -280,7 +280,7 @@ Security options -r Make the listed parameters read only. This gives the system - administrator a way to limit what the Varnish CLI can do. Consider + administrator a way to limit what the Vinyl Cache CLI can do. Consider making parameters such as *cc_command*, *vcc_allow_inline_c* and *vmod_path* read only as these can potentially be used to escalate privileges from the CLI. @@ -293,9 +293,9 @@ Security options If this argument is not provided, a secret drawn from the system PRNG will be written to a file called ``_.secret`` in the working directory (see `opt_n`_) with default ownership and permissions of - the user having started varnish. + the user having started `vinyld`. - Thus, users wishing to delegate control over varnish will probably + Thus, users wishing to delegate control over `vinyld` will probably want to create a custom secret file with appropriate permissions (ie. readable by a unix group to delegate control to). @@ -344,7 +344,7 @@ The following hash algorithms are available: -h critbit - self-scaling tree structure. The default hash algorithm in Varnish + self-scaling tree structure. The default hash algorithm in Vinyl Cache 2.1 and onwards. In comparison to a more traditional B tree the critbit tree is almost completely lockless. Do not change this unless you are certain what you're doing. @@ -362,7 +362,7 @@ The following hash algorithms are available: default is 16383. -.. _ref-varnishd-opt_s: +.. _ref-vinyld-opt_s: Storage Backend --------------- @@ -375,7 +375,7 @@ The argument format to define storage backends is: -s <[name]=kind[,options]> - If *name* is omitted, Varnish will name storages ``s``\ *N*, + If *name* is omitted, `vinyld` will name storages ``s``\ *N*, starting with ``s0`` and incrementing *N* for every new storage. For *kind* and *options* see details below. @@ -417,7 +417,7 @@ The following storage types and options are available: platforms where it is available. See the section on umem in chapter `Storage backends` of `The - Varnish Users Guide` for details. + Vinyl Users Guide` for details. -s @@ -435,7 +435,7 @@ The following storage types and options are available: Granularity sets the allocation block size. Defaults to the system page size or the filesystem block size, whichever is larger. - Advice tells the kernel how `varnishd` expects to use this mapped + Advice tells the kernel how `vinyld` expects to use this mapped region so that the kernel can choose the appropriate read-ahead and caching techniques. Possible values are ``normal``, ``random`` and ``sequential``, corresponding to MADV_NORMAL, MADV_RANDOM and @@ -444,30 +444,30 @@ The following storage types and options are available: -s - Persistent storage. Varnish will store objects in a file in a manner + Persistent storage. `vinyld` will store objects in a file in a manner that will secure the survival of *most* of the objects in the event - of a planned or unplanned shutdown of Varnish. The persistent + of a planned or unplanned shutdown of `vinyld`. The persistent storage backend has multiple issues with it and will likely be - removed from a future version of Varnish. + removed from a future version of Vinyl Cache -.. _ref-varnishd-opt_j: +.. _ref-vinyld-opt_j: Jail ---- -Varnish jails are a generalization over various platform specific -methods to reduce the privileges of varnish processes. They may have +Vinyl Cache jails are a generalization over various platform specific +methods to reduce the privileges of `vinyld` processes. They may have specific options. Available jails are: -j - Reduce `privileges(5)` for `varnishd` and sub-processes to the + Reduce `privileges(5)` for `vinyld` and sub-processes to the minimally required set. Only available on platforms which have the `setppriv(2)` call. The optional `worker` argument can be used to pass a privilege-specification (see `ppriv(1)`) by which to extend the - effective set of the varnish worker process. While extended + effective set of the `vinyld` worker process. While extended privileges may be required by custom vmods, *not* using the `worker` option is always more secure. @@ -498,15 +498,15 @@ specific options. Available jails are: -j - Default on all other platforms when `varnishd` is started with an + Default on all other platforms when `vinyld` is started with an effective uid of 0 ("as root"). - With the ``unix`` jail mechanism activated, varnish will switch to + With the ``unix`` jail mechanism activated, `vinyld` will switch to an alternative user for subprocesses and change the effective uid of the master process whenever possible. The optional `user` argument specifies which alternative user to - use. It defaults to ``varnish``. + use. It defaults to ``vinyl``. The optional `ccgroup` argument specifies a group to add to varnish subprocesses requiring access to a c-compiler. There is no default. @@ -518,49 +518,49 @@ specific options. Available jails are: the same primary ("login") group. To set up a system for the default users with a group name - ``varnish``, shell commands similar to these may be used:: + ``vinyl``, shell commands similar to these may be used:: - groupadd varnish - useradd -g varnish -d /nonexistent -s /bin/false \ - -c "Varnish-Cache Daemon User" varnish - useradd -g varnish -d /nonexistent -s /bin/false \ - -c "Varnish-Cache Worker User" vcache + groupadd vinyl + useradd -g vinyl -d /nonexistent -s /bin/false \ + -c "Vinyl-Cache Daemon User" vinyl + useradd -g vinyl -d /nonexistent -s /bin/false \ + -c "Vinyl-Cache Worker User" vcache -j none - last resort jail choice: With jail mechanism ``none``, varnish will + last resort jail choice: With jail mechanism ``none``, `vinyld` will run all processes with the privileges it was started with. -.. _ref-varnishd-opt_T: +.. _ref-vinyld-opt_T: Management Interface -------------------- -If the -T option was specified, `varnishd` will offer a command-line +If the -T option was specified, `vinyld` will offer a command-line management interface on the specified address and port. The recommended way of connecting to the command-line management interface is through :ref:`vinyladm(1)`. -The commands available are documented in :ref:`varnish-cli(7)`. +The commands available are documented in :ref:`vinyl-cli(7)`. CLI Command File ---------------- The -I option makes it possible to run arbitrary management commands -when `varnishd` is launched, before the worker process is started. In +when `vinyld` is launched, before the worker process is started. In particular, this is the way to load configurations, apply labels to them, and make a VCL instance active that uses those labels on startup:: - vcl.load panic /etc/varnish_panic.vcl - vcl.load siteA0 /etc/varnish_siteA.vcl - vcl.load siteB0 /etc/varnish_siteB.vcl - vcl.load siteC0 /etc/varnish_siteC.vcl + vcl.load panic /etc/vinyl_panic.vcl + vcl.load siteA0 /etc/vinyl_siteA.vcl + vcl.load siteB0 /etc/vinyl_siteB.vcl + vcl.load siteC0 /etc/vinyl_siteC.vcl vcl.label siteA siteA0 vcl.label siteB siteB0 vcl.label siteC siteC0 - vcl.load main /etc/varnish_main.vcl + vcl.load main /etc/vinyl_main.vcl vcl.use main Every line in the file, including the last line, must be terminated by @@ -574,13 +574,13 @@ Note that it is necessary to include an explicit `vcl.use` command to select which VCL should be the active VCL when relying on CLI Command File to load the configurations at startup. -.. _ref-varnishd-params: +.. _ref-vinyld-params: RUN TIME PARAMETERS =================== Runtime parameters can either be set during startup with the ``-p`` command -line option for ``vinyld(1)`` or through the CLI using the ``param.set`` or +line option for `vinyld(1)` or through the CLI using the ``param.set`` or ``param.reset`` commands. They can be locked during startup with the ``-r`` command line option. @@ -665,7 +665,7 @@ flags are: * `only_root` - Only works if `varnishd` is running as root. + Only works if `vinyld` is running as root. Default Value Exceptions on 32 bit Systems ------------------------------------------ @@ -696,7 +696,7 @@ you use the param.show command: EXIT CODES ========== -Varnish and bundled tools will, in most cases, exit with one of the +Vinyl Cache and bundled tools will, in most cases, exit with one of the following codes * `0` OK @@ -704,10 +704,10 @@ following codes * `2` Serious configuration / parameter error - retrying with the same configuration / parameters is most likely useless -The `varnishd` master process may also OR its exit code +The `vinyld` master process may also OR its exit code -* with `0x20` when the `varnishd` child process died, -* with `0x40` when the `varnishd` child process was terminated by a +* with `0x20` when the `vinyld` child process died, +* with `0x40` when the `vinyld` child process was terminated by a signal and * with `0x80` when a core was dumped. @@ -719,14 +719,14 @@ SEE ALSO * :ref:`vinylncsa(1)` * :ref:`vinylstat(1)` * :ref:`vinyltop(1)` -* :ref:`varnish-cli(7)` +* :ref:`vinyl-cli(7)` * :ref:`vcl(7)` HISTORY ======= -The `varnishd` daemon was developed by Poul-Henning Kamp in cooperation -with Verdens Gang AS and Varnish Software. +The `vinyld` daemon was developed by Poul-Henning Kamp in cooperation +with Verdens Gang AS and Redpill-Linpro This manual page was written by Dag-Erling Smørgrav with updates by Stig Sandbeck Mathisen , Nils Goroll and others. @@ -735,7 +735,7 @@ Stig Sandbeck Mathisen , Nils Goroll and others. COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinyl Cache itself. See LICENCE for details. * Copyright (c) 2007-2015 Varnish Software AS diff --git a/doc/sphinx/reference/vinylhist.rst b/doc/sphinx/reference/vinylhist.rst index 833349e4e2..76776246d5 100644 --- a/doc/sphinx/reference/vinylhist.rst +++ b/doc/sphinx/reference/vinylhist.rst @@ -7,13 +7,13 @@ .. _vinylhist(1): -=========== -varnishhist -=========== +========= +vinylhist +========= -------------------------- -Varnish request histogram -------------------------- +----------------------------- +Vinyl Cache request histogram +----------------------------- :Manual section: 1 @@ -21,12 +21,12 @@ SYNOPSIS ======== .. include:: ../include/vinylhist_synopsis.rst -varnishhist |synopsis| +vinylhist |synopsis| DESCRIPTION =========== -The varnishhist utility reads vinyld(1) shared memory logs and +The vinylhist utility reads vinyld(1) shared memory logs and presents a continuously updated histogram showing the distribution of the last N requests by their processing. The value of N and the vertical scale are displayed in the top left corner. The horizontal @@ -49,8 +49,8 @@ SEE ALSO HISTORY ======= -The varnishhist utility was developed by Poul-Henning Kamp in cooperation with -Verdens Gang AS and Varnish Software AS. This manual page was written by +The vinylhist utility was developed by Poul-Henning Kamp in cooperation with +Verdens Gang AS and Redpill-Linpro. This manual page was written by Dag-Erling Smørgrav. COPYRIGHT diff --git a/doc/sphinx/reference/vinyllog.rst b/doc/sphinx/reference/vinyllog.rst index bcbb4ea236..518514e23d 100644 --- a/doc/sphinx/reference/vinyllog.rst +++ b/doc/sphinx/reference/vinyllog.rst @@ -7,13 +7,13 @@ .. _vinyllog(1): -========== -varnishlog -========== +======== +vinyllog +======== --------------------- -Display Varnish logs --------------------- +------------------------ +Display Vinyl Cache logs +------------------------ :Manual section: 1 @@ -21,7 +21,7 @@ SYNOPSIS ======== .. include:: ../include/vinyllog_synopsis.rst -varnishlog |synopsis| +vinyllog |synopsis| OPTIONS ======= @@ -55,9 +55,9 @@ SEE ALSO HISTORY ======= -The varnishlog utility was developed by Poul-Henning Kamp +The vinyllog utility was developed by Poul-Henning Kamp in cooperation with Verdens Gang AS and -Varnish Software AS. This manual page was initially written by Dag-Erling +Redpill-Linpro. This manual page was initially written by Dag-Erling Smørgrav, and later updated by Per Buer and Martin Blix Grydeland. diff --git a/doc/sphinx/reference/vinylncsa.rst b/doc/sphinx/reference/vinylncsa.rst index ca702a7773..04dde5ab4c 100644 --- a/doc/sphinx/reference/vinylncsa.rst +++ b/doc/sphinx/reference/vinylncsa.rst @@ -7,13 +7,13 @@ .. _vinylncsa(1): -=========== -varnishncsa -=========== +========= +vinylncsa +========= ---------------------------------------------------------- -Display Varnish logs in Apache / NCSA combined log format ---------------------------------------------------------- +------------------------------------------------------------- +Display Vinyl Cache logs in Apache / NCSA combined log format +------------------------------------------------------------- :Manual section: 1 @@ -21,12 +21,12 @@ SYNOPSIS ======== .. include:: ../include/vinylncsa_synopsis.rst -varnishncsa |synopsis| +vinylncsa |synopsis| DESCRIPTION =========== -The varnishncsa utility reads vinyld(1) shared memory logs and +The vinylncsa utility reads vinyld(1) shared memory logs and presents them in the Apache / NCSA "combined" log format. Each log line produced is based on a single Request type transaction @@ -42,30 +42,30 @@ The following options are available: MODES ===== -The default mode of varnishncsa is "client mode". In this mode, the +The default mode of `vinylncsa` is "client mode". In this mode, the log will be similar to what a web server would produce in the absence -of varnish. Client mode can be explicitly selected by using -c. +of Vinyl Cache. Client mode can be explicitly selected by using -c. -If the -b switch is specified, varnishncsa will operate in "backend -mode". In this mode, requests generated by varnish to the backends +If the -b switch is specified, vinylncsa will operate in "backend +mode". In this mode, requests generated by Vinyl Cache to the backends will be logged. Unless -c is also specified, client requests received -by varnish will be ignored. +by `vinyld` will be ignored. -When running varnishncsa in both backend and client mode, it is -strongly advised to include the format specifier %{Varnish:side}x to +When running vinylncsa in both backend and client mode, it is +strongly advised to include the format specifier %{Vinyl:side}x to distinguish between backend and client requests. Client requests that results in a pipe (ie. return(pipe) in vcl), will -not generate logging in backend mode. This is because varnish is not +not generate logging in backend mode. This is because Vinyl Cache is not generating requests, but blindly passes on bytes in both directions. -However, a varnishncsa instance running in normal mode can see this -case by using the formatter %{Varnish:handling}x, which will be 'pipe'. +However, a vinylncsa instance running in normal mode can see this +case by using the formatter %{Vinyl:handling}x, which will be 'pipe'. In backend mode, some of the fields in the format string get different meanings. Most notably, the byte counting formatters (%b, %I, %O) -considers varnish to be the client. +considers `vinyld` to be the client. -It is possible to keep two varnishncsa instances running, one in +It is possible to keep two vinylncsa instances running, one in backend mode, and one in client mode, logging to different files. .. _ncsa-format: @@ -186,33 +186,33 @@ Supported formatters are: %{X}x Extended variables. Supported variables are: - Varnish:default_format + Vinyl:default_format The log format used when neither -f nor -F options are specified. Useful for appending/prepending with other formatters. - Varnish:time_firstbyte + Vinyl:time_firstbyte Time from when the request processing starts until the first byte is sent to the client, in seconds. For backend mode: Time from the request was sent to the backend to the entire header had been received. - Varnish:hitmiss + Vinyl:hitmiss In client mode, one of the 'hit' or 'miss' strings, depending on whether the request was a cache hit or miss. Pipe, pass and synth are considered misses. In backend mode, this field is blank. - Varnish:handling + Vinyl:handling In client mode, one of the 'hit', 'hitmiss', 'hitpass', 'miss', 'pass', 'pipe' or 'synth' strings indicating how the request was handled. In backend mode, this field is blank. - Varnish:side + Vinyl:side Backend or client side. One of two values, 'b' or 'c', depending on where the request was made. In pure backend or client mode, this field will be constant. - Varnish:vxid - The VXID of the varnish transaction. + Vinyl:vxid + The VXID of the `vinyld` transaction. VCL_Log:key The value set by std.log("key:value") in VCL. @@ -277,21 +277,21 @@ EXAMPLE Log the second field of the Begin record, corresponding to the VXID of the parent transaction:: - varnishncsa -F "%{VSL:Begin[2]}x" + vinylncsa -F "%{VSL:Begin[2]}x" Log the entire Timestamp record associated with the processing length:: - varnishncsa -F "%{VSL:Timestamp:Process}x" + vinylncsa -F "%{VSL:Timestamp:Process}x" Log in JSON, using the -j flag to ensure that the output is valid JSON for all inputs:: - varnishncsa -j -F '{"size": %b, "time": "%t", "ua": "%{User-Agent}i"}' + vinylncsa -j -F '{"size": %b, "time": "%t", "ua": "%{User-Agent}i"}' Log the first and last values of a request header that is modified multiple times in VCL: - varnishncsa -F "%{x-custom-header:first}i %{x-custom-header:last}i" + vinylncsa -F "%{x-custom-header:first}i %{x-custom-header:last}i" SEE ALSO ======== @@ -305,8 +305,8 @@ SEE ALSO HISTORY ======= -The varnishncsa utility was developed by Poul-Henning Kamp in -cooperation with Verdens Gang AS and Varnish Software AS. This manual page was +The vinylncsa utility was developed by Poul-Henning Kamp in +cooperation with Verdens Gang AS and Redpill-Linpro. This manual page was initially written by Dag-Erling Smørgrav , and later updated by Martin Blix Grydeland and Pål Hermunn Johansen. @@ -314,7 +314,7 @@ by Martin Blix Grydeland and Pål Hermunn Johansen. COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinly Cache itself. See LICENCE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vinylstat.rst b/doc/sphinx/reference/vinylstat.rst index 258a9e2adb..1153d59ae0 100644 --- a/doc/sphinx/reference/vinylstat.rst +++ b/doc/sphinx/reference/vinylstat.rst @@ -7,13 +7,13 @@ .. _vinylstat(1): -=========== -varnishstat -=========== +========= +vinylstat +========= ------------------------- -Varnish Cache statistics ------------------------- +---------------------- +Vinyl Cache statistics +---------------------- :Manual section: 1 @@ -21,12 +21,12 @@ SYNOPSIS ======== .. include:: ../include/vinylstat_synopsis.rst -varnishstat |synopsis| +vinylstat |synopsis| DESCRIPTION =========== -The varnishstat utility displays statistics from a running vinyld(1) instance. +The vinylstat utility displays statistics from a running vinyld(1) instance. The following options are available: @@ -64,7 +64,7 @@ Change Average The average value of this counter over the runtime of the - Varnish daemon, or a period if the counter can't be averaged. + `vinyld` daemon, or a period if the counter can't be averaged. Avg_10 The moving average over the last 10 update intervals. @@ -85,7 +85,7 @@ OUTPUTS The XML output format is:: - + FIELD NAME FIELD VALUE @@ -94,7 +94,7 @@ The XML output format is:: FIELD DESCRIPTION [..] - + The JSON output format is:: @@ -114,7 +114,7 @@ The JSON output format is:: } -Timestamp is the time when the report was generated by varnishstat. +Timestamp is the time when the report was generated by vinylstat. SEE ALSO @@ -126,7 +126,7 @@ SEE ALSO * :ref:`vinylncsa(1)` * :ref:`vinyltop(1)` * curses(3) -* :ref:`varnish-counters(7)` +* :ref:`vinyl-counters(7)` AUTHORS diff --git a/doc/sphinx/reference/vinyltest.rst b/doc/sphinx/reference/vinyltest.rst index 5a1235870e..5dd0e2d205 100644 --- a/doc/sphinx/reference/vinyltest.rst +++ b/doc/sphinx/reference/vinyltest.rst @@ -7,30 +7,30 @@ .. _vinyltest(1): -=========== -varnishtest -=========== +========= +vinyltest +========= ------------------------- -Test program for Varnish ------------------------- +---------------------------- +Test program for Vinyl Cache +---------------------------- :Manual section: 1 SYNOPSIS ======== -varnishtest [-hikLlqv] [-b size] [-D name=val] [-j jobs] [-n iter] [-t duration] file [file ...] +vinyltest [-hikLlqv] [-b size] [-D name=val] [-j jobs] [-n iter] [-t duration] file [file ...] DESCRIPTION =========== -The varnishtest program is a script driven program used to test the -Varnish Cache. +The `vinyltest` program is a script driven program used to test the +Vinyl Cache. -The varnishtest program, when started and given one or more script +The `vinyltest` program, when started and given one or more script files, can create a number of threads representing backends, some -threads representing clients, and a varnishd process. This is then used to +threads representing clients, and a `vinyld` process. This is then used to simulate a transaction to provoke a specific behavior. The following options are available: @@ -41,7 +41,7 @@ The following options are available: -h Show help --i Set PATH and vmod_path to find varnish binaries in build tree +-i Set PATH and vmod_path to find Vinyl Cache binaries in build tree -j jobs Run this many tests in parallel @@ -53,7 +53,7 @@ The following options are available: -n iterations Run tests this many times --p name=val Pass parameters to all varnishd command lines +-p name=val Pass parameters to all `vinyld` command lines -q Quiet mode: report only failures @@ -64,20 +64,20 @@ The following options are available: file File to use as a script -If `TMPDIR` is set in the environment, varnishtest creates temporary +If `TMPDIR` is set in the environment, `vinyltest` creates temporary `vtc.*` directories for each test in `$TMPDIR`, otherwise in `/tmp`. SCRIPTS ======= The vtc syntax is documented at length in :ref:`vtc(7)`. Should you want more -examples than the one below, you can have a look at the Varnish source code -repository, under `bin/varnishtest/tests/`, where all the regression tests for -Varnish are kept. +examples than the one below, you can have a look at the Vinyl Cache source code +repository, under `bin/vinyltest/tests/`, where all the regression tests for +Vinyl Cache are kept. An example:: - varnishtest "#1029" + vinyltest "#1029" server s1 { rxreq @@ -90,7 +90,7 @@ An example:: } -start - varnish v1 -vcl+backend { + vinyl v1 -vcl+backend { sub vcl_backend_response { set beresp.do_esi = true; if (bereq.url == "/foo") { @@ -113,7 +113,7 @@ An example:: } -run When run, the above script will simulate a server (s1) that expects -two different requests. It will start a Varnish server (v1) and add the +two different requests. It will start a `vinyld` (v1) and add the backend definition to the VCL specified (-vcl+backend). Finally it starts the c1-client, which is a single client sending two requests. @@ -121,17 +121,17 @@ TESTING A BUILD TREE ==================== Whether you are building a VMOD or trying to use one that you freshly -built, you can tell ``varnishtest`` to pass a *vmod_path* to ``varnishd`` -instances started using the ``varnish -start`` command in your test case:: +built, you can tell ``vinyltest`` to pass a *vmod_path* to ``vinyld`` +instances started using the ``vinyl -start`` command in your test case:: - varnishtest -p vmod_path=... /path/to/*.vtc + vinyltest -p vmod_path=... /path/to/*.vtc This way you can use the same test cases on both installed and built VMODs:: server s1 {...} -start - varnish v1 -vcl+backend { + vinyl v1 -vcl+backend { import wossname; ... @@ -144,42 +144,42 @@ allowing you to run a build matrix without changing the test suite. You can achieve the same with macros, but then they need to be defined on each run. -You can see the actual ``varnishd`` command lines in test outputs, +You can see the actual ``vinyld`` command lines in test outputs, they look roughly like this:: - exec varnishd [varnishtest -p params] [testing params] [vtc -arg params] + exec vinyld [vinyltest -p params] [testing params] [vtc -arg params] -Parameters you define with ``varnishtest -p`` may be overridden by -parameters needed by ``varnishtest`` to run properly, and they may in +Parameters you define with ``vinyltest -p`` may be overridden by +parameters needed by ``vinyltest`` to run properly, and they may in turn be overridden by parameters set in test scripts. -There's also a special mode in which ``varnishtest`` builds itself a -PATH and a *vmod_path* in order to find Varnish binaries (programs and -VMODs) in the build tree surrounding the ``varnishtest`` binary. This -is meant for testing of Varnish under development and will disregard +There's also a special mode in which ``vinyltest`` builds itself a +PATH and a *vmod_path* in order to find Vinyl Cache binaries (programs and +VMODs) in the build tree surrounding the ``vinyltest`` binary. This +is meant for testing of Vinyl Cache under development and will disregard your *vmod_path* if you set one. -If you need to test your VMOD against a Varnish build tree, you must +If you need to test your VMOD against a Vinyl Cache build tree, you must install it first, in a temp directory for instance. With information provided by the installation's *pkg-config(1)* you can build a proper -PATH in order to access Varnish programs, and a *vmod_path* to access +PATH in order to access Vinyl programs, and a *vmod_path* to access both your VMOD and the built-in VMODs:: export PKG_CONFIG_PATH=/path/to/install/lib/pkgconfig - BINDIR="$(pkg-config --variable=bindir varnishapi)" - SBINDIR="$(pkg-config --variable=sbindir varnishapi)" + BINDIR="$(pkg-config --variable=bindir vinylapi)" + SBINDIR="$(pkg-config --variable=sbindir vinylapi)" PATH="SBINDIR:BINDIR:$PATH" - VMODDIR="$(pkg-config --variable=vmoddir varnishapi)" + VMODDIR="$(pkg-config --variable=vmoddir vinylapi)" VMOD_PATH="/path/to/your/vmod/build/dir:$VMODDIR" - varnishtest -p vmod_path="$VMOD_PATH" ... + vinyltest -p vmod_path="$VMOD_PATH" ... SEE ALSO ======== -* varnishtest source code repository with tests +* vinyltest source code repository with tests * :ref:`vinylhist(1)` * :ref:`vinyllog(1)` * :ref:`vinylncsa(1)` @@ -192,8 +192,8 @@ SEE ALSO HISTORY ======= -The varnishtest program was developed by Poul-Henning Kamp - in cooperation with Varnish Software AS. This manual +The vinyltest program was developed by Poul-Henning Kamp + in cooperation with Redpill-Linpro. This manual page was originally written by Stig Sandbeck Mathisen and updated by Kristian Lyngstøl . @@ -201,7 +201,7 @@ and updated by Kristian Lyngstøl . COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinyl Cache itself. See LICENCE for details. * Copyright (c) 2007-2016 Varnish Software AS diff --git a/doc/sphinx/reference/vinyltop.rst b/doc/sphinx/reference/vinyltop.rst index 907212deda..4fb2a4e52b 100644 --- a/doc/sphinx/reference/vinyltop.rst +++ b/doc/sphinx/reference/vinyltop.rst @@ -7,13 +7,13 @@ .. _vinyltop(1): -========== -varnishtop -========== +======== +vinyltop +======== -------------------------- -Varnish log entry ranking -------------------------- +------------------------------------ +Vinyl Cache log entry real-time view +------------------------------------ :Manual section: 1 @@ -21,12 +21,12 @@ SYNOPSIS ======== .. include:: ../include/vinyltop_synopsis.rst -varnishtop |synopsis| +vinyltop |synopsis| DESCRIPTION =========== -The varnishtop utility reads :ref:`vinyld(1)` shared memory logs and +The `vinyltop` utility reads :ref:`vinyld(1)` shared memory logs and presents a continuously updated list of the most commonly occurring log entries. With suitable filtering using the ``-I``, ``-i``, ``-X`` and ``-x`` options, it can be used to display a ranking of requested @@ -43,12 +43,12 @@ EXAMPLES The following example displays a continuously updated list of the most frequently requested URLs:: - varnishtop -i ReqURL + vinyltop -i ReqURL The following example displays a continuously updated list of the most commonly used user agents:: - varnishtop -C -I ReqHeader:User-Agent + vinyltop -C -I ReqHeader:User-Agent SEE ALSO ======== @@ -62,8 +62,8 @@ SEE ALSO HISTORY ======= -The varnishtop utility was originally developed by Poul-Henning Kamp -in cooperation with Verdens Gang AS and Varnish Software AS, and later +The `vinyltop` utility was originally developed by Poul-Henning Kamp +in cooperation with Verdens Gang AS and Redpill-Linpro, and later substantially rewritten by Dag-Erling Smørgrav. This manual page was written by Dag-Erling Smørgrav, and later updated by Martin Blix Grydeland. diff --git a/doc/sphinx/reference/vmod.rst b/doc/sphinx/reference/vmod.rst index ee2d7e6261..87147124e9 100644 --- a/doc/sphinx/reference/vmod.rst +++ b/doc/sphinx/reference/vmod.rst @@ -51,10 +51,10 @@ Getting started writing VMODs There are some projects which can help interested developers get started writing VMODs: -.. _`Varnish Cache Development Kit`: https://git.sr.ht/~dridi/vcdk +.. _`Vinyl Cache Development Kit`: https://git.sr.ht/~dridi/vcdk .. _`varnish-rs`: https://github.com/varnish-rs/varnish-rs -* For the C programming language, there is the `Varnish Cache Development Kit`_ +* For the C programming language, there is the `Vinyl Cache Development Kit`_ (VCDK) * Rustacians might want to have a look at `varnish-rs`_. diff --git a/doc/sphinx/reference/vsm.rst b/doc/sphinx/reference/vsm.rst index 6378efb69f..5c0c103568 100644 --- a/doc/sphinx/reference/vsm.rst +++ b/doc/sphinx/reference/vsm.rst @@ -52,7 +52,7 @@ Inside the varnishd (worker) process, we use mutexes to guarantee consistency, both with respect to allocations, log entries and stats counters. -We do not want a varnishncsa trying to push data through a stalled +We do not want a vinylncsa trying to push data through a stalled ssh connection to stall the delivery of content, so readers like that are purely read-only, they do not get to affect the varnishd process and that means no locks for them. diff --git a/doc/sphinx/reference/vtla.rst b/doc/sphinx/reference/vtla.rst index 9bf19e6038..2f847f0b72 100644 --- a/doc/sphinx/reference/vtla.rst +++ b/doc/sphinx/reference/vtla.rst @@ -119,7 +119,7 @@ VTLA VUG Varnish User Group meeting -- Half-yearly event where the users and - developers of Varnish Cache gather to share experiences and plan + developers of Vinyl Cache gather to share experiences and plan future development. VUT diff --git a/doc/sphinx/tutorial/peculiarities.rst b/doc/sphinx/tutorial/peculiarities.rst index d62aa49e90..21c2cdcc4d 100644 --- a/doc/sphinx/tutorial/peculiarities.rst +++ b/doc/sphinx/tutorial/peculiarities.rst @@ -7,7 +7,7 @@ Peculiarities ------------- -There are a couple of things that are different with Varnish Cache, as +There are a couple of things that are different with Vinyl Cache, as opposed to other programs. One thing you've already seen - VCL. In this section we provide a very quick tour of other peculiarities you need to know about to get the most out of Varnish. Configuration @@ -24,10 +24,10 @@ settings on or off, you write polices on how the incoming traffic should be handled. -varnishadm +vinyladm ~~~~~~~~~~ -Varnish Cache has an admin console. You can connect it through the +Vinyl Cache has an admin console. You can connect it through the :ref:`vinyladm(1)` command. In order to connect the user needs to be able to read `/etc/varnish/secret` in order to authenticate. @@ -40,7 +40,7 @@ what it does. .. XXX:sample of the command here. benc -varnishlog +vinyllog ~~~~~~~~~~ Varnish does not log to disk. Instead it logs to a chunk of memory. It diff --git a/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst b/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst index 79f410b826..32c4c8ea13 100644 --- a/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst +++ b/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst @@ -48,7 +48,7 @@ Applying changes to the default service is best done by creating a new file ExecStart=/usr/sbin/varnishd -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s default,256m This will override the ExecStart part of the default configuration shipped -with Varnish Cache. +with Vinyl Cache. Run ``systemctl daemon-reload`` to make sure systemd picks up the new configuration before restarting Varnish. diff --git a/doc/sphinx/users-guide/command-line.rst b/doc/sphinx/users-guide/command-line.rst index a727f2294e..df20904657 100644 --- a/doc/sphinx/users-guide/command-line.rst +++ b/doc/sphinx/users-guide/command-line.rst @@ -75,4 +75,4 @@ Optional arguments ^^^^^^^^^^^^^^^^^^ For a complete list of the command line arguments please see -:ref:`vinyld(1) options `. +:ref:`vinyld(1) options `. diff --git a/doc/sphinx/users-guide/increasing-your-hitrate.rst b/doc/sphinx/users-guide/increasing-your-hitrate.rst index b90c93a0e6..53e6e0f3c3 100644 --- a/doc/sphinx/users-guide/increasing-your-hitrate.rst +++ b/doc/sphinx/users-guide/increasing-your-hitrate.rst @@ -26,21 +26,21 @@ this is to use :ref:`vinyllog(1)` and :ref:`vinyltop(1)` but sometimes a client-side tool makes sense. Here are the ones we commonly use. -Tool: varnishtop +Tool: vinyltop ~~~~~~~~~~~~~~~~ -You can use varnishtop to identify what URLs are hitting the backend -the most. ``varnishtop -i BereqURL`` is an essential command, showing +You can use vinyltop to identify what URLs are hitting the backend +the most. ``vinyltop -i BereqURL`` is an essential command, showing you the top requests Varnish is sending to the backend. You can see some other examples of :ref:`vinyltop(1)` usage in :ref:`users-guide-statistics`. -Tool: varnishlog +Tool: vinyllog ~~~~~~~~~~~~~~~~ When you have identified an URL which is frequently sent to the backend you can use :ref:`vinyllog(1)` to have a look at the -request. ``varnishlog -q 'ReqURL ~ "^/foo/bar"'`` will show you the +request. ``vinyllog -q 'ReqURL ~ "^/foo/bar"'`` will show you the requests coming from the client matching `/foo/bar`. For more information on how :ref:`vinyllog(1)` works please see @@ -212,7 +212,7 @@ copies it back to the request, deleting the original cookie header. } There are other scary examples of what can be done in VCL in the -Varnish Cache Wiki. +Vinyl Cache Wiki. .. XXX:Missing link here. @@ -246,7 +246,7 @@ Age Varnish adds an 'Age' header to indicate how long the object has been kept inside Varnish. You can grep out 'Age' from :ref:`vinyllog(1)` -with ``varnishlog -I RespHeader:^Age``. +with ``vinyllog -I RespHeader:^Age``. Pragma ~~~~~~ diff --git a/doc/sphinx/users-guide/intro.rst b/doc/sphinx/users-guide/intro.rst index 735571d3ca..f73fb22751 100644 --- a/doc/sphinx/users-guide/intro.rst +++ b/doc/sphinx/users-guide/intro.rst @@ -13,7 +13,7 @@ In this section we will cover answers to the questions: - what are all the different bits and pieces named? - Will you need a hex-wrench for assembly? -The two main parts of Varnish are the two processes in the `varnishd` +The two main parts of Varnish are the two processes in the `vinyld` program. The first process is called "the manager", and its job is to talk to you, the administrator, and make the things you ask for happen. @@ -22,7 +22,7 @@ The second process is called "the worker" or just "the child" and this is the process which does all the actual work with your HTTP traffic. -When you start `varnishd`, you start the manager process, and once it is +When you start `vinyld`, you start the manager process, and once it is done handling all the command line flags, it will start the child process for you. Should the child process die, the manager will start it again for you, automatically and right away. @@ -92,7 +92,7 @@ of cache hit-rate, resource usage and specific performance indicating metrics. Varnish comes with a number of tools which reports from shared -memory, `varnishlog`, `varnishstats`, `varnishncsa` etc, and with an API +memory, `vinyllog`, `vinylstats`, `vinylncsa` etc, and with an API library so you can write your own tools, should you need that. :ref:`users_report` explains how all that work. diff --git a/doc/sphinx/users-guide/operation-logging.rst b/doc/sphinx/users-guide/operation-logging.rst index 47772e28ae..f4d19b7e35 100644 --- a/doc/sphinx/users-guide/operation-logging.rst +++ b/doc/sphinx/users-guide/operation-logging.rst @@ -20,12 +20,12 @@ when you need it. The flip side is that if you forget to have a program actually write the logs to disk they will be overwritten. -`varnishlog` is one of the programs you can use to look at what Varnish -is logging. `varnishlog` gives you the raw logs, everything that is +`vinyllog` is one of the programs you can use to look at what Varnish +is logging. `vinyllog` gives you the raw logs, everything that is written to the logs. There are other clients that can access the logs as well, we'll show you these later. -In the terminal window you started Varnish now type ``varnishlog -g raw`` +In the terminal window you started Varnish now type ``vinyllog -g raw`` and press enter. You'll see lines like these scrolling slowly by.:: @@ -61,7 +61,7 @@ The third column tell us whether this is is data coming from or going to the client ('c'), or the backend ('b'). The forth column is the data being logged. -Now, you can filter quite a bit with `varnishlog`. The basic options we think you +Now, you can filter quite a bit with `vinyllog`. The basic options we think you want to know are: '-b' diff --git a/doc/sphinx/users-guide/operation-statistics.rst b/doc/sphinx/users-guide/operation-statistics.rst index cc24c67d48..d67543d408 100644 --- a/doc/sphinx/users-guide/operation-statistics.rst +++ b/doc/sphinx/users-guide/operation-statistics.rst @@ -13,8 +13,8 @@ Varnish comes with a couple of nifty and very useful statistics generating tools .. XXX:Heavy rewrite above. benc -varnishtop -~~~~~~~~~~ +vinyltop +~~~~~~~~ The :ref:`vinyltop(1)` utility reads the shared memory logs and presents a continuously updated list of the most commonly occurring log entries. @@ -23,13 +23,13 @@ With suitable filtering using the -I, -i, -X and -x options, it can be used to display a ranking of requested documents, clients, user agents, or any other information which is recorded in the log. -``varnishtop -i ReqURL`` will show you what URLs are being asked for by -the client. ``varnishtop -i BereqURL`` will show you what your backend -is being asked the most. ``varnishtop -I ReqHeader:Accept-Encoding`` will +``vinyltop -i ReqURL`` will show you what URLs are being asked for by +the client. ``vinyltop -i BereqURL`` will show you what your backend +is being asked the most. ``vinyltop -I ReqHeader:Accept-Encoding`` will show the most popular Accept-Encoding header the client are sending you. -varnishhist -~~~~~~~~~~~ +vinylhist +~~~~~~~~~ The :ref:`vinylhist(1)` utility reads :ref:`vinyld(1)` shared memory logs and presents a continuously updated histogram showing the @@ -38,8 +38,8 @@ The value of N and the vertical scale are displayed in the top left corner. The horizontal scale is logarithmic. Hits are marked with a pipe character ("|"), and misses are marked with a hash character ("#"). -varnishstat -~~~~~~~~~~~ +vinylstat +~~~~~~~~~ Varnish has lots of counters. We count misses, hits, information about the storage, threads created, deleted objects. Just about diff --git a/doc/sphinx/users-guide/params.rst b/doc/sphinx/users-guide/params.rst index 2d7e85b497..6f9a13291e 100644 --- a/doc/sphinx/users-guide/params.rst +++ b/doc/sphinx/users-guide/params.rst @@ -8,9 +8,9 @@ Parameters ---------- -Varnish Cache comes with a set of parameters that affects behaviour and +Vinyl Cache comes with a set of parameters that affects behaviour and performance. Parameters are set either though command line -arguments to ``varnishd`` or at runtime through ``varnishadm`` using +arguments to ``vinyld`` or at runtime through ``vinyladm`` using the ``param.set`` CLI command. We don't recommend that you tweak parameters unless you're sure of what diff --git a/doc/sphinx/users-guide/purging.rst b/doc/sphinx/users-guide/purging.rst index 6724c7635a..4820611a4c 100644 --- a/doc/sphinx/users-guide/purging.rst +++ b/doc/sphinx/users-guide/purging.rst @@ -78,7 +78,7 @@ Support for bans is built into Varnish and available in the CLI interface. To ban every png object belonging on example.com, issue the following command from the shell:: - varnishadm ban req.http.host == example.com '&&' req.url '~' '\\.png$' + vinyladm ban req.http.host == example.com '&&' req.url '~' '\\.png$' See :ref:`std.ban()` for details on the syntax of ban expressions. In particular, note that in the example given above, the quotes are diff --git a/doc/sphinx/users-guide/run_cli.rst b/doc/sphinx/users-guide/run_cli.rst index fd5cb1c2d1..51100ec380 100644 --- a/doc/sphinx/users-guide/run_cli.rst +++ b/doc/sphinx/users-guide/run_cli.rst @@ -8,28 +8,28 @@ CLI - bossing Varnish around ============================ -Once ``varnishd`` is started, you can control it using the ``varnishadm`` +Once ``vinyld`` is started, you can control it using the ``vinyladm`` program and the command line interface:: - varnishadm help + vinyladm help -If you want to run ``varnishadm`` from a remote system, we recommend -you use ``ssh`` into the system where ``varnishd`` runs. (But see also: +If you want to run ``vinyladm`` from a remote system, we recommend +you use ``ssh`` into the system where ``vinyld`` runs. (But see also: :ref:`Local and remote CLI connections `) -You can SSH into the ``varnishd`` computer and run ``varnishadm``:: +You can SSH into the ``vinyld`` computer and run ``vinyladm``:: - ssh $hostname varnishadm help + ssh $hostname vinyladm help -If you give no command arguments, ``varnishadm`` runs in interactive mode +If you give no command arguments, ``vinyladm`` runs in interactive mode with command-completion, command-history and other comforts: .. code-block:: text - critter phk> ./varnishadm + critter phk> ./vinyladm 200 ----------------------------- - Varnish Cache CLI 1.0 + Vinyl Cache CLI 1.0 ----------------------------- FreeBSD,13.0-CURRENT,amd64,-jnone,-sdefault,-sdefault,-hcritbit varnish-trunk revision 2bd5d2adfc407216ebaa653fae882d3c8d47f5e1 @@ -48,7 +48,7 @@ prevented the execution of the command. (If you get 201, it means that the output was truncated, See the :ref:`ref_param_cli_limit` parameter.) -When commands are given as arguments to ``varnishadm``, a status +When commands are given as arguments to ``vinyladm``, a status different than 200 or 201 will cause it to exit with status 1 and print the status code on standard error. @@ -182,7 +182,7 @@ and:: varnish> start -If you start ``varnishd`` with the '-d' (debugging) argument, you will +If you start ``vinyld`` with the '-d' (debugging) argument, you will always need to start the child process explicitly. Should the child process die, the master process will automatically diff --git a/doc/sphinx/users-guide/storage-backends.rst b/doc/sphinx/users-guide/storage-backends.rst index e488cf867a..64780e05fd 100644 --- a/doc/sphinx/users-guide/storage-backends.rst +++ b/doc/sphinx/users-guide/storage-backends.rst @@ -55,7 +55,7 @@ Malloc is a virtual memory based storage backend. Each object will be allocated using whatever ``malloc()`` implementation is in effect. If configured, virtual memory might get paged in and out to swap space by the operating system. -The size parameter specifies the maximum *net* amount of memory `varnishd` will +The size parameter specifies the maximum *net* amount of memory `vinyld` will allocate. The size is assumed to be in bytes, unless followed by one of the following suffixes: @@ -74,8 +74,8 @@ the total size of headers), segmented body data and metadata for the storage engine itself. This *net* amount of memory is the sum of all allocation sizes from the -perspective of `varnishd`, but for the actual *gross* amount, two additional -factors need to be considered: `varnishd` also requires memory outside the +perspective of `vinyld`, but for the actual *gross* amount, two additional +factors need to be considered: `vinyld` also requires memory outside the storage engine in the order of 1KB per object. And, more importantly, due to fragmentation, the amount of memory actually used by the malloc implementation might be substantially higher by a factor of typically **two to four times**. @@ -115,7 +115,7 @@ is output:: to indicate that `libumem`_ will not only be used for storage. Likely reasons for this to be the case are: -* some library ``varnishd`` is linked against was linked against +* some library ``vinyld`` is linked against was linked against `libumem`_ (most likely ``libpcre2-8``, check with ``ldd``) * ``LD_PRELOAD_64=/usr/lib/amd64/libumem.so.1``, @@ -154,7 +154,7 @@ for this limit like control groups (Linux) or resource controls .. XXX idk about the BSD and macOS abstractions -- slink The 'path' parameter specifies either the path to the backing file or -the path to a directory in which `varnishd` will create the backing file. +the path to a directory in which `vinyld` will create the backing file. The size parameter specifies the size of the backing file. The size is assumed to be in bytes, unless followed by one of the following @@ -175,7 +175,7 @@ existing file it is an error to not specify the size. If the backing file already exists, it will be truncated or expanded to the specified size. -Note that if `varnishd` has to create or expand the file, it will not +Note that if `vinyld` has to create or expand the file, it will not pre-allocate the added space, leading to fragmentation, which may adversely impact performance on rotating hard drives. Pre-creating the storage file using `dd(1)` will reduce fragmentation to a minimum. @@ -193,7 +193,7 @@ have many small objects. File performance is typically limited to the write speed of the device, and depending on use, the seek time. -The 'advice' parameter tells the kernel how `varnishd` expects to +The 'advice' parameter tells the kernel how `vinyld` expects to use this mapped region so that the kernel can choose the appropriate read-ahead and caching techniques. Possible values are ``normal``, ``random`` and ``sequential``, corresponding to MADV_NORMAL, MADV_RANDOM diff --git a/doc/sphinx/users-guide/troubleshooting.rst b/doc/sphinx/users-guide/troubleshooting.rst index c68f83f49a..bd3295ee81 100644 --- a/doc/sphinx/users-guide/troubleshooting.rst +++ b/doc/sphinx/users-guide/troubleshooting.rst @@ -37,7 +37,7 @@ on its port.:: Platform: Linux,2.6.32-21-generic,i686,-smalloc,-hcritbit 200 193 ----------------------------- - Varnish Cache CLI. + Vinyl Cache CLI. ----------------------------- Type 'help' for command list. Type 'quit' to close CLI session. @@ -185,13 +185,13 @@ data it might be hard to track the entries down. You can set :ref:`vinyllog(1)` to log all your 503 errors by issuing the following command:: - $ varnishlog -q 'RespStatus == 503' -g request + $ vinyllog -q 'RespStatus == 503' -g request If the error happened just a short time ago the transaction might still be in the shared memory log segment. To get :ref:`vinyllog(1)` to process the whole shared memory log just add the '-d' parameter:: - $ varnishlog -d -q 'RespStatus == 503' -g request + $ vinyllog -d -q 'RespStatus == 503' -g request Please see the :ref:`vsl-query(7)` and :ref:`vinyllog(1)` man pages for elaborations on further filtering capabilities and explanation of diff --git a/doc/sphinx/users-guide/vcl.rst b/doc/sphinx/users-guide/vcl.rst index d748983589..d614788cd0 100644 --- a/doc/sphinx/users-guide/vcl.rst +++ b/doc/sphinx/users-guide/vcl.rst @@ -32,7 +32,7 @@ request, another when files are fetched from the backend server. If you don't call an action in your subroutine and it reaches the end Varnish will execute some built-in VCL code. You will see this VCL -code commented out in the file `builtin.vcl` that ships with Varnish Cache. +code commented out in the file `builtin.vcl` that ships with Vinyl Cache. .. _users-guide-vcl_fetch_actions: diff --git a/doc/sphinx/whats-new/changes-4.1.rst b/doc/sphinx/whats-new/changes-4.1.rst deleted file mode 100644 index 298987a7c3..0000000000 --- a/doc/sphinx/whats-new/changes-4.1.rst +++ /dev/null @@ -1,170 +0,0 @@ -.. - Copyright (c) 2016 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_4_1: - -Changes in Varnish 4.1 -====================== - -Varnish 4.1 is the continuation of the new streaming architecture seen -in Varnish 4.0. - - -Proactive security features ---------------------------- - -New in 4.1 is support for different kinds of privilege separation methods, -collectively described as jails. - -On most systems, the Varnish parent process will now drop effective -privileges to normal user mode when not doing operations needing special -access. - -The Varnish worker child should now be run as a separate `vcache` user. - -``varnishlog``, ``varnishncsa`` and other Varnish shared log utilities -now must be run in a context with `varnish` group membership. - - -Warm and cold VCL configurations --------------------------------- - -Traditionally Varnish have had the concept of active and inactive -loaded VCLs. Any loaded VCL lead to state being kept, and a separate -set of health checks (if configured) were being run against the backends. - -To avoid the extra state and backend polling, a loaded VCL is now either -warm or cold. Runtime state (incl. backend counters) and health checks -are not present for cold VCLs. - -A warm VCL will automatically be set to cold after `vcl_cooldown` seconds. - -Output from `vcl.list`:: - - varnish> vcl.list - 200 - available auto/warm 0 boot - available auto/warm 0 62f5275f-a937-4df9-9fbb-c12336bdfdb8 - - -A single VCL's state can be changed with the `vcl.state` call in -``varnishadm``:: - - vcl.state - Force the state of the specified configuration. - State is any of auto, warm or cold values. - -Example:: - - - varnish> vcl.state 62f5275f-a937-4df9-9fbb-c12336bdfdb8 cold - 200 - - varnish> vcl.list - 200 - available auto/warm 0 boot - available auto/cold 0 62f5275f-a937-4df9-9fbb-c12336bdfdb8 - - -VMOD writers should read up on the new vcl_event system to -release unnecessary state when a VCL is transitioned to cold (see -:ref:`ref-vmod-event-functions`). - - -PROXY protocol support ----------------------- - -Socket support for PROXY protocol connections has been added. PROXY -defines a short preamble on the TCP connection where (usually) a SSL/TLS -terminating proxy can signal the real client address. - -The ``-a`` startup argument syntax has been expanded to allow for this:: - - $ varnishd -f /etc/varnish/default.vcl -a :6081 -a 127.0.0.1:6086,PROXY - -Both PROXY1 and PROXY2 protocols are supported on the resulting listening -socket. - -For connections coming in over a PROXY socket, ``client.ip`` and -``server.ip`` will contain the addresses given to Varnish in the PROXY -header/preamble (the "real" IPs). - -The new VCL variables ``remote.ip`` and ``local.ip`` contains the local -TCP connection endpoints. On non-PROXY connections these will be identical -to ``client.ip`` and ``server.ip``. - -An expected pattern following this is `if (std.port(local.ip) == 80) { }` -in ``vcl_recv`` to see if traffic came in over the HTTP listening socket -(so a client redirect to HTTPS can be served). - - -VMOD backends -------------- - -Before Varnish 4.1, backends could only be declared in native VCL. Varnish -4.0 moved directors from VCL to VMODs, and VMODs can now also create -backends. It is possible to both create the same backends than VCL but -dynamically, or create backends that don't necessarily speak HTTP/1 over -TCP to fetch resources. More details in the :ref:`ref-writing-a-director` -documentation. - - -Backend connection timeout --------------------------- - -Backend connections will now be closed by Varnish after `backend_idle_timeout` -seconds of inactivity. - -Previously they were kept around forever and the backend servers would close -the connection without Varnish noticing it. On the next traffic spike needing -these extra backend connections, the request would fail, perhaps multiple -times, before a working backend connection was found/created. - - -Protocol support ----------------- - -Support for HTTP/0.9 on the client side has been retired. - - -More modules available ----------------------- - -Varnish has an ecosystem for third-party modules (vmods). New since -the last release, these are worth knowing about: - -libvmod-saintmode: Saint mode ("inferred health probes from traffic") was taken -out of Varnish core in 4.0, and is now back as a separate vmod. This is useful -for detecting failing backends before the health probes pick it up. - -libvmod-xkey: Secondary hash keys for cache objects, based on the hashtwo vmod -written by Varnish Software. Allows for arbitrary grouping of objects to be -purged in one go, avoiding use of ban invalidation. Also known as Cache Keys or -Surrogate Key support. - -libvmod-rtstatus: Real time statistics dashboard. - - -Passing data between ESI requests ---------------------------------- - -A new `req_top` identifier is available in VCL, which is a reference to -`req` in the top-level ESI request. - -This is useful to pass data back and forth between the main ESI request -and any ESI sub-requests it leads to. - - -Other noteworthy small changes ------------------------------- - -* Varnish will now use the ``stale-while-revalidate`` defined in RFC5861 - to set object grace time. -* -smalloc storage is now recommended over -sfile on Linux systems. -* New VCL variable ``beresp.was_304`` has been introduced in - ``vcl_backend_response``. Will be set to ``true`` if the response - from the backend was a positive result of a conditional fetch (``304 - Not Modified``). - diff --git a/doc/sphinx/whats-new/changes-5.0.rst b/doc/sphinx/whats-new/changes-5.0.rst deleted file mode 100644 index 433386532e..0000000000 --- a/doc/sphinx/whats-new/changes-5.0.rst +++ /dev/null @@ -1,256 +0,0 @@ -.. - Copyright (c) 2016 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_5.0: - -Changes in Varnish 5.0 -====================== - -Varnish 5.0 changes some (mostly) internal APIs and adds some major new -features over Varnish 4.1. - - -Separate VCL files and VCL labels -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Varnish 5.0 supports jumping from the active VCL's ``vcl_recv{}`` to -another VCL via a VCL label. - -The major use of this will probably be to have a separate VCL for -each domain/vhost, in order to untangle complex VCL files, but -it is not limited to this criteria, it would also be possible to -send all POSTs, all JPEG images or all traffic from a certain -IP range to a separate VCL file. - -VCL labels can also be used to give symbolic names to loaded VCL -configurations, so that operations personnel only need to know -about "normal", "weekend" and "emergency", and web developers -can update these as usual, without having to tell ops what the -new weekend VCL is called. - - -Very Experimental HTTP/2 support -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We are in the process of adding HTTP/2 support to Varnish, but -the code is very green still - life happened. - -But you can actually get a bit of traffic though it already, and -we hope to have it production ready for the next major release -(2017-03-15). - -Varnish supports HTTP/1 -> 2 upgrade. For political reasons, -no browsers support that, but tools like curl does. - -For encrypted HTTP/2 traffic, put a SSL proxy in front of Varnish. - -HTTP/2 support is disabled by default, to enable, set the ``http2`` -feature bit. - - -The Shard Director -~~~~~~~~~~~~~~~~~~ - -We have added to the directors VMOD an overhauled version of a -director which was available as an out-of-tree VMOD under the name -VSLP for a couple of years: It's basically a better hash director, -which uses consistent hashing to provide improved stability of backend -node selection when the configuration and/or health state of backends -changes. There are several options to provide the shard key. The -rampup feature allows to take just-gone-healthy backends in production -smoothly, while the prewarm feature allows to prepare backends for -traffic which they would see if the primary backend for a certain key -went down. - -It can be reconfigured dynamically (outside ``vcl_init{}``), but -different to our other directors, configuration is transactional: Any -series of backend changes must be concluded by a reconfigure call for -activation. - - -Hit-For-Pass is now actually Hit-For-Miss -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Almost since the beginning of time (2008), varnish has hit-for-pass: -It is basically a negative caching feature, putting into the cache -objects as markers saying "when you hit this, your request should be a -pass". The purpose is to selectively avoid the request coalescing -(waitinglist) feature, which is useful for cacheable content, but not -for uncacheable objects. If we did not have hit-for-pass, without -additional configuration in vcl_recv, requests to uncacheable content -would be sent to the backend serialized (one after the other). - -As useful as this feature is, it has caused a lot of headaches to -varnish administrators along the lines of "why the *beep* doesn't -Varnish cache this": A hit-for-pass object stayed in cache for however -long its ttl dictated and prevented caching whenever it got hit ("for -that url" in most cases). In particular, as a pass object cannot be -turned into something cacheable retrospectively -(``beresp.uncacheable`` can be changed from ``false`` to ``true``, but -not the other way around), even responses which would have been -cacheable were not cached. So, when a hit-for-pass object got into -cache unintentionally, it had to be removed explicitly (using a ban or -purge). - -We've changed this now: - -A hit-for-pass object (we still call it like this in the docs, logging -and statistics) will now cause a cache-miss for all subsequent -requests, so if any backend response qualifies for caching, it will -get cached and subsequent requests will be hits. - -In short: We've changed from "the uncacheable case wins" to "the -cacheable case wins" or from hit-for-pass to hit-for-miss. - -The primary consequence which we are aware of at the time of this -release is caused be the fact that, to create cacheable objects, we -need to make backend requests unconditional (that is, remove the -``If-Modified-Since`` and ``If-None-Match headers``): For conditional -client requests on hit-for-pass objects, Varnish will now issue an -unconditional backend fetch and, for 200 responses, send a 304 or 200 -response to the client as appropriate. - -As of the time of this release we cannot say if this will remain the -final word on this topic, but we hope that it will mean an improvement -for most users of Varnish. - - -Ban Lurker Improvements -~~~~~~~~~~~~~~~~~~~~~~~ - -We have made the ban lurker even more efficient by example of some -real live situations with tens of thousands of bans using inefficient -regular expressions. - -The new parameter ``ban_lurker_holdoff`` tells the ban lurker for how -long it should get out of the way when it could potentially slow down -lookups due to lock contention. Previously this was the same as -``ban_lurker_sleep``. - -.. _whatsnew_changes_5.0_reqbody: - -Request Body sent always / "cacheable POST" -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Previously, we would only send a request body for passed requests (and -for pipe mode, but this is special anyway and should be avoided). - -Not so anymore, but the default behaviour has not changed: - -Whenever a request has a body, it will get sent to the backend for a -cache miss (and pass, as before). This can be prevented by an -``unset bereq.body`` and the ``builtin.vcl`` removes the body for GET -requests because it is questionable if GET with a body is valid anyway -(but some applications use it). - -So the often-requested ability to cache POST/PATCH/... is now available, -but not out-of-the-box: - -* The ``builtin.vcl`` still contains a ``return(pass)`` for anything - but a GET or HEAD because other HTTP methods, by definition, may cause - state changes / side effects on backends. The application at hand - should be understood well before caching of non-GET/non-HEAD is - considered. - -* For misses, core code still calls the equivalent of ``set - bereq.method = "GET"`` before calling ``vcl_backend_fetch``, so to - make a backend request with the original request method, it needs to - be saved in ``vcl_recv`` and restored in ``vcl_backend_fetch``. - -* Care should be taken to choose an appropriate cache key and/or Vary - criteria. Adding the request body to the cache key is not possible - with core varnish, but through a VMOD - https://github.com/aondio/libvmod-bodyaccess - -To summarize: You should know what you are doing when caching anything -but a GET or HEAD and without creating an appropriate cache key doing -so is almost guaranteed to be wrong. - - -ESI and Backend Request Coalescing ("waitinglist") Improvement -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Previously, ESI subrequests depending on objects being fetched from -the backed used polling, which typically added some ~5ms of processing -time to such subrequests and could lead to starvation effects in -extreme corner cases. - -The waitinglist logic for ESI subrequests now uses condition variables -to trigger immediate continuation of ESI processing when an object -being waited for becomes available. - - -Backend PROXY protocol requests -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Are now supported through the ``.proxy_header`` attribute of the -backend definition. - -Default VCL search path -~~~~~~~~~~~~~~~~~~~~~~~ - -For default builds, vcl files are now also being looked for under -``/usr/share/varnish/vcl`` if not found in ``/etc/varnish``. - -For custom builds, the actual search path is -``${varnishconfdir}:${datarootdir}/varnish/vcl`` - - -devicedetect.vcl -~~~~~~~~~~~~~~~~ - -The basic device detection vcl is now bundled with varnish. - -varnishtest -~~~~~~~~~~~ - -* ``resp.msg`` renamed to ``resp.reason`` for consistency with vcl -* HTTP2 testing capabilities added -* default search path for executables and vmods added -* ``sema`` mechanism replaced by ``barrier`` -* support for PROXY requests - -misc -~~~~ - -Brief notes on other changes - -* Added separate thread for object expiry -* The ESI parser is now more tolerant to some syntactic corner cases -* Reduced needless rushing of requests on the waitinglist -* ``varnishhist`` can now process backend requests and offers a timebend - function to control the processing speed -* ``std.integer()`` can now also parse real numbers and truncates them -* ``std.log()`` now also works correctly during ``vcl_init{}`` -* further improved stability when handling workspace overflows -* numerous vcl compiler improvements - -News for VMOD authors -~~~~~~~~~~~~~~~~~~~~~ - -* It is now mandatory to have a description in the ``$Module`` line of - a ``vcc`` file. - -* vcl cli events (in particular, ``vcl_init{}`` /``vcl_fini{}``) now - have a workspace and ``PRIV_TASK`` available for VMODs. - -* ``PRIV_*`` now also work for object methods with unchanged scope. - In particular, they are per VMOD and `not` per object - e.g. the - same ``PRIV_TASK`` gets passed to object methods as to functions - during a VCL task. - -* varnish now provides a random number api, see vrnd.h - -* vbm (variable size bitmaps) improved - -* ``vmodtool.py`` for translating vcc files has been largely - rewritten, there may still exist regressions which remained unnoticed - -* ``vmodtool.py`` now requires at least Python 2.6 - -* New autoconf macros are available, they should greatly simplify build - systems of out-of-tree VMODs. They are implemented and documented in - ``varnish.m4``, and the previous macros now live in ``varnish-legacy.m4`` - so existing VMODs should still build fine. diff --git a/doc/sphinx/whats-new/changes-5.1.rst b/doc/sphinx/whats-new/changes-5.1.rst deleted file mode 100644 index 19af7aa1ca..0000000000 --- a/doc/sphinx/whats-new/changes-5.1.rst +++ /dev/null @@ -1,367 +0,0 @@ -.. - Copyright (c) 2017 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_5.1: - -Changes in Varnish 5.1 -====================== - -We have a couple of new and interesting features in Varnish 5.1, -and we have a lot of smaller improvements and bugfixes all over -the place, in total we have made about 750 commits since Varnish 5.0, -so this is just some of the highlights. - -Probably the biggest change in Varnish 5.1 is that a couple of very -significant contributors to Varnish have changed jobs, and therefore -stopped being active contributors to the Varnish Project. - -Per Buer was one of the first people who realized that Varnish was -not just "Some program for a couple of Nordic newspapers", and he -started the company Varnish Software, which is one of the major -sponsors of the Varnish Project. - -Lasse Karstensen got roped into Varnish Software by Per, and in -addition to his other duties, he has taken care of the projects -system administration and release engineering for most of the 11 -years we have been around now. - -Per & Lasse: "Thanks" doesn't even start to cover it, and we wish -you all the best for the future! - -.. _whatsnew_clifile: - -Startup CLI command file -~~~~~~~~~~~~~~~~~~~~~~~~ - -The new '-I cli_file' option to varnishd will make it much more -practical to use the VCL labels introduced in Varnish 5.0. - -The cli commands in the file will be executed before the worker -process starts, so it could for instance contain:: - - vcl.load panic /etc/varnish_panic.vcl - vcl.load siteA0 /etc/varnish_siteA.vcl - vcl.load siteB0 /etc/varnish_siteB.vcl - vcl.load siteC0 /etc/varnish_siteC.vcl - vcl.label siteA siteA0 - vcl.label siteB siteB0 - vcl.label siteC siteC0 - vcl.load main /etc/varnish_main.vcl - vcl.use main - -If a command in the file is prefixed with '-', failure will not -abort the startup. - -Related to this change we have reordered the argument checking so -that argument problems are reported more consistently. - -In case you didn't hear about them yet, labelling VCL programs -allows you to branch out to other VCLs in the main::vcl_recv{}, -which in the above example could look like:: - - sub vcl_recv { - if (req.http.host ~ "asite.example.com$") { - return(vcl(siteA)); - } - if (req.http.host ~ "bsite.example.com$") { - return(vcl(siteB)); - } - if (req.http.host ~ "csite.example.com$") { - return(vcl(siteC)); - } - // Main site processing ... - } - -Universal VCL return(fail) -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -It is now possible to ``return(fail)`` anywhere in VCL, -including inside VMODs. This will cause VCL processing -to terminate forthright. - -In addition to ``return(fail)``, this mechanism will be -used to handle all failure conditions without a safe -fallback, for instance workspace exhaustion, too many -headers etc. (This is a work in progress, there is a -lot of code to review before we are done.) - -In ``vcl_init{}`` failing causes the ``vcl.load`` to fail, -this is nothing new for this sub-routine. - -A failure in any of the client side VCL methods (``vcl_recv{}``, -``vcl_hash{}`` ...) *except* ``vcl_synth{}``, sends the request -to ``vcl_synth{}`` with a 503, and reason "VCL failed". - -A failure on the backend side (``vcl_backend_*{}``) causes the -fetch to fail. - -(VMOD writers should use the new ``VRT_fail(ctx, format_string, ...)`` -function which logs a SLT_VCL_Error record.) - - -Progress on HTTP/2 support -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -HTTP/2 support is better than in 5.0, and is now enabled and survives -pretty well on our own varnish-cache.org website, but there are -still things missing, most notably windows and priority, which may -be fatal to more complex websites. - -We expect HTTP/2 support to be production ready in the autumn 2017 -release of Varnish-Cache, but that requires a testing and feedback -from real-world applications. - -So if you have a chance to test our HTTP/2 code, by all means do -so, please report any crashes, bugs or other trouble back to us. - -To enable HTTP/2 you need to ``param.set feature +http2`` but due -to internet-politics, you will only see HTTP/2 traffic if you have -an SSL proxy in front of Varnish which advertises HTTP2 with ALPN. - -For the hitch SSL proxy, add the argument ``--alpn-protos="h2,http/1.1"`` - -.. _whatsnew_changes_5.1_hitpass: - -Hit-For-Pass has returned -~~~~~~~~~~~~~~~~~~~~~~~~~ - -As hinted in :ref:`whatsnew_changes_5.0`, we have restored the -possibility of invoking the old hit-for-pass feature in VCL. The -treatment of uncacheable content that was new in version 5.0, which we -have taken to calling "hit-for-miss", remains the default. Now you can -choose hit-for-pass with ``return(pass(DURATION))`` from -``vcl_backend_response``, setting the duration of the hit-for-pass -state in the argument to ``pass``. For example: -``return(pass(120s))``. - -To recap: when ``beresp.uncacheable`` is set to ``true`` in -``vcl_backend_response``, Varnish makes a note of it with a minimal -object in the cache, and finds that information again on the next -lookup for the same object. In essence, the cache is used to remember -that the last backend response was not cacheable. In that case, -Varnish proceeds as with a cache miss, so that the response may become -cacheable on subsequent requests. The difference is that Varnish does -not perform request coalescing, as it does for ordinary misses, when a -response has been marked uncacheable. For ordinary misses, when there -are requests pending for the same object at the same time, only one -fetch is executed at a time, since the response may be cached, in -which case the cached response may be used for the remaining -requests. But this is not done for "hit-for-miss" objects, since they -are known to have been uncacheable on the previous fetch. - -``builtin.vcl`` sets ``beresp.uncacheable`` to ``true`` when a number -of conditions hold for a backend response that indicate that it should -not be cached, for example if the TTL has been determined to be 0 -(perhaps due to a ``Cache-Control`` header), or if a ``Set-Cookie`` -header is present in the response. So hit-for-miss is the default -for uncacheable backend responses. - -A consequence of this is that fetches for uncacheable responses cannot -be conditional in the default case. That is, the backend request may -not include the headers ``If-Modified-Since`` or ``If-None-Match``, -which might cause the backend to return status "304 Not Modified" with -no response body. Since the response to a cache miss might be cached, -there has to be a body to cache, and this is true of hit-for-miss as -well. If either of those two headers were present in the client -request, they are removed from the backend request for a miss or -hit-for-miss. - -Since conditional backend requests and the 304 response may be -critical to performance for non-cacheable content, especially if the -response body is large, we have made the old hit-for-pass feature -available again, with ``return(pass(DURATION))`` in VCL. - -As with hit-for-miss, Varnish uses the cache to make a note of -hit-for-pass objects, and finds them again on subsequent lookups. The -requests are then processed as for ordinary passes (``return(pass)`` -from ``vcl_recv``) -- there is no request coalescing, and the response -will not be cached, even if it might have been otherwise. -``If-Modified-Since`` or ``If-None-Match`` headers in the client -request are passed along in the backend request, and a backend -response with status 304 and no body is passed back to the client. - -The hit-for-pass state of an object lasts for the time given as the -DURATION in the previous return from ``vcl_backend_response``. After -the "hit-for-pass TTL" elapses, the next request will be an ordinary -miss. So a hit-for-pass object cannot become cacheable again until -that much time has passed. - -304 Not Modified responses after a pass -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Related to the previous topic, there has been a change in the way -Varnish handles a very specific case: deciding whether to send a "304 -Not Modified" response to the client after a pass, when the backend -had the opportunity to send a 304 response, but chose not to by -sending a 200 response status instead. - -Previously, Varnish went along with the backend when this happened, -sending the 200 response together with the response body to the -client. This was the case even if the backend set the response headers -``ETag`` and/or ``Last-Modified`` so that, when compared to the -request headers ``If-None-Match`` and ``If-Modified-Since``, a 304 -response would seem to be warranted. Since those headers are passed -back to the client, the result could appear a bit odd from the -client's perspective -- the client used the request headers to ask if -the response was unmodified, and the response headers seem to indicate -that it wasn't, and yet the response status suggests that it was. - -Now the decision to send a 304 client response status is made solely -at delivery time, based on the contents of the client request headers -and the headers in the response that Varnish is preparing to send, -regardless of whether the backend fetch was a pass. So Varnish may -send a 304 client response after a pass, even though the backend chose -not to, having seen the same request headers (if the response headers -permit it). - -We made this change for consistency -- for hits, misses, hit-for-miss, -hit-for-pass, and now pass, the decision to send a 304 client response -is based solely on the contents of client request headers and the -response headers. - -You can restore the previous behavior -- don't send a 304 client -response on pass if the backend didn't -- with VCL means, either by -removing the ``ETag`` or ``Last-Modified`` headers in -``vcl_backend_response``, or by removing the If-* client request -headers in ``vcl_pass``. - -VXID in VSL queries -~~~~~~~~~~~~~~~~~~~ - -The Varnish Shared Log (VSL) became much more powerful starting Varnish -4.0 and hasn't changed much since. Changes usually consist in adding new -log records when new feature are introduced, or when we realize that some -missing piece of information could really help troubleshooting. - -Varnish UTilities (VUT) relying on the VSL usually share the same ``-q`` -option for querying, which allows to filter transactions based on log -records. For example you could be looking for figures on a specific -domain:: - - varnishtop -i ReqURL -q 'ReqHeader:Host eq www.example.com' - -While options like ``-i`` and ``-q`` were until now both limited to log -records, it also meant you could only query a specific transaction using -the ``X-Varnish`` header. Depending on the nature of the transaction -(client or backend side) the syntax is not the same and you can't match -a session. - -For instance, we are looking for the transaction 1234 that occurred very -recently and we would like to collect everything from the same session. -We have two options:: - - # client side - varnishlog -d -g session -q 'RespHeader:X-Varnish[1] == 1234' - - # backend side - varnishlog -d -g session -q 'BereqHeader:X-Varnish == 1234' - -There was no simple way to match any transaction using its id until the -introduction of ``vxid`` as a possible left-hand side of a ``-q`` query -expression:: - - # client side - varnishlog -d -g session -q 'vxid == 1234' - - # backend side - varnishlog -d -g session -q 'vxid == 1234' - - # session - varnishlog -d -g session -q 'vxid == 1234' - -Another use case is the collection of non-transactional logs. With raw -grouping the output is organized differently and each record starts with -its transaction id or zero for non-transactional logs:: - - # before 5.1 - varnishlog -g raw | awk '$1 == 0' - - # from now on - varnishlog -g raw -q 'vxid == 0' - -This should offer you a more concise, and more consistent means to filter -transactions with ``varnishlog`` and other VUTs. - -.. _whatsnew_changes_5.1_vtest: - -Project tool improvements -~~~~~~~~~~~~~~~~~~~~~~~~~ - -We have spent a fair amount of time on the tools we use internally -in the project. - -The ``varnishtest`` program has been improved in many small ways, -in particular it is now much easier to execute and examine -results from other programs with the ``shell`` and ``process`` -commands. It might break existing test cases if you were already -using ``varnishtest``. - -The project now has *KISS* web-backend which summarizes -``make distcheck`` results from various platforms: - -http://varnish-cache.org/vtest/ - -If you want Varnish to be tested on a platform not already -covered, all you need to do is run the tools/vtest.sh script -from the source tree. We would love to see more platforms -covered (arm64, ppc, mips) and OS/X would also be nice. - -We also publish our code-coverage status now: - -http://varnish-cache.org/gcov/ - -Our goal is 90+% coverage, but we need to start implementing -terminal emulation in ``varnishtest`` before we can test the curses(1) -based programs (top/stat/hist) comprehensively, so they currently -drag us down. - - -News for authors of VMODs and Varnish API client applications -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -* The VRT version has been bumped to 6.0, since there have been some - changes and additions to the ABI. See ``vrt.h`` for an overview. - -* In particular, there have been some changes to the ``WS_*`` - interface for accessing workspaces. We are working towards fully - encapsulating workspaces with the ``WS_*`` family of functions, so - that it should not be necessary to access the internals of a - ``struct ws``, which may be revised in a future release. There are - no revisions at present, so your code won't break if you're - working with the innards of a ``struct ws`` now, but you would be - prudent to replace that code with ``WS_*`` calls some time before - the next release. And please let us know if there's something you - need to do that the workspace interface won't handle. - -* ``libvarnishapi.so`` now exports more symbols from Varnish internal - libraries: - - * All of the ``VTIM_*`` functions -- getting clock times, formatting - and parsing date & time formats, sleeping and so forth. - - * All of the ``VSB_*`` functions for working with safe string - buffers. - -* ``varnish.m4`` and ``varnishapi.pc`` now expose more information about - the Varnish installation. See "Since 5.1.0" comments for a comprehensive - list of what was added. - -* VMOD version coexistence improvements: In difference from executable - files, shared libraries are not protected against overwriting under - UNIX, and this has generally caused grief when VMODs were updated - by package management tools. - - We have decided to bite the bullet, and now the Varnishd management - process makes a copy of the VMOD shared library to a version-unique - name inside the workdir, from which the running VCL access it. This - ensures that Varnishd can always restart the worker process, no matter - what happened to the original VMOD file. - - It also means that VMODs maintaining state spanning VCL reloads might - break. It is still possible to maintain global state in a VMOD despite - VMOD caching: one solution is to move the global state into separate - shared library that won't be cached by Varnish. - -*EOF* diff --git a/doc/sphinx/whats-new/changes-5.2.rst b/doc/sphinx/whats-new/changes-5.2.rst deleted file mode 100644 index 3a2efc4e54..0000000000 --- a/doc/sphinx/whats-new/changes-5.2.rst +++ /dev/null @@ -1,176 +0,0 @@ -.. - Copyright (c) 2017 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_5.2: - -Changes in Varnish 5.2 -====================== - -Varnish 5.2 is mostly changes under the hood so most varnish -installations will be able to upgrade with no modifications. - -.. _whatsnew_new_vmods: - -New VMODs in the standard distribution -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We have added three new VMODs to the varnish project. - -VMOD blob ---------- - -We have added the variables ``req.hash`` and ``bereq.hash`` to VCL, -which contain the hash value computed by Varnish for the current -request, for use in cache lookup. Their data type is BLOB, which -represents opaque data of any length -- the new variables contain -the raw binary hashes. - -This is the first time that an element of standard VCL has the BLOB -type (BLOBs have only been used in third-party VMODs until now). So we -have added VMOD blob to facilitate their use. In particular, the VMOD -implements binary-to-text encodings, for example so that you can -assign the hash to a header as a base64 or hex string. It also -provides some other utilities such as getting the length of a BLOB or -testing BLOBs for equality. - -See :ref:`vmod_blob(3)`. - -VMOD purge ----------- - -Before the introduction of ``vcl 4.0`` there used to be a ``purge`` function -instead of a ``return(purge)`` transition. This module works like old-style -VCL purges (which should be used from both ``vcl_hit`` and ``vcl_miss``) and -provides more capabilities than regular purges, and lets you know how many -objects were affected. - -See :ref:`vmod_purge(3)`. - -VMOD vtc --------- - -As long as we have had VMODs, we had an internal vmod called ``vmod_debug`` -which was used with ``varnishtest`` to exercise the VMOD related parts of -``varnishd``. Over time this vmod grew other useful functions for writing -test-cases. - -We only distribute ``vmod_debug`` in source releases, because it has some -pretty evil functionality, for instance ``debug.panic()``. - -We have taken the non-suicidal test-writing goodies out of -``vmod_debug`` and put them into a new ``vmod_vtc``, to make them -available to people using ``varnishtest`` to test local configurations, -VMODs etc. - -The hottest trick in ``vmod_vtc`` is that VTC-barriers can be -accessed from the VCL code, but there are other conveniences like -workspace manipulations etc. - -See :ref:`vmod_vtc(3)`. - -News for authors of VMODs and Varnish API client applications -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. _whatsnew_abi: - -$ABI [strict|vrt] ------------------ - -VMOD authors have the option of only integrating with the blessed -interface provided by ``varnishd`` or go deeper in the stack. As -a general rule of thumb you are considered "on your own" if your -VMOD uses more than the VRT (Varnish RunTime) and it is supposed -to be built for the exact Varnish version. - -Varnish was already capable of checking the major/minor VRT version -a VMOD was built against, or require the exact version, but picking -one or the other depended on how Varnish was built. - -VMOD authors can now specify whether a module complies to the VRT -and only needs to be rebuilt when breaking changes are introduced -by adding ``$ABI vrt`` to their VCC descriptor. The default value -is ``$ABI strict`` when omitted. - -.. _whatsnew_vsm_vsc_5.2: - -VSM/VSC API changes -------------------- - -The export of statistics counters via shared memory has been -overhauled to get rid of limitations which made sense 11 years -ago but not so much now. - -A set of statistics counters are now fully defined in a ``.vsc`` -file which is processed by the ``vsctool.py`` script into a .c and -.h file, which is compiled into the relevant body of code. - -This means that statistics counters are now self-describing in -shared memory, and ``varnishstat`` or other VSC-API using programs -no longer have a compiled in list of which counters exist or how -to handle them. - -This paves the way for VMODs or maybe even VCL to define -custom counters, and have them show up in varnishstat and -other VSC-API based programs just like the rest of the counters. - -The rewrite of the VSM/VSC code simplified both APIs and -made them much more robust but code calling into these APIs -will have to be updated to match. - -The necessary changes mostly center around detecting if the -varnishd management/worker process has restarted. - -In the new VSM-API once setup is done, VSM_Attach() latches -on to a running varnishd master process and stays there. - -VSM_Status() updates the in-memory list of VSM segments, and -returns status information about the master and worker processes: -Are they running? Have they been restarted? Have VSM segments -been added/deleted? - -Each VSM segment is now a separate piece of shared memory -and the name of the segment can be much longer. - -Before the actual shared memory can be accessed, the -application must call VSM_Map() and when VSM_StillValid() -indicates that the segment is no longer valid, VSM_Unmap() -should be called to release the segment again. - -All in all, this should be simpler and more robust. - -.. _whatsnew_vrt_5.2: - -VRT API changes ---------------- - -``VRT_purge`` now fails a transaction instead of panicking when used -outside of ``vcl_hit`` or ``vcl_miss``. It also returns the number -of purged objects. - -.. _whatsnew_vut_5.2: - -Added VUT API -------------- - -One way to extend Varnish is to write VSM clients, programs that tap -into the Varnish Shared Memory (VSM) usually via ``libvarnishapi`` or -community bindings for other languages than C. Varnish already ships -with VUTs (Varnish UTilities) that either process the Varnish Shared -Log (VSL) like ``varnishlog`` or ``varnishncsa`` or the Varnish Shared -Counters (VSC) like ``varnishstat``. - -Most of the setup for these programs is similar, and so they shared an -API that is now available outside of the Varnish source tree. The VUT -API has been cleaned up to remove assumptions made for our utilities. -It hides most of the complexity and redundancy of setting up a log -processor and helps you focus on your functionality. If you use -autotools for building, a new macro in ``varnish.m4`` removes some of -the boilerplate to generate part of the documentation. - -We hope that we will see new tools that take advantage of this API to -extend Varnish in new ways, much like VMODs made it easy to add new -functionality to VCL. - -*eof* diff --git a/doc/sphinx/whats-new/changes-6.1.rst b/doc/sphinx/whats-new/changes-6.1.rst deleted file mode 100644 index 4565767369..0000000000 --- a/doc/sphinx/whats-new/changes-6.1.rst +++ /dev/null @@ -1,28 +0,0 @@ -.. - Copyright (c) 2018 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_6.1: - -Changes in Varnish 6.1 -====================== - -This release is a maintenance release, so while there are many actual -changes, and of course many bugfixes, they should not have little to no -impact on running Varnish installations. - -Nothing to see here, really ---------------------------- - -Since new users often forget to `vcl.discard` their old VCLs, we have -added a warning when you have more than 100 VCLs loaded. There are -parameters to set the threshold and decide what happens when it is -exceeded (ignore/warn/error). - -We have made `req.http.Host` mandatory and handle requests without it -on the fast DoS avoidance path. - -For all the details and new stuff, see :ref:`whatsnew_upgrading_6.1` - -*eof* diff --git a/doc/sphinx/whats-new/changes-6.2.rst b/doc/sphinx/whats-new/changes-6.2.rst deleted file mode 100644 index 91ef4aba03..0000000000 --- a/doc/sphinx/whats-new/changes-6.2.rst +++ /dev/null @@ -1,259 +0,0 @@ -.. - Copyright (c) 2019 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_2019_03: - -%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 6.2 -%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_2019_03`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -varnishd -======== - -Cache lookups have undergone a number of optimizations, among them -reduction in lock contention, and to shorten and simplify the critical -section of lookup code. We expect that this will improve performance -and scalability. - -We have added a "watchdog" for thread pools that will panic the worker -process, causing it to restart, if scheduling tasks onto worker -threads appears to be deadlocking. The length of time until the panic -is set by the :ref:`ref_param_thread_pool_watchdog` parameter. If this -happens, it probably means that thread pools are too small, and you -should consider increasing the parameters -:ref:`ref_param_thread_pool_min`, :ref:`ref_param_thread_pool_max` -and/or :ref:`ref_param_thread_pools`. - -.. _whatsnew_changes_params_2019_03: - -Parameters -~~~~~~~~~~ - -The default value of :ref:`ref_param_thread_pool_stack` has been -increased from 48k to 56k on 64-bit platforms and to 52k on 32-bit -platforms. - -Recently we had occasional reports of stack overflow, apparently -related to changes in external libraries that are not under control of -the Varnish project (such as glibc). This may also have been related -to stack overflow issues on some platforms when recent versions of -`jemalloc`_, the recommended memory allocator for Varnish, have been -used together with `pcre`_ with JIT compilation enabled. Compiler -hardening flags may also increase stack usage and on some systems such -stack protector flags may be enabled by default. With the addition of -new mitigations to new compiler releases, stack consumption may also -increase on that front. - -Tests have shown that Varnish runs stably with the new default stack -size on a number of platforms, under conditions that previously may -have led to stack overflow -- such as ESI includes up to the default -limit of :ref:`ref_param_max_esi_depth`, relatively deep VCL -subroutine call depth, and recent jemalloc together with pcre-jit. - -Different sites have different requirements regarding the stack size. -For example, if your site uses a high depth of ESI includes, you are -probably already using an increased value of -:ref:`ref_param_thread_pool_stack`. If you don't have such -requirements, and you want to reduce memory footprint, you can -consider lowering :ref:`ref_param_thread_pool_stack`, but make sure to -test the result. - -.. _jemalloc: http://jemalloc.net/ - -.. _pcre: https://www.pcre.org/ - -Some parameters that have been long deprecated are now retired. See -:ref:`whatsnew_upgrading_params_2019_03` in -:ref:`whatsnew_upgrading_2019_03`. - -Added :ref:`ref_param_thread_pool_watchdog`, see above. - -The :ref:`ref_param_debug` parameter now has a flag ``vcl_keep``. When -the flag is turned on, C sources and shared object libraries that were -generated from VCL sources are retained in the Varnish working -directory (see the notes about ``varnishtest`` below). - -For 32-bit platforms, we have increased the default -:ref:`ref_param_workspace_backend` from 16k to 20k accommodate larger -response headers which have become common. - -Other changes in varnishd -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The VCL syntax version is now displayed in a panic message, as 41 for -VCL 4.1 and 40 for VCL 4.0. - -Changes to VCL -============== - -VCL variables -~~~~~~~~~~~~~ - -Added ``req.is_hitmiss`` and ``req.is_hitpass``, see :ref:`vcl(7)`. - -Other changes to VCL -~~~~~~~~~~~~~~~~~~~~ - -Runtime restrictions concerning the accessibility of Unix domain -sockets have been relaxed, see :ref:`whatsnew_upgrading_vcl_2019_03` -in :ref:`whatsnew_upgrading_2019_03`. - -``return(miss)`` from ``vcl_hit{}`` did never work as intended for the -common case (it actually turned into a pass), so we now removed it and -changed the ``builtin.vcl``. See -:ref:`whatsnew_upgrading_vcl_2019_03`. - -VMODs -===== - -The type-conversion functions in :ref:`vmod_std(3)` have been reworked -to make them more flexible and easier to use. The ``std.``\ *x2y* -conversion functions are now deprecated. See -:ref:`whatsnew_upgrading_std_conversion_2019_03`. - -The function :ref:`directors.lookup()` has been added to -:ref:`vmod_directors(3)`, only for use in ``vcl_init`` or -``vcl_fini``. - -vinyllog(1), vinylncsa(1) and vsl(7) -======================================== - -The performance of bundled log readers, including ``varnishlog`` and -``varnishncsa`` (and any tool using the internal VUT interface for -Varnish utilities) has been improved. They continue reading log -contents in bulk as long as more contents are known to be available, -not stopping as frequently (and unnecessarily) to check the status of -the shared memory mapping. - -``varnishlog`` and ``varnishncsa`` now have the ``-R`` command-line -option for rate-limiting, to limit the number of log transactions read -per unit time. This can make it less likely for log reads to fall -behind and fail with overrun errors under heavy loads. See -:ref:`vinyllog(1)` and :ref:`vinylncsa(1)` for details. - -Timing information is now uniformly reported in the log with -microsecond precision. This affects the tags ``ExpKill`` and -``ExpRearm`` (previously with nanosecond precision). - -vinyladm(1) and varnish-cli(7) -================================ - -The output formats of the ``vcl.list`` and ``backend.list`` commands -have changed, see :ref:`whatsnew_upgrading_backend_list_2019_03` and -:ref:`whatsnew_upgrading_vcl_list_2019_03` in -:ref:`whatsnew_upgrading_2019_03`, as well as :ref:`varnish-cli(7)` -for details. - -.. _whatsnew_changes_cli_json: - -JSON output -~~~~~~~~~~~ - -JSON responses, requested with the ``-j`` option, are now possible for -the following commands (see :ref:`varnish-cli(7)`): - -* ``status -j`` -* ``vcl.list -j`` -* ``param.show -j`` -* ``ban.list -j`` -* ``storage.list -j`` -* ``panic.show -j`` - -The ``-j`` option was already available for ``backend.list``, ``ping`` -and ``help`` in previous versions. - -For automated parsing of CLI responses (:ref:`vinyladm(1)` output), -we recommend the use of JSON format. - -``param.reset `` -~~~~~~~~~~~~~~~~~~~~~~~ - -Added the command ``param.reset`` to reset a parameter's value to its -default, see :ref:`varnish-cli(7)`. - -Banning by expiration parameters -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Bans may now be defined with respect to ``obj.ttl``, ``obj.age``, -``obj.grace`` and ``obj.keep``, referring to the expiration and age -properties of the cached object. A ban expression may also be defined -with one of the comparison operators ``<``, ``<=``, ``>`` and ``>=``; -these may only be used with one of the new duration variables for -bans. Duration constants (such as ``5m`` for five minutes of ``3h`` -for three hours) may be used in the ```` position against which -these objects are compared in a ban expression. - -``obj.ttl`` and ``obj.age`` are evaluated with respect to the time at -which the ban was defined, while ``obj.grace`` and ``obj.keep`` are -evaluated as the grace or keep time assigned to the object. So to issue -a ban for objects whose TTL expires more than 5 hours from now and -whose keep parameter is greater than 3 hours, use this expression:: - - obj.ttl > 5h && obj.keep > 3h - -See :ref:`vcl(7)` and :ref:`users-guide-purging` for details. - -vinylstat(1) and varnish-counters(7) -====================================== - -Added the ``ws_*_overflow`` and ``client_resp_500`` counters to better -diagnose workspace overflow issues, see :ref:`varnish-counters(7)`. - -In curses mode, :ref:`vinylstat(1)` now allows use of the ``+`` and -``-`` keys to increase or decrease the refresh rate of the curses -window. - -varnishtest -=========== - -When :ref:`vinyltest(1)` is invoked with either of the ``-L`` or -``-l`` options to retain the temporary directory after tests, the -``vcl_keep`` flag for the :ref:`ref_param_debug` parameter is switched -on (see `Parameters`_ above). This means that C sources and shared -objects generated from VCL can also be inspected after a test. By -default, the temporary directory is deleted after each test. - -Since around the time of the last release, we have begun the project -`VTest`_, which is adapted from :ref:`vinyltest(1)`, but is made -available as a stand-alone program useful for testing various HTTP -clients, servers and proxies (not just Varnish). But for the time -being, we still use :ref:`vinyltest(1)` for our own testing. - -.. _VTest: https://code.vinyl-cache.org/vtest/VTest - -Changes for developers and VMOD authors -======================================= - -Python tools that generate code now require Python 3. - -.. _whatsnew_changes_director_api_2019_03: - -Directors -~~~~~~~~~ - -The director API has been changed slightly: The most relevant design -change is that the ``healthy`` callback now is the only means to -determine a director's health state dynamically, the ``sick`` member -of ``struct director`` has been removed. Consequently, -``VRT_SetHealth()`` has been removed and ``VRT_SetChanged()`` added to -update the last health state change time. - -Presence of the ``healthy`` callback now also signifies if the -director is considered to have a *probe* with respect to the CLI. - -The signature of the ``list`` callback has been changed to reflect the -retirement of the undocumented ``backend.list -v`` parameter and to -add a ``VRT_CTX``. - -*eof* diff --git a/doc/sphinx/whats-new/changes-6.3.rst b/doc/sphinx/whats-new/changes-6.3.rst deleted file mode 100644 index 2819104e1e..0000000000 --- a/doc/sphinx/whats-new/changes-6.3.rst +++ /dev/null @@ -1,229 +0,0 @@ -.. - Copyright (c) 2020 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_6.3: - -%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 6.3 -%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_6.3`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -varnishd -======== - -Parameters -~~~~~~~~~~ - -A new :ref:`ref_param_pipe_sess_max` parameter allows to limit the number of -concurrent pipe transactions. The default value is zero and means unlimited, -for backwards compatibility. - -Other changes in varnishd -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The transferred bytes accounting for HTTP/2 sessions is more accurate: -``ReqAcct`` log records no longer report a full delivery if a stream did -not complete. - -The meaning of VCL temperature changed for the ``auto`` state: it used to -automatically cool down a VCL transitioning from active to available, but -that VCL would remain ``cold``. It now works in both directions, and such a -cold VCL keeps the ``auto`` state and may be used or labelled immediately -without an explicit change of state to ``warm``. - -As a result, a VCL with the ``cold`` state will no longer warm up -automatically. - -The management of counters, and in particular dynamic counters (for example -appearing or disappearing when a VCL is loaded or discarded), has seen -significant performance improvements and setups involving a large amount of -backends should be more responsive. - -Changes to VCL -============== - -VCL variables -~~~~~~~~~~~~~ - -The :ref:`ref_param_timeout_idle` parameter can be overridden in VCL using the -``sess.timeout_idle`` variable. - -Other changes to VCL -~~~~~~~~~~~~~~~~~~~~ - -A new ``error`` transition to ``vcl_backend_error`` allows to purposely move -to that subroutine. It is similar to the ``synth`` transition and can -optionally take arguments. The three following statements are equivalent:: - - return (error); - return (error(503)); - return (error(503, "Service Unavailable")); - -The ``error`` transition is available in :ref:`vcl_backend_fetch` and -:ref:`vcl_backend_response`. Using an explicit ``error`` transition in -``vcl_backend_fetch`` does not increment the ``MAIN.fetch_failed`` counter. - -It is possible to import the same VMOD twice, as long as the two imports are -identical and wouldn't otherwise conflict. This allows for example included -VCL files to import the VMODs they need without preventing the including VCL -to also perform the same import. - -Similarly, it is now possible to include a VMOD under a different name:: - - import directors as dir; - - sub vcl_init { - new rr = dir.round_robin(); - } - -This can be useful for VMODs with a long name, or VMODs that could use a -more expressive name in VCL code. - -The built-in VCL turns the ``Host`` header lowercase in ``vcl_recv`` to -improve its hashing later in ``vcl_hash`` since domain names are case -insensitive. - -VMODs -===== - -``std.ip()`` now takes an optional ``STRING`` argument to specify a port -number or service name. - -See: :ref:`std.ip()` - -vsl-query(7) -============ - -The syntax for VSL queries, mainly available via the ``-q`` option with -:ref:`vinyllog(1)` and similar tools, has slightly changed. Previously -and end of line in a query would be treated as a simple token separator -so in a script you could for example write this:: - - varnishlog -q ' - tag operator operand or - tag operator operand or - tag operator operand - ' -g request ... - -From now on, a query ends at the end of the line, but multiple queries -can be specified in which case it acts as if the ``or`` operator was used -to join all the queries. - -With this change in the syntax, the following query:: - - varnishlog -q ' - query1 - query2 - ' - -is equivalent to:: - - varnishlog -q '(query1) or (query2)' - -In other words, if you are using a Varnish utility to process transactions -for several independent reasons, you can decompose complex queries into -simpler ones by breaking them into separate lines, and for the most complex -queries possibly getting rid of parenthesis you would have needed in a -single query. - -If your query is complex and long, but cannot appropriately be broken down -into multiple queries, you can still break it down into multiple lines by -using a backslash-newline sequence:: - - tag operator operand and \ - tag operator operand and \ - tag operator operand - -See :ref:`vsl-query(7)` for more information about this change. - -With this new meaning for an end of line in a query it is now possible to -add comments in a query. If you run into the situation where again you need -to capture transactions for multiple reasons, you may document it directly -in the query:: - - varnishlog -q ' - # catch varnish errors - *Error - - # catch client errors - BerespStatus >= 400 and BerespStatus < 500 - - # catch backend errors - BerespStatus >= 500 - ' -g request - -This way when you later revisit a complex query, comments may help you -maintain an understanding of each individual query. This can become even -more convenient when the query is stored in a file. - -vinyllog(1), vinylncsa(1) and others -======================================== - -Our collection of log-processing tools gained the ability to specify -multiple ``-q`` options. While previously only the last ``-q`` option -would prevail you may now pass multiple individual queries and filtering -will operate as if the ``or`` operator was used to join all the queries. - -A new ``-Q`` option allows you to read the query from a file instead. It -can also be used multiple times and adds up to any ``-q`` option specified. - -Similar to ``-c`` or ``-b`` for client or backend transactions, -``vinylncsa(1)`` can take a ``-E`` option to include ESI transactions. - -``BackendStart`` log records are no longer used, but newer versions of log -utilities should still recognize deprecated records. It remains possible -to read logs written to a file with an older version of ``vinyllog(1)``, -and that backward compatibility officially goes as far as Varnish 6.0.0 -even though it *may* be possible to read logs saved from older releases. - -``Debug`` records are no longer logged by default and can be removed from -the :ref:`ref_param_vsl_mask` parameter to appear in the logs. Since such -records are not meant for production they are only automatically enabled -by ``vinyltest(1)``. - -varnishstat -=========== - -A new ``MAIN.n_pipe`` gauge keeps track of the number of ongoing pipe -transactions. - -A new ``MAIN.pipe_limited`` counter keeps track of how many times a -transaction failed to turn into a pipe because of the -:ref:`ref_param_pipe_sess_max` parameter. - -varnishtest -=========== - -A ``client`` can now use the ``-method`` action for ``txreq`` commands to -specify the request method. This used to be done with ``-req`` which remains -as an alias for compatibility. - -A ``client`` or ``server`` may use the ``-bodyfrom`` action for respectively -``txreq`` or ``txresp`` commands to send a body from a file. - -An HTTP/2 ``client`` or ``server`` can work with gzip content encoding and has -access to ``-gzipbody`` and ``-gziplen``. - -Changes for developers and VMOD authors -======================================= - -The most notable change for VMOD developers is the deprecation of string lists -in favor of strands. - -As usual, new functions were added to VRT, and others were changed or removed. -See ``vrt.h`` for a list of changes since the 6.2.0 release. - -We continue to remove functions from VRT that weren't meant to be used by VMOD -authors and were only part of the VMOD infrastructure code. - -*eof* diff --git a/doc/sphinx/whats-new/changes-6.4.rst b/doc/sphinx/whats-new/changes-6.4.rst deleted file mode 100644 index b894dd2ecf..0000000000 --- a/doc/sphinx/whats-new/changes-6.4.rst +++ /dev/null @@ -1,209 +0,0 @@ -.. - Copyright (c) 2020 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_6.4: - -%%%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 6.4.0 -%%%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_6.4`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -varnishd -======== - -bugs -~~~~ - -Numerous bugs have been fixed. - -Generic Parameter Handling -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Some parameters have dependencies and those are better documented now. For -example :ref:`ref_param_thread_pool_min` can't be increased above -:ref:`ref_param_thread_pool_max`, which is now indicated as such in the -manual. - -On a running Varnish instance the ``param.show`` command will display the -actual minimum or maximum, but an attempt to ``param.set`` a parameter above -or below its dynamic maximum or minimum will mention the failure's cause in -the error message:: - - varnish> param.show thread_pool_reserve - 200 - thread_pool_reserve - Value is: 0 [threads] (default) - Maximum is: 95 - - [...] - - varnish> param.show thread_pool_min - 200 - thread_pool_min - Value is: 100 [threads] (default) - Maximum is: 5000 - - [...] - - varnish> param.set thread_pool_reserve 100 - 106 - Must be no more than 95 (95% of thread_pool_min) - - (attempting to set param 'thread_pool_reserve' to '100') - -Expect further improvements in future releases. - -Parameters -~~~~~~~~~~ - -* Raised the minimum for the :ref:`ref_param_vcl_cooldown` parameter - to 1 second. - -Changes in behavior -~~~~~~~~~~~~~~~~~~~ - -* The ``if-range`` header is now handled, allowing clients to conditionally - request a range based on a date or an ETag. - -* Output VCC warnings also for VCLs loaded via the ``varnishd -f`` - option - -Changes to VCL -============== - -* New syntax for "no backend":: - - backend dummy none; - - sub vcl_recv { - set req.backend_hint = dummy; - } - - It can be used whenever a backend is needed for syntactical - reasons. The ``none`` backend will fail any attempt to use it. - The other purpose is to avoid the declaration of a dummy backend - when one is not needed: for example an active VCL only passing - requests to other VCLs with the ``return (vcl(...))`` syntax or - setups relying on dynamic backends from a VMOD. - -* ``std.rollback(bereq)`` is now safe to use, see :ref:`vmod_std(3)` - for details. - -* Deliberately closing backend requests through ``return(abandon)``, - ``return(fail)`` or ``return(error)`` is no longer accounted as a - fetch failure. - -* Numerical expressions can now be negative or negated as in - ``set resp.http.ok = -std.integer("-200");``. - -* The ``+=`` operator is now available for headers and response bodies:: - - set resp.http.header += "string"; - -VCL variables -~~~~~~~~~~~~~ - -* Add more vcl control over timeouts with the ``sess.timeout_linger``, - ``sess.send_timeout`` and ``sess.idle_send_timeout`` variables - corresponding the parameters by the same names. - -VMODs -===== - -* Imported :ref:`vmod_cookie(3)` from `varnish_modules`_ - - The previously deprecated function ``cookie.filter_except()`` has - been removed during import. It was replaced by ``cookie.keep()`` - -varnishlog -========== - -* A ``Notice`` VSL tag has been added. - -* Log records can safely have empty fields or fields containing blanks - if they are delimited by "double quotes". This was applied to - ``SessError`` and ``Backend_health``. - -varnishadm -========== - -* New ``pid`` command in the Varnish CLI, to get the master and optionally - cache process PIDs, for example from ``varnishadm``. - -varnishstat -=========== - -* Add vi-style CTRL-f / CTRL-b for page down/up to interactive - ``varnishstat``. - -* The ``MAIN.sess_drop`` counter is gone. - -* Added ``rx_close_idle`` counter for separate accounting when - ``sess.timeout_idle`` / :ref:`ref_param_timeout_idle` is reached. - -* ``sess.send_timeout`` / :ref:`ref_param_send_timeout` being reached - is no longer reported as ``MAIN.sc_rem_close``, but as - ``MAIN.sc_tx_error``. - -Changes for developers and VMOD authors -======================================= - -General -~~~~~~~ - -* New configure switch: ``--with-unwind``. Alpine linux appears to offer a - ``libexecinfo`` implementation that crashes when called by Varnish, this - offers the alternative of using ``libunwind`` instead. - -* The option ``varnishtest -W`` is gone, the same can be achieved with - ``varnishtest -p debug=+witness``. A ``witness.sh`` script is available - in the source tree to generate a graphviz dot file and detect potential - lock cycles from the test logs. - -* Introduced ``struct reqtop`` to hold information on the ESI top request - and ``PRIV_TOP``. - -* New or improved Coccinelle semantic patches that may be useful for - VMOD or utilities authors. - -* Added ``VSLs()`` and ``VSLbs()`` functions for logging ``STRANDS`` to - VSL. - -* Added ``WS_VSB_new()`` / ``WS_VSB_finish()`` for VSBs on workspaces. - -* added ``v_dont_optimize`` attribute macro to instruct compilers - (only gcc as of this release) to not optimize a function. - -* Added ``VSB_tofile()`` to ``libvarnishapi``. - -VMODs -~~~~~ - -* It is now possible for VMOD authors to customize the connection pooling - of a dynamic backend. A hash is now computed to determine uniqueness and - a backend declaration can contribute arbitrary data to influence the pool. - -* ``VRB_Iterate()`` signature has changed. - -* ``VRT_fail()`` now also works from director code. - -* ``body_status`` and ``req_body_status`` have been collapsed into one - type. In particular, the ``REQ_BODY_*`` enums now have been replaced - with ``BS_*``. - -* Added ``VRT_AllocStrandsWS()`` as a utility function to allocate - STRANDS on a workspace. - -*eof* - -.. _varnish_modules: https://github.com/varnish/varnish-modules diff --git a/doc/sphinx/whats-new/changes-6.5.rst b/doc/sphinx/whats-new/changes-6.5.rst deleted file mode 100644 index 56d78ad4ef..0000000000 --- a/doc/sphinx/whats-new/changes-6.5.rst +++ /dev/null @@ -1,252 +0,0 @@ -.. - Copyright (c) 2020 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_6.5: - -%%%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 6.5.0 -%%%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_6.5`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -varnishd -======== - -Access Control Lists (ACLs) -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The VCL compiler now emits warnings if network numbers used in ACLs do -not have an all-zero host part (as, for example, -``"192.168.42.42"/24``). By default, such ACL entries are fixed to -all-zero and that fact logged with the ``ACL`` VSL tag. - -Parameters -~~~~~~~~~~ - -A new ``vcc_acl_pedantic`` parameter, when set to ``true``, turns the -ACL warnings documented above into errors for the case where an ACL -entry includes a network prefix, but host bits aren't all zeroes. - -The ``solaris`` jail has been improved and can reduce privileges even further. -There is now a new optional ``-j solaris,worker=...`` argument which allows to -extend the effective privilege set of the worker (cache) process. - -Other changes in varnishd -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Some error messages improved in the VCL compiler. - -Changes to VCL -============== - -VCL variables -~~~~~~~~~~~~~ - -A new ``obj.can_esi`` variable has been added to identify whether the response -can be ESI processed. - -Once ``resp.filters`` is explicitly set, trying to set a ``resp.do_*`` field -results in a VCL failure. The same rule applies to ``beresp.filters`` and -``beresp.do_*`` fields. - -The ``BACKEND`` VCL type now has a ``.resolve()`` method to find the effective -backend directly from VCL. When a director is selected, the resolution would -otherwise be delayed until after returning from ``vcl_backend_fetch`` or -``vcl_pipe``:: - - # eager backend selection - set bereq.backend = bereq.backend.resolve(); - -It is now possible to manually set a ``Connection: close`` header in -``beresp`` to signal that the backend connection shouldn't be recycled. -This might help dealing with backends that would under certain circumstances -have trouble managing their end of the connection, for example for certain -kinds of resources. - -Care should be taken to preserve other headers listed in the connection -header:: - - sub vcl_backend_response { - if (beresp.backend == faulty_backend) { - if (beresp.http.Connection) { - set beresp.http.Connection += ", close"; - } else { - set beresp.http.Connection = "close"; - } - } - } - -Other changes to VCL -~~~~~~~~~~~~~~~~~~~~ - -A failure in ``vcl_recv`` could resume execution in ``vcl_hash`` before -effectively ending the transaction, this has been corrected. A failure in -``vcl_recv`` is now definitive. - -There is a new syntax for ``BLOB`` literals: ``::``. This syntax is -also used to automatically cast a blob into a string. - -Behavior for 304 responses was changed not to update the -``Content-Encoding`` response header of the stored object. - -VMODs -===== - -A new ``std.blobread()`` function similar to ``std.fileread()`` was added to -work with binary files. - -The shard director's ``.add_backend()`` method has a new optional ``weight`` -parameter. An error when a backend is added or removed now fails the -transaction (or the ``vcl.load`` command in ``vcl_init``), but an invalid -weight does not result in a hard failure. - -The shard director no longer outputs the (unused) ``canon_point`` property -in ``backend.list`` commands. - -varnishlog -========== - -The ``BackendReuse`` log record has been retired. It was named -inconsistently with other places like stat counters where we use the -words reuse and recycle (it should have been named ``BackendRecycle`` -if anything). - -The ``BackendOpen`` record can now tell whether the connection to the backend -was opened or reused from the pool, and the ``BackendClose`` record will tell -whether the connection was effectively closed or recycled into the pool. - -varnishadm -========== - -The ``backend.set_health`` command can be used to force a specific state -between sick and healthy or restore the automatic behavior, which depends on -the presence of a probe. While forcing a backend to be sick would prevent it -from being selected by a director, a straight selection of the backend from -VCL would still attempt a connection. This has been fixed, and the command's -documentation was clarified. - -varnishstat -=========== - -A help screen is now available in interactive mode via the ``h`` key. - -Again in interactive mode, the initial verbosity is now chosen such -that fields selected via the ``-f`` or ``-I`` options are actually -displayed without manually increasing the verbosity level. - -Filtering using the ``-f`` option is now deprecated in favor of ``-I`` and -``-X`` options that are treated in order. While still present, the ``-f`` -option now also works in order instead of exclusive filters first and then -inclusive filters. It was also wrongly documented as inclusive first. - -The JSON output slightly changed to more easily be consumed with programming -languages that may map JSON objects to types. See upgrade notes for more -details. - -There are two new ``MAIN.beresp_uncacheable`` and ``MAIN.beresp_shortlived`` -counters. - -varnishtest -=========== - -The ``process -expect-text`` command will wait an order of magnitude longer -for the text to appear. It used to be too sensitive to any kind of timing -disruption. - -Changes for developers and VMOD authors -======================================= - -Build System -~~~~~~~~~~~~ - -VMOD authors who would like to generate VCC files can now use the -``VINYL_VMODS_GENERATED()`` macro from ``varnish.m4`` for autotools -builds. - -.. _whatsnew_changes_6.5_workspace: - -Workspace API -~~~~~~~~~~~~~ - -The workspace API saw a number of changes in anticipation of a future -inclusion in VRT. The deprecated ``WS_Reserve()`` function was finally -removed, after the functions ``WS_ReserveSize()`` and -``WS_ReserveAll()`` were introduced in Varnish Cache 6.3.0. - -On the topic of workspace reservation, the ``WS_Front()`` function is -now deprecated in favor of ``WS_Reservation()``. The two functions -behave similarly, but the latter ensures that it is only ever called -during a reservation. There was no legitimate reason to access the -workspace's front outside of a reservation. - -In a scenario where a reservation is made in a part of the code, but -used somewhere else, it is possible to later query the size with the -new ``WS_ReservationSize()`` function. - -The return value for ``WS_Printf()`` is now a constant string. - -Other VRT / cache.h changes -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -* Added ``VRT_DirectorResolve()`` to resolve a director - -* Added ``VRT_BLOB_string()`` for the default BLOB folding documented above - -.. _whatsnew_changes_6.5_vsc: - -libvarnishapi -~~~~~~~~~~~~~ - -There are three new VSC arguments that can be set with the ``VSC_Arg()`` -function: - -- ``'I'`` to include counters matching a glob pattern -- ``'X'`` to exclude counters matching a glob pattern -- ``'R'`` to include required counters regardless of ``'I'`` and ``'X'`` - -The ``'f'`` argument is now deprecated and emulated with ``'I'`` and ``'X'``. -Filtering with ``'f'`` used to check exclusions first and then inclusions, -they are all tested in order and the first to match determines the outcome. - -The ``'R'`` argument takes precedence over regular filtering and can be used -to ensure that some counters are present regardless of user configuration. - -.. _whatsnew_changes_6.5_libvarnish: - -libvarnish -~~~~~~~~~~ - -A ``VSA_BuildFAP()`` function has been added as a convenience to build a -``struct suckaddr`` (aka ``VCL_IP``) from a Family, Address and Protocol -components. - -We added ``VRE_quote()`` to facilitate building literal string matches -with regular expressions. It can be used to ensure that a user-defined -string literal put inside a regular expression may not accidentally -change the behavior of the overall expression. - -The varnish binary heap implementation has been added with the -``VBH_`` prefix for use with VMODs (via include of ``vbh.h``). - -VSB support for dynamic vs. static allocations has been changed: - -For dynamic allocations use:: - - VSB_new_auto() + VSB_destroy() - -For preexisting buffers use:: - - VSB_init() + VSB_fini() - -``VSB_new()`` + ``VSB_delete()`` are now deprecated. - -*eof* diff --git a/doc/sphinx/whats-new/changes-6.6.rst b/doc/sphinx/whats-new/changes-6.6.rst deleted file mode 100644 index 3275f99418..0000000000 --- a/doc/sphinx/whats-new/changes-6.6.rst +++ /dev/null @@ -1,493 +0,0 @@ -.. - Copyright 2021 UPLEX Nils Goroll Systemoptimierung - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_6.6: - -%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 6.6 -%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_6.6`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -varnishd -======== - -Arguments -~~~~~~~~~ - -* ``varnishd`` now supports the ``-b none`` argument to start with - only the builtin VCL and no backend at all. - -Parameters -~~~~~~~~~~ - -* The ``validate_headers`` parameter has been added to control - `header validation `_. - -* The ``ban_cutoff`` parameter now refers to the overall length of the - ban list, including completed bans, where before only non-completed - ("active") bans were counted towards ``ban_cutoff``. - -* The ``vary_notice`` parameter has been added to control the - threshold for the new `Vary Notice - `_. - -``feature`` Flags -~~~~~~~~~~~~~~~~~ - -* The ``busy_stats_rate`` feature flag has been added to ensure - statistics updates (as configured using the ``thread_stats_rate`` - parameter) even in scenarios where worker threads never run out - of tasks and may remain forever busy. - -.. _whatsnew_changes_6.6_accounting: - -Accounting -~~~~~~~~~~ - -Body bytes accounting has been fixed to always represent the number of -body bytes moved on the wire, exclusive of protocol-specific overhead -like HTTP/1 chunked encoding or HTTP/2 framing. - -This change affects counters like - -- ``MAIN.s_req_bodybytes``, - -- ``MAIN.s_resp_bodybytes``, - -- ``VBE.*.*.bereq_bodybytes`` and - -- ``VBE.*.*.beresp_bodybytes`` - -as well as the VSL records - -- ``ReqAcct``, - -- ``PipeAcct`` and - -- ``BereqAcct``. - -.. _whatsnew_changes_6.6_sc_close: - -Session Close Reasons -~~~~~~~~~~~~~~~~~~~~~ - -The connection close reason has been fixed to properly report -``SC_RESP_CLOSE`` / ``resp_close`` where previously only -``SC_REQ_CLOSE`` / ``req_close`` was reported. - -For failing PROXY connections, ``SessClose`` now provides more -detailed information on the cause of the failure. - -The session close reason logging/statistics for HTTP/2 connections -have been improved. - -.. _whatsnew_changes_6.6_vary_notice: - -Vary Notice -~~~~~~~~~~~ - -A log (VSL) ``Notice`` record is now emitted whenever more than -``vary_notice`` variants are encountered in the cache for a specific -hash. The new ``vary_notice`` parameter defaults to 10. - -Changes to VCL -============== - -.. _whatsnew_changes_6.6_header_validation: - -Header Validation -~~~~~~~~~~~~~~~~~ - -Unless the new ``validate_headers`` feature is disabled, all newly set -headers are now validated to contain only characters allowed by -RFC7230. A (runtime) VCL failure is triggered if not. - -VCL variables -~~~~~~~~~~~~~ - -* The ``client.identity`` variable is now accessible on the backend - side. - -* The variables ``bereq.is_hitpass`` and ``bereq.is_hitmiss`` have - been added to the backend side matching ``req.is_hitpass`` and - ``req.is_hitmiss`` on the client side. - -* The ``bereq.xid`` variable is now also available in ``vcl_pipe {}`` - -* The ``resp.proto`` variable is now read-only as it should have been - for long, like the other ``*.proto`` variables. - -Other changes to VCL -~~~~~~~~~~~~~~~~~~~~ - -* Long strings in VCL can now also be denoted using ``""" ... """`` in - addition to the existing ``{" ... "}``. - -* The ``ban()`` builtin is now deprecated and should be replaced with - `std.ban() `_. - -* Trying to use ``std.rollback()`` from ``vcl_pipe`` now results in - VCL failure. - -* The modulus operator ``%`` has been added to VCL. - -* ``return(retry)`` from ``vcl_backend_error {}`` now correctly resets - ``beresp.status`` and ``beresp.reason``. - -* The builtin VCL has been reworked: VCL code has been split into - small subroutines, which custom VCL can prepend custom code to. - - This allows for better integration of custom VCL and the built-in - VCL and better reuse. - -VMODs -===== - -``directors.shard()`` -~~~~~~~~~~~~~~~~~~~~~ - -* The shard director now supports reconfiguration (adding/removing - backends) of several instances without any special ordering - requirement. - -* Calling the shard director ``.reconfigure()`` method is now - optional. If not called explicitly, any shard director backend - changes are applied at the end of the current task. - -* Shard director ``Error`` log messages with ``(notice)`` have been - turned into ``Notice`` log messages. - -* All shard ``Error`` and ``Notice`` messages now use the unified - prefix ``vmod_directors: shard %s``. - -``std.set_ip_tos()`` -~~~~~~~~~~~~~~~~~~~~ - -The ``set_ip_tos()`` function from the bundled ``std`` vmod now sets -the IPv6 Traffic Class (TCLASS) when used on an IPv6 connection. - -.. _whatsnew_changes_6.6_ban: - -``std.ban()`` and ``std.ban_error()`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The ``std.ban()`` and ``std.ban_error()`` functions have been added to -the ``std`` vmod, allowing VCL to check for ban errors. A typical -usage pattern with the new interface is:: - - if (std.ban(...)) { - return(synth(200, "Ban added")); - } else { - return(synth(400, std.ban_error())); - } - -.. _whatsnew_changes_6.6_cookie: - -``cookie`` functions -~~~~~~~~~~~~~~~~~~~~ - -The ``filter_re``, ``keep_re`` and ``get_re`` functions from the -bundled ``cookie`` vmod have been changed to take the ``VCL_REGEX`` -type. This implies that their regular expression arguments now need to -be literal, whereas before they could be taken from some other -variable or function returning ``VCL_STRING``. - -Note that these functions never actually handled *dynamic* regexen, -the string passed with the first call was compiled to a regex, which -was then used for the lifetime of the respective VCL. - - -varnishlog -========== - -* See `Accounting `_ for changes - to accounting-related VSL records. - -* See `Session Close Reasons `_ - for a change affecting ``SessClose``. - -* Three new ``Timestamp`` VSL records have been added to backend - request processing: - - - The ``Process`` timestamp after ``return(deliver)`` or - ``return(pass(x))`` from ``vcl_backend_response``, - - - the ``Fetch`` timestamp before a backend connection is requested - and - - - the ``Connected`` timestamp when a connection to a regular backend - (VBE) is established, or when a recycled connection was selected for - reuse. - -* The ``FetchError`` log message ``Timed out reusing backend - connection`` has been renamed to ``first byte timeout (reused - connection)`` to clarify that it is emit for effectively the same - reason as ``first byte timeout``. - -* ``ExpKill`` log (VSL) records are now masked by default. See the - ``vsl_mask`` parameter. - -* Comparisons of numbers in VSL queries have been improved to match - better the behavior which is likely expected by users who have not - read the documentation in all detail. - -* See `Vary Notice `_ for - information on a newly added ``Notice`` log (VSL) record. - -varnishncsa -=========== - -* The ``%{X}T`` format has been added to ``varnishncsa``, which - generalizes ``%D`` and ``%T``, but also support milliseconds - (``ms``) output. - -* The ``varnishncsa`` ``-E`` argument to show ESI requests has been - changed to imply ``-c`` (client mode). This behavior is now shared - by all log utilities, and ``-c`` no longer includes ESI requests. - - -varnishadm -========== - -* The ``vcl.discard`` CLI command can now be used to discard more than - one VCL with a single command, which succeeds only if all given VCLs - could be discarded (atomic behavior). - -* The ``vcl.discard`` CLI command now supports glob patterns for vcl names. - -* The ``vcl.deps`` CLI command has been added to output dependencies - between VCLs (because of labels and ``return(vcl)`` statements). - -* ``varnishadm`` now has the ``-p`` option to disable readline support - for use in scripts and as a generic CLI connector. - -varnishstat -=========== - -* See `Accounting `_ for changes - to accounting-related counters. - -* See `Session Close Reasons `_ - for a change affecting ``MAIN.sc_*`` counters. - -* The ``MAIN.esi_req`` counter has been added as a statistic of the - number of ESI sub requests created. - -* The ``MAIN.s_bgfetch`` counter has been added as a statistic on the - number of background fetches issued. - -.. _whatsnew_changes_6.6_varnishstat_raw: - -* ``varnishstat`` now avoids display errors of gauges which previously - could underflow to negative values, being displayed as extremely - high positive values. - - The ``-r`` option and the ``r`` key binding have been added to - return to the previous behavior. When raw mode is active in - ``varnishstat`` interactive (curses) mode, the word ``RAW`` is - displayed at the right hand side in the lower status line. - -varnishtest -=========== - -Various improvements have been made to the ``varnishtest`` facility: - -- the ``loop`` keyword now works everywhere - -- HTTP/2 logging has been improved - -- Default HTTP/2 parameters have been tweaked - -- Varnish listen address information is now available by default in - the macros ``${vNAME_addr}``, ``${vNAME_port}`` and - ``${vNAME_sock}``. Macros by the names ``${vNAME_SOCKET_*}`` contain - the address information for each listen socket as created with the - ``-a`` argument to ``varnishd``. - -- Synchronization points for counters (VSCs) have been added as - ``varnish vNAME -expect PATTERN OP PATTERN`` - -- varnishtest now also works with IPv6 setups - -- ``feature ipv4`` and ``feature ipv6`` can be used to control - execution of test cases which require one or the other protocol. - -- haproxy arguments can now be externally provided through the - ``HAPROXY_ARGS`` variable. - -- logexpect now supports alternatives with the ``expect ? ...`` syntax - and negative matches with the ``fail add ...`` and ``fail clear`` - syntax. - -- The overall logexpect match expectation can now be inverted using - the ``-err`` argument. - -- Numeric comparisons for HTTP headers have been added: ``-lt``, - ``-le``, ``-eq``, ``-ne``, ``-ge``, ``-gt`` - -- ``rxdata -some`` has been fixed. - -Other Changes to Varnish Utilities -================================== - -All varnish tools using the VUT library utilities for argument -processing now support the ``--optstring`` argument to return a string -suitable for use with ``getopts`` from shell scripts. - -.. _whatsnew_changes_6.6_vmod: - -Developer: Changes for VMOD authors -=================================== - -VMOD/VCL interface -~~~~~~~~~~~~~~~~~~ - -* The ``VCL_REGEX`` data type is now supported for VMODs, allowing - them to use regular expression literals checked and compiled by the - VCL compiler infrastructure. - - Consequently, the ``VRT_re_init()`` and ``VRT_re_fini()`` functions - have been removed, because they are not required and their use was - probably wrong anyway. - -* The ``VCL_SUB`` data type is now supported for VMODs to save - references to subroutines to be called later using - ``VRT_call()``. Calls from a wrong context (e.g. calling a - subroutine accessing ``req`` from the backend side) and recursive - calls fail the VCL. - - See `VMOD - Varnish Modules`_ in the Reference Manual. - -.. _VMOD - Varnish Modules: https://vinyl-cache.org/docs/trunk/reference/vmod.html - - VMOD functions can also return the ``VCL_SUB`` data type for calls - from VCL as in ``call vmod.returning_sub();``. - -* ``VRT_check_call()`` can be used to check if a ``VRT_call()`` would - succeed in order to avoid the potential VCL failure in case it would - not. - - It returns ``NULL`` if ``VRT_call()`` would make the call or an - error string why not. - -* ``VRT_handled()`` has been added, which is now to be used instead of - access to the ``handling`` member of ``VRT_CTX``. - -* ``vmodtool.py`` has been improved to simplify Makefiles when many - VMODs are built in a single directory. - -General API -~~~~~~~~~~~ - -* ``VRT_ValidHdr()`` has been added for VMODs to conduct the same - check as the `whatsnew_changes_6.6_header_validation`_ feature, - for example when headers are set by VMODs using the ``cache_http.c`` - Functions like ``http_ForceHeader()`` from untrusted input. - -* Client and backend finite state machine internals (``enum req_step`` - and ``enum fetch_step``) have been removed from ``cache.h``. - -* The ``verrno.h`` header file has been removed and merged into - ``vas.h`` - -* The ``pdiff()`` function declaration has been moved from ``cache.h`` - to ``vas.h``. - -VSA -~~~ - -* The ``VSA_getsockname()`` and ``VSA_getpeername()`` functions have - been added to get address information of file descriptors. - -Private Pointers -~~~~~~~~~~~~~~~~ - -* The interface for private pointers in VMODs has been changed: - - - The ``free`` pointer in ``struct vmod_priv`` has been replaced - with a pointer to ``struct vmod_priv_methods``, to where the - pointer to the former free callback has been moved as the ``fini`` - member. - - - The former free callback type has been renamed from - ``vmod_priv_free_f`` to ``vmod_priv_fini_f`` and as gained a - ``VRT_CTX`` argument - -* The ``VRT_priv_task_get()`` and ``VRT_priv_top_get()`` functions - have been added to VRT to allow vmods to retrieve existing - ``PRIV_TASK`` / ``PRIV_TOP`` private pointers without creating any. - -Backends -~~~~~~~~ - -* The VRT backend interface has been changed: - - - ``struct vrt_endpoint`` has been added describing a UDS or TCP - endpoint for a backend to connect to. - - Endpoints also support a preamble to be sent with every new - connection. - - - This structure needs to be passed via the ``endpoint`` member of - ``struct vrt_backend`` when creating backends with - ``VRT_new_backend()`` or ``VRT_new_backend_clustered()``. - -* ``VRT_Endpoint_Clone()`` has been added to facilitate working with - endpoints. - -Filters (VDP/VFP) -~~~~~~~~~~~~~~~~~ - -* Many filter (VDP/VFP) related signatures have been changed: - - - ``vdp_init_f`` - - - ``vdp_fini_f`` - - - ``vdp_bytes_f`` - - - ``VDP_bytes()`` - - as well as ``struct vdp_entry`` and ``struct vdp_ctx`` - - ``VFP_Push()`` and ``VDP_Push()`` are no longer intended for VMOD - use and have been removed from the API. - -* The VDP code is now more strict about ``VDP_END``, which must be - sent down the filter chain at most once. Care should be taken to - send ``VDP_END`` together with the last payload bytes whenever - possible. - -Stevedore API -~~~~~~~~~~~~~ - -* The stevedore API has been changed: - - - ``OBJ_ITER_FINAL`` has been renamed to ``OBJ_ITER_END`` - - - ``ObjExtend()`` signature has been changed to also cover the - ``ObjTrimStore()`` use case and - - - ``ObjTrimStore()`` has been removed. - -Developer: Changes for Authors of Varnish Utilities -=================================================== - -libvarnishapi -~~~~~~~~~~~~~ - -* The ``VSC_IsRaw()`` function has been added to ``libvarnishapi`` to - query if a gauge is being returned raw or adjusted (see - `varnishstat -r option `_). - -*eof* diff --git a/doc/sphinx/whats-new/changes-7.0.rst b/doc/sphinx/whats-new/changes-7.0.rst deleted file mode 100644 index a281223eb9..0000000000 --- a/doc/sphinx/whats-new/changes-7.0.rst +++ /dev/null @@ -1,310 +0,0 @@ -.. - Copyright 2021 Varnish Software - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_changes_7.0: - -%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 7.0 -%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_7.0`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -PCRE2 -===== - -One major change for this release is the migration of the regular expression -engine from PCRE to PCRE2. This change should be mostly transparent anywhere -regular expressions are used, like VCL, ban expressions, VSL queries etc. - -There were some parameters changes, see the upgrade notes for more details. - -RFC8941 - Structured Fields -=========================== - -It will come as no surprise to VCL writers that HTTP headers use what can -charitably be described as "heterogenous syntax". - -In 2016, on the train back from the HTTP Workshop in Stockholm, and -in response to proposals to allow JSON in HTTP headers, I started an effort -which culminated with the publication of `RFC 8941 Structured Fields`_. - -The syntax in Structured Fields is distilled from current standardized headers, -which means that the vast majority of existing HTTP headers are already -covered. - -There are unfortunate exceptions, most notably the Cookie headers. - -Starting with this release, we are gently migrating VCL towards the -Structured Field semantics. - -The first change is that it is now possible to include BLOBs in VCL, -by using the RFC 8941 syntax of:: - - ':' + + ':' - -For example, the VCL string ``"helloworld"`` can be represented as the BLOB -literal ``:aGVsbG93b3JsZA==:`` without involving a VMOD. - -See :ref:`vmod_blob(3)`. - -The second and likely more significant change is numbers in VCL -now conform to RFC8941 as well: Up to 15 digits and at most 3 -decimal places, and "scientific notation" is no longer allowed. - -(These restrictions were chosen after much careful deliberation, to -ensure that no overflows would occur, even when HTTP headers are -processed in languages where numbers are represented by IEEE-754 -64 binary floating point variables.) - -.. _RFC 8941 Structured Fields: https://www.rfc-editor.org/rfc/rfc8941.html - -varnishd -======== - -Parameters -~~~~~~~~~~ - -There were changes to the parameters: - -- new ``pcre2_jit_compilation`` boolean defaulting to on -- the default value increased to 16kB for ``vsl_buffer`` -- the default value increased to 96kB for ``workspace_client`` -- the default value increased to 96kB for ``workspace_backend`` -- the minimum value increased to 384B for ``workspace_session`` -- the minimum value increased to 65535B for ``h2_initial_window_size`` -- the default value increased to 80kB for ``thread_pool_stack`` -- the default value increased to 64kB for ``thread_pool_stack`` on 32bit - systems -- ``vcc_acl_pedantic`` was removed, see upgrade notes for more details. -- ``pcre_match_limit`` was renamed to ``pcre2_match_limit`` -- ``pcre_match_limit_recursion`` was renamed to ``pcre2_depth_limit`` -- new ``h2_rxbuf_storage`` defaulting to ``Transient``, see upgrade notes for - more details. - -Other changes in varnishd -~~~~~~~~~~~~~~~~~~~~~~~~~ - -For pass transactions, ``varnishd`` no longer strips ``Range`` headers from -client requests or ``Accept-Range`` and ``Content-Range`` headers from backend -responses to allow partial delivery directly from the backend. - -When ``http_range_support`` is on (the default) a consistency check is -performed on the backend response and malformed or inconsistent responses -are treated as fetch errors. - -There is a new buffer for HTTP/2 request bodies allocated from storage. - -See upgrade notes for more details on both topics. - -Changes to VCL -============== - -VCL variables -~~~~~~~~~~~~~ - -A new ``req.hash_ignore_vary`` flag allows to skip vary header checks during a -lookup. This can be useful when only the freshness of a resource is relevant, -and not a slight difference in representation. - -For interoperability purposes, it is now possible to quote header names that -aren't valid VCL symbols, but valid HTTP header names, for example:: - - req.http."dotted.name" - -This is rarely observed and should only be needed to better integrate with the -specific needs of certain clients or servers. - -Some global VCL symbols can be referenced before their declaration, this was -extended to all global VCL symbols for the following keywords: - -- ``acl`` -- ``backend`` -- ``probe`` -- ``sub`` - -Consider the following example:: - - sub vcl_recv { - set req.backend_hint = b; - } - - backend b { - .host = "example.org"; - } - -It used to fail the VCL compilation with "Symbol not found: 'b'" in -``vcl_recv``, and is now supported. - -Bit flags -~~~~~~~~~ - -There is a new bit flag syntax for certain VCL keywords:: - - keyword +flag -other ... - -Similarly to bit flag ``varnishd`` parameters ``debug``, ``feature`` and -``vsl_mask``, a ``+`` prefix means that a flag is raised and a ``-`` prefix -that a flag is cleared. - -The ``acl`` keyword supports the following flags: - -- ``log`` -- ``pedantic`` (enabled by default) -- ``table`` - -For example:: - - acl +log -pedantic { ... } - -See :ref:`vcl-acl`. - -The ``include`` keyword supports a ``glob`` flag. - -For example:: - - include +glob "example.org/*.vcl"; - -See :ref:`vcl-include`. - -See upgrade notes for more details. - -VMODs -===== - -New ``BASE64CF`` encoding scheme in ``vmod_blob``. It is similar to -``BASE64URL``, with the following changes to ``BASE64``: - -- ``+`` replaced with ``-`` -- ``/`` replaced with ``~`` -- ``_`` as the padding character - -It is used by a certain CDN provider who also inspired the name. - -See the ``vmod_blob`` manual (:ref:`vmod_blob-base64`). - -varnishlog -========== - -If a cache hit occurs on a streaming object, an object that is still being -fetched, ``Hit`` records contain progress of the fetch task. This should help -troubleshooting when cache hits appear to be slow, whether or not the backend -is still serving the response. - -See :ref:`vcl(7)`. - -By default ``VCL_acl`` records are no longer emitted. They can be brought back -by adding a ``+log`` flag to the ACL declaration. - -See :ref:`vcl-acl`. - -varnishncsa -=========== - -New ``%{...}t`` time formats: - -- ``sec`` -- ``msec`` -- ``usec`` -- ``msec_frac`` -- ``usec_frac`` - -See the ``varnishncsa`` manual (:ref:`ncsa-format`) for more information. - -varnishadm -========== - -The ``-t`` option sets up the timeout for both attaching to a running -``varnishd`` instance and individual commands sent to that instance. - -Command completion should be more accurate in interactive mode. - -varnishtest -=========== - -Test cases should be generally more reactive, whether it is detecting -a ``varnishd`` startup failure, waiting for ``varnishd`` to stop, or -when tests fail and there are barriers waiting for a synchronization. - -Clients and servers can have up to 64 headers in requests and responses. - -The ``feature`` command allows to skip gracefully test cases that are -missing specific requirements. It is now possible to skip a test based on -the presence of a feature. - -For example, for test cases targeting 32bit environment with a working DNS -setup:: - - feature dns !64bit - -There are new feature checks: - -- ``coverage`` -- ``asan`` -- ``msan`` -- ``tsan`` -- ``ubsan`` -- ``sanitizer`` -- ``workspace_emulator`` - -The undocumented ``pcre_jit`` feature check is gone. - -See the VTC manual (:ref:`vtc-feature`) for more details. - -There is a new ``tunnel`` command that acts as a proxy between two peers. A -tunnel can pause and control how much data goes in each direction, and can -be used to trigger socket timeouts, possibly in the middle of protocol frames, -without having to change how the peers are implemented. - -See the VTC manual (:ref:`vtc-tunnel`) for more details. - -There is a new dynamic macro ``${string,repeat,,}`` to avoid -very long lines or potential mistakes when maintained by hand. For example, -the two following strings are equivalent:: - - "AAA" - "${string,repeat,3,A}" - -See the VTC manual (:ref:`vtc-macros`) for more details. - -There were also various improvements to HTTP/2 testing, and more should be -expected. - -Changes for developers and VMOD authors -======================================= - -Varnish now comes with a second workspace implementation called the workspace -emulator. It needs to be enabled during the build with the configure flag -``--enable-workspace-emulator``. - -The workspace emulator performs sparse allocations and can help VMOD authors -interested in fuzzing, especially when the Address Sanitizer is enabled as -well. - -In order to make the emulator possible, some adjustments were needed for the -workspace API. Deprecated functions ``WS_Front()`` and ``WS_Inside()`` were -removed independently of the emulator. - -The ``STRING_LIST`` type is gone in favor of ``STRANDS``. All the VRT symbols -related to ``STRING_LIST`` are either gone or changed. - -Convenience constants ``vrt_null_strands`` and ``vrt_null_blob`` were added. - -The migration to PCRE2 also brought many changes to the VRE API. The VRT -functions handling ``REGEX`` arguments didn't change. - -The VNUM API also changed substantially for structured field number parsing. - -The deprecated functions ``VSB_new()`` and ``VSB_delete()`` were removed. - -See upgrade notes for more information. - -*eof* diff --git a/doc/sphinx/whats-new/changes-7.1.rst b/doc/sphinx/whats-new/changes-7.1.rst deleted file mode 100644 index b14076f279..0000000000 --- a/doc/sphinx/whats-new/changes-7.1.rst +++ /dev/null @@ -1,227 +0,0 @@ -.. _whatsnew_changes_7.1: - -%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 7.1 -%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_7.1`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -varnishd -======== - -Parameters -~~~~~~~~~~ - -A new kind of parameters exists: deprecated aliases. Their documentation is -minimal, mainly referring to the actual symbols they alias. They are not -listed in the CLI, unless referred to explicitly. - -There is no deprecated alias yet, but some are already planned for future -releases. Alias parameters have next to no overhead when used directly. - -The deprecated ``vsm_space`` parameter was removed. - -A new ``cc_warnings`` parameter contains a subset of the compiler flags -extracted from ``cc_command``, which in turn grew new expansions: - -- ``%d``: the raw default ``cc_command`` -- ``%D``: the expanded default ``cc_command`` -- ``%w``: the ``cc_warnings`` parameter -- ``%n``: the working directory (``-n`` option) - -This should facilitate the creation of wrapper scripts around VCL compilation. - -There is a new ``experimental`` parameter that is identical to the ``feature`` -parameter, except that it guards features that may not be considered complete -or stable. An experimental feature may be promoted to a regular feature or -dropped without being considered a breaking change. - -Command line options -~~~~~~~~~~~~~~~~~~~~ - -The deprecated sub-argument of the ``-l`` option was removed, it is now a -shorthand for the ``vsl_space`` parameter only. - -The ``-T``, ``-M`` and ``-P`` command line options can be used multiple times, -instead of retaining only the last occurrence. - -When there is no active VCL, the first loaded VCL was always implicitly used -too. This is now only true for VCLs loaded with either the ``-f`` or ``-b`` -options, since they imply a ``vcl.use``. VCL loaded through the Varnish CLI -(``vcl.load`` or ``vcl.inline``) via a CLI script loaded through the ``-I`` -command line option require an explicit ``vcl.use``. - -Other changes in varnishd -~~~~~~~~~~~~~~~~~~~~~~~~~ - -ESI includes now support the ``onerror="continue"`` attribute. However, in -order to take effect a new ``+esi_include_onerror`` feature flag needs to be -raised. - -Changes to VCL -============== - -It is now possible to assign a ``BLOB`` value to a ``BODY`` variable, -in addition to ``STRING`` as before. - -VCL variables -~~~~~~~~~~~~~ - -New VCL timestamp variables have been added to track the point in time -when HTTP messages were created: - -- ``req.time`` -- ``req_top.time`` -- ``resp.time`` -- ``bereq.time`` -- ``beresp.time`` -- ``obj.time`` - -The new ``req.transport`` variable returns "HTTP/1" or "HTTP/2" as -appropriate. - -Other changes to VCL -~~~~~~~~~~~~~~~~~~~~ - -Where a regular expression literal is expected, it is now possible to have a -concatenation of constant strings. It can be useful when part of the -expression comes from an environment-specific include, or to break a long -expression into multiple lines. (introduced with 7.0.1) - -Similarly to ``varnishd`` parameters, it is now possible to have deprecated -aliases of VCL variables. Although there are none so far, aliases will allow -some symbols to be renamed without immediately breaking existing VCL code. - -Deprecated VCL aliases have no runtime overhead, they are reified at VCL -compile time. - -VMODs -===== - -New :ref:`std.strftime()` function for UTC formatting. - -It is now possible to declare deprecated aliases of VMOD functions and object -methods, just like VCL aliases. The ``cookie.format_rfc1123()`` function was -renamed to :ref:`cookie.format_date()`, and the former was retained as a -deprecated alias of the latter for compatibility. - -Deprecated VMOD aliases have no runtime overhead, they are reified at VCL -compile time. - -varnishlog -========== - -It is now possible to write to the standard output with ``-w -``, to be on par -with the ability to read from the standard input with ``-r -``. This is not -possible in daemon mode. - -In a pipe scenario, the backend transaction emits a Start timestamp and both -client and backend transactions emit the Process timestamp. - -varnishncsa -=========== - -It is now possible to write to the standard output with ``-w -``, to be on par -with the ability to read from the standard input with ``-r -``. This is not -possible in daemon mode. - -varnishadm -========== - -When ``vcl.show`` is invoked without a parameter, it defaults to the active -VCL. - -The ``param.set`` command accepts a ``-j`` option. In this case the JSON -output is the same as ``param.show -j`` of the updated parameter. - -A new ``debug.shutdown.delay`` command is available in the Varnish CLI for -testing purposes. It can be useful for testing purposes to see how its -environment (service manager, container orchestrator, etc) reacts to a -``varnishd``'s child process taking significant time to ``stop``. - -varnishtest -=========== - -The ``SO_RCVTIMEO_WORKS`` feature check is gone. (introduced with 7.0.1) - -The reporting of ``logexpect`` events was rearranged for readability. - -The ``abort`` command in the ``logexpect`` facility of ``varnishtest`` -can now be used to trigger an ``abort()`` to help debugging the vsl -client library code. - -The ``vtc.barrier_sync()`` VMOD function can be used in ``vcl_init`` from now -on. - -Changes for developers and VMOD authors -======================================= - -The ``SO_RCVTIMEO`` and ``SO_SNDTIMEO`` socket options are now -required at build time since their absence would otherwise prevent -some timeouts to take effect. We no longer check whether they -effectively work, hence the removal of the ``SO_RCVTIMEO_WORKS`` -feature check in ``varnishtest``. (introduced with 7.0.1) - -Varnish will use libunwind by default when available at configure time, the -``--without-unwind`` configure flag can prevent this and fall back to -libexecinfo to generate backtraces. - -There is a new debug storage backend for testing purposes. So far, it can only -be used to ensure that allocation attempts return less space than requested. - -There are new C macros for ``VCL_STRANDS`` creation: ``TOSTRAND()`` and -``TOSTRANDS()`` are available in ``vrt.h``. - -New utility macros ``vmin[_t]``, ``vmax[_t]`` and ``vlimit[_t]`` available in -``vdef.h``. - -The fetch and delivery filters should now be registered and unregistered with -``VRT_AddFilter()`` and ``VRT_RemoveFilter()``. - -Dynamic backends are now reference-counted, and VMOD authors must explicitly -track assignments with ``VRT_Assign_Backend()``. - -The ``vtc.workspace_reserve()`` VMOD function will zero memory from now on. - -When the ``+workspace`` debug flag is raised, workspace logs are no longer -emitted as raw logs disconnected from the task. Having workspace logs grouped -with the rest of the task should help workspace footprint analysis. - -It is now possible to generate arbitrary log lines with ``vtc.vsl()`` -and ``vtc.vsl_replay()``, which can help testing log processing -utilities. - -It is also possible to tweak the VXID cache chunk size per thread pool with -the ``debug.xid`` command for the Varnish CLI, which can also help testing -log processing utilities. - -``http_IsHdr()`` is now exposed as part of the strict ABI for VMODs. - -Platform Support -================ - -CentOS -~~~~~~ - -With the End of Life of CentOS 8, we will build el8 packages on almalinux -from now on. This means that we will always target the oldest el8 branch. -For example a package built for el8.5 is not guaranteed to work on el8.1 -even though the latter may still be supported by Red Hat. - -systemd -~~~~~~~ - -The kill mode of the varnish service was changed from ``process`` to ``mixed`` -to ensure that the cache process is killed if the manager process is timed out -by systemd. Otherwise, a race exists with the cache process where a restart is -carried on before the old cache process exits, creating conflict on resources -such as listen ports. - -*eof* diff --git a/doc/sphinx/whats-new/changes-7.2.rst b/doc/sphinx/whats-new/changes-7.2.rst deleted file mode 100644 index 63c0ada8d6..0000000000 --- a/doc/sphinx/whats-new/changes-7.2.rst +++ /dev/null @@ -1,169 +0,0 @@ -.. _whatsnew_changes_7.2: - -%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 7.2 -%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_7.2`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -varnishd -======== - -Extensions -~~~~~~~~~~ - -From the very first days of Varnish, we have been talking about having -an extension points for "more advanced stuff" and we did, by and large, -keep a place ready for it in the overall architecture. - -Now a credible use-case finally appeared, and we have implemented -"Varnish Extensions" (VTLA: "VEXT"), which can both be used to load -ambient VMODs and to implement entirely new functionality, for instance -stevedores. - -See :ref:`ref-vext` in the reference manual for more information. - -Parameters -~~~~~~~~~~ - -Duration values (with a unit in seconds) can optionally take a duration -unit with the same syntax as VCL. For example, the default values of -``default_ttl``, ``default_grace`` and ``default_keep`` were changed -respectively from ``120.000``, ``10.000`` and ``0.000`` to ``2m``, ``10s`` -and ``0s``. - -The platform-dependent ``tcp_keepalive_time`` parameter is supported on -macOS. - -The new ``vcc_feature`` bits parameter replaces previous ``vcc_*`` boolean -parameters. The latter still exist as deprecated aliases. - -Other changes in varnishd -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The metadata VMODs exposes to Varnishd has changed to a non-binary -format, and it is incompatible with all previous releases. -That makes it possible for the VCC (compilation) process to avoid -opening the VMODs with ``dlopen(3)``, which is both faster and -safer. - -Background fetch tasks are no longer queued as this could result in slow -grace hits subject to indefinite delays when thread pools are saturated. - -Changes to VCL -============== - -VCL variables -~~~~~~~~~~~~~ - -ESI sub-requests can no longer inherit a ``req.http.transfer-encoding`` -header since the request body is strictly handled by the top request. - -The ``resp.http.via`` header generated by Varnish uses ``server.identity`` -which defaults to the host name. A ``req.http.via`` header is generated -also before entering ``vcl_recv``. If a client request or backend response -already had a Via header, it is now appended to instead of overwritten. - -A ``resp.http.via`` header is no longer overwritten by varnish, but -rather appended to. - -The ``server.identity`` variable is guaranteed to be a single token as -defined in the HTTP grammar, to safely be used as either a host name or -pseudonym in Via headers. - -The ``now`` variable remains constant in a VCL subroutine. This was already -the case, but is now (pun intended) formally defined behavior. It keeps the -same value even if the execution blocks for a significant time, for example -while calling a VMOD function. - -Bundled VMODs -============= - -For a real time timestamp, the function ``std.now()`` can be used instead. -There is also a new ``std.timed_call()`` to measure the execution time of a -subroutine. - -Cookie headers generated by vmod_cookie no longer have a spurious trailing -semi-colon (``';'``) at the end of the string. - -varnishlog -========== - -The ``Begin`` log records may contain a 4th field with the sub-level of -sub-tasks. The ``Begin[4]`` field is used by the ``-E`` option (or lack -thereof) in log utilities to include sub-tasks or not. Internally, only ESI -tasks are subject to this filtering, but it can apply to tasks spawned by -VMODs too. - -Similarly, the ``Link`` record has the same optional 4th field. - -.. XXX: any reason against ``varnish{hist,top} -k``? - -The ``-k`` option from ``varnishlog`` is now available in ``varnishncsa``. - -varnishstat -=========== - -The unused counter ``MAIN.fetch_no_thread`` was repurposed and renamed to -``MAIN.bgfetch_no_thread`` to signal when background fetch tasks fail to -be scheduled because thread pools are saturated. - -To help estimate the rate of ``vsl_space`` consumption, the new counter -``MAIN.shm_bytes`` was added. It offers a finer-grained metric than the -existing ``MAIN.shm_cycles`` that depends on the ``vsl_space`` setting. - -A new contribution script called ``varnishstatdiff`` can be used to compare -the output of two ``varnishstat -1`` executions with a friendly diff format -for ``varnishstat``'s specific output. - -varnishtest -=========== - -New macros ``${pkg_version}`` and ``${pkg_branch}`` expanding respectively -to ``7.2.0`` and ``7.2`` for the current release. - -It is possible to match the text on screen against a regular expression -with the new ``process -match`` command. - -The new ``filewrite [-a]`` command can put or append text into a file. - -A Varnish instance name in a VTC is used by default as the server identity -for predictable Via headers. - -For example:: - - varnish v1 -vcl+backend { ... } - -The expected Via header is:: - - Via: 1.1 v1 (Varnish/7.2) - -The instance name can still be set to a different value using the ``-arg`` -command to change the ``varnishd -i`` option. - -Changes for developers and VMOD authors -======================================= - -The ``varnishtest -i`` option only works from a Varnish source tree, in -which case the new macro ``${topsrc}`` is available in addition to the -old ``${topbuild}`` macro. - -The functions ``VRT_AddVDP()``, ``VRT_AddVFP()``, ``VRT_RemoveVDP()`` and -``VRT_RemoveVFP()`` are deprecated. - -The ``VCS_String()`` function can take the string ``"B"`` for the package -branch. - -The ``vnum.h`` functions are exposed to VMOD and VEXT authors. - -The termination rules for ``WRK_BgThread()`` were relaxed to allow VMODs to -use it. - -*eof* diff --git a/doc/sphinx/whats-new/changes-7.3.rst b/doc/sphinx/whats-new/changes-7.3.rst deleted file mode 100644 index 2e84a228fd..0000000000 --- a/doc/sphinx/whats-new/changes-7.3.rst +++ /dev/null @@ -1,178 +0,0 @@ -.. _whatsnew_changes_7.3: - -%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 7.3 -%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_7.3`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -varnishd -======== - -Parameters -~~~~~~~~~~ - -There is a new parameter ``transit_buffer`` disabled by default to limit the -amount of storage used for uncacheable responses. This is useful in situations -where slow clients may consume large but uncacheable objects, to prevent them -from filling up storage too fast at the expense of cacheable resources. When -transit buffer is enabled, a client request will effectively hold its backend -connection open until the client response delivery completes. - -ESI processing changes ----------------------- - -Response status codes other than 200 and 204 are now considered errors for ESI -fragments. - -Previously, any ``ESI:include`` object would be included, no matter what -the status of it were, 200, 503, didn't matter. - -From now on, by default, only objects with 200 and 204 status will be -included and any other status code will fail the parent ESI request. - -If objects with other status should be delivered, they should have -their status changed to 200 in VCL, for instance in ``sub -vcl_backend_error{}``, ``vcl_synth{}`` or ``vcl_deliver{}``. - -If ``param.set feature +esi_include_onerror`` is used, and the -```` tag has a ``onerror="continue"`` attribute, any -and all ESI:include objects will be delivered, no matter what their -status might be, and not even a partial delivery of them will fail the -parent ESI request. To be used with great caution. - - -Other changes in varnishd -~~~~~~~~~~~~~~~~~~~~~~~~~ - -In addition to classic Unix-domain sockets, Varnish now supports -abstract sockets. If the operating system supports them, as does any -fairly recent Linux kernel, abstract sockets can be specified using -the commonplace ``@`` notation for accept sockets, e.g.:: - - varnishd -a @kandinsky - -Weak ``Last-Modified`` headers whose timestamp lies within one second -of the corresponding ``Date`` header are no longer candidates for -revalidation. This means that a subsequent fetch will not, when a -stale object is available, include an ``If-Modified-Since`` header. A -weak ``Last-Modified`` header does not prevent ``Etag`` revalidation. - -A cache hit on an object being streamed no longer prevents delivery of partial -responses (status code 206) to range requests. - -Changes to VCL -============== - -VCL variables -~~~~~~~~~~~~~ - -The variables ``req.xid``, ``bereq.xid`` and ``sess.xid`` are now integers -instead of strings, but should remain usable without a VCL change in a string -context. - -Transit buffer can be controlled per fetch with the ``beresp.transit_buffer`` -variable. - -Other changes to VCL -~~~~~~~~~~~~~~~~~~~~ - -Backends have a new ``.via`` attribute optionally referencing another backend:: - - backend detour { - .host = "..."; - } - - backend destination { - .host = "..."; - .via = detour; - } - -Attempting a connection for ``destination`` connects to ``detour`` with a -PROXYv2 protocol header targeting ``destination``'s address. Optionally, the -``destination`` backend could use the other new ``.authority`` attribute to -define an authority TLV in the PROXYv2 header. - -Backends can connect to abstract sockets on linux:: - - backend miro { - .path = "@miro"; - } - -This is the same syntax as the ``varnishd -a`` command line option. - -Probes have a new ``.expect_close`` attribute defaulting to ``true``, matching -the current behavior. Setting it to ``false`` will defer final checks until -after the probe times out. - -varnishlog -========== - -The in-memory and on-disk format of VSL records changed to allow 64bit -VXID numbers. The new binary format is **not compatible** with -previous versions, and log dumps performed with a previous Varnish -release are no longer readable from now on. Consequently, unused log -tags have been removed. - -The VXID range is limited to ``VRT_INTEGER`` to fit in VCL the variables -``req.xid``, ``bereq.xid`` and ``sess.xid``. - -A ``ReqStart`` record is emitted for bad requests, allowing ``varnishncsa`` to -find the client IP address. - -varnishadm -========== - -The ``debug.xid`` command generally used by ``varnishtest`` now sets -up the next VXID directly. - -varnishtest -=========== - -It is now possible to send special keys NPAGE, PPAGE, HOME and END to a -process. - -The ``-nolen`` option is implied for ``txreq`` and ``txresp`` when either -``Content-Length`` or ``Transfer-Encoding`` headers are present. - -A new ``stream.peer_window`` variable similar to ``stream.window`` is -available for HTTP/2 checks. - -Changes for developers and VMOD authors -======================================= - -There is a new convenience macro ``WS_TASK_ALLOC_OBJ()`` to allocate objects -from the current tasks' workspace. - -The ``NO_VXID`` macro can be used to explicitly log records outside of a -transaction. - -Custom backend implementations are now in charge of printing headers, which -avoids duplicates when a custom implementation relied on ``http_*()`` that -would also log the headers being set up. - -The ``VRT_new_backend*()`` functions take an additional backend argument, the -optional via backend. It cannot be a custom backend implementation, but it -can be a director resolving a native backend. - -There is a new ``authority`` field for via backends in ``struct vrt_backend``. - -There is a new ``exp_close`` field in ``struct vrt_backend_probe``. - -Directors which take and hold references to other directors via -``VRT_Assign_Backend()`` (typically any director which has other -directors as backends) are now expected to implement the new -``.release`` callback of type ``void -vdi_release_f(VCL_BACKEND)``. This function is called by -``VRT_DelDirector()``. The implementation is expected drop any backend -references which the director holds (again using -``VRT_Assign_Backend()`` with ``NULL`` as the second argument). - -*eof* diff --git a/doc/sphinx/whats-new/changes-7.4.rst b/doc/sphinx/whats-new/changes-7.4.rst deleted file mode 100644 index 0a7407ce57..0000000000 --- a/doc/sphinx/whats-new/changes-7.4.rst +++ /dev/null @@ -1,129 +0,0 @@ -.. _whatsnew_changes_7.4: - -%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 7.4 -%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_7.4`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -varnishd -======== - -HTTP/2 header field validation is now more strict with respect to -allowed characters. - -The :ref:`vcl-step(7)` manual page has been added to document the VCL -state machines. - -VCL Tracing -~~~~~~~~~~~ - -VCL tracing now needs to be explicitly activated by setting the -``req.trace`` or ``bereq.trace`` VCL variables, which are initialized -from the ``feature +trace`` flag. Only if the trace variables are set -will ``VCL_trace`` log records be generated. - -Consequently, ``VCL_trace`` has been removed from the default -``vsl_mask``, so any trace records will be emitted by -default. ``vsl_mask`` can still be used to filter ``VCL_trace`` -records. - -To trace ``vcl_init {}`` and ``vcl_fini {}``, set the ``feature -+trace`` flag while the vcl is loaded/discarded. - -Parameters -~~~~~~~~~~ - -The ``startup_timeout`` parameter now specifically replaces -``cli_timeout`` for the initial startup only. - -Changes to VCL -============== - -The ``Content-Length`` and ``Transfer-Encoding`` headers are now -protected. For the common use case of ``unset -(be)req.http.Content-Length`` to dismiss a body, ``unset -(be)req.body`` should be used. - -varnishlog -========== - -Object creation failures by the selected storage engine are now logged -under the ``Error`` tag as ``Failed to create object from %s -%s``. - -varnishadm -========== - -Tabulation of the ``vcl.list`` CLI output has been modified slightly. - -varnishstat -=========== - -The counter ``MAIN.http1_iovs_flush`` has been added to track the -number of premature ``writev()`` calls due to an insufficient number -of IO vectors. This number is configured through the ``http1_iovs`` -parameter for client connections and implicitly defined by the amount -of free workspace for backend connections. - -varnishtest -=========== - -The basename of the test directory is now available as the ``vtcid`` -macro to serve as a unique string across concurrently running tests. - -The ``varnishd_args_prepend`` and ``varnishd_args_append`` macros have -been added to allow addition of arguments to ``varnishd`` invocations -before and after those added by ``varnishtest`` by default. - -``User-Agent`` request and ``Server`` response headers are now created -by default, containing the respective client and server name. The -``txreq -nouseragent`` and ``txresp -noserver`` options disable -addition of these headers. - -Changes for developers and VMOD authors -======================================= - -Call sites of VMOD functions and methods can now be restricted to -built-in subroutines using the ``$Restrict`` stanza in the VCC file. - -``.vcc`` files of VMODs are now installed to -``/usr/share/varnish/vcc`` (or equivalent) to enable re-use by other -tools like code editors. - -API Changes -~~~~~~~~~~~ - -The ``varnishapi`` version has been increased to 3.1 and the -``VSHA256_*``, ``VENC_Encode_Base64()`` and ``VENC_Decode_Base64()`` -functions are now exposed. - -In ``struct vsmwseg`` and ``struct vsm_fantom``, the ``class`` member -has been renamed to ``category``. - -The ``VSB_quote_pfx()`` (and, consequently, ``VSB_quote()``) function -no longer produces ``\v`` for a vertical tab. This improves -compatibility with JSON. - -Additions to varnish C header files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The ``PTOK()`` macro has been added to ``vas.h`` to simplify error -checking of ``pthread_*`` POSIX functions. - -The ``v_cold`` macro has been added to add ``__attribute__((cold))`` -on compilers supporting it. It is used for ``VRT_fail()`` to mark -failure code paths as cold. - -The utility macros ``ALLOC_OBJ_EXTRA()`` and ``ALLOC_FLEX_OBJ()`` have -been added to ``miniobj.h`` to simplify allocation of objects larger -than a struct and such with a flexible array. - -*eof* diff --git a/doc/sphinx/whats-new/changes-7.5.rst b/doc/sphinx/whats-new/changes-7.5.rst deleted file mode 100644 index b58772c255..0000000000 --- a/doc/sphinx/whats-new/changes-7.5.rst +++ /dev/null @@ -1,325 +0,0 @@ -.. _whatsnew_changes_7.5: - -%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 7.5 -%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_7.5`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -Security -======== - -CVE-2023-44487 -~~~~~~~~~~~~~~ - -Also known as the HTTP/2 Rapid Reset Attack, or `VSV 13`_, this vulnerability -is addressed with two mitigations introducing several changes since the 7.4.0 -release of Varnish Cache. The first one detects and stops Rapid Reset attacks -and the second one interrupts the processing of HTTP/2 requests that are no -longer open (stream reset, client disconnected etc). - -.. _VSV 13: https://varnish-cache.org/security/VSV00013.html - -CVE-2024-30156 -~~~~~~~~~~~~~~ - -Another denial of service attack vector received a CVE number in the aftermath -of the Rapid Reset debacle. `VSV 14`_ is called the HTTP/2 Broke Window attack -and can be summarized as the ability for clients to hold a server still by not -crediting the control flow window of HTTP/2 streams. - -.. _VSV 14: https://varnish-cache.org/security/VSV00014.html - -varnishd -======== - -Parameters -~~~~~~~~~~ - -The default value of ``cli_limit`` has been increased from 48KB to -64KB to avoid truncating the ``param.show -j`` output for common use -cases. - -A new ``pipe_task_deadline`` specifies the maximum duration of a pipe -transaction. The default value is the special value "never" to align with the -former lack of such timeout:: - - # both equivalent for now - param.set pipe_task_deadline never - param.reset pipe_task_deadline - -All the timeout parameters that can be disabled accept the "never" value: - -- ``between_bytes_timeout`` -- ``cli_timeout`` -- ``connect_timeout`` -- ``first_byte_timeout`` -- ``idle_send_timeout`` -- ``pipe_task_deadline`` -- ``pipe_timeout`` -- ``send_timeout`` -- ``startup_timeout`` - -The :ref:`vinyld(1)` manual advertises the ``timeout`` flag for these -parameters. - -The following parameters address the HTTP/2 Rapid Reset attach: - -- ``h2_rapid_reset`` (duration below which a reset is considered rapid) -- ``h2_rapid_reset_limit`` (maximum number of rapid resets per period) -- ``h2_rapid_reset_period`` (the sliding period to track rapid resets) - -The new ``h2_window_timeout`` parameter defines how long an HTTP/2 stream can -stall its delivery waiting for a control flow window update. A stream without -any credits is considered broke, and if all streams are broke when the new -timeout triggers the entire connection is considered bankrupt. - -A new bit flag ``vcl_req_reset`` for the ``feature`` parameter interrupts -client request tasks during VCL transitions when an HTTP/2 stream is no longer -open. The result is equivalent to a ``return (fail);`` statement and can save -significant server resources. It can also break setups expecting requests to -always be fully processed, even when they are not delivered. - -Bits parameters -~~~~~~~~~~~~~~~ - -In Varnish 7.1.0 the ``param.set`` command grew a new ``-j`` option that -displays the same output as ``param.show -j`` for the parameter that is -successfully updated. - -The goal was to atomically change a value and communicate how a subsequent -``param.show`` would render it. This could be used for consistency checks, -to ensure that a parameter was not changed by a different party. Collecting -how the parameter is displayed can be important for example for floating-point -numbers parameters that could be displayed with different resolutions, or -parameters that can take units and have multiple representations. - -Here is a concrete example:: - - $ varnishadm param.set -j workspace_client 16384 | jq '.[3].value' - 16384 - $ varnishadm param.set -j workspace_client 128k | jq '.[3].value' - 131072 - -However, this could not work with bits parameters:: - - $ varnishadm param.set -j feature +http2 | jq -r '.[3].value' - +http2,+validate_headers - -If the ``feature`` parameter is changed, reusing the output of ``param.set`` -cannot guarantee the restoration that exact value:: - - # third party intervention - $ varnishadm param.set feature +no_coredump | jq -r '.[3].value' - - # attempt at restoring the captured value - $ varnishadm param.set -j feature +http2,+validate_headers | jq -r '.[3].value' - +http2,+no_coredump,+validate_headers - -To fill this gap, bits parameters are now displayed as absolute values, -relative to none of the bits being set. A list of bits can start with the -special value ``none`` to clear all the bits, followed by specific bits to -raise:: - - # atomically update and capture feature flags - $ varnishadm param.set -j feature +http2 | jq -r '.[3].value' - none,+http2,+validate_headers - - # very insistent systems administrator - $ varnishadm param.set feature +no_coredump - - # successful attempt at restoring the captured value - $ varnishadm param.set -j feature none,+http2,+validate_headers | jq -r '.[3].value' - none,+http2,+validate_headers - -The output of ``param.show`` and ``param.set`` is now idempotent for bits -parameters, and can be used by a consistency check system to restore a -parameter to its desired value. - -Almost all bits parameters are displayed as bits set relative to a ``none`` -value. The notable exception is ``vsl_mask`` that is expressed with bits -cleared. For this purpose the ``vsl_mask`` parameter is now displayed as -bits cleared relative to an ``all`` value:: - - - $ varnishadm param.set -j vsl_mask all,-Debug | jq -r '.[3].value' - all,-Debug - -The special value ``default`` for bits parameters was deprecated in -favor of the generic ``param.reset`` command. It might be removed in a -future release. - -Other changes in varnishd -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The CLI script specified with the ``-I`` option must end with a new line -character or ``varnishd`` will fail to start. Previously, an incomplete last -line would be ignored. - -Changes to VCL -============== - -VCL variables -~~~~~~~~~~~~~ - -A new ``bereq.task_deadline`` variable is available in ``vcl_pipe`` to -override the ``pipe_task_deadline`` parameter. - -All the timeouts that can be overridden in VCL can be unset as well: - -- ``bereq.between_bytes_timeout`` -- ``bereq.connect_timeout`` -- ``bereq.first_byte_timeout`` -- ``bereq.task_deadline`` -- ``sess.idle_send_timeout`` -- ``sess.send_timeout`` -- ``sess.timeout_idle`` -- ``sess.timeout_linger`` - -They are unset by default, and if they are read unset, the parameter value is -returned. If the timeout parameter was disabled with the "never" value, it is -capped in VCL to the maximum decimal number (999999999999.999). It is not -possible to disable a timeout in VCL. - -ESI -~~~ - -In the 7.3.0 release a new error condition was added to ESI fragments. A -fragment is considered valid only for the response status code 200 and 204. - -However, when introduced it also changed the default behavior of the feature -flag ``esi_include_onerror`` in an inconsistent way. - -The behavior is reverted to the traditional Varnish handling of ESI, and the -effect of the feature flag is clarified: - -- by default, fragments are always included, even errors -- the feature flag ``esi_include_onerror`` enable processing of the - ``onerror`` attribute of the ```` tag -- ``onerror="continue"`` allows a parent request to resume its delivery after - a sub-request failed -- when streaming is disabled for the sub-request, the ESI fragment is omitted - as mandated by the ESI specification - -See :ref:`users-guide-esi` for more information. - -Other changes to VCL -~~~~~~~~~~~~~~~~~~~~ - -The new ``+fold`` flag for ACLs merges adjacent subnets together and optimize -out subnets for which there exist another all-encompassing subnet. - -VMODs -===== - -A new :ref:`vmod_h2(3)` can override the ``h2_rapid_reset*`` parameters on a -per-session basis. - -varnishlog -========== - -The ``SessClose`` record may contain the ``RAPID_RESET`` reason. This can be -used to monitor attacks successfully mitigated or detect false positives. - -When the ``feature`` flag ``vcl_req_reset`` is raised, an interrupted client -logs a ``Reset`` timestamps, and the response status code 408 is logged. - -When a ``BackendClose`` record includes a reason field, it now shows the -reason tag (for example ``RX_TIMEOUT``) instead of its description (Receive -timeout) to align with ``SessClose`` records. See :ref:`vsl(7)`. - -The ``ExpKill`` tag can be used to troubleshoot a cache policy. It is masked -by default because it is very verbose and requires a good understanding of -Varnish internals in the expiry vicinity. - -A new field with the number of hits is present in the ``EXP_Expired`` entry of -an object. Objects removed before they expired are now logged a new entry -``EXP_Removed``, removing a blind spot. Likewise, purged objects are no longer -logged as expired, but removed instead. The ``EXP_expire`` entry formerly -undocumented was renamed to ``EXP_Inspect`` for clarity and consistency. A new -``VBF_Superseded`` entry explains which object is evicting another one. - -varnishncsa -=========== - -A new custom format ``%{Varnish:default_format}x`` expands to the output -format when nothing is specified. This allows enhancing the default format -without having to repeat it:: - - varnishncsa -F ``%{Varnish:default_format}x %{Varnish:handling}x`` - -varnishstat -=========== - -A new ``MAIN.sc_rapid_reset`` counter counts the number of HTTP/2 connections -closed because the number of rapid resets exceed the limit over the configured -period. - -Likewise, ``MAIN.sc_bankrupt`` counts the number of HTTP/2 connections closed -because all streams ran out of credits and ``h2_window_timeout`` triggered. - -Their ``MAIN.req_reset`` counterpart counts the number of time a client task -was prematurely failed because the HTTP/2 stream it was processing was no -longer open and the feature flag ``vcl_req_reset`` was raised. - -A new counter ``MAIN.n_superseded`` adds visibility on how many objects are -inserted as the replacement of another object in the cache. This can give -insights regarding the nature of churn in a cache. - -varnishtest -=========== - -When an HTTP/2 stream number does not matter and the stream is handled in a -single block, the automatic ``next`` identifier can be used:: - - server s1 { - stream next { - rxreq - txresp - } -run - } -start - -It is now possible to include other VTC fragments:: - - include common-server.vtc common-varnish.vtc - -An include command takes at least one file name and expands it in place of the -include command itself. There are no guards against recursive includes. - -Changes for developers and VMOD authors -======================================= - -The ``VSB_tofile()`` function can work with VSBs larger than ``INT_MAX`` and -tolerate partial writes. - -The semantics for ``vtim_dur`` changed so that ``INFINITY`` is interpreted as -never timing out. A zero duration that was used in certain scenarios as never -timing out is now interpreted as non-blocking or when that is not possible, -rounded up to one millisecond. A negative value in this context is considered -an expired deadline as if zero was passed, giving a last chance for operations -to succeed before timing out. - -To support this use case, new functions convert ``vtim_dur`` to other values: - -- ``VTIM_poll_tmo()`` computes a timeout for ``poll(2)`` -- ``VTIM_timeval_sock()`` creates a ``struct timeval`` for ``setsockopt(2)`` - -The value ``NAN`` is used to represent unset timeouts in VCL with one notable -exception. The ``struct vrt_backend`` duration fields cannot be initialized to -``NAN`` and zero was the unset value, falling back to parameters. Zero will -disable a timeout in a backend definition (which can be overridden by VCL -variables) and a negative value will mean unset. - -This is an API breakage of ``struct vrt_backend`` and its consumers. - -Likewise, VMODs creating their own lock classes with ``Lck_CreateClass()`` -must stop using zero an indefinite ``Lck_CondWaitTimeout()``. - -*eof* diff --git a/doc/sphinx/whats-new/changes-7.6.rst b/doc/sphinx/whats-new/changes-7.6.rst deleted file mode 100644 index 54b44ac8c1..0000000000 --- a/doc/sphinx/whats-new/changes-7.6.rst +++ /dev/null @@ -1,170 +0,0 @@ -.. _whatsnew_changes_7.6: - -%%%%%%%%%%%%%%%%%%%%%% -Changes in Varnish 7.6 -%%%%%%%%%%%%%%%%%%%%%% - -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_7.6`. - -A more detailed and technical account of changes in Varnish, with -links to issues that have been fixed and pull requests that have been -merged, may be found in the `change log`_. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -Changes applying to most varnish-cache programs -=============================================== - -The environment variable ``VINYL_DEFAULT_N`` now provides the default "varnish -name" / "workdir" as otherwise specified by he ``-n`` argument to ``varnishd`` -and ``varnish*`` utilities except ``varnishtest``. - -Programs attaching to ``varnishd``'s shared memory are now performing more -precise status checks of the ``varnishd`` process. They should in particular -better detect restarts of the process. This comes with signal-based liveness -checks that can be disabled when ``VSM_NOPID`` is exported to the environment -of utilities like ``varnishlog``, ``varnishstat`` or ``varnishncsa``. - -varnishd -======== - -A new ``linux`` jail has been added (configured via the ``-j`` argument) which is -now the default on Linux. For now, it is almost identical to the ``unix`` jail -with one :ref:`whatsnew_upgrading_7.6_linux_jail` added. - -The port of a *listen_endpoint* given with the ``-a`` argument to ``varnishd`` -can now also be a numerical port range like ``80-89``, besides the existing -options of port number (e.g. ``80``) and service name (e.g. ``http``). With a -port range, Varnish will accept connections on all ports within the range. - -.. _whatsnew_changes_7.6_connq: - -Backend connection queuing -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -A feature has been added to instruct backend tasks to queue if the backend has -reached its ``max_connections``. This allows tasks to wait for a connection to -become available rather than immediately fail. This feature must be enabled -through new global parameters or individual backend properties: - -* ``backend_wait_timeout`` sets the amount of time a task will wait. -* ``backend_wait_limit`` sets the maximum number of tasks that can wait. - -These parameters can also be set for individual backends using the -``wait_timeout`` and ``wait_limit`` properties. - -Tasks waiting on a backend going sick (either explicitly via the -``backend.set_health`` command or implicitly through the probe) fail -immediately. - -Global VSC counters have been added under ``MAIN``: - -* ``backend_wait`` counts tasks which waited in queue for a connection. -* ``backend_wait_fail`` counts tasks which waited in queue but failed because - ``wait_timeout`` was reached or the backend went sick. - -Parameters -~~~~~~~~~~ - -The ``backend_wait_timeout`` and ``backend_wait_limit`` parameters have been -added, see :ref:`whatsnew_changes_7.6_connq` above for details. - -The size of the buffer to hold panic messages is now tunable through the new -``panic_buffer`` parameter. - -Changes to VCL -============== - -The ``wait_timeout`` and ``wait_limit`` backend properties have been added, see -:ref:`whatsnew_changes_7.6_connq` above for details. - -For backends using the ``.via`` attribute to connect through a *proxy*, the -``connect_timeout``, ``first_byte_timeout`` and ``between_bytes_timeout`` -attributes are now inherited from *proxy* unless explicitly given. - -varnishlog -========== - -Additional ``SessError`` VSL events are now generated for various HTTP/2 -protocol errors. Some HTTP/2 log events have been changed from ``Debug`` and -``Error`` to ``SessError``. - -varnishstat -=========== - -VSC counters for waiters have been added: - -* ``conns`` to count waits on idle connections -* ``remclose`` to count idle connections closed by the peer -* ``timeout`` to count idle connections which timed out in the waiter -* ``action`` to count idle connections which resulted in a read - -These can be found under ``WAITER..``. - -The ``MAIN.backend_wait`` and ``MAIN.backend_wait_fail`` counters have been -added, see :ref:`whatsnew_changes_7.6_connq` above for details. - -varnishtest -=========== - -``varnishtest`` now supports the ``shutdown`` command corresponding to the -``shutdown(2)`` standard C library call. - -Changes for developers and VMOD authors -======================================= - -.. _whatsnew_changes_7.6_VDP: - -VDP filter API changes -~~~~~~~~~~~~~~~~~~~~~~ - -The Varnish Delivery Processor (VDP) filter API has been generalized to also -accommodate future use for backend request bodies: - -``VDP_Init()`` gained a ``struct busyobj *`` argument for use of VDPs on the -backend side, which is mutually exclusive with the existing ``struct req *`` -argument (one of the two needs to be ``NULL``). ``VDP_Init()`` also gained an -``intmax_t *`` pointer, which needs to point to the known content length of the -body data or ``-1`` for "unknown length". Filters can change this value. - -``struct vdp_ctx`` lost the ``req`` member, but gained ``struct objcore *oc``, -``struct http *hp`` and ``intmax_t *clen`` members. The rationale here is that a -VDP should be concerned mainly with transforming body data (for which ``clen`` -is relevant) and optionally changing (from the ``vdp_init_f``) the headers sent -before the body data, for which ``hp`` is intended. Some VDPs also work directly -on a ``struct objcore *``, so ``oc`` is provided to the first VDP in the chain -only. - -Generic VDPs should specifically not access the request or be concerned with the -object. - -Yet special purpose VDPs still can take from ``VRT_CTX`` whatever references -they need in the ``vdp_init_f`` and store them in their private data. - -Consequent to what as been explained above, ``vdp_init_f`` lost its ``struct -objcore *`` argument. - -VDPs with no ``vdp_bytes_f`` function are now supported if the ``vdp_init_f`` -returns a value greater than zero to signify that the filter is not to be added -to the chain. This is useful to support VDPs which only need to work on headers. - -.. _whatsnew_changes_7.6_Obj: - -Object API changes -~~~~~~~~~~~~~~~~~~ - -The ``ObjWaitExtend()`` Object API function gained a ``statep`` argument to -optionally return the busy object state consistent with the current extension. -A ``NULL`` value may be passed if the caller does not require it. - -Other changes relevant for developers -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -``VSS_resolver_range()`` as been added to ``libvarnish`` to implement resolution -of port ranges. - -The implementation of the ``transit_buffer`` has now been made the -responsibility of storage engines. - -*eof* diff --git a/doc/sphinx/whats-new/index.rst b/doc/sphinx/whats-new/index.rst index 1cdf674028..955a0cbdf4 100644 --- a/doc/sphinx/whats-new/index.rst +++ b/doc/sphinx/whats-new/index.rst @@ -31,123 +31,6 @@ Varnish 7.7 changes-7.7 upgrading-7.7 -Varnish 7.6 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-7.6 - upgrading-7.6 - -Varnish 7.5 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-7.5 - upgrading-7.5 - -Varnish 7.4 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-7.4 - upgrading-7.4 - -Varnish 7.3 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-7.3 - upgrading-7.3 - -Varnish 7.2 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-7.2 - upgrading-7.2 - -Varnish 7.1 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-7.1 - upgrading-7.1 - -Varnish 7.0 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-7.0 - upgrading-7.0 - -Varnish 6.6 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-6.6 - upgrading-6.6 - -Varnish 6.5 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-6.5 - upgrading-6.5 - -Varnish 6.4 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-6.4 - upgrading-6.4 - -Varnish 6.3 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-6.3 - upgrading-6.3 - -Varnish 6.2 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-6.2 - upgrading-6.2 - -Varnish 6.1 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-6.1 - upgrading-6.1 - Varnish 6.0 ----------- @@ -156,48 +39,3 @@ Varnish 6.0 changes-6.0 upgrading-6.0 - -Varnish 5.2 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-5.2 - upgrading-5.2 - -Varnish 5.1 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-5.1 - upgrading-5.1 - -Varnish 5.0 ------------ - -.. toctree:: - :maxdepth: 2 - - relnote-5.0 - changes-5.0 - upgrading-5.0 - -Varnish 4.1 ------------ - -.. toctree:: - :maxdepth: 2 - - changes-4.1 - upgrading-4.1 - -Varnish 4.0 ------------ - -.. toctree:: - :maxdepth: 2 - - upgrading-4.0 diff --git a/doc/sphinx/whats-new/relnote-5.0.rst b/doc/sphinx/whats-new/relnote-5.0.rst deleted file mode 100644 index 766ee2de91..0000000000 --- a/doc/sphinx/whats-new/relnote-5.0.rst +++ /dev/null @@ -1,165 +0,0 @@ -.. - Copyright (c) 2016-2017 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_relnote_5.0: - -Varnish 5.0 Release Note -======================== - -This is the first Varnish release after the Varnish Project moved out -of Varnish Software's basement, so to speak, and it shows. - -But it is also our 10 year anniversary release, `Varnish 1.0 was -released`_ on September 20th 2006. - -That also means that we have been doing this for 10 years -without any bad security holes. - -So yeah... 5.0 is not entirely what we had hoped it would be, but we -are as proud as one can possibly be anyway. - -To keep this release note short(er), we have put the purely technical -stuff in two separate documents: - -* :ref:`whatsnew_changes_5.0` - -* :ref:`whatsnew_upgrading_5.0` - -How to get Varnish 5.0 ----------------------- - -`Source download `_ - -Packages for mainstream operating systems should appear in as -soon as they trickle through the machinery. - - -Reasons to upgrade to Varnish 5.0 ---------------------------------- - -The separate VCL/VCL labels feature can probably help you untangle -your VCL code if it has become too complex. Upgrading from 4.1 -to get that feature should be a no-brainer. - -The HTTP/2 code is not mature enough for production, and if you -want to start to play with H2, you should not upgrade to 5.0, -but rather track -trunk from github and help us find all the bugs -before the next release. - -The Shard director is new in the tree, but it has a lot of live -hours out of tree. Upgrading from 4.1 to 5.0 to get that should -also be a no-brainer. - -We have also fixed at lot of minor bugs, and improved many details -here and there, See :ref:`whatsnew_upgrading_5.0` for more of this. - - -Reasons not to upgrade to Varnish 5.0 -------------------------------------- - -None that we know of at this time. - -Only in very special cases should you need to modify your VCL. - - -Next release ------------- - -Next release is scheduled for March 15th 2017, and will most -likely be Varnish 5.1. - - -The obligatory thank-you speech -------------------------------- - -This release of Varnish Cache is brought to you by the generous -support and donations of money and manpower from four companies: - -* Fastly - -* Varnish Software - -* UPLEX - -* The company which prefers to simply be known as "ADJS" - -Without them, this release, and for that matter all the previous -ones, would not have happened. - -Even though they are all employees of those very -same companies, these developers merit personal praise: - -* Martin - HTTP/2 HPACK header compression code, stevedore API, VSL - -* Nils & Geoff - Shard backend director, ban-lurker improvements - -* Guillame - HTTP/2 support for varnishtest - -* Dridi - Backend temperatures etc. - -* Federico - Too many fixes and ideas to count - -* Lasse - Our tireless release-manager - -* Devon - Performance insights and critical review. - -* The rest of the V-S crew - Too many things to list. - - -We need more money ------------------- - -Until now Varnish Software has done a lot of work for the Varnish -Cache project, but for totally valid reasons, they are scaling that -back and the project either needs to pick up the slack or drop some -of those activities. - -It is important that people understand that Free and Open Source -Software isn't the same as gratis software: Somebody has to pay -the developers mortgages and student loans. - -A very large part of the Varnish development is funded through the -`Varnish Moral License`_, which enables Poul-Henning Kamp to have -Varnish as his primary job, but right now he is underfunded to the -tune of EUR 2000-3000 per month. - -Please consider if your company makes enough money using Varnish -Cache, to spare some money, or employee-hours for its future -maintenance and development. - - -We also need more manpower --------------------------- - -First and foremost, we could really use a Postmaster to look after -our mailman mailing lists, including the increasingly arcane art -of anti-spam techniques and invocations. - -We also need to work more on our documentation, it is in bad need -of one or more writers which can actually write text rather than -code. - -We could also use more qualified content for our new project homepage, -so a webmaster is on our shopping list as well. - -Finally, we can always use C-developers, we have more ideas than -we have coders, and since we have very high standards for quality -things take time to write. - -The best way to get involved is to just jump in and do stuff that -needs done. - -Here is the `Varnish Cache github page `_. - -And here is the `Varnish Projects homepage on github `_. - -Welcome on board! - -*phk* - - -.. _Varnish Moral License: http://phk.freebsd.dk/VML - -.. _Varnish 1.0 was released: https://sourceforge.net/p/varnish/news/2006/09/varnish-10-released/ diff --git a/doc/sphinx/whats-new/upgrading-4.0.rst b/doc/sphinx/whats-new/upgrading-4.0.rst deleted file mode 100644 index f5173d140a..0000000000 --- a/doc/sphinx/whats-new/upgrading-4.0.rst +++ /dev/null @@ -1,253 +0,0 @@ -.. - Copyright (c) 2016 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_4_0: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 4.0 -%%%%%%%%%%%%%%%%%%%%%%%% - -Changes to VCL -============== - -The backend fetch parts of VCL have changed in Varnish 4. We've tried to -compile a list of changes needed to upgrade here. - -Version statement -~~~~~~~~~~~~~~~~~ - -To make sure that people have upgraded their VCL to the current -version, Varnish now requires the first line of VCL to indicate the -VCL version number:: - - vcl 4.0; - -req.request is now req.method -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To align better with RFC naming, `req.request` has been renamed to -`req.method`. - -vcl_fetch is now vcl_backend_response -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Directors have been moved to the vmod_directors -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To make directors (backend selection logic) easier to extend, the -directors are now defined in loadable VMODs. - -Setting a backend for future fetches in `vcl_recv` is now done as follows:: - - sub vcl_init { - new cluster1 = directors.round_robin(); - cluster1.add_backend(b1, 1.0); - cluster1.add_backend(b2, 1.0); - } - - sub vcl_recv { - set req.backend_hint = cluster1.backend(); - } - -Note the extra `.backend()` needed after the director name. - -Use the hash director as a client director -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Since the client director was already a special case of the hash director, it -has been removed, and you should use the hash director directly:: - - sub vcl_init { - new h = directors.hash(); - h.add_backend(b1, 1); - h.add_backend(b2, 1); - } - - sub vcl_recv { - set req.backend_hint = h.backend(client.identity); - } - -vcl_error is now vcl_backend_error -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To make a distinction between internally generated errors and -VCL synthetic responses, `vcl_backend_error` will be called when -varnish encounters an error when trying to fetch an object. - -error() is now synth() -~~~~~~~~~~~~~~~~~~~~~~ - -And you must explicitly return it:: - - return (synth(999, "Response")); - -Synthetic responses in vcl_synth -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Setting headers on synthetic response bodies made in vcl_synth are now done on -resp.http instead of obj.http. - -The synthetic keyword is now a function:: - - if (resp.status == 799) { - set resp.status = 200; - set resp.http.Content-Type = "text/plain; charset=utf-8"; - synthetic("You are " + client.ip); - return (deliver); - } - -obj in vcl_error replaced by beresp in vcl_backend_error -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To better represent the context in which it is called, you -should now use `beresp.*` vcl_backend_error, where you used to -use `obj.*` in `vcl_error`. - -hit_for_pass objects are created using beresp.uncacheable -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Example:: - - sub vcl_backend_response { - if (beresp.http.X-No-Cache) { - set beresp.uncacheable = true; - set beresp.ttl = 120s; - return (deliver); - } - } - -req.* not available in vcl_backend_response -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -req.* used to be available in `vcl_fetch`, but after the split of -functionality, you only have 'bereq.*' in `vcl_backend_response`. - -vcl_* reserved -~~~~~~~~~~~~~~ - -Any custom-made subs cannot be named 'vcl_*' anymore. This namespace -is reserved for builtin subs. - -req.backend.healthy replaced by std.healthy(req.backend_hint) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Remember to import the std module if you're not doing so already. - -client.port, and server.port replaced by respectively std.port(client.ip) and std.port(server.ip) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -`client.ip` and `server.ip` are now proper data types, which renders -as an IP address by default. You need to use the `std.port()` -function to get the port number. - -Invalidation with purge -~~~~~~~~~~~~~~~~~~~~~~~ - -Cache invalidation with purges is now done via `return(purge)` from `vcl_recv`. -The `purge;` keyword has been retired. - -obj is now read-only -~~~~~~~~~~~~~~~~~~~~ - -`obj` is now read-only. `obj.last_use` has been retired. - -Some return values have been replaced -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Apart from the new `synth` return value described above, the -following has changed: - - - `vcl_recv` must now return `hash` instead of `lookup` - - `vcl_hash` must now return `lookup` instead of `hash` - - `vcl_pass` must now return `fetch` instead of `pass` - - -Backend restarts are now retry -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In 3.0 it was possible to do `return(restart)` after noticing that -the backend response was wrong, to change to a different backend. - -This is now called `return(retry)`, and jumps back up to `vcl_backend_fetch`. - -This only influences the backend fetch thread, client-side handling is not affected. - - -default/builtin VCL changes -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The VCL code that is appended to user-configured VCL automatically -is now called the builtin VCL. (previously default.vcl) - -The builtin VCL now honors Cache-Control: no-cache (and friends) -to indicate uncacheable content from the backend. - - -The `remove` keyword is gone -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Replaced by `unset`. - - -X-Forwarded-For is now set before vcl_recv -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In many cases, people unintentionally removed X-Forwarded-For when -implementing their own vcl_recv. Therefore it has been moved to before -vcl_recv, so if you don't want an IP added to it, you should remove it -in vcl_recv. - - -Changes to existing parameters -============================== - -session_linger -~~~~~~~~~~~~~~ -`session_linger` has been renamed to `timeout_linger` and it is in -seconds now (previously was milliseconds). - -sess_timeout -~~~~~~~~~~~~ -`sess_timeout` has been renamed to `timeout_idle`. - -sess_workspace -~~~~~~~~~~~~~~ - -In 3.0 it was often necessary to increase `sess_workspace` if a -lot of VMODs, complex header operations or ESI were in use. - -This is no longer necessary, because ESI scratch space happens -elsewhere in 4.0. - -If you are using a lot of VMODs, you may need to increase -either `workspace_backend` and `workspace_client` based on where -your VMOD is doing its work. - -thread_pool_purge_delay -~~~~~~~~~~~~~~~~~~~~~~~ -`thread_pool_purge_delay` has been renamed to `thread_pool_destroy_delay` -and it is in seconds now (previously was milliseconds). - -thread_pool_add_delay and thread_pool_fail_delay -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -They are in seconds now (previously were milliseconds). - -New parameters since 3.0 -======================== - -vcc_allow_inline_c -~~~~~~~~~~~~~~~~~~ - -You can now completely disable inline C in your VCL, and it is -disabled by default. - -Other changes -============= - -New log filtering -~~~~~~~~~~~~~~~~~ - -The logging framework has a new filtering language, which means that -the -m switch has been replaced with a new -q switch. See -:ref:`vsl-query(7)` for more information about the new query language. diff --git a/doc/sphinx/whats-new/upgrading-4.1.rst b/doc/sphinx/whats-new/upgrading-4.1.rst deleted file mode 100644 index 66b4d5a035..0000000000 --- a/doc/sphinx/whats-new/upgrading-4.1.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. - Copyright (c) 2016 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_4_1: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 4.1 -%%%%%%%%%%%%%%%%%%%%%%%% - -Changes to VCL -============== - -Data type conversion functions now take a fallback -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Data type conversion functions in the std vmod now takes an additional -argument *fallback*, which is returned if the conversion does not succeed. - - -Version statement is kept -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The VCL syntax has not chanced significantly, and as such the Varnish 4.0 -version marker is kept for Varnish 4.1. - -One of the initial lines in a Varnish 4.1 VCL should read:: - - vcl 4.0; - -Remote address accessors -~~~~~~~~~~~~~~~~~~~~~~~~ - -New in 4.1 is the `local.ip` and `remote.ip` representing the (local) TCP -connection endpoints. - -With PROXY listeners the `server.ip` and `client.ip` are set from the PROXY -preamble. On normal HTTP listeners the behaviour is unchanged. - - -Management interface -==================== - -The management interface enabled with ``-M`` previously supported the telnet -protocol. - -Support for telnet control sequences have been retired. Replacement clients -like netcat or (preferred) ``varnishadm`` should be used instead. - - -Runtime users and groups -======================== - -With the new jail support, an additional runtime user (`vcache`) should be used -for the Varnish worker child process. - -Additionally, the ``varnishlog``, ``varnishncsa`` and other Varnish shared log -utilities must now be run in a context with `varnish` group membership. - - -Changes to parameters -===================== - -`vcl_cooldown` is new, and decides how long time a VCL is kept warm after being -replaced as the active VCL. - -The following parameters have been retired: - -* `group` (security revamp) -* `group_cc` (security revamp) -* `listen_address` (security revamp) -* `pool_vbc` -* `timeout_req` - merged with `timeout_idle`. -* `user` (security revamp) - -Minor changes of default values on `workspace_session` and `vsl_mask`. diff --git a/doc/sphinx/whats-new/upgrading-5.0.rst b/doc/sphinx/whats-new/upgrading-5.0.rst deleted file mode 100644 index 800fa1ebee..0000000000 --- a/doc/sphinx/whats-new/upgrading-5.0.rst +++ /dev/null @@ -1,122 +0,0 @@ -.. - Copyright (c) 2016 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_5.0: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 5.0 -%%%%%%%%%%%%%%%%%%%%%%%% - -Changes to VCL -============== - -* All VCL Objects should now be defined before used - - * in particular, this is now required for ACLs. The error message - for ACLs being used before being defined is confusing - see PR #2021:: - - Name is a reserved name - -* VCL names are restricted to alphanumeric characters, dashes (-) and - underscores (_). In addition, the first character should be alphabetic. - That is, the name should match "[A-Za-z][A-Za-z0-9\_-]*". - -* Like strings, backends and integers can now be used as boolean - expressions in if statements. See ``vcl(7)`` for details. - -* Add support to perform matches in assignments, obtaining a boolean - as result:: - - set req.http.foo = req.http.bar ~ "bar"; - -* Returned values from functions and methods' calls can be thrown away. - -backends -~~~~~~~~ - -* Added support for the PROXY protocol via ``.proxy_header`` attribute. - Possible values are 1 and 2, corresponding to the PROXY protocol - version 1 and 2, respectively. - -vcl_recv -~~~~~~~~ - -* Added ``return (vcl(label))`` to switch to the VCL labelled `label`. -* The ``rollback`` function has been retired. - -vcl_hit -~~~~~~~ - -* Replace ``return (fetch)`` with ``return (miss)``. - -vcl_backend_* -~~~~~~~~~~~~~ - -* Added read access to ``remote.ip``, ``client.ip``, ``local.ip`` and - ``server.ip``. - -vcl_backend_fetch -~~~~~~~~~~~~~~~~~ - -* Added write access to ``bereq.body``, the request body. Only ``unset`` - is supported at this time. - -* We now send request bodies by default (see - :ref:`whatsnew_changes_5.0_reqbody`). To keep the previous behaviour - add the following code before any ``return (..)`` statement in this - subroutine:: - - if (bereq.method == "GET") { - unset bereq.body; - } - - -vcl_backend_error -~~~~~~~~~~~~~~~~~ - -* Added write access to ``beresp.body``, the response body. This may - replace ``synthetic()`` in future releases. - -vcl_deliver -~~~~~~~~~~~ - -* Added read access to ``obj.ttl``, ``obj.age``, ``obj.grace`` and - ``obj.keep``. - -vcl_synth -~~~~~~~~~ - -* Added write access to ``resp.body``, the response body. This may replace - ``synthetic()`` in future releases. - -Management interface -==================== - -* To disable CLI authentication use ``-S none``. - -* ``n_waitinglist`` statistic removed. - -Changes to parameters -===================== - -* Added ``ban_lurker_holdoff``. - -* Removed ``session_max``. This parameter actually had no effect since - 4.0 but might come back in a future release. - -* ``vcl_path`` is now a colon-separated list of directories, replacing - ``vcl_dir``. - -* ``vmod_path`` is now a colon-separated list of directories, replacing - ``vmod_dir``. - -Other changes -============= - -* ``vinylstat(1)`` -f option accepts a ``glob(7)`` pattern. - -* Cache-Control and Expires headers for uncacheable requests (i.e. passes) - will not be parsed. As a result, the RFC variant of the TTL VSL tag - is no longer logged. diff --git a/doc/sphinx/whats-new/upgrading-5.1.rst b/doc/sphinx/whats-new/upgrading-5.1.rst deleted file mode 100644 index 1594ee2788..0000000000 --- a/doc/sphinx/whats-new/upgrading-5.1.rst +++ /dev/null @@ -1,320 +0,0 @@ -.. - Copyright (c) 2017-2019 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_5.1: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 5.1 -%%%%%%%%%%%%%%%%%%%%%%%% - -varnishd command-line options -============================= - -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 :ref:`vinyld(1)`, but here's a summary: - -* Added ``-I clifile`` to run CLI commands at startup, before the - worker process starts. See :ref:`whatsnew_clifile`. - -* More than one ``-f`` option is now permitted, to pre-load VCL - instances at startup. The last of these becomes the "boot" instance - that is is active at startup. - -* Either ``-b`` or one or more ``-f`` options must be specified, but - not both, and they cannot both be left out, unless ``-d`` is used to - start `varnishd` in debugging mode. If the empty string is specified - as the sole ``-f`` option, then `varnishd` starts without starting - the worker process, and the management process will accept CLI - commands. - -* Added ``-?`` to print the usage message, which is only printed for - this option. - -* Added the ``-x`` option to print certain kinds of documentation and - exit. When ``-x`` is used, it must be the only option. - -* Only one of ``-F`` or ``-d`` may be used, and neither of these can - be used with ``-C``. - -* Added the ``workuser`` parameter to the ``-j`` option. - -varnishd parameters -=================== - -* The size of the shared memory log is now limited to 4G-1b - (4294967295 bytes). This places upper bounds on the ``-l`` - command-line option and on the ``vsl_space`` and ``vsm_space`` - parameters. - -* Added ``clock_step``, ``thread_pool_reserve`` and ``ban_cutoff`` (see - :ref:`ref_param_clock_step`, :ref:`ref_param_thread_pool_reserve`, - :ref:`ref_param_ban_cutoff`). - -* ``thread_pool_stack`` is no longer considered experimental, and is - more extensively documented, see :ref:`ref_param_thread_pool_stack`. - -* ``thread_queue_limit`` only applies to queued client requests, see - :ref:`ref_param_thread_queue_limit`. - -* ``vcl_dir`` and ``vmod_dir`` are deprecated and will be removed from - a future release, use ``vcl_path`` and ``vmod_path`` instead (see - :ref:`ref_param_vcl_path`, :ref:`ref_param_vmod_path`). - -* All parameters are defined on every platform, including those that - that are not functional on every platform. Most of these involve - features of the TCP stack, such as ``tcp_keepalive_intvl``, - ``tcp_keepalive_probes``, ``accept_filter`` and ``tcp_fastopen``. - The unavailability of a parameter is documented in the output of the - ``param.show`` command. Setting such a parameter is not an error, - but has no effect. - - -Changes to VCL -============== - -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. - -Type conversions -~~~~~~~~~~~~~~~~ - -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: - -* If both operands of ``+`` or ``-`` are one of BYTES, DURATION, INT - or REAL, then the result has the same data type, with the obvious - numeric interpretation. If such an expression is evaluated in a - context that expects a STRING (for example for assignment to a - header), then the arithmetic is done first, and the result it - converted to a STRING. - -* INTs and REALs can be added or subtracted to yield a REAL. - -* A DURATION can be added to or subtracted from a TIME to yield a - TIME. - -* No other combinations of operand types are legal with ``-``. - -* When a ``+`` expression is evaluated in a STRING context, then for - all other combinations of operand data types, the operands are - converted to STRINGs and concatenated. - -* If a STRING is not expected for the ``+`` expression, then no other - combination of data types is legal. - -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 -~~~~~~~~~~~~~~ - -Response codes 1000 or greater may now be set in VCL internally. -``resp.status`` is delivered modulo 1000 in client responses. - -IP address comparison -~~~~~~~~~~~~~~~~~~~~~ - -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 STEVEDORE type and storage objects -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -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 :ref:`guide-storage`, and -the notes about ``beresp.storage`` and ``req.storage`` below. - -All VCL subroutines (except ``vcl_fini``) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -* Added ``return(fail)`` to immediately terminate VCL processing. In - all cases but ``vcl_synth``, control is directed to ``vcl_synth`` - with ``resp.status`` and ``resp.reason`` set to 503 and "VCL - failed", respectively. ``vcl_synth`` is aborted on ``return(fail)``. - ``vcl_fini`` is executed when a VCL instance in unloaded (enters the - COLD state) and has no failure condition. - -* VCL failure is invoked on any attempt to set one of the fields in the - the first line of a request or response to the empty string, such - as ``req.url``, ``req.proto``, ``resp.reason`` and so forth. - -Client-side VCL subroutines -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -* ``req.ttl`` is deprecated, see :ref:`vcl(7)`. - -vcl_recv -~~~~~~~~ - -* Added ``req.storage``, which tells Varnish which storage backend to - use if you choose to save the request body (see - :ref:`std.cache_req_body()`). - -* ``return(vcl(LABEL))`` may not be called after a restart. It can - only be called from the active VCL instance. - -vcl_backend_response -~~~~~~~~~~~~~~~~~~~~ - -* Added ``return(pass(DURATION))`` to set an object to hit-for-pass, - see :ref:`whatsnew_changes_5.1_hitpass`. - -* The object ``beresp.storage`` of type STEVEDORE should now be used - to set a storage backend; ``beresp.storage_hint`` is deprecated and - will be removed in a future release. Setting ``beresp.storage_hint`` - to a valid storage will set ``beresp.storage`` as well. If the - storage is invalid, ``beresp.storage`` is left untouched. - -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 -:ref:`ref_param_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. - -vmod_std -~~~~~~~~ - -* Added :ref:`std.getenv()`. - -* Added :ref:`std.late_100_continue()`. - -Other changes -============= - -* The storage backend type umem, long in disuse, has been retired. - -* ``vinylstat(1)``: - - * Added the ``cache_hitmiss`` stat to count hits on hit-for-miss - objects. - - * The ``cache_hitpass`` stat now only counts hits on hit-for-pass - objects. - - * ``fetch_failed`` is incremented for any kind of fetch failure -- - when there is a failure after ``return(deliver)`` from - ``vcl_backend_response``, or when control is diverted to - ``vcl_backend_error``. - - * Added the ``n_test_gunzip`` stat, which is incremented when - Varnish verifies a compressed response from a backend -- this - operation was previously counted together with ``n_gunzip``. - - * Added the ``bans_lurker_obj_killed_cutoff`` stat to count the - number of objects killed by the ban lurker to keep the number of - bans below ``ban_cutoff``. - -* ``vinyllog(1)``: - - * Hits on hit-for-miss and hit-for-pass objects are logged with - the ``HitMiss`` and ``HitPass`` tags, respectively. In each case, - the log payload is the VXID of the previous transaction in which - the object was saved in the cache (as with ``Hit``). - - * An entry with the ``TTL`` tag and the prefix ``HFP`` is logged to - record the duration set for hit-for-pass objects. - - * Added ``vxid`` as a lefthand side token for VSL queries, allowing - for queries that search for transaction IDs in the log. See - :ref:`vsl-query(7)`. - -* ``vinylncsa(1)``: - - * Clarified the meaning of the ``%r`` formatter, see NOTES in - :ref:`vinylncsa(1)`. - - * Clarified the meaning of the ``%{X}i`` and ``%{X}o`` formatters - when the header X appears more than once (the last occurrence is - is used). - -* ``vinyltest(1)``: - - * Added the ``setenv`` and ``write_body`` commands, see :ref:`vtc(7)`. - - * ``-reason`` replaces ``-msg`` to set the reason string for a - response (default "OK"). - - * Added ``-cliexpect`` to match expected CLI responses to regular - expressions. - - * Added the ``-match`` operator for the ``shell`` command. - - * Added the ``-hdrlen`` operator to generate a header with a - given name and length. - - * The ``err_shell`` command is deprecated, use ``shell -err - -expect`` instead. - - * The ``${bad_backend}`` macro can now be used for a backend that - is always down, which does not require a port definition (as does - ``${bad_ip}`` in a backend definition). - - * ``varnishtest`` can be stopped with the ``TERM``, ``INT`` of ``KILL`` - signals, but not with ``HUP``. These signals kill the process group, - so that processes started by running tests are stopped. - -* Added the ``vtest.sh`` tool to automate test builds, see - :ref:`whatsnew_changes_5.1_vtest`. diff --git a/doc/sphinx/whats-new/upgrading-5.2.rst b/doc/sphinx/whats-new/upgrading-5.2.rst deleted file mode 100644 index 5943005502..0000000000 --- a/doc/sphinx/whats-new/upgrading-5.2.rst +++ /dev/null @@ -1,264 +0,0 @@ -.. - Copyright (c) 2017-2019 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_5.2: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 5.2 -%%%%%%%%%%%%%%%%%%%%%%%% - -Varnish statistics and logging -============================== - -There are extensive changes under the hood with respect to statistics -counters, but these should all be transparent at the user-level. - -varnishd parameters -=================== - -The ``vsm_space`` and ``cli_buffer`` parameters are now deprecated and -ignored. They will be removed in a future major release. - -The updated shared memory implementation manages space automatically, so -it no longer needs ``vsm_space``. Memory for the CLI command buffer is now -dynamically allocated. - -We have updated the documentation for :ref:`ref_param_send_timeout`, -:ref:`ref_param_idle_send_timeout`, :ref:`ref_param_timeout_idle` and -:ref:`ref_param_ban_cutoff`. - -Added the debug bit ``vmod_so_keep``, see :ref:`ref_param_debug` and -the notes about changes for developers below. - -Changes to VCL -============== - -We have added a few new variables and clarified some matters. VCL -written for Varnish 5.1 should run without changes on 5.2. - -Consistent symbol names -~~~~~~~~~~~~~~~~~~~~~~~ - -VCL symbols originate from various parts of Varnish: there are built-in -variables, subroutines, functions, and the free-form headers. Symbols -may live in a namespace denoted by the ``'.'`` (dot) character as in -``req.http.Cache-Control``. When you create a VCL label, a new symbol -becomes available, named after the label. Storage backends always have -a name, even if you don't specify one, and they can also be accessed in -VCL: for example ``storage.Transient``. - -Because headers and VCL names could contain dashes, while subroutines or -VMOD objects couldn't, this created an inconsistency. All symbols follow -the same rules now and must follow the same (case-insensitive) pattern: -``[a-z][a-z0-9_-]*``. - -You can now write code like:: - - sub my-sub { - new my-obj = my_vmod.my_constuctor(storage.my-store); - } - - sub vcl_init { - call my-sub; - } - -As you may notice in the example above, it is not possible yet to have -dashes in a vmod symbol. - -Long storage backend names used to be truncated due to a limitation in -the VSC subsystem, this is no longer the case. - -VCL variables -~~~~~~~~~~~~~ - -``req.hash`` and ``bereq.hash`` -------------------------------- - -Added ``req.hash`` and ``bereq.hash``, which contain the hash value -computed by Varnish for cache lookup in the current transaction, to -be used in client or backend context, respectively. Their data type -is BLOB, and they contain the raw binary hash. - -You can use :ref:`vmod_blob(3)` to work with the hashes:: - - import blob; - - sub vcl_backend_fetch { - # Send the transaction hash to the backend as a hex string - set bereq.http.Hash = blob.encode(HEX, blob=bereq.hash); - } - - sub vcl_deliver { - # Send the hash in a response header as a base64 string - set resp.http.Hash = blob.encode(BASE64, blob=req.hash); - } - -``server.identity`` -------------------- - -If the ``-i`` option is not set in the invocation of ``varnishd``, -then ``server.identity`` is set to the host name (as returned by -``gethostname(3)``). Previously, ``server.identity`` defaulted to the -value of the ``-n`` option (or the default instance name if ``-n`` was -not set). See :ref:`vinyld(1)`. - -``bereq.is_bgfetch`` --------------------- - -Added ``bereq.is_bgfetch``, which is readable in backend contexts, and -is true if the fetch takes place in the background. That is, it is -true if Varnish found a response in the cache whose TTL was expired, -but was still in grace time. Varnish returns the stale cached response -to the client, and initiates the background fetch to refresh the cache -object. - -``req.backend_hint`` --------------------- - -We have clarified what happens to ``req.backend_hint`` on a client -restart -- it gets reset to the default backend. So you might want to -make sure that the backend hint gets set the way you want in that -situation. - -vmod_std -~~~~~~~~ - -Added :ref:`std.file_exists()`. - -New VMODs in the standard distribution -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -See :ref:`vmod_blob(3)`, :ref:`vmod_purge(3)` and -:ref:`vmod_vtc(3)`. Read about them in :ref:`whatsnew_new_vmods`. - -Bans -~~~~ - -We have clarified the interpretation of a ban when a comparison in the -ban expression is attempted against an unset field, see -:ref:`vcl(7)_ban` in :ref:`vcl(7)`. - -Other changes -============= - -* ``vinyld(1)``: - - * The total size of the shared memory space for logs and counters - no longer needs to be configured explicitly and therefore the - second subargument to ``-l`` is now ignored. - - * The default value of ``server.identity`` when the ``-i`` option is - not set has been changed as noted above. - - * Also, ``-i`` no longer determines the ``ident`` field used by - ``syslog(3)``; now Varnish is always identified by the string - ``varnishd`` in the syslog. - - * On a system that supports ``setproctitle(3)``, the Varnish - management process will appear in the output of ``ps(1)`` as - ``Varnish-Mgt``, and the child process as ``Varnish-Child``. If - the ``-i`` option has been set, then these strings in the ps - output are followed by ``-i`` and the identity string set by the - option. - - * The ``-f`` option for a VCL source file now honors the - ``vcl_path`` parameter if a relative file name is used, see - :ref:`vinyld(1)` and :ref:`ref_param_vcl_path`. - - * The ``-a`` option can now take a name, for example ``-a - admin=127.0.0.1:88`` to identify an address used for - administrative requests but not regular client traffic. Otherwise, - a default name is selected for the listen address (``a0``, ``a1`` - and so forth). Endpoint names appear in the log output, as noted - below, and may become accessible in VCL in the future. - -* ``vinylstat(1)``: - - * In curses mode, the top two lines showing uptimes for the - management and child processes show the text ``Not Running`` if - one or both of the processes are down. - - * The interpretation of multiple ``-f`` options in the command line - has changed slightly, see :ref:`vinylstat(1)`. - - * The ``type`` and ``ident`` fields have been removed from the XML - and JSON output formats, see :ref:`vinylstat(1)`. - - * The ``MAIN.s_req`` statistic has been removed, as it was identical - to ``MAIN.client_req``. - - * Added the counter ``req_dropped``. Similar to ``sess_dropped``, - this is the number of times an HTTP/2 stream was refused because - the internal queue is full. See :ref:`varnish-counters(7)` and - :ref:`ref_param_thread_queue_limit`. - -* ``vinyllog(1)``: - - * The ``Hit``, ``HitMiss`` and ``HitPass`` log records grew an - additional field with the remaining TTL of the object at the time - of the lookup. While this should greatly help troubleshooting, - it might break tools relying on those records to get the VXID of - the object hit during lookup. - - Instead of using ``Hit``, such tools should now use ``Hit[1]``, - and the same applies to ``HitMiss`` and ``HitPass``. - - The ``Hit`` record also grew two more fields for the grace and - keep periods. This should again be useful for troubleshooting. - - See :ref:`vsl(7)`. - - * The ``SessOpen`` log record displays the name of the listen address - instead of the endpoint in its 3rd field. - - See :ref:`vsl(7)`. - - * The output format of ``VCL_trace`` log records, which appear if - you have switched on the ``VCL_trace`` flag in the VSL mask, has - changed to include the VCL configuration name. See :ref:`vsl(7)` - and :ref:`ref_param_vsl_mask`. - -* ``vinyltest(1)`` and ``vtc(7)``: - - * When varnishtest is invoked with ``-L`` or ``-l``, Varnish - instances started by a test do not clean up their copies of VMOD - shared objects when they stop. See the note about ``vmod_so_keep`` - below. - - * Added the feature switch ``ignore_unknown_macro`` for test cases, - see :ref:`vtc(7)`. - -* ``vinylncsa(1)`` - - * Field specifiers (such as the 1 in ``Hit[1]``) are now limited to - to 255, see :ref:`vinylncsa(1)`. - -* The ``-N`` command-line option, which was previously available for - ``vinyllog(1)``, ``vinylstat(1)``, ``vinylncsa(1)`` and - ``vinylhist(1)``, is not compatible with the changed internal - logging API, and has been retired. - -* Changes for developers: - - * The VSM and VSC APIs for shared memory and statistics have - changed, and may necessitate changes in client applications, see - :ref:`whatsnew_vsm_vsc_5.2`. - - * Added the ``$ABI`` directive for VMOD vcc declarations, see - :ref:`whatsnew_abi`. - - * There have been some minor changes in the VRT API, which may be - used for VMODs and client apps, see :ref:`whatsnew_vrt_5.2`. - - * The VUT API (for Varnish UTilities), which facilitates the - development of client apps, is now publicly available, see - :ref:`whatsnew_vut_5.2`. - - * The debug bit ``vmod_so_keep`` instructs Varnish not to clean - up its copies of VMOD shared objects when it stops. This makes - it possible for VMOD authors to load their code into a debugger - after a varnishd crash. See :ref:`ref_param_debug`. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-6.0.rst b/doc/sphinx/whats-new/upgrading-6.0.rst index 7c03945935..9d81a1f147 100644 --- a/doc/sphinx/whats-new/upgrading-6.0.rst +++ b/doc/sphinx/whats-new/upgrading-6.0.rst @@ -16,7 +16,7 @@ Unix domain sockets as listen addresses The ``varnishd -a`` command-line argument now has this form, where the ``address`` may be a Unix domain socket, identified as such when it -begins with ``/`` (see varnishd :ref:`ref-varnishd-options`):: +begins with ``/`` (see varnishd :ref:`ref-vinyld-options`):: -a [name=][address][:port][,PROTO][,user=][,group=][,mode=] @@ -90,7 +90,7 @@ backend. The path of a socket file may also be specified in the ``varnishd -b`` command-line option (see varnishd -:ref:`ref-varnishd-options`):: +:ref:`ref-vinyld-options`):: $ varnishd -b /path/to/backend.sock @@ -161,7 +161,7 @@ request was received. ``local.socket`` is the name provided in the ``-a`` command-line argument for the current listener, which defaults to ``a0``, ``a1`` -and so on (see varnishd :ref:`ref-varnishd-options`). +and so on (see varnishd :ref:`ref-vinyld-options`). ``local.endpoint`` is the value of the ``address[:port]`` or ``path`` field provided as the ``-a`` value for the current listener, exactly diff --git a/doc/sphinx/whats-new/upgrading-6.1.rst b/doc/sphinx/whats-new/upgrading-6.1.rst deleted file mode 100644 index f607968535..0000000000 --- a/doc/sphinx/whats-new/upgrading-6.1.rst +++ /dev/null @@ -1,398 +0,0 @@ -.. - Copyright (c) 2018-2019 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_6.1: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 6.1 -%%%%%%%%%%%%%%%%%%%%%%%% - -A configuration for Varnish 6.0.x will run for version 6.1 without -changes. There has been a subtle change in the interpretation of the -VCL variable ``beresp.keep`` under specific circumstances, as -discussed below. Other than that, the changes in 6.1 are new features, -described in the following. - -varnishd parameters -=================== - -We have added the :ref:`ref_param_max_vcl` parameter to set a -threshold for the number of loaded VCL programs, since it is a common -error to let previous VCL instances accumulate without discarding -them. The remnants of undiscarded VCLs take the form of files in the -working directory of the management process. Over time, too many of -these may take up significant storage space, and administrative -operations such as ``vcl.list`` may become noticeably slow, or even -time out, when Varnish has to iterate over many files. - -The default threshold in :ref:`ref_param_max_vcl` is 100, and VCL -labels are not counted against the total. The -:ref:`ref_param_max_vcl_handling` parameter controls what happens when -you reach the limit. By default you just get a warning from the VCL -compiler, but you can set it to refuse to load more VCLs, or to ignore -the threshold. - -Added the :ref:`ref_param_backend_local_error_holddown` and -:ref:`ref_param_backend_remote_error_holddown` parameters. These define -delays for new attempts to connect to backends when certain classes of -errors have been encountered, for which immediate re-connect attempts -are likely to be counter-productive. See the parameter documentation -for details. - -Changes to VCL -============== - -VCL variables -~~~~~~~~~~~~~ - -``req.ttl``, ``req.grace`` and keep ------------------------------------ - -``req.grace`` had been previously removed, but was now reintroduced, -since there are use cases that cannot be solved without it. Similarly, -``req.ttl`` used to be deprecated and is now fully supported again. - -``req.ttl`` and ``req.grace`` limit the ttl and grace times that are -permitted for the current request. If ``req.ttl`` is set, then cache -objects are considered fresh (and may be cache hits) only if their -remaining ttl is less than or equal to ``req.ttl``. Likewise, -``req.grace`` sets an upper bound on the time an object has spent in -grace to be considered eligible for grace mode (which is to deliver -this object and fetch a fresh copy in the background). - -A common application is to set shorter TTLs when the backend is known -to be healthy, so that responses are fresher when all is well. But if -the backend is unhealthy, then use cached responses with longer TTLs -to relieve load on the troubled backend:: - - sub vcl_recv { - # ... - if (std.healthy(req.backend_hint)) { - # Get responses no older than 70s for healthy backends - set req.ttl = 60s; - set req.grace = 10s; - } - - # If the backend is unhealthy, then permit cached responses - # that are older than 70s. - } - -The evaluation of the ``beresp.keep`` timer has changed a -bit. ``keep`` sets a lifetime in the cache in addition to TTL for -objects that can be validated by a 304 "Not Modified" response from -the backend to a conditional request (with ``If-None-Match`` or -``If-Modified-Since``). If an expired object is also out of grace -time, then ``vcl_hit`` will no longer be called, so it is impossible -to deliver the "keep" object in this case. - -Note that the headers ``If-None-Match`` and ``If-Modified-Since``, -together with the 304 behavior, are handled automatically by Varnish. -If you, for some reason, need to explicitly disable this for a backend -request, then you need do this by removing the headers in -``vcl_backend_fetch``. - -The documentation in :ref:`users-guide-handling_misbehaving_servers` -has been expanded to discuss these matters in greater depth, look -there for more details. - -``beresp.filters`` and support for backend response processing with VMODs -------------------------------------------------------------------------- - -The ``beresp.filters`` variable is readable and writable in -``vcl_backend_response``. This is a space-separated list of modules -that we call VFPs, for "Varnish fetch processors", that may be applied -to a backend response body as it is being fetched. In default Varnish, -the list may include values such as ``gzip``, ``gunzip``, and ``esi``, -depending on how you have set the ``beresp.do_*`` variables. - -This addition makes it possible for VMODs to define VFPs to filter or -manipulate backend response bodies, which can be added by changing the -list in ``beresp.filters``. VFPs are applied in the order given in -``beresp.filters``, and you may have to ensure that a VFP is -positioned correctly in the list, for example if it can only apply to -uncompressed response bodies. - -This is a new capability, and at the time of release we only know of -test VFPs implemented in VMODs. Over time we hope that an "ecology" of -VFP code will develop that will enrich the features available to -Varnish deployments. - -``obj.hits`` ------------- - -Has been fixed to return the correct value in ``vcl_hit`` (it had been -0 in ``vcl_hit``). - -Other changes to VCL -~~~~~~~~~~~~~~~~~~~~ - -* The ``Host`` header in client requests is mandatory for HTTP/1.1, as - proscribed by the HTTP standard. If it is missing, then - ``builtin.vcl`` causes a synthetic 400 "Bad request" response to be - returned. - -* You can now provide a string argument to ``return(fail("Foo!"))``, - which can be used in ``vcl_init`` to emit an error message if the - VCL load fails due to the return. - -* Additional ``import`` statements of an already imported vmod are now - ignored. - -VMODs -===== - -Added the :ref:`std.fnmatch()` function to :ref:`vmod_std(3)`, which -you can use for shell-style wildcard matching. Wildcard patterns may -be a good fit for matching URLs, to match against a pattern like -``/foo/*/bar/*``. The patterns can be built at runtime, if you need to -do that, since they don't need the pre-compile step at VCL load time -that is required for regular expressions. And if you are simply more -comfortable with the wildcard syntax than with regular expressions, -you now have the option. - -:ref:`vmod_unix(3)` is now supported for SunOS and descendants. This -entails changing the privilege set of the child process while the VMOD -is loaded, see the documentation. - -Other changes -============= - -* ``vinyld(1)``: - - * Some VCL compile-time error messages have been improved, for - example when a symbol is not found or arguments to VMOD calls are - missing. - - * Varnish now won't rewrite the ``Content-Length`` header when - responding to any HEAD request, making it possible to cache - responses to HEAD requests independently from the GET responses - (previously a HEAD request had to be a pass to avoid this - rewriting). - - * If you have set ``.proxy_header=1`` (to use the PROXYv1 protocol) - for a backend addressed as a Unix domain socket (with a ``.path`` - setting for the socket file), and have also defined a probe for - the backend, then the address family ``UNKNOWN`` is sent in - the proxy header for the probe request. If you have set - ``.proxy_header=2`` (for PROXYv2) for a UDS backend with a probe, - then ``PROXY LOCAL`` is sent for the probe request. - -* ``vinyllog(1)`` and ``vsl(7)``: - - * The contents of ``FetchError`` log entries have been improved to - give better human-readable diagnostics for certain classes of - backend fetch failures. - - In particular, http connection (HTC) errors are now reported - symbolically in addition to the previous numerical value. - - * Log entries under the new ``SessError`` tag now give more - diagnostic information about session accept failures (failure to - accept a client connection). These must be viewed in raw grouping, - since accept failures are not part of any request/response - transaction. - - * When a backend is unhealthy, ``Backend_health`` now reports some - diagnostic information in addition to the HTTP response and timing - information. - - * The backend name logged for ``Backend_health`` is just the backend - name without the VCL prefix (as appears otherwise for backend - naming). - - * Added the log entry tag ``Filters``, which gives a list of the - filters applied to a response body (see ``beresp.filters`` - discussed above). - -* ``vinyladm(1)`` and ``varnish-cli(7)`` - - * For a number of CLI commands, you can now use the ``-j`` argument - to get a JSON response, which may help in automation. These include: - - * ``ping -j`` - - * ``backend.list -j`` - - * ``help -j`` - - A JSON response in the CLI always includes a timestamp (epoch time - in seconds with millisecond precision), indicating the time at - which the response was generated. - - * The ``backend.list`` command now lists both directors and - backends, with their health status. The command now has a ``-v`` - option for verbose output, in which detailed health states for - each backend/director are displayed. - -* ``vinylstat(1)`` and ``varnish-counters(7)``: - - * We have added a number of counters to the ``VBE.*`` group to help - better diagnose error conditions with backends: - - * ``VBE.*.unhealthy``: the number of fetches that were not - attempted because the backend was unhealthy - - * ``.busy``: number of fetches that were not attempted because the - ``.max_connections`` limit was reached - - * ``.fail``: number of failed attempts to open a connection to the - backend. Detailed reasons for the failures are given in the - ``.fail_*`` counters (shown at DIAG level), and in the log entry - ``FetchError``. ``.fail`` is the sum of the values in the - ``.fail_*`` counters. - - * ``.fail_eaccess``, ``.fail_eaddrnotavail``, - ``.fail_econnrefused``, ``.fail_enetunreach`` and - ``.fail_etimedout``: these are the number of attempted - connections to the backend that failed with the given value of - ``errno(3)``. - - * ``.fail_other``: number of connections to the backend that - failed for reasons other than those given by the other - ``.fail_*`` counters. For such cases, details on the failure - can be extracted from the varnish log as described above for - ``FetchError``. - - * ``.helddown``: the number of connections not attempted because - the backend was in the period set by one of the parameters - :ref:`ref_param_backend_local_error_holddown` or - :ref:`ref_param_backend_remote_error_holddown` - - * Similarly, we have added a series of counters for better diagnostics - of session accept failures (failure to accept a connection from a - client). As before, the ``sess_fail`` counter gives the total number - of accept failures, and it is now augmented with the ``sess_fail_*`` - counters. ``sess_fail`` is the sum of the values in ``sess_fail_*``. - - * ``sess_fail_econnaborted``, ``sess_fail_eintr``, - ``sess_fail_emfile``, ``sess_fail_ebadf`` and - ``sess_fail_enomem``: the number of accept failures with the - indicated value of ``errno(3)``. The :ref:`varnish-counters(7)` - man page, and the "long descriptions" shown by ``varnishstat``, - give possible reasons why each of these may happen, and what - might be done to counter the problem. - - * ``sess_fail_other``: number of accept failures for reasons - other than those given by the other ``sess_fail_*`` counters. - More details may appear in the ``SessError`` entry of the log - (:ref:`varnish-counters(7)` shows a ``varnishlog`` invocation - that may help). - - * In curses mode, the information in the header lines (uptimes and - cache hit rates) is always reported, even if you have defined a - filter that leaves them out of the stats table. - - * Ban statistics are now reported more accurately (they had been - subject to inconsistencies due to race conditions). - -* ``vinyltest(1)`` and ``vtc(7)``: - - * ``varnishtest`` and the ``vtc`` test script language now support - testing for haproxy as well as Varnish. The ``haproxy`` directive - in a test can be used to define, configure, start and stop a - haproxy instance, and you can also script messages to send on the - haproxy CLI connection, and define expectations for the - responses. See the ``haproxy`` section in :ref:`vtc(7)` for - details. - - * Related to haproxy support, you can now define a ``syslog`` - instance in test scripts. This defines a syslog server, and allows - you to test expectations for syslog output from a haproxy - instance. - - * Added the ``-keepalive`` argument for client and server scripts to - be used with the ``-repeat`` directive, which causes all test - iterations to run on the same connection, rather than open a new - connection each time. This makes the test run faster and use fewer - ephemeral ports. - - * Added the ``-need-bytes`` argument for the ``process`` command, - see :ref:`vtc(7)`. - -* ``vinylhist(1)``: - - * The ``-P min:max`` command-line parameters are now optional, - see :ref:`vinylhist(1)`. - -* For all of the utilities that access the Varnish log -- - ``vinyllog(1)``, ``vinylncsa(1)``, ``vinyltop(1)`` and - ``vinylhist(1)`` -- it was already possible to set multiple ``-I`` - and ``-X`` command-line arguments. It is now properly documented - that you can use multiple include and exclude filters that apply - regular expressions to selected log records. - -* Changes for developers: - - * As mentioned above, VMODs can now implement VFPs that can be added - to backend response processing by changing ``beresp.filters``. - The interface for VFPs is defined in ``cache_filters.h``, and the - debug VMOD included in the distribution shows an example of a - VFP for rot13. - - * The Varnish API soname version (for libvarnishapi.so) has been - bumped to 2.0.0. - - * The VRT version has been bumped to 8.0. See ``vrt.h`` for details - on the changes since 7.0. - - * Space required by varnish for maintaining the ``PRIV_TASK`` and - ``PRIV_TOP`` parameters is now taken from the appropriate - workspace rather than from the heap as before. For a failing - allocation, a VCL failure is triggered. - - The net effect of this change is that in cases of a workspace - shortage, the almost unavoidable failure will happen earlier. The - amount of workspace required is slightly increased and scales with - the number of vmods per ``PRIV_TASK`` and ``PRIV_TOP`` parameter. - - The VCL compiler (VCC) guarantees that if a vmod function is - called with a ``PRIV_*`` argument, that argument value is set. - - There is no change with respect to the API the ``PRIV_*`` vmod - function arguments provide. - - * ``VRT_priv_task()``, the function implementing the allocation of - the ``PRIV_TASK`` and ``PRIV_TOP`` parameters as described above, - is now more likely to return ``NULL`` for allocation failures for - the same reason. - - Notice that explicit use of this function from within VMODs is - considered experimental as this interface may change. - - * We have improved support for the ``STRANDS`` data type, which you - may find easier to use than the varargs-based ``STRING_LIST``. See - ``vrt.h`` for details. :ref:`vmod_blob(3)` has been refactored to - use ``STRANDS``, so you can look there for an example. - - * We have fixed a bug that had limited the precision available for - the ``INT`` data type, so you now get the full 64 bits. - - * Portions of what had previously been declared in - ``cache_director.h`` have been moved into ``vrt.h``, constituting - the public API for directors. The remainder in - ``cache_director.h`` is not public, and should not be used by a - VMOD intended for VRT ABI compatibility. - - * The director API in ``vrt.h`` differs from the previous - interface. :ref:`ref-writing-a-director` has been updated - accordingly. In short, the most important changes include: - - * ``struct director_methods`` is replaced by ``struct vdi_methods`` - * signatures of various callbacks have changed - * ``VRT_AddDirector()`` and ``VRT_DelDirector()`` are to be used - for initialization and destruction. - * ``vdi_methods`` callbacks are not to be called from vmods any more - * ``VRT_Healthy()`` replaces calls to the ``healthy`` function - * The admin health is not to be manipulated by vmods any more - * director private state destruction is recommended to be - implemented via a ``destroy`` callback. - - * Python 3 is now preferred in builds, and will likely be required - in future versions. - - * We believe builds are now reproducible, and intend to keep them - that way. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-6.2.rst b/doc/sphinx/whats-new/upgrading-6.2.rst deleted file mode 100644 index eb2b3cd1eb..0000000000 --- a/doc/sphinx/whats-new/upgrading-6.2.rst +++ /dev/null @@ -1,202 +0,0 @@ -.. - Copyright (c) 2019 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_2019_03: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 6.2 -%%%%%%%%%%%%%%%%%%%%%%%% - -.. _whatsnew_upgrading_vcl_2019_03: - -VCL -=== - -VCL programs for Varnish 6.1 can be expected to run without changes in -the new version. - -A VCL load will now issue a warning, but does not fail as previously, -if a backend declaration uses the ``.path`` field to specify a Unix -domain socket, but the socket file does not exist or is not accessible -at VCL load time. This makes it possible to start the peer component -listening at the socket, or set its permissions, after Varnish starts -or the VCL is loaded. Backend fetches fail if the socket is not -accessible by the time the fetch is attempted. - -``return(miss)`` from ``vcl_hit{}`` is now removed. An option for -implementing similar functionality is: - -* ``return (restart)`` from ``vcl_hit{}`` - -* in ``vcl_recv{}`` for the restart (when ``req.restarts`` has - increased), ``set req.hash_always_miss = true;``. - -.. _whatsnew_upgrading_params_2019_03: - -Runtime parameters -================== - -Some varnishd ``-p`` parameters that have been deprecated for some -time have been removed. If you haven't changed them yet, you have to -now. These are: - -* ``shm_reclen`` -- use :ref:`ref_param_vsl_reclen` instead - -* ``vcl_dir`` -- use :ref:`ref_param_vcl_path` instead - -* ``vmod_dir`` -- use :ref:`ref_param_vmod_path` instead - -The default value of :ref:`ref_param_thread_pool_stack` has been -increased from 48k to 56k on 64-bit platforms and to 52k on 32-bit -platforms. See the discussion under -:ref:`whatsnew_changes_params_2019_03` in -:ref:`whatsnew_changes_2019_03` for details. - -.. _whatsnew_upgrading_std_conversion_2019_03: - -Type conversion functions in VMOD std -===================================== - -The existing type-conversion functions in :ref:`vmod_std(3)` have been -reworked to make them more flexible and easier to use. These functions -now also accept suitable numeral or quantitative arguments. - -* :ref:`std.duration()` -* :ref:`std.bytes()` -* :ref:`std.integer()` -* :ref:`std.real()` -* :ref:`std.time()` - -These type-conversion functions should be fully backwards compatible, -but the following differences should be noted: - -* The *fallback* is not required anymore. A conversion failure in the - absence of a *fallback* argument will now trigger a VCL failure. - -* A VCL failure will also be triggered if no or more than one argument - (plus optional *fallback*) is given. - -* Conversion functions now only ever truncate if necessary (instead of - rounding). - -* :ref:`std.round()` has been added for explicit rounding. - -The following functions are deprecated and should be replaced by the -new conversion functions: - -* ``std.real2integer()`` -* ``std.real2time()`` -* ``std.time2integer()`` -* ``std.time2real()`` - -They will be removed in a future version of Varnish. - -varnishadm and the CLI -====================== - -The ``-j`` option for JSON output has been added to a number of -commands, see :ref:`whatsnew_changes_cli_json` in -:ref:`whatsnew_changes_2019_03` and :ref:`varnish-cli(7)`. We -recommend the use of JSON format for automated parsing of CLI -responses (:ref:`vinyladm(1)` output). - -.. _whatsnew_upgrading_backend_list_2019_03: - -Listing backends -~~~~~~~~~~~~~~~~ - -``backend.list`` has grown an additional column, the output has -changed and fields are now of dynamic width: - -* The ``Admin`` column now accurately states ``probe`` only if a - backend has some means of dynamically determining health state. - -* The ``Probe`` column has been changed to display ``X/Y``, where: - - * Integer ``X`` is the number of good probes in the most recent - window; or if the backend in question is a director, the number of - healthy backends accessed via the director or any other - director-specific metric. - - * Integer ``Y`` is the window in which the threshold for overall - health of the backend is defined (from the ``.window`` field of a - probe, see :ref:`vcl(7)`); or in the case of a director, the total - number of backends accessed via the director or any other - director-specific metric. - - If there is no probe or the director does not provide details, - ``0/0`` is output. - -* The ``Health`` column has been added to contain the dynamic (probe) - health state and the format has been unified to just ``healthy`` or - ``sick``. - - If there is no probe, ``Health`` is always given as - ``healthy``. Notice that the administrative health as shown in the - ``Admin`` column has precedence. - -In the ``probe_message`` field of ``backend.list -j`` output, the -``Probe`` and ``Health`` columns appear as the array ``[X, Y, -health]``. - -See :ref:`varnish-cli(7)` for details. - -.. _whatsnew_upgrading_vcl_list_2019_03: - -Listing VCLs -~~~~~~~~~~~~ - -The non-JSON output of ``vcl.list`` has been changed: - -* The ``state`` and ``temperature`` fields appear in separate columns - (previously combined in one column). - -* The optional column showing the relationships between labels and VCL - configurations (when labels are in use) has been separated into two - columns. - -See :ref:`varnish-cli(7)` for details. In the JSON output for -``vcl.list -j``, this information appears in separate fields. - -The width of columns in ``backend.list`` and ``vcl.list`` output -(non-JSON) is now dynamic, to fit the width of the terminal window. - -For developers and authors of VMODs and API clients -=================================================== - -Python 3.4 or later is now required to build Varnish, or use scripts -installed along with Varnish, such as ``vmodtool.py`` to build VMODs -or other Varnish artifacts. Python 2 is no longer supported, and this -support will likely be dropped in a future 6.0 LTS release too. - -The VRT API has been bumped to version 9.0. Changes include: - -* Functions in the API have been added, and others removed. - -* The ``VCL_BLOB`` type is now implemented as ``struct vrt_blob``. - -* The ``req_bodybytes`` field of ``struct req`` has been removed, and - should now be accessed as an object core attribute. - -See ``vrt.h``, the `change log`_ and -:ref:`whatsnew_changes_director_api_2019_03` in -:ref:`whatsnew_changes_2019_03` for details. - -.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst - -The vmodtool has been changed significantly to avoid name clashes in -the C identifiers declared in ``vcc_if.h``. This may necessitate -changing names in your VMOD code. To facilitate renaming, ``vcc_if.h`` -defines macros for prepending the vmod prefix, and for naming enums -and argument structs. For details, see the `change log`_, and examine -the contents of ``vcc_if.h`` after generation. - -Going forward, we will adhere to the principle that data returned by -VMOD methods and functions are immutable. This is now enforced in some -places by use of the ``const`` modifier. A VMOD is free to do as it -sees fit within its own implementation, but if you attempt to change -something returned by another VMOD, the results are undefined. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-6.3.rst b/doc/sphinx/whats-new/upgrading-6.3.rst deleted file mode 100644 index efe47007ea..0000000000 --- a/doc/sphinx/whats-new/upgrading-6.3.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. - Copyright (c) 2020 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_6.3: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 6.3 -%%%%%%%%%%%%%%%%%%%%%%%% - -For users of many and/or labeled VCLs -===================================== - -Users of the advanced mechanics behind the ``vcl.state`` CLI command -(most likely used via ``varnishadm``) should be aware of the following -changes, which may require adjustments to (or, more likely, allow for -simplifications of) scripts/programs interfacing with varnish: - -The VCL ``auto`` state has been streamlined. Conceptually, it used to -be a variant of the ``warm`` state which would automatically cool -the vcl. Yet, cooling did not only transition the temperature, but -also the state, so ``auto`` only worked one way - except that -``vcl.use`` or moving a label (by labeling another vcl) would also set -``auto``, so a manual warm/cold setting would get lost. - -Now the ``auto`` state will remain no matter the actual temperature or -labeling, so when a vcl needs to implicitly change temperature (due to -being used or being labeled), an ``auto`` vcl will remain ``auto``, -and a ``cold`` / ``warm`` vcl will change state, but never become -``auto`` implicitly. - -For developers and authors of VMODs and API clients -=================================================== - -The Python 2 EOL is approaching and our build system now favors Python 3. In -the 2020-03-15 release we plan to only support Python 3. - -The "vararg" ``VCL_STRING_LIST`` type is superseded by the array-based -``VCL_STRANDS`` type. The deprecated string list will eventually be removed -entirely and VMOD authors are strongly encouraged to convert to strands. -VRT functions working with string list arguments now take strands. - -More functions such as ``VRT_Vmod_Init()`` and ``VRT_Vmod_Unload()`` from -the VRT namespace moved away to the Varnish Private Interface (VPI). Such -functions were never intended for VMODs in the first place. - -The functions ``VRT_ref_vcl()`` and ``VRT_rel_vcl()`` were renamed to -respectively ``VRT_VCL_Prevent_Discard()`` and ``VRT_VCL_Allow_Discard()``. - -Some functions taking ``VCL_IP`` arguments now take a ``VRT_CTX`` in order -to fail in the presence of an invalid IP address. - -See ``vrt.h`` for a list of changes since the 6.2.0 release. - -We sometimes use Coccinelle_ to automate C code refactoring throughout the -code base. Our collection of semantic patches may be used by VMOD and API -clients authors and are available in the Varnish source tree in the -``tools/coccinelle/`` directory. - -.. _Coccinelle: http://coccinelle.lip6.fr/ - -The ``WS_Reserve()`` function is deprecated and replaced by two functions -``WS_ReserveAll()`` and ``WS_ReserveSize()`` to avoid ambiguous situations. -Its removal is planned for the 2020-09-15 release. - -A ``ws_reserve.cocci`` semantic patch can help with the transition. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-6.4.rst b/doc/sphinx/whats-new/upgrading-6.4.rst deleted file mode 100644 index 79be9e779c..0000000000 --- a/doc/sphinx/whats-new/upgrading-6.4.rst +++ /dev/null @@ -1,76 +0,0 @@ -.. - Copyright (c) 2020 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_6.4: - -%%%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 6.4.0 -%%%%%%%%%%%%%%%%%%%%%%%%%% - -Upgrading to Varnish 6.4 from 6.3 should not require any changes -to VCL. - -This document contains information about other relevant aspects which -should be considered when upgrading. - -varnishd --------- - -* The hash algorithm of the ``hash`` director was changed, so backend - selection will change once only when upgrading. - - Users of the ``hash`` director are advised to consider using the - ``shard`` director instead, which, amongst other advantages, offers - more stable backend selection through consistent hashing. See - :ref:`vmod_directors(3)` for details. - -* We fixed a case where :ref:`ref_param_send_timeout` had no effect on HTTP/1 - connections when streaming from a backend fetch, in other words, a - connection might not have got closed despite the :ref:`ref_param_send_timeout` - having been reached. HTTP/2 was not affected. - - When :ref:`ref_param_send_timeout` is reached on HTTP/1, the - ``MAIN.sc_tx_error`` is increased. Users with long running backend - fetches and HTTP/1 clients should watch out for an increase of that - counter compared to before the deployment and consider increasing - :ref:`ref_param_send_timeout` appropriately. - - The timeout can also be set per connection from VCL as - ``sess.send_timeout``. - - .. actually H2 is really quite different and we have a plan to - harmonize timeout handling across the board - -Statistics ----------- - -* The ``MAIN.sess_drop`` counter is gone. It should be removed from - any statistics gathering tools, if present - -* ``sess.timeout_idle`` / :ref:`ref_param_timeout_idle` being reached - on HTTP/1 used to be accounted to the ``MAIN.rx_timeout`` - statistic. We have now added the ``MAIN.rx_close_idle`` counter for - this case specifically. - -* ``sess.send_timeout`` / :ref:`ref_param_send_timeout` being reached - on HTTP/1 used to be accounted to ``MAIN.sc_rem_close``. Such - timeout events are now accounted towards ``MAIN.sc_tx_error``. - -See :ref:`varnish-counters(7)` for details. - -vsl/logs --------- - -* The ``Process`` timestamp for ``vcl_synth {}`` was wrongly issued - before the VCL subroutine was called, now it gets emitted after VCL - returns for consistency with ``vcl_deliver {}``. - - Users of this timestamp should be aware that it now includes - ``vcl_synth {}`` processing time and appears at a different - position in the log. - -* A ``Notice`` VSL tag has been added. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-6.5.rst b/doc/sphinx/whats-new/upgrading-6.5.rst deleted file mode 100644 index b22050a825..0000000000 --- a/doc/sphinx/whats-new/upgrading-6.5.rst +++ /dev/null @@ -1,114 +0,0 @@ -.. - Copyright (c) 2020 Varnish Software AS - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_6.5: - -%%%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 6.5.0 -%%%%%%%%%%%%%%%%%%%%%%%%%% - -varnishstat -=========== - -The JSON output (``-j`` option) changed to avoid having the ``timestamp`` -field mixed with the counters fields. As such the schema version was bumped -from 0 to 1, and a ``version`` top-level field was added to keep track of -future schema changes. Counters are in a new ``counters`` top-level field. - -Before:: - - { - "timestamp": "YYYY-mm-ddTHH:MM:SS", - "MGT.uptime": { - ... - }, - ... - } - -After:: - - { - "version": 1, - "timestamp": "YYYY-mm-ddTHH:MM:SS", - "counters": { - "MGT.uptime": { - ... - }, - ... - } - } - -The filter option ``-f`` is now deprecated in favor of the ``-I`` and -``-X`` options for field inclusions and exclusions, respectively. Tools -using ``varnishstat`` should prepare for future removal and be changed -accordingly. - -VSL -=== - -If you need to build VSL queries that depend on ``BackendReuse`` you can -now rely on ``BackendClose``, for example:: - - varnishlog -q 'BackendReuse[2] ~ www' - -The new query would be:: - - varnishlog -q 'BackendClose[2] ~ www and BackendClose[3] eq recycle' - -Changes for developers and VMOD authors -======================================= - -VSB -~~~ - -VSB support for dynamic vs. static allocations has been changed and -code using VSBs will need to be adjusted, see -:ref:`whatsnew_changes_6.5_libvarnish`. - -It should be noted that the VSB itself and the string buffer must be either -both dynamic or both static. It is no longer possible for example to have -a static ``struct`` with a dynamic buffer with the new API. - -Workspace API -~~~~~~~~~~~~~ - -VMODs using the Workspace API might need minor adjustments, see -:ref:`whatsnew_changes_6.5_workspace`. - -In general, accessing any field of ``struct ws`` is strongly discouraged -and if the workspace API doesn't satisfy all your needs please bring -that to our attention. - -VSC -~~~ - -The ``'f'`` argument for ``VSC_Arg()`` is now deprecated as mentioned in -the above note on `varnishstat`_ and :ref:`whatsnew_changes_6.5_vsc`. - -Otherwise you can use the ``'I'`` ans ``'X'`` arguments to respectively -include or exclude counters, they work in a first-match fashion. Since -``'f'`` is now emulated using the new arguments, its filtering behavior -slightly changed from exclusions first to first match. - -If like ``varnishstat`` in curses mode, you have a utility that always -needs some counters to be present the ``'R'`` argument takes a glob of -required fields. Such counters are not affected by filtering from other -``VSC_Arg()`` arguments. - -Official Packages related changes -================================= - -* The default systemd `varnish.service` unit file now sets `varnishd` to - listen for PROXY protocol connections on port 8443. This corresponds - with the Hitch default configuration, making it easier to set up Varnish - using TLS. - -* The default systemd `varnish.service` unit file now enables the HTTP/2 - feature of `varnishd`. This corresponds with the default ALPN token - advertisement in the Hitch default configuration, making it easier to - enable HTTP/2 in Varnish setups. - - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-6.6.rst b/doc/sphinx/whats-new/upgrading-6.6.rst deleted file mode 100644 index f605931f56..0000000000 --- a/doc/sphinx/whats-new/upgrading-6.6.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. - Copyright 2021 UPLEX Nils Goroll Systemoptimierung - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_6.6: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 6.6 -%%%%%%%%%%%%%%%%%%%%%%%% - -In general, this release should not come with relevant incompatibilities -to the previous release 6.5. - -VCL should continue to work as before except when rather exotic, -partly unintended and/or undocumented features are used. - -Header Validation -================= - -Varnish now validates any headers set from VCL to contain only -characters allowed by RFC7230. A (runtime) VCL failure is triggered if -not. Such VCL failures, which result in ``503`` responses, should be -investigated. As a last resort, the ``validate_headers`` parameter can -be set to ``false`` to avoid these VCL failures. - -BAN changes -=========== - -* The ``ban_cutoff`` parameter now refers to the overall length of the - ban list, including completed bans, where before only non-completed - ("active") bans were counted towards ``ban_cutoff``. - -* The ``ban()`` VCL builtin is now deprecated and should be replaced - with :ref:`whatsnew_changes_6.6_ban` - -Accounting Changes -================== - -Accounting statistics and Log records have changed. See -:ref:`whatsnew_changes_6.6_accounting` for details. - -VSL changes -=========== - -The ``-c`` option of log utilities no longer includes ESI requests. A -new ``-E`` option is now available for ESI requests and it implies ``-c`` -too. This brings all log utilities on par with ``varnishncsa`` where the -``-E`` option was initially introduced. - -If you use ``-c`` to collect both client and ESI requests, you should -use ``-E`` instead. If you use ``-c`` and a VSL query to exclude ESI -requests, the query should no longer be needed. - -VMOD ``cookie`` functions -========================= - -The regular expression arguments taken by various functions from the -``cookie`` VMOD now need to be literal. See -:ref:`whatsnew_changes_6.6_cookie` for details. - -Other VCL Changes -================= - -* The ``resp.proto`` variable is now read-only as it should have been - for long, like the other ``*.proto`` variables. - - Changing the protocol is an error and should not be required. - -* Trying to use ``std.rollback()`` from ``vcl_pipe`` now results in - VCL failure. - -* ``return(retry)`` from ``vcl_backend_error {}`` now correctly resets - ``beresp.status`` and ``beresp.reason``. - -Changes to VMODs -================ - -Many VMODs will need minor adjustments to work with this release. See -:ref:`whatsnew_changes_6.6_vmod` for details. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-7.0.rst b/doc/sphinx/whats-new/upgrading-7.0.rst deleted file mode 100644 index 6fd865b34e..0000000000 --- a/doc/sphinx/whats-new/upgrading-7.0.rst +++ /dev/null @@ -1,341 +0,0 @@ -.. - Copyright 2021 Varnish Software - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - -.. _whatsnew_upgrading_7.0: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 7.0 -%%%%%%%%%%%%%%%%%%%%%%%% - -PCRE2 -===== - -The migration from PCRE to PCRE2 led to many changes, starting with a -change of build dependencies. See the current installation notes for -package dependencies on various platforms. - -Previously the Just In Time (jit) compilation of regular expressions was -always enabled at run time if it was present during the build. From now -on jit compilation is enabled by default, but can be disabled with the -``--disable-pcre2-jit`` configure option. Once enabled, jit compilation -is merely attempted and failures are ignored since they are not essential. - -The new ``varnishd`` parameter ``pcre2_jit_compilation`` controls whether -jit compilation should be attempted and has no effect if jit support was -disabled at configure time. - -See :ref:`ref_param_pcre2_jit_compilation`. - -The former parameters ``pcre_match_limit`` and ``pcre_match_limit_recursion`` -were renamed to ``pcre2_match_limit`` and ``pcre2_depth_limit``. With older -PCRE2 libraries, it is possible to see the depth limit being referred to as -recursion limit in error messages. - -See :ref:`ref_param_pcre2_depth_limit` and :ref:`ref_param_pcre2_depth_limit` -for more information. - -The syntax of regular expression should be the same, but it is possible to -run into subtle differences. We are aware one such difference, PCRE2 fails -the compilation of unknown escape sequences. For example PCRE interprets -``"\T"`` as ``"T"`` and ignores the escape character, but PCRE2 sees it as -a syntax error. The solution is to simply use ``"T"`` and in general remove -all spurious escape characters. - -While PCRE2 can capture named groups and has its own substitution syntax -where captured groups can be referred to by position with ``$`` or even -by name. The substitution syntax for VCL's ``regsub()`` remains the same and -captured groups still require the ``\`` syntax where ``\1`` refers to -the first group. - -For this reason, there shouldn't be changes required to existing VCL, ban -expressions, VSL queries, or anything working with regular expression in -Varnish, except maybe where PCRE2 seems to be stricter and refuses invalid -escape sequences. - -VMOD authors manipulating ``VCL_REGEX`` arguments should not be affected by -this migration if they only use the VRT API. However, the underlying VRE API -was substantially changed and the new revision of VRE allowed to cover all -the Varnish use cases so that ``libvarnish`` is now the only binary linking -*directly* to ``libpcre2-8``. - -The migration implies that bans persisted in the deprecated persistent storage -are no longer compatible and a new deprecated persistent storage should be -rebuilt from scratch. - -Structured Fields numbers -========================= - -VCL types INTEGER and REAL now map respectively to Structured Fields integer -and decimal numbers. Numbers outside of the Structured Fields bounds are no -longer accepted by the VCL compiler and the various conversion functions from -vmod_std will fail the transaction for numbers out of bounds. - -The scientific notation is no longer supported, for example ``12.34e+3`` must -be spelled out as ``12340`` instead. - -Memory footprint -================ - -In order to lower the likelihood of flushing the logs of a single task more -than once, the default value for ``vsl_buffer`` was increased to 16kB. This -should generally result in better performance with tools like ``varnishlog`` -or ``varnishncsa`` except for ``raw`` grouping. - -To accommodate this extra workspace consumption and add even more headroom -on top of it, ``workspace_client`` and ``workspace_backend`` both increased -to 96kB by default. - -The PCRE2 jit compiler produces code that consumes more stack, so the default -value of ``thread_pool_stack`` was increased to 80kB, and to 64kB on 32bit -systems. - -If you are relying on default values, this will result in an increase of -virtual memory consumption proportional to the number of concurrent client -requests and backend fetches being processed. This memory is not accounted -for in the storage limits that can be applied. - -To address a potential head of line blocking scenario with HTTP/2, request -bodies are now buffered between the HTTP/2 session (stream 0) and the client -request. This is allocated on storage, controlled by the ``h2_rxbuf_storage`` -parameter and comes in addition to the existing buffering between a client -request and a backend fetch also allocated on storage. The new buffer size -depends on ``h2_initial_window_size`` that has a new default value of 65535B -to avoid having streams with negative windows. - -Range requests -============== - -Varnish only supports bytes units for range requests and always stripped -``Accept-Range`` headers coming from the backend. This is no longer the case -for pass transactions. - -To find out whether an ``Accept-Range`` header came from the backend, the -``obj.uncacheable`` in ``vcl_deliver`` indicates whether this was a pass -transaction. - -When ``http_range_support`` is on, a consistency check is added to ensure -the backend doesn't act as a bad gateway. If an unexpected ``Content-Range`` -header is received, or if it doesn't match the client's ``Range`` header, -it is considered an error and a 503 response is generated instead. - -If your backend adds spurious ``Content-Range`` headers that you can assess -are safe to ignore, you can amend the response in VCL:: - - sub vcl_backend_response { - if (!bereq.http.range) { - unset beresp.http.content-range; - } - } - -When a consistency check fails, an error is logged with the specific range -problem encountered. - -ACL -=== - -The ``acl`` keyword in VCL now supports bit flags: - -- ``log`` -- ``pedantic`` (enabled by default) -- ``table`` - -The global parameter ``vcc_acl_pedantic`` (off by default) was removed, and -as a result ACLs are now pedantic by default. TODO: reference to manual. - -They are also quiet by default, the following ACL declarations are -equivalent:: - - acl { ... } - acl -log +pedantic -table { ... } - -This means that the entry an ACL matched is no longer logged as ``VCL_acl`` by -default. - -To restore the previous default behavior, declare your ACL like this:: - - acl +log -pedantic { ... } - -ACLs are optimized for runtime performance by default, which can increase -significantly the VCL compilation time with very large ACLs. The ``table`` -flag improves compilation time at the expense of runtime performance. - -See :ref:`vcl-acl`. - -Changes for developers -====================== - -Build ------ - -Building from source requires autoconf 2.69 or newer and automake 1.13 or -newer. Neither are needed when building from a release archive since they -are already bootstrapped. - -There is a new ``--enable-workspace-emulator`` configure flag to replace the -regular "packed allocation" workspace with a "sparse allocation" alternative. -Combined with the Address Sanitizer it can help VMOD authors find memory -handling issues like buffer overflows that could otherwise be missed on a -regular workspace. - -``vdef.h`` ----------- - -The ``vdef.h`` header is no longer self-contained, it includes ``stddef.h``. - -Since it is the first header that should be included when working with Varnish -bindings, some definitions were promoted to ``vdef.h``: - -- a fallback for the ``__has_feature()`` macro in its absence -- VRT macros for Structured Fields number limits -- ``struct txt`` and its companion macros (the macros require ``vas.h`` too) - -This header is implicitly included by ``vrt.h`` and ``cache.h`` and should not -concern VMOD authors. - -Workspace API -------------- - -The deprecated functions ``WS_Front()`` and ``WS_Inside()`` are gone, they -were replaced by ``WS_Reservation()`` and ``WS_Allocated()``. For this reason -``WS_Assert_Allocated()`` was removed despite not being deprecated, since it -became redundant with ``assert(WS_Allocated(...))``. Accessing the workspace -front pointer only makes sense during a reservation, that's why ``WS_Front()`` -was deprecated in a previous release. - -It should no longer be needed to access ``struct ws`` fields directly, and -everything should be possible with the ``WS_*()`` functions. It even becomes -mandatory when the workspace emulator is enabled, the ``struct ws`` fields -have different semantics. - -``STRING_LIST`` ---------------- - -VMOD authors can no longer take ``STRING_LIST`` arguments in functions or -object methods. To work with string fragments, use ``VCL_STRANDS`` instead. - -As a result the following symbols are gone: - -- ``VRT_String()`` -- ``VRT_StringList()`` -- ``VRT_CollectString()`` -- ``vrt_magic_string_end`` - -Functions that used to take a ``STRING_LIST`` in the form of a prototype -ending with ``const char *, ...`` now take ``const char *, VCL_STRANDS``: - -- ``VRT_l_client_identity()`` -- ``VRT_l_req_method()`` -- ``VRT_l_req_url()`` -- ``VRT_l_req_proto()`` -- ``VRT_l_bereq_method()`` -- ``VRT_l_bereq_url()`` -- ``VRT_l_bereq_proto()`` -- ``VRT_l_beresp_body()`` -- ``VRT_l_beresp_proto()`` -- ``VRT_l_beresp_reason()`` -- ``VRT_l_beresp_storage_hint()`` -- ``VRT_l_beresp_filters()`` -- ``VRT_l_resp_body()`` -- ``VRT_l_resp_proto()`` -- ``VRT_l_resp_reason()`` -- ``VRT_l_resp_filters()`` - -The ``VRT_SetHdr()`` function also used to take a ``STRING_LIST`` and now -takes a ``const char *, VCL_STRANDS`` too. But, in addition to this change, -it also no longer accepts the special ``vrt_magic_string_unset`` argument. - -Instead, a new ``VRT_UnsetHdr()`` function was added. - -The ``VRT_CollectStrands()`` function was renamed to ``VRT_STRANDS_string()``, -which was its original intended name. - -Null sentinels --------------- - -Two convenience sentinels ``vrt_null_strands`` and ``vrt_null_blob`` were -added to avoid ``NULL`` usage. ``VRT_blob()`` returns ``vrt_null_blob`` when -the source is null or the length is zero. The null blob has the type -``VRT_NULL_BLOB_TYPE``. - -libvarnishapi -------------- - -Deprecated functions ``VSB_new()`` and ``VSB_delete()`` were removed. Use -``VSB_init()`` and ``VSB_fini()`` for static buffers and ``VSB_new_auto()`` -and ``VSB_destroy()`` for dynamic buffers. - -Their removal resulted in bumping the soname to 3.0.0 for libvarnishapi. - -libvarnish ----------- - -Other changes were made to libvarnish, those are only available to VMOD -authors since they are not exposed by libvarnishapi. - -VNUM -'''' - -The ``VNUMpfx()`` function was replaced by ``SF_Parse_Number()`` that parses -both decimal and integer numbers from RFC8941. In addition there are new -``SF_Parse_Decimal()`` and ``SF_Parse_Integer()`` more specialized functions. - -``VNUM_bytes_unit()`` returns an integer and no longer parses factional bytes. - -New token parsers ``VNUM_uint()`` and ``VNUM_hex()`` were added. - -The other VNUM functions rely on the new SF functions for parsing, with the -same limitations. - -The following macros define the Structured Fields number bounds: - -- ``VRT_INTEGER_MIN`` -- ``VRT_INTEGER_MAX`` -- ``VRT_DECIMAL_MIN`` -- ``VRT_DECIMAL_MAX`` - -VRE -''' - -The VRE API completely changed in preparation for the PCRE2 migration, in -order to funnel all PCRE usage in the Varnish source code through VRE. - -Similarly to how parameters were renamed, the ``match_recursion`` field from -``struct vre_limits`` was renamed to ``depth``. It has otherwise the same -meaning and purpose. - -Notable breaking changes: - -- ``VRE_compile()`` signature changed -- ``VRE_exec()`` was replaced: - - ``VRE_match()`` does simple matching - - ``VRE_capture()`` captures matched groups in a ``txt`` array - - ``VRE_sub()`` substitute matches with a replacement in a VSB -- ``VRE_error()`` prints an error message for all the functions above in a VSB -- ``VRE_export()`` packs a usable ``vre_t`` that can be persisted as a byte - stream - -An exported regular expression takes the form of a byte stream of a given size -that can be used as-is by the various matching functions. Care should be taken -to always maintain pointer alignment of an exported ``vre_t``. - -The ``VRE_ERROR_NOMATCH`` symbol is now hard-linked like ``VRE_CASELESS``, and -``VRE_NOTEMPTY`` is no longer supported. There are no match options left in -the VRE facade but the ``VRE_match()``, ``VRE_capture()`` and ``VRE_sub()`` -functions still take an ``options`` argument to keep the ability of allowing -match options in the future. - -The ``VRE_ERROR_LEN`` gives a size that should be safe to avoid truncated -error messages in a static buffer. - -To gain full access to PCRE2 features from a regular expression provided via -``vre_t`` a backend-specific ``vre_pcre2.h`` contains a ``VRE_unpack()`` -function. This opens for example the door to ``pcre2_substitute()`` with the -PCRE2 substitution syntax and named capture groups as an alternative to VCL's -``regsub()`` syntax backed by ``VRE_sub()``. - -Ideally, ``vre_pcre2.h`` will be the only breaking change next time we move -to a different regular expression engine. Hopefully not too soon. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-7.1.rst b/doc/sphinx/whats-new/upgrading-7.1.rst deleted file mode 100644 index fc8497e5a3..0000000000 --- a/doc/sphinx/whats-new/upgrading-7.1.rst +++ /dev/null @@ -1,137 +0,0 @@ -.. _whatsnew_upgrading_7.1: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 7.1 -%%%%%%%%%%%%%%%%%%%%%%%% - -varnishd -======== - -Varnish now has an infrastructure in place to rename parameters or VCL -variables while keeping a deprecated alias for compatibility. - -Parameters -~~~~~~~~~~ - -There are plans to rename certain arguments. When this happens, aliases will -not be listed by ``param.show [-j|-l]`` commands, but they will be displayed -by ``param.show [-j] ``. Systems operating on top of ``varnishadm`` or -the Varnish CLI can be updated to anticipate this change with the help of the -``deprecated_dummy`` parameter added for testing purposes. - -The deprecated ``vsm_space`` parameter was removed. It was ignored and having -no effect since Varnish 6.0.0 and should have disappeared with the 7.0.0 -release. The sub-argument of the ``-l`` command line option that was used as -a shorthand for ``vsm_space`` is also no longer accepted. - -Command line options -~~~~~~~~~~~~~~~~~~~~ - -A common pattern when a CLI script is used during startup is to -combine the ``-I`` and ``-f ''`` options to prevent an automatic -startup of the cache process. In this case a start command is usually -present in the CLI script, most likely as the last command. This -enables loading VCLs and potentially VCL labels which require a -specific order if the active VCL is supposed to switch execution to -labels. - -To support this pattern, a VCL loaded through the CLI script is no -longer implicitly used if there is no active VCL yet. If no VCL was -loaded through the ``-b`` or ``-f`` options it means that an explicit -``vcl.use`` command is needed before the ``start`` command. - -In the scenario described above, that would already be the case since the -desired active VCL would likely need to be loaded last, not eligible for an -implicit ``vcl.use`` since dependencies were loaded first. This change should -not affect existing ``-I`` scripts, but if it does, simply add the missing -``vcl.use`` command. - -Other changes in varnishd -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The ESI parser now recognizes the ``onerror="continue"`` attribute of -the ```` XML tag. - -The ``+esi_include_onerror`` feature flag controls if the attribute is -honored: If enabled, failure of an include stops ESI processing unless -the ``onerror="continue"`` attribute was set for it. - -The feature flag is off by default, preserving the existing behavior -to continue ESI processing despite include failures. - -Users of persistent storage engines be advised that objects created -before the introduction of this change cannot carry the -``onerror="continue"`` attribute and, consequently, will be handled as -if it was not present if the ``+esi_include_onerror`` feature flag is -enabled. - -Also, as this change is not backwards compatible, downgrades with -persisted storage are not supported across this release. - -varnishtest -=========== - -The deprecated ``err_shell`` command was removed, use ``shell -err`` instead. - -Changes for developers and VMOD authors -======================================= - -Backends -~~~~~~~~ - -Backends have reference counters now to avoid the uncertainty of a task -holding onto a dynamic backend for a long time, for example in the waiting -list, with the risk of the backend going away during the transaction. - -Assignments should be replaced as such:: - - -lvalue = expr; - +VRT_Assign_Backend(&lvalue, expr); - -.. XXX: there should be a coccinelle patch to help. - -For backends which are guaranteed at least VCL lifetime, the -respective VMOD can opt out of reference counting with -``VRT_StaticDirector()`` to avoid the reference counting overhead. - -Filters -~~~~~~~ - -Two new functions ``VRT_AddFilter()`` and ``VRT_RemoveFilter()`` -manage filters as VDP/VFP pairs. When used as pairs, the filters must -have the same name, otherwise operating with only one fetch or -delivery filter is fine. - -Unlike its deprecated predecessors ``VRT_AddVFP()`` and ``VRT_AddVDP()``, -the new ``VRT_AddFilter()`` returns an error string. The ``VRT_RemoveVFP()`` -and ``VRT_RemoveVDP()`` functions are also deprecated and kept for now -as wrappers of ``VRT_RemoveFilter()`` without error handling. - -VMOD deprecated aliases -~~~~~~~~~~~~~~~~~~~~~~~ - -A VMOD author can from now on rename a function or object method without -immediately breaking compatibility by declaring the old name as an alias. - -In the VMOD descriptor, it is possible to add the following stanza:: - - $Alias deprecated_function original_function - - or - - $Alias .deprecated_method object.original_method - -This is a good occasion to revisit unfortunate name choices in existing VMODs. - -Platform Support -================ - -systemd -~~~~~~~ - -To make the selection of the main process deterministic for the kill mode, a -PID file is now expected by default in the varnish service. In a setup where -the service command for ``ExecStart`` is overridden, a ``-P`` option matching -the ``PIDFile`` setting is needed. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-7.2.rst b/doc/sphinx/whats-new/upgrading-7.2.rst deleted file mode 100644 index 16d86c32da..0000000000 --- a/doc/sphinx/whats-new/upgrading-7.2.rst +++ /dev/null @@ -1,101 +0,0 @@ -.. _whatsnew_upgrading_7.2: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 7.2 -%%%%%%%%%%%%%%%%%%%%%%%% - -varnishd -======== - -Parameters -~~~~~~~~~~ - -The following parameters are deprecated: - -- ``vcc_allow_inline_c`` -- ``vcc_err_unref`` -- ``vcc_unsafe_path`` - -They can still be set as individual boolean parameters. The deprecated -aliases will be removed in a future release. - -They are replaced by the ``vcc_feature`` bits parameter: - -- ``allow_inline_c`` -- ``err_unref`` (enabled by default) -- ``unsafe_path`` (enabled by default) - -The following commands are equivalent:: - - param.set vcc_err_unref off - param.set vcc_feature -err_unref - -Identity -~~~~~~~~ - -The server identity must be a valid HTTP token, which may pose a problem -to existing setups. For example ``varnishd -i "edge server 1"`` is no -longer accepted. You can use something like ``varnishd -i "edge-server-1"`` -instead. - -VCL -=== - -Varnish generates a Via header and forwards it to the backend by default. -This can be prevented for example in ``vcl_recv`` or ``vcl_backend_fetch``. - -:: - - sub vcl_recv { - unset req.http.via; - } - - sub vcl_backend_fetch { - unset bereq.http.via; - } - -The Via header is generated with the ``server.identity`` variable for -the ``received-by`` field. See `rfc9110_` for a description of the Via -header. - -A ``resp.http.via`` header is no longer overwritten by varnish, but -rather appended to. - -.. _rfc9110: https://www.rfc-editor.org/rfc/rfc9110#name-via - -VMODs -===== - -Cookies generated by vmod_cookie used to have a trailing semi-colon that -goes against the recommendations from `rfc6265`_. This should not pose a -problem, unless a piece of VCL code or a backend have come to rely on this -incorrect behavior. - -.. _rfc6265: https://www.rfc-editor.org/rfc/rfc6265 - -varnishlog -========== - -The ``Begin`` and ``Link`` log records have an optional 4th field for the -sub-request level. This may break log processors, log queries or NCSA -formats that expect those records to have exactly 3 fields. - -varnishstat -=========== - -The ``MAIN.fetch_no_thread`` counter is gone, it never worked. Track the -``MAIN.bgfetch_no_thread`` counter instead. - -Changes for developers and VMOD authors -======================================= - -The functions ``VRT_AddVDP()``, ``VRT_AddVFP()``, ``VRT_RemoveVDP()`` and -``VRT_RemoveVFP()`` are deprecated. Use ``VRT_AddFilter()`` to add a pair -(VFP and VDP) and ``VRT_RemoveFilter()`` to remove it. A filter pair needs -at least one member of the pair. - -The ``varnishtest -i`` option no longer works outside of a Varnish source -tree. There shouldn't be a reason to use ``-i`` outside of the Varnish -test suite. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-7.3.rst b/doc/sphinx/whats-new/upgrading-7.3.rst deleted file mode 100644 index 38ae1cd7db..0000000000 --- a/doc/sphinx/whats-new/upgrading-7.3.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. _whatsnew_upgrading_7.3: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 7.3 -%%%%%%%%%%%%%%%%%%%%%%%% - -New VSL format -============== - -The binary format of Varnish logs changed to increase the space for VXIDs from -32 bits to 64. This is not a change that older versions of the Varnish logging -utilities can understand, and the new utilities can also not process old logs. - -There is no conversion tool from the old format to the new one, so this should -become a problem only when raw logs are stored for future processing. If old -binary logs need to remain usable, the only solution is to use a compatible -Varnish version and at the time of this release, the 6.0 branch is the only -one without an EOL date. - -For developers and VMOD authors: C interface changes requiring adjustments -========================================================================== - -Via backends ------------- - -The new backend argument to the ``VRT_new_backend*()`` functions is optional -and ``NULL`` can be passed to match the previous behavior. - -suckaddr --------- - -The following functions return or accept ``const`` pointers from now on: - -- ``VSA_Clone()`` -- ``VSA_getsockname()`` -- ``VSA_getpeername()`` -- ``VSA_Malloc()`` -- ``VSA_Build*()`` -- ``VSS_ResolveOne()`` -- ``VSS_ResolveFirst()`` - -``VSA_free()`` has been added to free heap memory allocated by -``VSA_Malloc()`` or one of the ``VSA_Build*()`` functions with a -``NULL`` first argument. - -directors ---------- - -Directors which take and hold references to other directors via -``VRT_Assign_Backend()`` (typically any director which has other -directors as backends) are now expected to implement the new -``.release`` callback of type ``void -vdi_release_f(VCL_BACKEND)``. This function is called by -``VRT_DelDirector()``. The implementation is expected drop any backend -references which the director holds (again using -``VRT_Assign_Backend()`` with ``NULL`` as the second argument). - -Failure to implement this callback can result in deadlocks, in -particular during VCL discard. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-7.4.rst b/doc/sphinx/whats-new/upgrading-7.4.rst deleted file mode 100644 index cab2f38246..0000000000 --- a/doc/sphinx/whats-new/upgrading-7.4.rst +++ /dev/null @@ -1,30 +0,0 @@ -.. _whatsnew_upgrading_7.4: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 7.4 -%%%%%%%%%%%%%%%%%%%%%%%% - -Important VCL Changes -===================== - -When upgrading from Varnish-Cache 7.3, there is only one breaking -change to consider in VCL: - -The ``Content-Length`` and ``Transfer-Encoding`` headers are now -*protected*, they can neither be changed nor unset. This change was -implemented to avoid de-sync issues from accidental, inadequate -modifications of these headers. - -For the common use case of ``unset (be)req.http.Content-Length`` to -dismiss a request body, ``unset (be)req.body`` should be used. - -Parameter Changes -================= - -The new ``varnishd`` parameter ``startup_timeout`` now specifically -replaces ``cli_timeout`` for the initial startup only. In cases where -``cli_timeout`` was increased specifically to accommodate long startup -times (e.g. for storage engine initialization), ``startup_timeout`` -should be used. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-7.5.rst b/doc/sphinx/whats-new/upgrading-7.5.rst deleted file mode 100644 index 67d8beb34b..0000000000 --- a/doc/sphinx/whats-new/upgrading-7.5.rst +++ /dev/null @@ -1,88 +0,0 @@ -.. _whatsnew_upgrading_7.5: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 7.5 -%%%%%%%%%%%%%%%%%%%%%%%% - -Logs -==== - -The optional reason field of ``BackendClose`` records changed from a -description (for example "Receive timeout") to a reason tag (for example -``RX_TIMEOUT``). This will break VSL queries based on the reason field. - -Using a tag should however make queries more reliable:: - - # before - varnishlog -q 'BackendClose ~ "Receive timeout"' - - # after - varnishlog -q 'BackendClose[4] eq RX_TIMEOUT' - -Such queries would no longer break when a description is changed. - -Timeouts -======== - -The value zero for timeouts could mean either timing out immediately, never -timing out, or not having a value and falling back to another. The semantic -changed so zero always means non-blocking, timing out either immediately after -checking whether progress is possible, or after a millisecond in parts where -this can't practically be done in a non-blocking fashion. - -In order to disable a timeout, that is to say never time out, the value -``INFINITY`` is used (or tested with ``isinf()``). - -In the places where a timeout setting may fall back to another value, like -VCL variables falling back to parameters, ``NAN`` is used to convey the lack -of timeout setting. - -VCL -~~~ - -All the timeouts backed by parameters can now be unset, meaning that setting -the value zero no longer falls back to parameters. - -Parameters -~~~~~~~~~~ - -All the timeout parameters that can be disabled are now documented with the -``timeout`` flag, meaning that they can take the special value ``never`` for -that purpose:: - - varnishadm param.set pipe_timeout never - -The parameters ``idle_send_timeout`` and ``timeout_idle`` are now -limited to a maximum of 1 hour. - -VRT -~~~ - -For VMOD authors, it means that the ``vtim_dur`` type expects ``INFINITY`` to -never time out or ``NAN`` to not set a timeout. - -For VMOD authors managing backends, there is one exception where a timeout -fallback did not change from zero to ``NAN`` in ``struct vrt_backend``. The -``vtim_dur`` fields must take a negative value in order to fall back to the -respective parameters due to a limitation in how VCL is compiled. - -As a convenience, a new macro ``VRT_BACKEND_INIT()`` behaves like ``INIT_OBJ`` -but initializes timeouts to a negative value. - -VCL COLD events have been fixed for directors vs. VMODs: VDI COLD now -comes before VMOD COLD. - -Other changes relevant for VMOD / VEXT authors -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Transports are now responsible for calling ``VDP_Close()`` in all -cases. - -Storage engines are now responsible for deciding which -``fetch_chunksize`` to use. When Varnish-Cache does not know the -expected object size, it calls the ``objgetspace`` stevedore function -with a zero ``sz`` argument. - -``(struct req).filter_list`` has been renamed to ``vdp_filter_list``. - -*eof* diff --git a/doc/sphinx/whats-new/upgrading-7.6.rst b/doc/sphinx/whats-new/upgrading-7.6.rst deleted file mode 100644 index bbe2e4abcf..0000000000 --- a/doc/sphinx/whats-new/upgrading-7.6.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. _whatsnew_upgrading_7.6: - -%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Varnish 7.6 -%%%%%%%%%%%%%%%%%%%%%%%% - -In general, upgrading from Varnish 7.5 to 7.6 should not require any changes -besides the actual upgrade. - -The changes mentioned below are considered noteworthy nevertheless: - -Noteworthy changes for container workloads -========================================== - -When ``varnishd`` runs in a different PID namespace on Linux, typically in a -container deployment, ``VSM_NOPID`` must be added to the environment of other -containers running programs attaching themselves to ``varnishd``'s shared -memory. This will otherwise fail liveness checks performed by VSM consumers. - -Noteworthy changes when upgrading varnishd -========================================== - -Warning about failed memory locking -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The ``Warning: mlock() of VSM failed`` message is now emitted when locking of -shared memory segments (via ``mlock(2)``) fails. As Varnish performance may be -severely impacted if shared memory segments are not resident in RAM, users -seeing this message are urged to review the ``RLIMIT_MEMLOCK`` resource control -as set via ``ulimit -l`` or ``LimitMEMLOCK`` with ``systemd(1)``. This is not -new at all, just now the warning has been added to make administrators more -aware. - -.. _whatsnew_upgrading_7.6_linux_jail: - -Warning if tmpfs is not used -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -On Linux (when the new ``linux`` jail is used), the ``Working directory not -mounted on tmpfs partition`` warning is now emitted if the working directory is -found to reside on a file system other than ``tmpfs``. While other file systems -are supported (and might be the right choice where administrators understand how -to avoid blocking disk IO while ``varnishd`` is writing to shared memory), -``tmpfs`` is the failsafe option to avoid performance issues. - -Upgrading VCL -============= - -.. _RFC9110: https://www.rfc-editor.org/rfc/rfc9110.html#section-14.4 - -An issue has been addressed in the ``builtin.vcl`` where backend responses -would fail if they contained a ``Content-Range`` header when no range was -requested. According to `RFC9110`_, this header should just be ignored, yet -some Varnish users might prefer stricter checks. Thus, we decided to change -the ``builtin.vcl`` only and users hitting this issue are advised to call -``vcl_beresp_range`` from custom VCL. - -Changes for developers and VMOD authors -======================================= - -The VDP filter API has changed. See :ref:`whatsnew_changes_7.6_VDP` for details. - -The signature of ``ObjWaitExtend()`` has changed. See -:ref:`whatsnew_changes_7.6_Obj` for details. - -``varnishd`` now creates a ``worker_tmpdir`` which can be used by VMODs for -temporary files. See :ref:`ref-vmod-event-functions` for details. - -*eof* diff --git a/vinyl.m4 b/vinyl.m4 index 488600debf..53d2bee9f3 100644 --- a/vinyl.m4 +++ b/vinyl.m4 @@ -30,19 +30,19 @@ # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED # OF THE POSSIBILITY OF SUCH DAMAGE. -# varnish.m4 - Macros to build against Varnish. -*- Autoconf -*- -# serial 12 (varnish-7.5.0) +# vinyl.m4 - Macros to build against Vinyl Cache. -*- Autoconf -*- +# serial 12 (vinyl-7.5.0) # # This collection of macros helps create VMODs or tools interacting with -# Varnish Cache using the GNU build system (autotools). In order to work +# Vinyl Cache using the GNU build system (autotools). In order to work # from a source checkout, recommended versions of autotools are 2.68 for # autoconf, 1.12 for automake and 2.2.6 for libtool. For pkg-config, at # least version 0.21 is required ; it should be available even on old # platforms. Only pkg-config is needed when building from a dist archive. # # Macros whose name start with an underscore are private and may change at -# any time. Public macros starting with VARNISH_ are documented and will -# maintain backwards compatibility with older versions of Varnish Cache. +# any time. Public macros starting with VINYL_ are documented and will +# maintain backwards compatibility with older versions of Vinyl Cache. # _VINYL_CHECK_LIB(LIB, FUNC) # ----------------------------- @@ -84,12 +84,12 @@ AC_DEFUN([_VINYL_PKG_CONFIG], [ PKG_CHECK_VAR([VSCTOOL], [vinylapi], [vsctool]) AC_SUBST([VINYL_LIBRARY_PATH], - [$VINYLAPI_LIBDIR:$VINYLAPI_LIBDIR/varnish]) + [$VINYLAPI_LIBDIR:$VINYLAPI_LIBDIR/vinyl]) AC_SUBST([VINYL_TEST_PATH], [$VINYLAPI_SBINDIR:$VINYLAPI_BINDIR:$PATH]) - dnl Inherit Varnish's prefix if undefined + dnl Inherit Vinyl Cache's prefix if undefined dnl Also the libdir for multi-lib systems if test "$prefix" = NONE then @@ -116,7 +116,7 @@ AC_DEFUN([_VINYL_CHECK_DEVEL], [ [CPPFLAGS=$VINYLAPI_CFLAGS] AC_CHECK_HEADERS([vsha256.h cache/cache.h], [], - [AC_MSG_ERROR([Missing Varnish development files.])]) + [AC_MSG_ERROR([Missing Vinyl Cache development files.])]) [CPPFLAGS=$_orig_cppflags] ]) @@ -166,7 +166,7 @@ AC_DEFUN([_VINYL_VMOD_CONFIG], [ dnl Expose the location of the std and directors VMODs AC_SUBST([VINYLAPI_VMODDIR]) - dnl Expose Varnish's aclocal directory to automake + dnl Expose Vinyl Cache's aclocal directory to automake AC_SUBST([VINYLAPI_DATAROOTDIR]) dnl Define the VMOD directory for libtool @@ -303,7 +303,7 @@ clean-vmod-$1: # skip man page generation as it is often the case from a dist archive # (usually /bin/true when the manual is distributed). # -# Two notable variables are exposed from Varnish's pkg-config: +# Two notable variables are exposed from Vinyl Cache's pkg-config: # # - VINYLAPI_VMODDIR (locate vmod-std and vmod-directors in your tests) # - VINYLAPI_DATAROOTDIR (for when aclocal is called from a Makefile) @@ -317,7 +317,7 @@ clean-vmod-$1: # VMOD maintenance, initialization of autoconf, automake and libtool is # still the maintainer's responsibility. It cannot be avoided. # -# Once your VMOD is built, you can use varnishtest to run test cases. For +# Once your VMOD is built, you can use vinyltest to run test cases. For # that you can rely on automake's default test driver, and all you need # is a minimal setup: # @@ -325,19 +325,19 @@ clean-vmod-$1: # PATH="$(VINYL_TEST_PATH):$(PATH)" \ # LD_LIBRARY_PATH="$(VINYL_LIBRARY_PATH)" # TEST_EXTENSIONS = .vtc -# VTC_LOG_COMPILER = varnishtest -v +# VTC_LOG_COMPILER = vinyltest -v # AM_VTC_LOG_FLAGS = -Dvmod_foo="$(VMOD_FOO)" -Dvmod_bar="$(VMOD_BAR)" # # Setting up the different paths is mostly relevant when you aren't building -# against the system installation of Varnish. In the case of the PATH, you +# against the system installation of Vinyl Cache. In the case of the PATH, you # may also need to preserve the original PATH if you run commands outside of -# the Varnish distribution in your test cases (as shown above). +# the Vinyl Cache distribution in your test cases (as shown above). # # The $(VMOD_*) variables contain a proper import statement if the relevant # VMOD was built in the same directory as the test runner. With the example # above you could import VMODs this way in a test case: # -# varnish v1 -vcl+backend { +# vinyl v1 -vcl+backend { # import std; # import ${vmod_bar}; # @@ -362,7 +362,7 @@ clean-vmod-$1: # vmod_foo_vcl_DATA = some_addition.vcl # # This way the end-user's VCL only needs few lines of code to start using both -# VMODs and VCLs assuming Varnish's default vmod_path and vcl_path were not +# VMODs and VCLs assuming Vinyl Cache's default vmod_path and vcl_path were not # changed: # # vcl 4.0; @@ -391,7 +391,7 @@ AC_DEFUN([VINYL_VMODS], [ # If that VCC file only needs to be generated once and is distributed, builds # from the dist archive will have the VCC file in the source directory. # -# With Varnish's ability to run VMODTOOL in a VPATH build both scenarios are +# With Vinyl Cache's ability to run VMODTOOL in a VPATH build both scenarios are # taken care of. This macro works otherwise exactly like VINYL_VMODS. # AC_DEFUN([VINYL_VMODS_GENERATED], [ @@ -453,7 +453,7 @@ clean-vsc-$1: # ----------------------- # Since: Varnish 6.0.0 # -# In order to manipulate custom counters that tools like varnishstat can +# In order to manipulate custom counters that tools like vinylstat can # report, it is possible to do that via a VMOD. This macro allows you # to declare sets of counters, but does not associate them automatically # with their respective VMODs: @@ -534,9 +534,9 @@ clean-vut-$1: # Since: Varnish 5.2.0 # # To write programs that consume the VSM, and in particular the VSL, it is -# possible since Varnish 5.2.0 to use the VUT (Varnish UTility) API already -# used by varnishlog, varnishstat and the other utilities from the standard -# Varnish distribution. +# possible since Varnish 5.2.0 to use the VUT (Vinyl UTility) API already +# used by vinyllog, vinylstat and the other utilities from the standard +# Vinyl Cache distribution. # # This API can optionally be used to generate part of the manual: the synopsis # and the list of options. The generated RST files can then be included from @@ -633,7 +633,7 @@ AC_DEFUN([VINYL_UTILITIES], [ # Since Varnish 5.2.0: # - VSCTOOL added # -# Verify that the version of Varnish Cache found by pkg-config is at least +# Verify that the version of Vinyl Cache found by pkg-config is at least # MINIMUM-VERSION. If MAXIMUM-VERSION is specified, verify that the version # is strictly below MAXIMUM-VERSION. # @@ -644,8 +644,8 @@ AC_DEFUN([VINYL_UTILITIES], [ # - VINYL_LIBRARY_PATH (for both public and private libraries) # - VINYL_VERSION (also available in autoconf) # -# The following variables are available in autoconf, read from the varnish -# pkg-config: +# The following variables are available in autoconf, read from the +# Vinyl Cache pkg-config: # # - VINYLAPI_CFLAGS # - VINYLAPI_LIBS @@ -664,8 +664,8 @@ AC_DEFUN([VINYL_UTILITIES], [ # - vcldir # - pkgvcldir # -# The vcldir is where Varnish will by default look up VCL files using relative -# paths not found in its sysconfdir (by default /etc/varnish). The pkgvcldir on +# The vcldir is where Vinyl Cache will by default look up VCL files using relative +# paths not found in its sysconfdir (by default /etc/vinyl). The pkgvcldir on # the other hand is a recommended location for your package's VCL files, it # defaults to "${vcldir}/${PACKAGE}". # @@ -674,15 +674,15 @@ AC_DEFUN([VINYL_UTILITIES], [ # AC_DEFUN([VINYL_PREREQ], [ AC_REQUIRE([_VINYL_PKG_CONFIG]) - AC_MSG_CHECKING([for Varnish]) + AC_MSG_CHECKING([for Vinyl Cache]) AC_MSG_RESULT([$VINYL_VERSION]) AS_VERSION_COMPARE([$VINYL_VERSION], [$1], [ - AC_MSG_ERROR([Varnish version $1 or higher is required.]) + AC_MSG_ERROR([Vinyl Cache version $1 or higher is required.]) ]) test $# -gt 1 && AS_VERSION_COMPARE([$2], [$VINYL_VERSION], [ - AC_MSG_ERROR([Varnish version below $2 is required.]) + AC_MSG_ERROR([Vinyl Cache version below $2 is required.]) ]) ]) From 6c4b240cfaab7a9a0fafe28cdf5cdaf496f8cabf Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Mon, 9 Mar 2026 09:36:09 +0000 Subject: [PATCH 106/196] More s/varnish/vinyl/ --- doc/sphinx/dev-guide/homepage_dogfood.rst | 10 ++-- doc/sphinx/glossary/index.rst | 58 +++++++++++------------ doc/sphinx/index.rst | 24 +++++----- include/vut_options.h | 6 +-- 4 files changed, 49 insertions(+), 49 deletions(-) diff --git a/doc/sphinx/dev-guide/homepage_dogfood.rst b/doc/sphinx/dev-guide/homepage_dogfood.rst index 46e86d8779..02812d2ccb 100644 --- a/doc/sphinx/dev-guide/homepage_dogfood.rst +++ b/doc/sphinx/dev-guide/homepage_dogfood.rst @@ -11,7 +11,7 @@ How our website works The principle of eating your own dogfood is important for software quality, that is how you experience what your users are dealing with, and I am not the least ashamed to admit that several obvious improvements -have happened to Varnish as a result of running the project webserver. +have happened to Vinyl Cache as a result of running the project webserver. But it is also important to externalize what you learn doing so, and therefore I thought I would document here how the projects new "internal @@ -40,7 +40,7 @@ So, dogfood: Obviously FreeBSD. Apart from the obvious reason that I wrote a lot of FreeBSD and can get world-class support by bugging my buddies about it, there -are two equally serious reasons for the Varnish Project to run on +are two equally serious reasons for the Vinyl Cache Project to run on FreeBSD: Dogfood and jails. Vinyl Cache is not "software for Linux", it is software for any @@ -60,7 +60,7 @@ We currently have three jails: * Hitch - runs the `Hitch SSL proxy `_ -* Varnish - You guessed it +* Vinyl Cache - You guessed it * Tools - backend webserver, currently `ACME Labs' thttpd `_ @@ -86,7 +86,7 @@ is, unabridged:: # Configure the host sh build_host.sh |& tee _.bh # Build the jails - foreach i (Tools Hitch Varnish) + foreach i (Tools Hitch Vinyl) (cd $i ; sh build* |& tee _.bj) end @@ -150,7 +150,7 @@ Once it was as I wanted it, I pushed the changes the live machine and then:: git pull cd Tools sh build_j_tools.sh |& tee _.bj - vinyladm vcl.load foobar varnish-live.vcl + vinyladm vcl.load foobar vinyl-live.vcl vinyladm vcl.use foobar For a few minutes our website was a bit slower (because of the diff --git a/doc/sphinx/glossary/index.rst b/doc/sphinx/glossary/index.rst index 2015339371..9bac95edbb 100644 --- a/doc/sphinx/glossary/index.rst +++ b/doc/sphinx/glossary/index.rst @@ -6,8 +6,8 @@ .. _glossary: -Varnish Glossary -================ +Vinyl Cache Glossary +==================== .. glossary:: :sorted: @@ -17,15 +17,15 @@ Varnish Glossary so we keep the source in subject order to make sure we cover all bases. - .. comment: "components of varnish --------------------------------" + .. comment: "components of Vinyl Cache --------------------------------" - varnishd (NB: with 'd') - This is the actual Varnish cache program. There is only + vinyld (NB: with 'd') + This is the main Vinyl Cache program. There is only one program, but when you run it, you will get *two* processes: The "master" and the "worker" (or "child"). master (process) - One of the two processes in the varnishd program. + One of the two processes in the vinyld program. The master process is a manager/nanny process which handles configuration, parameters, compilation of :term:VCL etc. but it does never get near the actual HTTP traffic. @@ -33,38 +33,38 @@ Varnish Glossary worker (process) The worker process is started and configured by the master process. This is the process that does all the work you actually - want varnish to do. If the worker dies, the master will try start + want vinyld to do. If the worker dies, the master will try start it again, to keep your website alive. backend - The HTTP server varnishd is caching for. This can be + The HTTP server vinyld is caching for. This can be any sort of device that handles HTTP requests, including, but not limited to: a webserver, a CMS, a load-balancer - another varnishd, etc. + another vinyld, etc. client - The program which sends varnishd an HTTP request, typically + The program which sends vinyld an HTTP request, typically a browser, but do not forget to think about spiders, robots script-kiddies and criminals. vinylstat - Program which presents varnish statistics counters. + Program which presents Vinyl Cache statistics counters. vinyllog - Program which presents varnish transaction log in native format. + Program which presents Vinyl Cache transaction log in native format. vinyltop Program which gives real-time "top-X" list view of transaction log. vinylncsa - Program which presents varnish transaction log in "NCSA" format. + Program which presents Vinyl Cache transaction log in "NCSA" format. vinylhist Eye-candy program showing response time histogram in 1980s ASCII-art style. - varnishtest - Program to test varnishd's behaviour with, simulates backend + vinyltest + Program to test vinyld's behaviour with, simulates backend and client according to test-scripts. .. comment: "components of traffic ---------------------------------" @@ -73,51 +73,51 @@ Varnish Glossary An HTTP protocol header, like "Accept-Encoding:". request - What the client sends to varnishd and varnishd sends to the backend. + What the client sends to vinyld and vinyld sends to the backend. response - What the backend returns to varnishd and varnishd returns to - the client. When the response is stored in varnishd's cache, + What the backend returns to vinyld and vinyld returns to + the client. When the response is stored in vinyld's cache, we call it an object. backend response The response specifically served from a backend to - varnishd. The backend response may be manipulated in + vinyld. The backend response may be manipulated in vcl_backend_response. body - The bytes that make up the contents of the object, varnishd + The bytes that make up the contents of the object, vinyld does not care if they are in HTML, XML, JPEG or even EBCDIC, - to varnishd they are just bytes. + to vinyld they are just bytes. object - The (possibly) cached version of a backend response. varnishd + The (possibly) cached version of a backend response. vinyld receives a response from the backend and creates an object, from which it may deliver cached responses to clients. If the object is created as a result of a request which is passed, it will not be stored for caching. - .. comment: "configuration of varnishd -----------------------------" + .. comment: "configuration of vinyld -----------------------------" VCL - Varnish Configuration Language, a small specialized language - for instructing Varnish how to behave. + Vinyl Configuration Language, a small specialized language + for instructing vinyld how to behave. .. comment: "actions in VCL ----------------------------------------" hit - An object Varnish delivers from cache. + An object vinyld delivers from cache. miss - An object Varnish fetches from the backend before it is served + An object vinyld fetches from the backend before it is served to the client. The object may or may not be put in the cache, that depends. pass - An object Varnish does not try to cache, but simply fetches + An object vinyld does not try to cache, but simply fetches from the backend and hands to the client. pipe - Varnish just moves the bytes between client and backend, it + vinyld just moves the bytes between client and backend, it does not try to understand what they mean. diff --git a/doc/sphinx/index.rst b/doc/sphinx/index.rst index 0e1570fa8c..940039ecd5 100644 --- a/doc/sphinx/index.rst +++ b/doc/sphinx/index.rst @@ -4,49 +4,49 @@ See LICENSE file for full text of license -Varnish Documentation -===================== +Vinyl Cache Documentation +========================= -Varnish Cache is a web application accelerator also known as a caching HTTP +Vinyl Cache is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and -configure it to cache the contents. Varnish Cache is really, really fast. It +configure it to cache the contents. Vinyl Cache is really, really fast. It typically speeds up delivery with a factor of 300 - 1000x, depending on your architecture. -To get started with Varnish-Cache we recommend that you read the installation -guide :ref:`install-index`. Once you have Varnish up and running we recommend +To get started with Vinyl Cache we recommend that you read the installation +guide :ref:`install-index`. Once you have Vinyl Cache up and running we recommend that you go through our tutorial - :ref:`tutorial-index`, and finally the :ref:`users-guide-index`. -If you need to find out how to use a specific Varnish tool, the +If you need to find out how to use a specific Vinyl Cache tool, the :ref:`reference-index` contains detailed documentation over the tools. Changes from previous versions are located in the :ref:`whats-new-index` chapter. In closing, we have :ref:`phk`, a collection of blog posts from Poul-Henning Kamp -related to Varnish and HTTP. +related to Vinyl Cache and HTTP. Conventions used in this manual include: - ``service varnish restart`` + ``service vinyl restart`` A command you can run, or a shortkey you can press. Used either in the terminal or after starting one of the tools. `/usr/local/`, `vinyladm`, `sess_timeout` - A utility, Varnish configurable parameter or path. + A utility, Vinyl configurable parameter or path. https://www.vinyl-cache.org/ A hyperlink. Longer listings like example command output and VCL look like this:: - $ /opt/varnish/sbin/varnishd -V + $ /opt/vinyl/sbin/vinyld -V varnishd (varnish-8.0.0 revision 1234567) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2025 Varnish Software .. For maintainers: -.. * always write Varnish with a capital V: Varnish, Varnish Cache. +.. * always write Vinyl Cache with a capital V&C: Vinyl Cache. .. * Write Varnish tools as their executable name: `vinyld`, `vinyladm`. .. * if part of a command actually runable by the reader, use double backticks: .. ``varnishd -f foo.c`` diff --git a/include/vut_options.h b/include/vut_options.h index 50b9837661..0fe7c68980 100644 --- a/include/vut_options.h +++ b/include/vut_options.h @@ -69,8 +69,8 @@ ) #define VUT_OPT_n \ - VOPT("n:", "[-n ]", "varnish working directory", \ - "Specify the varnish working directory of the instance " \ + VOPT("n:", "[-n ]", "vinyl working directory", \ + "Specify the vinyl working directory of the instance " \ "to attach to. See :ref:`vinyld(1)` ``-n`` option " \ "documentation for additional information and defaults." \ ) @@ -106,6 +106,6 @@ " attempted only once and will fail immediately if" \ " unsuccessful. If set to \"off\", the connection will not" \ " fail, allowing the utility to start and wait" \ - " indefinitely for the Varnish instance to appear. " \ + " indefinitely for the `vinyld` instance to appear. " \ " Defaults to 5 seconds." \ ) From 65b55628b8de41115cf25410d916087505996585 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Mon, 9 Mar 2026 10:11:19 +0000 Subject: [PATCH 107/196] More s/varnish/vinyl/ --- README.Packaging | 7 +- bin/vinyld/mgt/mgt_param.c | 8 +-- doc/sphinx/index.rst | 6 +- doc/sphinx/installation/index.rst | 4 +- doc/sphinx/installation/install.rst | 24 ++----- doc/sphinx/reference/states.rst | 10 +-- doc/sphinx/reference/vcl-backend.rst | 2 +- doc/sphinx/reference/vcl-probe.rst | 4 +- doc/sphinx/reference/vcl-step.rst | 2 +- doc/sphinx/reference/vcl-var.rst | 6 +- doc/sphinx/reference/vcl.rst | 30 ++++---- doc/sphinx/reference/vcl_var.rst | 26 +++---- doc/sphinx/reference/vinylhist.rst | 2 +- doc/sphinx/reference/vinyllog.rst | 2 +- doc/sphinx/reference/vinyltop.rst | 2 +- doc/sphinx/reference/vsl-query.rst | 18 ++--- doc/sphinx/reference/vsl.rst | 18 ++--- doc/sphinx/reference/vtc.rst | 16 ++--- doc/sphinx/reference/vtla.rst | 100 +++++++++++++-------------- doc/sphinx/users-guide/run_cli.rst | 20 +++--- include/tbl/vsl_tags.h | 8 +-- include/vsc_priv.h | 2 +- vmod/vmod_blob.vcc | 12 ++-- vmod/vmod_cookie.vcc | 6 +- vmod/vmod_debug.vcc | 2 +- vmod/vmod_directors.vcc | 32 ++++----- vmod/vmod_h2.vcc | 2 +- vmod/vmod_proxy.vcc | 2 +- vmod/vmod_purge.vcc | 2 +- vmod/vmod_std.vcc | 18 ++--- vmod/vmod_unix.vcc | 6 +- vmod/vmod_vtc.vcc | 10 +-- 32 files changed, 192 insertions(+), 217 deletions(-) diff --git a/README.Packaging b/README.Packaging index b15c3efc1b..9591984b57 100644 --- a/README.Packaging +++ b/README.Packaging @@ -1,7 +1,7 @@ Packaging ========= -Varnish Cache packaging files are kept outside of the main distribution. +Vinyl Cache packaging files are kept outside of the main distribution. The main reason for this is to decouple the development work from the packaging work. @@ -12,9 +12,6 @@ to wait for the packagers to finish their work/changes. Official packages ----------------- -The official Debian and Redhat packages are built by the Varnish Cache team -and made available on https://packagecloud.io/varnishcache/ . - Packaging files and scripts for Debian and Redhat: https://code.vinyl-cache.org/vinyl-cache/pkg-vinyl-cache @@ -23,5 +20,5 @@ Packaging files and scripts for Debian and Redhat: Third-party packages -------------------- -Varnish Cache is built and packaged in many different operating systems and +Vinyl Cache is built and packaged in many different operating systems and distributions. Please see https://vinyl-cache.org/ for more information. diff --git a/bin/vinyld/mgt/mgt_param.c b/bin/vinyld/mgt/mgt_param.c index 75491f695a..39d00cdb3a 100644 --- a/bin/vinyld/mgt/mgt_param.c +++ b/bin/vinyld/mgt/mgt_param.c @@ -102,7 +102,7 @@ static const char PROTECTED_TEXT[] = static const char ONLY_ROOT_TEXT[] = "\n\n" - "NB: This parameter only works if varnishd is run as root."; + "NB: This parameter only works if vinyld is run as root."; static const char NOT_IMPLEMENTED_TEXT[] = "\n\n" @@ -117,7 +117,7 @@ static const char PLATFORM_DEPENDENT_TEXT[] = static const char BUILD_OPTIONS_TEXT[] = "\n\n" "NB: The actual default value for this parameter depends on the" - " Varnish build environment and options."; + " Vinyl Cache build environment and options."; /*--------------------------------------------------------------------*/ @@ -782,7 +782,7 @@ MCF_InitParams(struct cli *cli) * Adjust default parameters for 32 bit systems to conserve * VM space. * - * Reflect changes in doc/sphinx/reference/varnishd.rst ! + * Reflect changes in doc/sphinx/reference/vinyld.rst ! */ MCF_ParamConf(MCF_DEFAULT, "workspace_client", "24k"); MCF_ParamConf(MCF_DEFAULT, "workspace_backend", "20k"); @@ -872,7 +872,7 @@ MCF_DumpRstParam(void) size_t z; printf("\n.. The following is the autogenerated " - "output from varnishd -x parameter\n\n"); + "output from vinyld -x parameter\n\n"); VTAILQ_FOREACH(pl, &phead, list) { pp = pl->spec; if (!strcmp("deprecated_dummy", pp->name)) diff --git a/doc/sphinx/index.rst b/doc/sphinx/index.rst index 940039ecd5..df15821552 100644 --- a/doc/sphinx/index.rst +++ b/doc/sphinx/index.rst @@ -40,16 +40,16 @@ Conventions used in this manual include: Longer listings like example command output and VCL look like this:: $ /opt/vinyl/sbin/vinyld -V - varnishd (varnish-8.0.0 revision 1234567) + vinyld (vinyl-8.0.0 revision 1234567) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2025 Varnish Software .. For maintainers: .. * always write Vinyl Cache with a capital V&C: Vinyl Cache. -.. * Write Varnish tools as their executable name: `vinyld`, `vinyladm`. +.. * Write Vinyl tools as their executable name: `vinyld`, `vinyladm`. .. * if part of a command actually runable by the reader, use double backticks: -.. ``varnishd -f foo.c`` +.. ``vinyld -f foo.c`` .. * wrap lines at 80 characters, ident with 4 spaces. No tabs, please. .. We use the following header indicators .. For titles: diff --git a/doc/sphinx/installation/index.rst b/doc/sphinx/installation/index.rst index 254172ae81..9587d1edf5 100644 --- a/doc/sphinx/installation/index.rst +++ b/doc/sphinx/installation/index.rst @@ -5,8 +5,8 @@ .. _install-index: -Varnish Installation -==================== +Vinyl Cache Installation +======================== This section covers installation prerequisites, a step-by-step installation procedure, how and where to get help, and how to report diff --git a/doc/sphinx/installation/install.rst b/doc/sphinx/installation/install.rst index 3033ffbde7..e4dc727e27 100644 --- a/doc/sphinx/installation/install.rst +++ b/doc/sphinx/installation/install.rst @@ -5,8 +5,8 @@ .. _install-doc: -Installing Varnish -================== +Installing Vinyl Cache +====================== .. no section heading here. @@ -27,8 +27,8 @@ is highly operating system specific: install_openbsd install_redhat -Compiling Varnish from source -============================= +Compiling Vinyl Cache from source +================================= If there are no binary packages available for your system, or if you want to compile Varnish from source for other reasons: @@ -38,17 +38,7 @@ want to compile Varnish from source for other reasons: install_source -Other pre-built Varnish packages -================================ - -Here is a list of the ones we know about: - -* `ArchLinux package`_ and `ArchLinux wiki`_ -* `Alpine Linux`_ -* `UPLEX Packages`_ with various vmods for Debian, Ubuntu and RHEL/CentOS - -.. _`ArchLinux package`: https://www.archlinux.org/packages/extra/x86_64/varnish/ -.. _`ArchLinux wiki`: https://wiki.archlinux.org/index.php/Varnish -.. _`Alpine Linux`: https://pkgs.alpinelinux.org/package/edge/main/x86_64/varnish -.. _`UPLEX Packages`: https://pkg.uplex.de/ +Other pre-built Vinyl-Cache packages +==================================== +We will update this as things appear after the name change. diff --git a/doc/sphinx/reference/states.rst b/doc/sphinx/reference/states.rst index 2a4cbbacce..634b18eab7 100644 --- a/doc/sphinx/reference/states.rst +++ b/doc/sphinx/reference/states.rst @@ -5,17 +5,17 @@ .. _reference-states: -========================= -Varnish Processing States -========================= +============================= +Vinyl Cache Processing States +============================= ------------ Introduction ------------ -Varnish processing of client and backend requests is implemented as +Vinyl Cache processing of client and backend requests is implemented as state machines. Whenever a state is entered, a C function is called, -which in turn calls the appropriate Varnish core code functions to +which in turn calls the appropriate Vinyl Cache 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_steps`). diff --git a/doc/sphinx/reference/vcl-backend.rst b/doc/sphinx/reference/vcl-backend.rst index c44cbc6a08..79994d7d33 100644 --- a/doc/sphinx/reference/vcl-backend.rst +++ b/doc/sphinx/reference/vcl-backend.rst @@ -253,7 +253,7 @@ Kristian Lyngstøl, Lasse Karstensen and others. COPYRIGHT --------- -This document is licensed under the same license as Varnish +This document is licensed under the same license as Vinyl Cache itself. See LICENSE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vcl-probe.rst b/doc/sphinx/reference/vcl-probe.rst index 2c35b269a4..41791f05ce 100644 --- a/doc/sphinx/reference/vcl-probe.rst +++ b/doc/sphinx/reference/vcl-probe.rst @@ -132,7 +132,7 @@ In the CLI, a good backend health status looks like this: .. code-block:: text - varnish> backend.list -p boot.backend + vinyl> backend.list -p boot.backend Backend name Admin Probe Health Last change boot.backend probe 5/5 healthy Wed, 13 Jan 2021 10:31:50 GMT Current states good: 5 threshold: 4 window: 5 @@ -199,7 +199,7 @@ Kristian Lyngstøl, Lasse Karstensen and others. COPYRIGHT ========= -This document is licensed under the same license as Varnish +This document is licensed under the same license as Vinyl Cache itself. See LICENSE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vcl-step.rst b/doc/sphinx/reference/vcl-step.rst index 3945bfd4d9..128af43817 100644 --- a/doc/sphinx/reference/vcl-step.rst +++ b/doc/sphinx/reference/vcl-step.rst @@ -145,7 +145,7 @@ SEE ALSO COPYRIGHT ========= -This document is licensed under the same license as Varnish +This document is licensed under the same license as Vinyl Cache itself. See LICENSE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vcl-var.rst b/doc/sphinx/reference/vcl-var.rst index 40f06adf97..595c13f1b9 100644 --- a/doc/sphinx/reference/vcl-var.rst +++ b/doc/sphinx/reference/vcl-var.rst @@ -52,7 +52,7 @@ HTTP response status A HTTP status code has 3 digits XYZ where X must be between 1 and 5 included. Since it is not uncommon to see HTTP clients or servers relying -on non-standard or even invalid status codes, Varnish can work +on non-standard or even invalid status codes, Vinyl Cache can work with any status between 100 and 999. Within VCL code it is even possible to use status codes in the form @@ -90,7 +90,7 @@ status message. 304 handling ~~~~~~~~~~~~ -For a 304 response, Varnish core code amends ``beresp`` before calling +For a 304 response, `vinyld` core code amends ``beresp`` before calling `vcl_backend_response`: * If the gzip status changed, ``Content-Encoding`` is unset and any @@ -176,7 +176,7 @@ Kristian Lyngstøl, Lasse Karstensen and others. COPYRIGHT ========= -This document is licensed under the same license as Varnish +This document is licensed under the same license as Vinyl Cache itself. See LICENSE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vcl.rst b/doc/sphinx/reference/vcl.rst index 30e889e323..91fcbf9c79 100644 --- a/doc/sphinx/reference/vcl.rst +++ b/doc/sphinx/reference/vcl.rst @@ -11,9 +11,9 @@ VCL === ------------------------------- -Varnish Configuration Language ------------------------------- +---------------------------- +Vinyl Configuration Language +---------------------------- :Manual section: 7 @@ -24,17 +24,13 @@ The VCL language is a small domain-specific language designed to be used to describe request handling and document caching policies for Vinyl Cache. -When a new configuration is loaded, the varnishd management process +When a new configuration is loaded, the `vinyld` management process translates the VCL code to C and compiles it to a shared object which is then loaded into the server process. This document focuses on the syntax of the VCL language. For a full description of syntax and semantics, with ample examples, please see -the online documentation at https://www.varnish-cache.org/docs/ . - -Starting with Varnish 4.0, each VCL file must start by declaring its -version with ``vcl`` *.*\ ``;`` marker at the top of -the file. See more about this under Versioning below. +the online documentation at https://www.vinyl-cache.org/docs/ . .. _Identifiers: @@ -56,7 +52,7 @@ Character Sets While identifiers can only consist of this subset of ASCII, **strings** can contain any bytes except *NUL* (zero, 0), which marks the end of the string. The -Varnish Configuration Language itself is not concerned with the character +Vinyl Configuration Language itself is not concerned with the character encoding of strings. VCL code handling strings in different character sets needs to track encodings itself. `VMODs`_ exist to help with such tasks (e.g. ``iconv``). @@ -250,7 +246,7 @@ with their value rounded to 3 decimal places, e.g. ``3.142``. Regular Expressions ------------------- -Varnish uses Perl-compatible regular expressions (PCRE). For a +Vinyl Cache uses Perl-compatible regular expressions (PCRE). For a complete description please see the pcre(3) man page. To send flags to the PCRE engine, such as to do case-insensitive matching, add @@ -279,7 +275,7 @@ The included file can be specified as follows: Optionally, the ``include`` keyword can take a ``+glob`` flag to include all files matching a glob pattern:: - include +glob "/etc/varnish/example.org/*.vcl"; + include +glob "/etc/vinyl/example.org/*.vcl"; Note that the ``+glob`` option can only be used with absolute paths and relative paths starting with './', which means that ``+glob`` includes cannot @@ -288,7 +284,7 @@ be searched in ``vcl_path`` directories. Import statement ---------------- -The ``import`` statement is used to load Varnish Modules (VMODs.) +The ``import`` statement is used to load Vinyl Modules (VMODs.) Example:: @@ -333,7 +329,7 @@ control list which can later be used to match client addresses:: ! "192.0.2.23"; # except for the dial-in router } -If an ACL entry specifies a host name which Varnish is unable to +If an ACL entry specifies a host name which `vinyld` is unable to resolve, it will match any address it is compared to. Consequently, if it is preceded by a negation mark, it will reject any address it is compared to, which may not be what you intended. If the entry is @@ -484,7 +480,7 @@ Multiple subroutines If multiple subroutines with the name of one of the built-in ones are defined, they are concatenated in the order in which they appear in the source. -The built-in VCL distributed with Varnish will be implicitly concatenated +The built-in VCL distributed with Vinyl Cach will be implicitly concatenated when the VCL is compiled. Functions @@ -556,7 +552,7 @@ not have surprises in the future. The syntax version set in an included file only applies to that file and any files it includes - unless these set their own VCL syntax version. -The version of Varnish this file belongs to supports syntax 4.0 and 4.1. +The version of Vinyl Cache this file belongs to supports syntax 4.0 and 4.1. EXAMPLES @@ -586,7 +582,7 @@ Kristian Lyngstøl, Lasse Karstensen and others. COPYRIGHT ========= -This document is licensed under the same license as Varnish +This document is licensed under the same license as Vinyl Cache itself. See LICENSE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vcl_var.rst b/doc/sphinx/reference/vcl_var.rst index e3766688b6..9f873901a2 100644 --- a/doc/sphinx/reference/vcl_var.rst +++ b/doc/sphinx/reference/vcl_var.rst @@ -12,21 +12,21 @@ local, server, remote and client -------------------------------- These variables describe the network connection between the -client and varnishd. +client and `vinyld`. Without PROXY protocol:: client server remote local v v - CLIENT ------------ VARNISHD + CLIENT ------------ VINYLD With PROXY protocol:: client server remote local v v v v - CLIENT ------------ PROXY ------------ VARNISHD + CLIENT ------------ PROXY ------------ VINYLD .. _client.identity: @@ -83,7 +83,7 @@ server.identity The identity of the server, as set by the ``-i`` parameter. - If an ``-i`` parameter is not passed to varnishd, the return + If an ``-i`` parameter is not passed to `vinyld`, the return value from `gethostname(3)` system function will be used. @@ -246,7 +246,7 @@ req.filters Writable from: vcl_recv - List of Varnish Fetch Processor (VFP) filters the req.body + List of Vinyl Fetch Processor (VFP) filters the req.body will be pulled through. The order left to right signifies processing from client to cache, iow the leftmost filter is run first on the body as received from the client after @@ -919,7 +919,7 @@ bereq.retry_connect Writable from: backend Default: ``true``. - Controls whether Varnish will make a second attempt to connect to the + Controls whether `vinyld` will make a second attempt to connect to the backend if a first connection reuse attempt failed. Setting to ``false`` means that no retries will be made. However, setting this to ``true`` does not guarantee that a retry will always be attempted, as there are @@ -1161,7 +1161,7 @@ beresp.do_stream Default: ``true``. Deliver the object to the client while fetching the whole - object into varnish. + object into `vinyld`. For uncacheable objects, storage for parts of the body which have been sent to the client may get freed early, depending @@ -1181,7 +1181,7 @@ beresp.filters Writable from: vcl_backend_response - List of Varnish Fetch Processor (VFP) filters the beresp.body + List of Vinyl Fetch Processor (VFP) filters the beresp.body will be pulled through. The order left to right signifies processing from backend to cache, iow the leftmost filter is run first on the body as received from the backend after @@ -1191,7 +1191,7 @@ beresp.filters being handed to the client side, where it may get processed again by resp.filters. - The following VFP filters exist in varnish-cache: + The following VFP filters exist in Vinyl Cache: * ``gzip``: compress a body using gzip @@ -1367,7 +1367,7 @@ beresp.storage The storage backend to use to save this object. If - none is set, Varnish will pick a storage backend in a + none is set, `vinyld` will pick a storage backend in a round-robin fashion, or the `Transient` backend if the object is short-lived. @@ -1845,7 +1845,7 @@ resp.do_esi ``VCL >= 4.1`` This can be used to selectively disable ESI processing, even though ESI parsing happened during fetch (see beresp.do_esi). - This is useful when Varnish caches peer with each other. + This is useful when Vinyl Caches peer with each other. It is a VCL error to use resp.do_esi after setting resp.filters. @@ -1863,7 +1863,7 @@ resp.filters List of VDP filters the resp.body will be pushed through. Before resp.filters is set, the value read will be the default - filter list as determined by varnish based on resp.do_esi and + filter list as determined by `vinyld` based on resp.do_esi and request headers. After resp.filters is set, changing any of the conditions @@ -2028,7 +2028,7 @@ now sess ---- -A session corresponds to the "conversation" that Varnish has with a +A session corresponds to the "conversation" that `vinyld` has with a single client connection, over which one or more request/response transactions may take place. It may comprise the traffic over an HTTP/1 keep-alive connection, or the multiplexed traffic over an diff --git a/doc/sphinx/reference/vinylhist.rst b/doc/sphinx/reference/vinylhist.rst index 76776246d5..1df01ce69d 100644 --- a/doc/sphinx/reference/vinylhist.rst +++ b/doc/sphinx/reference/vinylhist.rst @@ -56,7 +56,7 @@ Dag-Erling Smørgrav. COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinyl Cache itself. See LICENCE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vinyllog.rst b/doc/sphinx/reference/vinyllog.rst index 518514e23d..5b9e808406 100644 --- a/doc/sphinx/reference/vinyllog.rst +++ b/doc/sphinx/reference/vinyllog.rst @@ -64,7 +64,7 @@ Smørgrav, and later updated by Per Buer and Martin Blix Grydeland. COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinyl Cache itself. See LICENCE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vinyltop.rst b/doc/sphinx/reference/vinyltop.rst index 4fb2a4e52b..4fbccb3f64 100644 --- a/doc/sphinx/reference/vinyltop.rst +++ b/doc/sphinx/reference/vinyltop.rst @@ -72,7 +72,7 @@ Grydeland. COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinyl Cache itself. See LICENCE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vsl-query.rst b/doc/sphinx/reference/vsl-query.rst index f5e70ee74c..753cc52794 100644 --- a/doc/sphinx/reference/vsl-query.rst +++ b/doc/sphinx/reference/vsl-query.rst @@ -11,17 +11,17 @@ vsl-query ========= ------------------------------ -Varnish VSL Query Expressions ------------------------------ +--------------------------------- +Vinyl Cache VSL Query Expressions +--------------------------------- :Manual section: 7 OVERVIEW ======== -The Varnish VSL Query Expressions extracts transactions from the -Varnish shared memory log, and perform queries on the transactions +The Vinyl Cache VSL Query Expressions extracts transactions from the +Vinyl Cache shared memory log, and perform queries on the transactions before reporting matches. A transaction is a set of log lines that belongs together, e.g. a @@ -101,11 +101,11 @@ MEMORY USAGE The API will use pointers to shared memory log data as long as possible to keep memory usage at a minimum. But as the shared memory log is a ring buffer, data will get overwritten eventually, so the API -creates local copies of referenced log data when varnishd comes close +creates local copies of referenced log data when `vinyld` comes close to overwriting still unreported content. This process avoids loss of log data in many scenarios, but it is not -failsafe: Overruns where varnishd "overtakes" the log reader process +failsafe: Overruns where `vinyld` "overtakes" the log reader process in the ring buffer can still happen when API clients cannot keep up reading and/or copying, for instance due to output blocking. @@ -143,7 +143,7 @@ them. For example this list of queries:: - # catch varnish errors + # catch `vinyld` errors *Error # catch backend errors @@ -343,7 +343,7 @@ by others. COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinyl Cache itself. See LICENCE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vsl.rst b/doc/sphinx/reference/vsl.rst index 10a255e713..dc78b02ff1 100644 --- a/doc/sphinx/reference/vsl.rst +++ b/doc/sphinx/reference/vsl.rst @@ -11,18 +11,18 @@ VSL === ------------------------------ -Varnish Shared Memory Logging ------------------------------ +--------------------------------- +Vinyl Cache Shared Memory Logging +--------------------------------- :Manual section: 7 OVERVIEW ======== -This document describes the format and content of all the Varnish shared memory +This document describes the format and content of all the Vinyl Cache shared memory logging tags. These tags are used by the vinyllog(1), vinyltop(1), etc. -logging tools supplied with Varnish. +logging tools supplied with Vinyl Cache. VSL tags ~~~~~~~~ @@ -38,7 +38,7 @@ which event was completed. The reported fields show the absolute time of the event, the time spent since the start of the task and the time spent since the last timestamp was logged. -The timestamps logged automatically by Varnish are inserted after +The timestamps logged automatically by `vinyld` are inserted after completing events that are expected to have delays (e.g. network IO or spending time on a waitinglist). Timestamps can also be inserted from VCL using the std.timestamp() function. If one is doing time consuming @@ -78,7 +78,7 @@ Restart Reset The client closed its connection, reset its stream or caused - a stream error that forced Varnish to reset the stream. Request + a stream error that forced `vinyld` to reset the stream. Request processing is interrupted and considered failed, with a 408 "Request Timeout" status code. @@ -136,7 +136,7 @@ NOTICE MESSAGES Notice messages contain informational messages about the handling of a request. These can be exceptional circumstances encountered that causes deviation from the normal handling. The messages are prefixed with ``vsl:`` -for core Varnish generated messages, and VMOD authors are encouraged to +for core `vinyld` generated messages, and VMOD authors are encouraged to use ``vmod_:`` for their own notice messages. This matches the name of the manual page where detailed descriptions of notice messages are expected. @@ -185,7 +185,7 @@ SEE ALSO COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinyl Cache itself. See LICENCE for details. * Copyright (c) 2006 Verdens Gang AS diff --git a/doc/sphinx/reference/vtc.rst b/doc/sphinx/reference/vtc.rst index 16a6f5b645..9f4ccaa2c2 100644 --- a/doc/sphinx/reference/vtc.rst +++ b/doc/sphinx/reference/vtc.rst @@ -11,18 +11,18 @@ VTC === ------------------------- -Varnish Test Case Syntax ------------------------- +---------------------------- +Vinyl Cache Test Case Syntax +---------------------------- :Manual section: 7 OVERVIEW ======== -This document describes the syntax used by Varnish Test Cases files (.vtc). +This document describes the syntax used by Vinyl Cache Test Cases files (.vtc). A vtc file describe a scenario with different scripted HTTP-talking entities, -and generally one or more Varnish instances to test. +and generally one or more Vinyl Cache instances to test. PARSING ======= @@ -95,7 +95,7 @@ Built-in macros The first IP address that resolves to "localhost". ``${pwd}`` - The working directory from which ``varnishtest`` was executed. + The working directory from which ``vinyltest`` was executed. ``${string,[,...]}`` The ``string`` macro is the entry point for text generation, it takes @@ -114,7 +114,7 @@ Built-in macros absolute path to the working directory is needed. ``${topbuild}`` - Only present when the ``-i`` option is used, to work on Varnish itself + Only present when the ``-i`` option is used, to work on Vinyl Cache itself instead of a regular installation. SYNTAX @@ -136,7 +136,7 @@ SEE ALSO COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinyl Cache itself. See LICENCE for details. * Copyright (c) 2006-2016 Varnish Software AS diff --git a/doc/sphinx/reference/vtla.rst b/doc/sphinx/reference/vtla.rst index 2f847f0b72..5af126cd82 100644 --- a/doc/sphinx/reference/vtla.rst +++ b/doc/sphinx/reference/vtla.rst @@ -7,9 +7,9 @@ .. _vtla: -==================================== -VTLA - Varnish Three Letter Acronyms -==================================== +================================== +VTLA - Vinyl Three Letter Acronyms +================================== Very early in the project, we made a fortunate bargain on eBay, buying up a batch of 676 three letter acronyms, all starting with @@ -19,133 +19,133 @@ This page tells you what we use them for, if & when we remember to add them... VAV - Varnish Arg Vector -- Argv parsing. + Vinyl Arg Vector -- Argv parsing. VBE - Varnish Back End -- Code for contacting backends - (bin/varnishd/cache_backend.c) + Vinyl Back End -- Code for contacting backends + (bin/Vinyld/cache_backend.c) VBP - Varnish Backend Polling -- Health checks of backends - (bin/varnishd/cache_backend_poll.c) + Vinyl Backend Polling -- Health checks of backends + (bin/Vinyld/cache_backend_poll.c) VCA - Varnish Connection Acceptor -- The code that receives/accepts the - TCP connections (bin/varnishd/cache_acceptor.c) + Vinyl Connection Acceptor -- The code that receives/accepts the + TCP connections (bin/Vinyld/cache_acceptor.c) VCC VCL to C Compiler -- The code that compiles VCL to C code. (lib/libvcl) VCF - Varnish CatFlap + Vinyl CatFlap VCL - Varnish Configuration Language -- The domain-specific programming - language used for configuring a varnishd. + Vinyl Configuration Language -- The domain-specific programming + language used for configuring a Vinyld. VCT - Varnish CType(3) -- Character classification for RFC2616 and XML parsing. + Vinyl CType(3) -- Character classification for RFC2616 and XML parsing. VDD - Varnish (Core) Developer Day -- Quarterly invite-only meeting strictly - for Varnish core (C) developers, packagers and VMOD hackers. + Vinyl (Core) Developer Day -- Quarterly invite-only meeting strictly + for Vinyl core (C) developers, packagers and VMOD hackers. VENC - Varnish ENCoding -- base64 functions + Vinyl ENCoding -- base64 functions VEND - Varnish ENDianess -- functions to marshall data in specified endianness + Vinyl ENDianess -- functions to marshall data in specified endianness VEV - Varnish EVent -- library functions to implement a simple event-dispatcher. + Vinyl EVent -- library functions to implement a simple event-dispatcher. VEXT - Varnish Extension -- Shared library loaded into the child process. + Vinyl Extension -- Shared library loaded into the child process. VGB - Varnish Governing Board -- May or may not exist. + Vinyl Governing Board -- May or may not exist. If you need to ask, you are not on it. VGC - Varnish Generated Code -- Code generated by VCC from VCL. + Vinyl Generated Code -- Code generated by VCC from VCL. VIN - Varnish Instance Naming -- Resolution of -n arguments. + Vinyl Instance Naming -- Resolution of -n arguments. VLU - Varnish Line Up -- library functions to collect stream of bytes - into lines for processing. (lib/libvarnish/vlu.c) + Vinyl Line Up -- library functions to collect stream of bytes + into lines for processing. (lib/libVinyl/vlu.c) VPI - VCC Private Interface -- functions in varnishd which only VCC is + VCC Private Interface -- functions in Vinyld which only VCC is allowed to call. VRE - Varnish Regular Expression -- library functions for regular expression - based matching and substring replacement. (lib/libvarnish/vre.c) + Vinyl Regular Expression -- library functions for regular expression + based matching and substring replacement. (lib/libVinyl/vre.c) VRT - Varnish Run Time -- functions called from compiled code. - (bin/varnishd/cache_vrt.c) + Vinyl Run Time -- functions called from compiled code. + (bin/Vinyld/cache_vrt.c) VRY VaRY -- Related to processing of Vary: HTTP headers. - (bin/varnishd/cache_vary.c) + (bin/Vinyld/cache_vary.c) VSL - Varnish Shared memory Log -- The log written into the shared - memory segment for varnish{log,ncsa,top,hist} to see. + Vinyl Shared memory Log -- The log written into the shared + memory segment for Vinyl{log,ncsa,top,hist} to see. VSB - Varnish string Buffer -- a copy of the FreeBSD "sbuf" library, + Vinyl string Buffer -- a copy of the FreeBSD "sbuf" library, for safe string handling. VSC - Varnish Statistics Counter -- counters for various stats, - exposed via varnishapi. + Vinyl Statistics Counter -- counters for various stats, + exposed via Vinylapi. VSS - Varnish Session Stuff -- library functions to wrap DNS/TCP. - (lib/libvarnish/vss.c) + Vinyl Session Stuff -- library functions to wrap DNS/TCP. + (lib/libVinyl/vss.c) VTC - Varnish Test Code -- a test-specification for the varnishtest program. + Vinyl Test Code -- a test-specification for the Vinyltest program. VTE - Varnish Turbo Encabulator + Vinyl Turbo Encabulator VTLA - Varnish Three Letter Acronym -- No rule without an exception. + Vinyl Three Letter Acronym -- No rule without an exception. VUG - Varnish User Group meeting -- Half-yearly event where the users and + Vinyl User Group meeting -- Half-yearly event where the users and developers of Vinyl Cache gather to share experiences and plan future development. VUT - Varnish UTilities -- An API for client utilities to tap into VSM or VSC. + Vinyl UTilities -- An API for client utilities to tap into VSM or VSC. VWx - Varnish Waiter 'x' -- A code module to monitor idle sessions. + Vinyl Waiter 'x' -- A code module to monitor idle sessions. VWE - Varnish Waiter Epoll -- epoll(2) (linux) based waiter module. + Vinyl Waiter Epoll -- epoll(2) (linux) based waiter module. VWK - Varnish Waiter Kqueue -- kqueue(2) (freebsd) based waiter module. + Vinyl Waiter Kqueue -- kqueue(2) (freebsd) based waiter module. VWP - Varnish Waiter Poll -- poll(2) based waiter module. + Vinyl Waiter Poll -- poll(2) based waiter module. VWS - Varnish Waiter Solaris -- Solaris ports(2) based waiter module. + Vinyl Waiter Solaris -- Solaris ports(2) based waiter module. COPYRIGHT ========= -This document is licensed under the same licence as Varnish +This document is licensed under the same licence as Vinyl itself. See LICENCE for details. -* Copyright (c) 2019 Varnish Software AS +* Copyright (c) 2019 Vinyl Software AS diff --git a/doc/sphinx/users-guide/run_cli.rst b/doc/sphinx/users-guide/run_cli.rst index 51100ec380..afb83286eb 100644 --- a/doc/sphinx/users-guide/run_cli.rst +++ b/doc/sphinx/users-guide/run_cli.rst @@ -38,7 +38,7 @@ with command-completion, command-history and other comforts: Type 'quit' to close CLI session. Type 'start' to launch worker process. - varnish> + vinyl> The CLI always returns a three digit status code to tell how things went. @@ -75,7 +75,7 @@ all new requests start out. To load new VCL program:: - varnish> vcl.load some_name some_filename + vinyl> vcl.load some_name some_filename Loading will read the VCL program from the file, and compile it. If the compilation fails, you will get an error messages: @@ -93,12 +93,12 @@ the compilation fails, you will get an error messages: If compilation succeeds, the VCL program is loaded, and you can now make it the active VCL, whenever you feel like it:: - varnish> vcl.use some_name + vinyl> vcl.use some_name If you find out that was a really bad idea, you can switch back to the previous VCL program again:: - varnish> vcl.use old_name + vinyl> vcl.use old_name The switch is instantaneous, all new requests will start using the VCL you activated right away. The requests currently being processed complete @@ -123,7 +123,7 @@ Varnish to stop serving the old logo out of the cache: .. code-block:: text - varnish> ban req.url ~ "logo.*[.]png" + vinyl> ban req.url ~ "logo.*[.]png" should do that, and yes, that is a regular expression. @@ -134,7 +134,7 @@ cache is unaffected. Even when you want to throw out *all* the cached content, banning is both faster and less disruptive that a restart:: - varnish> ban obj.http.date ~ .* + vinyl> ban obj.http.date ~ .* .. In addition to handling such special occasions, banning can be used .. in many creative ways to keep the cache up to date, more about @@ -150,14 +150,14 @@ from the CLI: .. code-block:: text - varnish> param.show prefer_ipv6 + vinyl> param.show prefer_ipv6 200 prefer_ipv6 off [bool] Default is off Prefer IPv6 address when connecting to backends which have both IPv4 and IPv6 addresses. - varnish> param.set prefer_ipv6 true + vinyl> param.set prefer_ipv6 true 200 In general it is not a good idea to modify parameters unless you @@ -176,11 +176,11 @@ Starting and stopping the worker process In general you should just leave the worker process running, but if you need to stop and/or start it, the obvious commands work:: - varnish> stop + vinyl> stop and:: - varnish> start + vinyl> start If you start ``vinyld`` with the '-d' (debugging) argument, you will always need to start the child process explicitly. diff --git a/include/tbl/vsl_tags.h b/include/tbl/vsl_tags.h index f5c754bb10..61d8b82133 100644 --- a/include/tbl/vsl_tags.h +++ b/include/tbl/vsl_tags.h @@ -53,7 +53,7 @@ * kept for now for VSL binary compatibility */ #define NOSUP_NOTICE \ - "NOTE: This tag is currently not in use in the Varnish log.\n" \ + "NOTE: This tag is currently not in use in the Vinyl Cache log.\n" \ "It is mentioned here to document legacy versions of the log,\n" \ "or reserved for possible use in future versions.\n\n" @@ -71,7 +71,7 @@ SLTM(Error, 0, "Error messages", ) SLTM(CLI, 0, "CLI communication", - "CLI communication between varnishd master and child process.\n\n" + "CLI communication between vinyld master and child process.\n\n" ) /*---------------------------------------------------------------------*/ @@ -547,8 +547,8 @@ SLTM(Storage, 0, "Where object is stored", ) SLTM(Timestamp, 0, "Timing information", - "Contains timing information for the Varnish worker threads.\n\n" - "Time stamps are issued by Varnish on certain events," + "Contains timing information for the vinyld worker threads.\n\n" + "Time stamps are issued by vinyld on certain events," " and show the absolute time of the event, the time spent since the" " start of the work unit, and the time spent since the last timestamp" " was logged. See the TIMESTAMPS section below for information about" diff --git a/include/vsc_priv.h b/include/vsc_priv.h index 110e618d2e..8640d00c3a 100644 --- a/include/vsc_priv.h +++ b/include/vsc_priv.h @@ -30,7 +30,7 @@ * * Define the layout of the statistics VSM segments * - * NB: THIS IS NOT A PUBLIC API TO VARNISH! + * NB: THIS IS NOT A PUBLIC API TO VINYL! */ #ifdef VSC_PRIV_H_INCLUDED diff --git a/vmod/vmod_blob.vcc b/vmod/vmod_blob.vcc index cbbc60bb0d..253ec5f907 100644 --- a/vmod/vmod_blob.vcc +++ b/vmod/vmod_blob.vcc @@ -1,5 +1,5 @@ #- -# This document is licensed under the same conditions as Varnish itself. +# This document is licensed under the same conditions as Vinyl Cache itself. # See LICENSE for details. # # SPDX-License-Identifier: BSD-2-Clause @@ -371,7 +371,7 @@ But the `xblob.encode()`_ object method is more efficient -- the encoding is computed once and cached (with allocation in heap memory), and the cached encoding is retrieved on every subsequent call. The `blob.encode()`_ function computes the encoding on every -call, allocating space for the string in Varnish workspaces. +call, allocating space for the string in Vinyl Cache workspaces. So if the data in a BLOB are fixed at VCL initialization time, so that its encodings will always be the same, it is better to create a @@ -414,15 +414,15 @@ from the heap, and hence they are only limited by available virtual memory. The `blob.encode()`_, `blob.decode()`_ and -`blob.transcode()`_ functions allocate Varnish workspace, as does +`blob.transcode()`_ functions allocate Vinyl Cache workspace, as does `blob.sub()`_ for the newly created BLOB. If these functions are -failing, as indicated by "out of space" messages in the Varnish log +failing, as indicated by "out of space" messages in the Vinyl Cache log (with the ``VCL_Error`` tag), then you will need to increase the -varnishd parameters ``workspace_client`` and/or ``workspace_backend``. +`vinyld` parameters ``workspace_client`` and/or ``workspace_backend``. The `blob.transcode()`_ function also allocates space on the stack for a temporary BLOB. If this function causes stack overflow, you may -need to increase the varnishd parameter ``thread_pool_stack``. +need to increase the `vinyld` parameter ``thread_pool_stack``. SEE ALSO ======== diff --git a/vmod/vmod_cookie.vcc b/vmod/vmod_cookie.vcc index cbc133e47f..e5f5a0b0f8 100644 --- a/vmod/vmod_cookie.vcc +++ b/vmod/vmod_cookie.vcc @@ -1,15 +1,15 @@ #- -# This document is licensed under the same conditions as Varnish itself. +# This document is licensed under the same conditions as Vinyl Cache itself. # See LICENSE for details. # # SPDX-License-Identifier: BSD-2-Clause -$Module cookie 3 "Varnish Cookie Module" +$Module cookie 3 "Vinyl Cache Cookie Module" DESCRIPTION =========== -Handle HTTP cookies more easily in Varnish VCL. +Handle HTTP cookies more easily in Vinyl Cache VCL. Parses a cookie header into an internal data store, where per-cookie get/set/delete functions are available. A keep() function removes all diff --git a/vmod/vmod_debug.vcc b/vmod/vmod_debug.vcc index 861ccbcb00..27416cabe5 100644 --- a/vmod/vmod_debug.vcc +++ b/vmod/vmod_debug.vcc @@ -37,7 +37,7 @@ DESCRIPTION =========== This vmod is used to develop, test and debug the various aspects -of VMOD handling in Varnish. +of VMOD handling in Vinyl Cache. $Event event_function diff --git a/vmod/vmod_directors.vcc b/vmod/vmod_directors.vcc index 6941304d47..73e055bd87 100644 --- a/vmod/vmod_directors.vcc +++ b/vmod/vmod_directors.vcc @@ -1,5 +1,5 @@ #- -# This document is licensed under the same licence as Varnish +# This document is licensed under the same licence as Vinyl Cache # itself. See LICENCE for details. # # SPDX-License-Identifier: BSD-2-Clause @@ -37,29 +37,21 @@ # SUCH DAMAGE. $ABI strict -$Module directors 3 "Varnish Directors Module" +$Module directors 3 "Vinyl Cache Directors Module" DESCRIPTION =========== -*vmod_directors* enables backend load balancing in Varnish. +*vmod_directors* enables backend load balancing in Vinyl Cache. The module implements load balancing techniques, and also serves as an example on how one could extend the load balancing capabilities of -Varnish. +Vinyl Cache. To enable load balancing you must import this vmod (directors). Then you define your backends. Once you have the backends declared you -can add them to a director. This happens in executed VCL code. If you -want to emulate the previous behavior of Varnish 3.0 you can just -initialize the directors in ``vcl_init{}``, like this:: - - sub vcl_init { - new vdir = directors.round_robin(); - vdir.add_backend(backend1); - vdir.add_backend(backend2); - } +can add them to a director. This happens in executed VCL code. As you can see there is nothing keeping you from manipulating the directors elsewhere in VCL. So, you could have VCL code that would add @@ -152,7 +144,7 @@ Create a random backend director. The random director distributes load over the backends using a weighted random probability distribution. -The "testable" random generator in varnishd is used, which enables +The "testable" random generator in `vinyld` is used, which enables deterministic tests to be run (See: ``d00004.vtc``). Example:: @@ -257,10 +249,10 @@ Sharding ```````` This basic technique allows for numerous applications like optimizing -backend server cache efficiency, Varnish clustering or persisting +backend server cache efficiency, Vinyl Cache clustering or persisting sessions to servers without keeping any state, and, in particular, without the need to synchronize state between nodes of a cluster of -Varnish servers: +Vinyl Cache servers: * Many applications use caches for data objects, so, in a cluster of application servers, requesting similar objects from the same server @@ -270,7 +262,7 @@ Varnish servers: been shown to drastically improve the efficiency of many content management systems. -* As special case of the previous example, in clusters of Varnish +* As special case of the previous example, in clusters of Vinyl Cache servers without additional request distribution logic, each cache will need store all hot objects, so the effective cache size is approximately the smallest cache size of any server in the cluster. @@ -286,11 +278,11 @@ Varnish servers: such that all requests sharing a certain criterion (such as an IP address or session ID) get forwarded to the same backend server. -When used with clusters of varnish servers, the shard director will, +When used with clusters of Vinyl Cache servers, the shard director will, if otherwise configured equally, make the same decision on all servers. In other words, requests sharing a common criterion used as the shard key will be balanced onto the same backend server(s) no -matter which Varnish server handles the request. +matter which Vinyl Cache server handles the request. The drawbacks are: @@ -457,7 +449,7 @@ is _not_ the order given when backends are added. * ``HASH``: * when called in backend context and in ``vcl_pipe {}``: Use the - varnish hash value as set by ``vcl_hash{}`` + vinyl hash value as set by ``vcl_hash{}`` * when called in client context other than ``vcl_pipe {}``: hash ``req.url`` diff --git a/vmod/vmod_h2.vcc b/vmod/vmod_h2.vcc index 4849cf588d..768ef8bbb3 100644 --- a/vmod/vmod_h2.vcc +++ b/vmod/vmod_h2.vcc @@ -34,7 +34,7 @@ DESCRIPTION =========== This VMOD contains functions to control the HTTP2 transport built into -Varnish-Cache. +Vinyl Cache. $Function BOOL is() $Restrict client diff --git a/vmod/vmod_proxy.vcc b/vmod/vmod_proxy.vcc index c672717646..1151db5d5a 100644 --- a/vmod/vmod_proxy.vcc +++ b/vmod/vmod_proxy.vcc @@ -28,7 +28,7 @@ # SUCH DAMAGE. $ABI strict -$Module proxy 3 "Varnish Module to extract TLV attributes from PROXYv2" +$Module proxy 3 "Vinyl Cache Module to extract TLV attributes from PROXYv2" DESCRIPTION =========== diff --git a/vmod/vmod_purge.vcc b/vmod/vmod_purge.vcc index 7fa7639dad..ca4937001d 100644 --- a/vmod/vmod_purge.vcc +++ b/vmod/vmod_purge.vcc @@ -28,7 +28,7 @@ # SUCH DAMAGE. $ABI strict -$Module purge 3 "Varnish Purge Module" +$Module purge 3 "Vinyl Cache Purge Module" DESCRIPTION =========== diff --git a/vmod/vmod_std.vcc b/vmod/vmod_std.vcc index 6ac3ce9ca1..0768f6f4c7 100644 --- a/vmod/vmod_std.vcc +++ b/vmod/vmod_std.vcc @@ -28,17 +28,17 @@ # SUCH DAMAGE. $ABI strict -$Module std 3 "Varnish Standard Module" +$Module std 3 "Vinyl Cache Standard Module" DESCRIPTION =========== .. note: not using :ref:`vmod_std(3)` because it expands to "VMOD - std - Varnish Standard Module" and here just the plan vmod name + std - Vinyl Cache Standard Module" and here just the plan vmod name makes more sense. *vmod_std* contains basic functions which are part and parcel of -Varnish, but which for reasons of architecture fit better in a VMOD. +Vinyl Cache, but which for reasons of architecture fit better in a VMOD. Numeric functions ================= @@ -47,7 +47,7 @@ $Function REAL random(REAL lo, REAL hi) Returns a random real number between *lo* and *hi*. -This function uses the "testable" random generator in varnishd which +This function uses the "testable" random generator in `vinyld` which enables deterministic tests to be run (See ``debug.srandom`` CLI command). This function should not be used for cryptographic applications. @@ -226,7 +226,7 @@ Returns ``true`` if path or the file pointed to by path exists, Example:: if (std.file_exists("/etc/return_503")) { - return (synth(503, "Varnish is in maintenance")); + return (synth(503, "Vinyl Cache is in maintenance")); } @@ -483,7 +483,7 @@ $Function VOID timestamp(STRING s) Introduces a timestamp in the log with the current time, using the string *s* as the label. This is useful to time the execution of lengthy VCL subroutines, and makes the timestamps inserted automatically by -Varnish more accurate. +Vinyl Cache more accurate. Example:: @@ -525,10 +525,10 @@ $Restrict vcl_recv $Function VOID late_100_continue(BOOL late) -Controls when varnish reacts to an ``Expect: 100-continue`` client +Controls when `vinyld` reacts to an ``Expect: 100-continue`` client request header. -Varnish always generates a ``100 Continue`` response if requested by +Vinyl Cache always generates a ``100 Continue`` response if requested by the client trough the ``Expect: 100-continue`` header when waiting for request body data. @@ -652,7 +652,7 @@ The format of *STRING* is:: Either a literal string or a regular expression. Note that ** does not use any of the string delimiters like ``"`` or ``{"``\ *...*\ ``"}`` or ``"""``\ *...*\ ``"""`` used elsewhere - in varnish. To match against strings containing whitespace, + in Vinyl Cache. To match against strings containing whitespace, regular expressions containing ``\s`` can be used. * for duration fields: diff --git a/vmod/vmod_unix.vcc b/vmod/vmod_unix.vcc index b0100fd693..f5da321f53 100644 --- a/vmod/vmod_unix.vcc +++ b/vmod/vmod_unix.vcc @@ -1,5 +1,5 @@ #- -# This document is licensed under the same conditions as Varnish itself. +# This document is licensed under the same conditions as Vinyl Cache itself. # See LICENSE for details. # # SPDX-License-Identifier: BSD-2-Clause @@ -15,7 +15,7 @@ DESCRIPTION This VMOD provides information about the credentials of the peer process (user and group of the process owner) that is connected to a -Varnish listener via a Unix domain socket, if the platform supports +Vinyl Cache listener via a Unix domain socket, if the platform supports it. Examples:: @@ -57,7 +57,7 @@ one of the following: * `getpeerucred(3C)` (SunOS and descendants) On SunOS and friends, the ``PRIV_PROC_INFO`` privilege set is added to -the Varnish child process while the VMOD is loaded, see +the `vinyld` child process while the VMOD is loaded, see `setppriv(2)`. On most platforms, the value returned is the effective user or group diff --git a/vmod/vmod_vtc.vcc b/vmod/vmod_vtc.vcc index a4cd55d46e..806ba89513 100644 --- a/vmod/vmod_vtc.vcc +++ b/vmod/vmod_vtc.vcc @@ -29,18 +29,18 @@ # NB: Default to strict $ABI handling, so that path is tested in vmodtool.py -$Module vtc 3 "Utility module for varnishtest" +$Module vtc 3 "Utility module for vinyltest" DESCRIPTION =========== The goal for this VMOD is to provide VCL users and VMOD authors means to -test corner cases or reach certain conditions with varnishtest. +test corner cases or reach certain conditions with ``vinyltest``. $Function VOID barrier_sync(STRING addr, DURATION timeout = 0) When writing test cases, the most common pattern is to start a mock server -instance, a Varnish instance, and spin up a mock client. Those entities run +instance, a Vinyl Cache instance, and spin up a mock client. Those entities run asynchronously, and others exist like background processes (``process``) or log readers (``logexpect``). While you can synchronize with individual entities and wait for their completion, you must use a barrier if you need @@ -174,7 +174,7 @@ VSL === These functions allow to generate arbitrary log entries to test the -Varnish Shared Log (VSL) implementation and readers like vinyllog. +Vinyl Cache Shared Log (VSL) implementation and readers like vinyllog. $Function VOID vsl(INT vxid, STRING tag, ENUM { c, b } side, STRANDS s) @@ -190,7 +190,7 @@ $Function VOID vsl_replay(STRANDS s) Replay literal log lines. The parser accepts the output generated by ``vinyllog -g raw`` and -varnishtest log ``vsl|`` lines. +``vinyltest log`` ``vsl|`` lines. Unparseable lines are silently ignored. From 98744f02332bdb9944dffdac3986527108661018 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Mon, 9 Mar 2026 10:41:23 +0000 Subject: [PATCH 108/196] Always, explicitly, give varnishd a -n argument. --- bin/vinyltest/tests/b00045.vtc | 4 ++-- bin/vinyltest/tests/c00030.vtc | 6 +++--- bin/vinyltest/tests/s00003.vtc | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/bin/vinyltest/tests/b00045.vtc b/bin/vinyltest/tests/b00045.vtc index ad475b8790..c4a1e5a081 100644 --- a/bin/vinyltest/tests/b00045.vtc +++ b/bin/vinyltest/tests/b00045.vtc @@ -15,11 +15,11 @@ client c1 { delay .2 shell -err -expect {Error: Could not open pid-file} { - vinyld -P /dev/tty -b None -a :0 + vinyld -P /dev/tty -b None -a :0 -n ${tmpdir}/v1 } shell -err -expect {Error: vinyld is already running} { - vinyld -P ${v1_name}/vinyld.pid -b None -a :0 + vinyld -P ${v1_name}/vinyld.pid -b None -a :0 -n ${tmpdir}/v1 } shell -err -expect {Error: vinyld is already running} { diff --git a/bin/vinyltest/tests/c00030.vtc b/bin/vinyltest/tests/c00030.vtc index 76914d9685..a47feff76a 100644 --- a/bin/vinyltest/tests/c00030.vtc +++ b/bin/vinyltest/tests/c00030.vtc @@ -1,13 +1,13 @@ vtest "debug storage" shell -err -expect {Error: Only one -sdebug instance supported} \ - "vinyld -b none -a ${tmpdir}/vtc.sock -sdebug -sdebug" + "vinyld -b none -a ${tmpdir}/vtc.sock -n ${tmpdir}/v1 -sdebug -sdebug" shell -err -expect {Error: -sdebug conflicting options} \ - "vinyld -b none -a ${tmpdir}/vtc.sock -sdebug,lessspace,maxspace=1KB" + "vinyld -b none -a ${tmpdir}/vtc.sock -n ${tmpdir}/v1 -sdebug,lessspace,maxspace=1KB" shell -err -expect {Error: Unknown BYTES} \ - "vinyld -b none -a ${tmpdir}/vtc.sock -sdebug,maxspace=1DJT" + "vinyld -b none -a ${tmpdir}/vtc.sock -n ${tmpdir}/v1 -sdebug,maxspace=1DJT" # lessspace is implicitly tested in b00017.vtc diff --git a/bin/vinyltest/tests/s00003.vtc b/bin/vinyltest/tests/s00003.vtc index c54edb3774..9313f44c2f 100644 --- a/bin/vinyltest/tests/s00003.vtc +++ b/bin/vinyltest/tests/s00003.vtc @@ -46,14 +46,14 @@ vinyl v1 -vsl_catchup vinyl v1 -cliok "ban obj.http.date ~ ." process p1 { - vinyld -sTransient=file,${tmpdir}/foo,xxx -b${localhost} -a:0 2>&1 + vinyld -n${tmpdir}/v2 -sTransient=file,${tmpdir}/foo,xxx -b${localhost} -a:0 2>&1 } -expect-exit 0x2 -dump -start -expect-text 0 0 "Invalid number" -wait -screen_dump process p1 { - vinyld -sTransient=file,${tmpdir}/foo,10M,xxx -b${localhost} -a:0 2>&1 + vinyld -n${tmpdir}/v3 -sTransient=file,${tmpdir}/foo,10M,xxx -b${localhost} -a:0 2>&1 } -expect-exit 0x2 -dump -start -expect-text 0 0 "granularity" -wait -screen_dump process p1 { - vinyld -sTransient=file,${tmpdir}/foo,10m,,foo -b${localhost} -a:0 2>&1 + vinyld -n${tmpdir}/v4 -sTransient=file,${tmpdir}/foo,10m,,foo -b${localhost} -a:0 2>&1 } -expect-exit 0x2 -dump -start -expect-text 0 0 "invalid advice" -wait From f354842a82077142934aaf9142d1b22925922bae Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Mon, 9 Mar 2026 11:00:03 +0000 Subject: [PATCH 109/196] Remove beresp.storage_hint, as threathened many years ago. --- bin/vinyld/cache/cache_vrt_var.c | 33 -------------------------------- bin/vinyltest/tests/c00078.vtc | 22 --------------------- doc/sphinx/reference/vcl_var.rst | 16 ---------------- 3 files changed, 71 deletions(-) diff --git a/bin/vinyld/cache/cache_vrt_var.c b/bin/vinyld/cache/cache_vrt_var.c index 8ba04c2f6b..d32b995214 100644 --- a/bin/vinyld/cache/cache_vrt_var.c +++ b/bin/vinyld/cache/cache_vrt_var.c @@ -460,39 +460,6 @@ VRT_l_beresp_storage(VRT_CTX, VCL_STEVEDORE stv) #include "storage/storage.h" -VCL_STRING -VRT_r_beresp_storage_hint(VRT_CTX) -{ - CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); - CHECK_OBJ_NOTNULL(ctx->bo, BUSYOBJ_MAGIC); - if (ctx->bo->storage == NULL) - return (NULL); - CHECK_OBJ_NOTNULL(ctx->bo->storage, STEVEDORE_MAGIC); - return (ctx->bo->storage->vclname); -} - -VCL_VOID -VRT_l_beresp_storage_hint(VRT_CTX, const char *str, VCL_STRANDS s) -{ - const char *p; - VCL_STEVEDORE stv; - - CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); - CHECK_OBJ_NOTNULL(ctx->bo, BUSYOBJ_MAGIC); - - p = VRT_StrandsWS(ctx->ws, str, s); - - if (p == NULL) { - VSLb(ctx->vsl, SLT_LostHeader, "storage_hint"); - WS_MarkOverflow(ctx->ws); - return; - } - - stv = VRT_stevedore(p); - if (stv != NULL) - ctx->bo->storage = stv; -} - /*--------------------------------------------------------------------*/ #define VRT_OC_VAR_R(obj, which, which_magic, field) \ diff --git a/bin/vinyltest/tests/c00078.vtc b/bin/vinyltest/tests/c00078.vtc index 24a45e4c8f..377c005832 100644 --- a/bin/vinyltest/tests/c00078.vtc +++ b/bin/vinyltest/tests/c00078.vtc @@ -17,11 +17,8 @@ vinyl v1 \ set beresp.storage = storage.s1; } else if (bereq.url == "/6") { set beresp.storage = vtc.no_stevedore(); - } else if (bereq.url == "/deprecated") { - set beresp.storage_hint = "s1"; } set beresp.http.storage = beresp.storage; - set beresp.http.storage-hint = beresp.storage_hint; } } -start @@ -29,38 +26,19 @@ client c1 { txreq -url /1 rxresp expect resp.http.storage == "storage.s1" - expect resp.http.storage == resp.http.storage-hint txreq -url /2 rxresp expect resp.http.storage == "storage.s1" - expect resp.http.storage == resp.http.storage-hint txreq -url /3 rxresp expect resp.http.storage == "storage.s0" - expect resp.http.storage == resp.http.storage-hint txreq -url /4 rxresp expect resp.http.storage == "storage.s1" - expect resp.http.storage == resp.http.storage-hint txreq -url /5 rxresp expect resp.http.storage == "storage.s2" - expect resp.http.storage == resp.http.storage-hint txreq -url /6 rxresp expect resp.http.storage == - expect resp.http.storage == resp.http.storage-hint - txreq -url /deprecated - rxresp - expect resp.http.storage == "storage.s1" - expect resp.http.storage == resp.http.storage-hint } -run - -vinyl v1 \ - -syntax 4.1 \ - -errvcl "Only available when VCL syntax <= 4.0" { - import vtc; - sub vcl_backend_response { - set beresp.storage_hint = "foo"; - } -} diff --git a/doc/sphinx/reference/vcl_var.rst b/doc/sphinx/reference/vcl_var.rst index 9f873901a2..3223d3b88a 100644 --- a/doc/sphinx/reference/vcl_var.rst +++ b/doc/sphinx/reference/vcl_var.rst @@ -1371,22 +1371,6 @@ beresp.storage round-robin fashion, or the `Transient` backend if the object is short-lived. -beresp.storage_hint ``VCL <= 4.0`` - - Type: STRING - - Readable from: vcl_backend_response, vcl_backend_error, vcl_backend_refresh - - Writable from: vcl_backend_response, vcl_backend_error, vcl_backend_refresh - - - Deprecated since varnish 5.1 and discontinued since VCL - 4.1 (varnish 6.0). Use beresp.storage instead. - - Hint to Varnish that you want to save this object to a - particular storage backend. - - .. _beresp.time: beresp.time From 827ce5b31f29376d03a0bce2075cc83f631aa726 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Mon, 9 Mar 2026 11:01:05 +0000 Subject: [PATCH 110/196] Ignore the vinyl-cache-trunk.tar.gz file --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 32e2bbfc3f..feb8eca055 100644 --- a/.gitignore +++ b/.gitignore @@ -146,6 +146,9 @@ cscope.*out /cov-int /myproject.tgz +# Source artifact +/vinyl-cache-trunk.tar.gz + # Witness droppings witness.dot witness.svg From 7512afb2b5df3cd97f3fbd882e777fb3c84ba00d Mon Sep 17 00:00:00 2001 From: Walid Boudebouda Date: Mon, 9 Mar 2026 12:31:53 +0100 Subject: [PATCH 111/196] vtc: Stabilize f00007.vtc The only way I found to reproduce the same error reported in #4461 is to send the second data frame after timeout_idle is passed, which causes var^W vinyl to deliver a 400 response due to req body read error. In order to avoid that, the arbitrary 0.5s delay is replaced by a proper synchronization barrier and timeout_idle value is doubled. Refs #4461 --- bin/vinyltest/tests/f00007.vtc | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/bin/vinyltest/tests/f00007.vtc b/bin/vinyltest/tests/f00007.vtc index 968f7dd0ff..fc8a4711f2 100644 --- a/bin/vinyltest/tests/f00007.vtc +++ b/bin/vinyltest/tests/f00007.vtc @@ -1,5 +1,7 @@ vtest "H/2 content length smuggling attack" +barrier b1 cond 2 + server s1 { rxreqhdrs expect_close @@ -12,6 +14,7 @@ server s2 { server s3 { rxreq + barrier b1 sync expect_close } -start @@ -38,6 +41,7 @@ vinyl v1 -vcl+backend { vinyl v1 -cliok "param.set feature +http2" vinyl v1 -cliok "param.set debug +syncvsl" +vinyl v1 -cliok "param.set timeout_idle 10" client c1 { stream 1 { @@ -62,7 +66,7 @@ client c3 { stream 1 { txreq -req POST -url /3 -hdr "content-length" "1" -nostrend txdata -data "A" -nostrend - delay 0.5 + barrier b1 sync txdata -data "GET /FAIL HTTP/1.1\r\n\r\n" rxrst expect rst.err == PROTOCOL_ERROR From ee2ee58d344a086a29a353f7b42ae7b1355ac3f7 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Mon, 9 Mar 2026 11:54:00 +0000 Subject: [PATCH 112/196] Pass -n explicity to vinyld --- bin/vinyltest/tests/p00000.vtc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/vinyltest/tests/p00000.vtc b/bin/vinyltest/tests/p00000.vtc index c23f6955c7..e0130d4cda 100644 --- a/bin/vinyltest/tests/p00000.vtc +++ b/bin/vinyltest/tests/p00000.vtc @@ -3,7 +3,7 @@ vtest "Test Basic persistence" feature persistent_storage process p1 -dump { - vinyld -spersistent -b ${localhost} -a :0 -d 2>&1 + vinyld -spersistent -b ${localhost} -n${tmpdir}/v1 -a :0 -d 2>&1 } -start -expect-exit 1 process p1 -expect-text 0 0 {to launch} From 7f40311d4eab6153534e956e9fb425e227426e2f Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Mon, 9 Mar 2026 12:24:18 +0000 Subject: [PATCH 113/196] Try to stabilize r03159 a bit --- bin/vinyltest/tests/r03159.vtc | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/bin/vinyltest/tests/r03159.vtc b/bin/vinyltest/tests/r03159.vtc index c96f447a03..a2465479de 100644 --- a/bin/vinyltest/tests/r03159.vtc +++ b/bin/vinyltest/tests/r03159.vtc @@ -14,18 +14,13 @@ process p1 -log { -l 2m 2>&1 } -start -expect-exit 0x40 -shell { - # wait for startup vcl.load to complete - vinyladm -n ${tmpdir}/t ping || - vinyladm -n ${tmpdir}/t ping -} - process p1 -screen_dump process p1 -expect-text 0 1 "Unused sub foo, defined:" process p1 -expect-text 0 1 "(That was just a warning)" process p2 -log { set -e + vinyladm -n ${tmpdir}/t ping || (sleep 3 && vinyladm -n ${tmpdir}/t ping) vinyladm -n ${tmpdir}/t "vcl.list" vinyladm -n ${tmpdir}/t -t 20 "vcl.load unref ${tmpdir}/unref.vcl" vinyladm -n ${tmpdir}/t "vcl.list" From 26b69013089d33edd442aeffbbe58d52d239192d Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Wed, 11 Mar 2026 09:14:58 +0000 Subject: [PATCH 114/196] Another round of s/varnish/vinyl/ in doc files --- doc/sphinx/installation/bugs.rst | 55 ++++---- doc/sphinx/reference/directors.rst | 26 ++-- doc/sphinx/reference/shell_tricks.rst | 6 +- doc/sphinx/reference/vcl-backend.rst | 2 +- doc/sphinx/reference/vcl-probe.rst | 2 +- doc/sphinx/reference/vcl-step.rst | 4 +- doc/sphinx/reference/vinyld.rst | 2 +- doc/sphinx/reference/vsm.rst | 36 ++--- doc/sphinx/tutorial/now_what.rst | 4 +- doc/sphinx/tutorial/peculiarities.rst | 20 +-- .../tutorial/putting_vinyl_on_port_80.rst | 38 +++--- doc/sphinx/users-guide/command-line.rst | 20 +-- .../users-guide/increasing-your-hitrate.rst | 126 +++++++++--------- 13 files changed, 172 insertions(+), 169 deletions(-) diff --git a/doc/sphinx/installation/bugs.rst b/doc/sphinx/installation/bugs.rst index fc5f7842ad..9abf2a8335 100644 --- a/doc/sphinx/installation/bugs.rst +++ b/doc/sphinx/installation/bugs.rst @@ -7,7 +7,7 @@ Reporting bugs %%%%%%%%%%%%%% -Varnish can be a tricky beast to debug, having potentially thousands +Vinyl Cache can be a tricky beast to debug, having potentially thousands of threads crowding into a few data structures makes for *interesting* core dumps. @@ -27,25 +27,27 @@ allow us to reproduce. To report a bug please follow the suggested procedure described in the "Trouble Tickets" section of the documentation (above). -Roughly we categorize bugs into three kinds of bugs (described below) with Varnish. The information +Roughly we categorize Vinly Cache bugs into three kinds of bugs, +described below. +The information we need to debug them depends on what kind of bug we are facing. -Varnish crashes -=============== +``Vinyld`` crashes +================== Plain and simple: **boom** -Varnish is split over two processes, the manager and the child. The child -does all the work, and the manager hangs around to resurrect it if it +Vinyld is split over two processes, the manager and the child. The child +does all the work, and the manager hangs around to resurrect it, if it crashes. -Therefore, the first thing to do if you see a Varnish crash, is to examine +Therefore, the first thing to do, if you see a ``vinyld`` crash, is to examine your syslogs to see if it has happened before. (One site is rumoured -to have had Varnish restarting every 10 minutes and *still* provide better +to have had ``vinyld`` restarting every 10 minutes and *still* provide better service than their CMS system.) -When it crashes, which is highly unlikely to begin with, Varnish will spew out a crash dump -that looks something like:: +When it crashes, which is highly unlikely to begin with, +``vinyld`` will spew out a crash dump that looks something like:: Child (32619) died signal=6 (core dumped) Child (32619) Panic message: Assert error in ccf_panic(), cache_cli.c line 153: @@ -70,7 +72,8 @@ If you can get that information to us, we are usually able to see exactly where things went haywire, and that speeds up bugfixing a lot. -There will be a lot more information in the crash dump besides this, and before sending +There will be a lot more information in the crash dump besides this, +and before sending it all to us, you should obscure any sensitive/secret data/cookies/passwords/ip# etc. Please make sure to keep context when you do so, ie: do not change all the IP# to "X.X.X.X", but @@ -81,8 +84,8 @@ The most important line is the "Panic Message", which comes in two general forms: "Missing errorhandling code in ..." - This is a situation where we can conceive Varnish ending up, which we have not - (yet) written the padded-box error handling code for. + This is a situation where we can conceive ``vinyld`` ending up, + which we have not (yet) written the padded-box error handling code for. The most likely cause here, is that you need a larger workspace for HTTP headers and Cookies. @@ -99,25 +102,25 @@ general forms: In your syslog it may all be joined into one single line, but if you can reproduce the crash, do so while running :ref:`vinyld(1)` manually: - ``varnishd -d |& tee /tmp/_catch_bug`` + ``vinyld -d |& tee /tmp/_catch_bug`` That will get you the entire panic message into a file. (Remember to type ``start`` to launch the worker process, that is not automatic when ``-d`` is used.) -Varnish goes on vacation -======================== +``Vinyld`` goes on vacation +=========================== This kind of bug is nasty to debug, because usually people tend to -kill the process and send us an email saying "Varnish hung, I +kill the process and send us an email saying "``vinyld`` hung, I restarted it" which gives us only about 1.01 bit of usable debug information to work with. What we need here is all the information you can squeeze out of -your operating system **before** you kill the Varnish process. +your operating system **before** you kill the ``vinyld`` process. -One of the most valuable bits of information, is if all Varnish' +One of the most valuable bits of information, is if all ``vinyld``'s threads are waiting for something or if one of them is spinning furiously on some futile condition. @@ -129,28 +132,28 @@ able to figure that out. If one or more threads are spinning, use ``strace`` or ``ktrace`` or ``truss`` (or whatever else your OS provides) to get a trace of which system calls -the Varnish process issues. Be aware that this may generate a lot +the ``vinyld`` process issues. Be aware that this may generate a lot of very repetitive data, usually one second worth of data is more than enough. Also, run :ref:`vinyllog(1)` for a second, and collect the output for us, and if :ref:`vinylstat(1)` shows any activity, capture that also. -When you have done this, kill the Varnish *child* process, and let +When you have done this, kill the ``vinyld`` *child* process, and let the *master* process restart it. Remember to tell us if that does -or does not work. If it does not, kill all Varnish processes, and +or does not work. If it does not, kill all Vinyl Cache processes, and start from scratch. If that does not work either, tell us, that means that we have wedged your kernel. -Varnish does something wrong -============================ +``Vinyld`` does something wrong +=============================== These are the easy bugs: usually all we need from you is the relevant transactions recorded with :ref:`vinyllog(1)` and your explanation -of what is wrong about what Varnish does. +of what is wrong about what ``vinyld`` does. -Be aware, that often Varnish does exactly what you asked it to, rather +Be aware, that often ``vinyld`` does exactly what you asked it to, rather than what you intended it to do. If it sounds like a bug that would have tripped up everybody else, take a moment to read through your VCL and see if it really does what you think it does. diff --git a/doc/sphinx/reference/directors.rst b/doc/sphinx/reference/directors.rst index 1f5cd55206..51b8ae8c39 100644 --- a/doc/sphinx/reference/directors.rst +++ b/doc/sphinx/reference/directors.rst @@ -9,11 +9,11 @@ Writing a Director %%%%%%%%%%%%%%%%%% -Varnish already provides a set of general-purpose directors, and since Varnish -4, it is bundled in the built-in :ref:`vmod_directors(3)`. Writing a director +``Vinyld`` already provides a set of general-purpose directors, bundled +in the built-in :ref:`vmod_directors(3)`. Writing a director boils down to writing a VMOD, using the proper data structures and APIs. Not only can you write your own director if none of the built-ins fit your needs, -but since Varnish 4.1 you can even write your own backends. +but you can even write your own backends. Backends can be categorized as such: @@ -147,9 +147,9 @@ Consider the following snippet:: } The VCL compiler turns this declaration into a ``struct -vrt_backend``. When the VCL is loaded, Varnish calls +vrt_backend``. When the VCL is loaded, ``vinyld`` calls ``VRT_new_backend`` (or rather ``VRT_new_backend_clustered`` for VSM -efficiency) in order to create the director. Varnish doesn't expose +efficiency) in order to create the director. ``Vinyld`` doesn't expose its data structure for actual backends, only the director abstraction and dynamic backends are built just like static backends, one *struct* at a time. You can get rid of the ``struct vrt_backend`` as soon as @@ -164,11 +164,11 @@ to take care of it. Reference counting is used to ensure that backends which are no longer referenced are destroyed. -Finally, Varnish will take care of event propagation for *all* native backends, +Finally, ``vinyld`` will take care of event propagation for *all* native backends, but dynamic backends can only be created when the VCL is warm. If your backends are created by an independent thread (basically outside of VCL scope) you must subscribe to VCL events and watch for VCL state (see -:ref:`ref-vmod-event-functions`). Varnish will panic if you try to create a +:ref:`ref-vmod-event-functions`). ``Vinyld`` will panic if you try to create a backend on a cold VCL, and ``VRT_new_backend`` will return ``NULL`` if the VCL is cooling. You are also encouraged to comply with the :ref:`ref_vcl_temperature` in general. @@ -190,7 +190,7 @@ or director. For dynamic backends, it is just a matter of assigning the ``probe`` field in the ``struct vrt_backend``. Once the director is created, the probe definition -too is no longer needed. It is then Varnish that will take care of the health +too is no longer needed. It is then ``vinyld`` that will take care of the health probe and disable the feature on a cold VCL (see :ref:`ref-vmod-event-functions`). @@ -201,13 +201,13 @@ directly built from VCL (see :ref:`ref-vmod-vcl-c-types`). Custom Backends =============== -If you want to implement a custom backend, have a look at how Varnish +If you want to implement a custom backend, have a look at how ``vinyld`` implements native backends. It is the canonical implementation, and though it provides other services like connection pooling or statistics, it is essentially a director which state is a ``struct -backend``. Varnish native backends currently speak HTTP/1 over TCP or +backend``. ``Vinyld`` native backends currently speak HTTP/1 over TCP or UDS, and as such, you need to make your own custom backend if you want -Varnish to do otherwise such as connect over UDP or speak a different +``vinyld`` to do otherwise such as connect over UDP or speak a different protocol. If you want to leverage probes declarations in VCL, which have the advantage of @@ -230,9 +230,9 @@ When you are creating a custom backend, you may want to provide the semantics of the native backends. In this case, instead of repeating the redundant fields between data structures, you can use the macros ``VRT_BACKEND_FIELDS`` and ``VRT_BACKEND_PROBE_FIELDS`` to declare them all at once. This is the little -dance Varnish uses to copy data between the ``struct vrt_backend`` and its +dance ``vinyld`` uses to copy data between the ``struct vrt_backend`` and its internal data structure for example. The copy can be automated with the macros ``VRT_BACKEND_HANDLE`` and ``VRT_BACKEND_PROBE_HANDLE``. You can look at how they can be used in the -Varnish code base. +Vinyl Cache code base. diff --git a/doc/sphinx/reference/shell_tricks.rst b/doc/sphinx/reference/shell_tricks.rst index d09fd4df4c..d711767e1f 100644 --- a/doc/sphinx/reference/shell_tricks.rst +++ b/doc/sphinx/reference/shell_tricks.rst @@ -9,13 +9,13 @@ Shell Tricks %%%%%%%%%%%% -All the varnish programs can be invoked with the single +All the Vinyl Cache programs can be invoked with the single argument ``--optstring`` to request their `getopt()` specification, which simplifies wrapper scripts: .. code-block:: text - optstring=$(varnishfoo --optstring) + optstring=$(vinylfoo --optstring) while getopts "$optstring" opt do @@ -30,6 +30,6 @@ specification, which simplifies wrapper scripts: esac done - varnishfoo "$@" + vinylfoo "$@" # do something with the options diff --git a/doc/sphinx/reference/vcl-backend.rst b/doc/sphinx/reference/vcl-backend.rst index 79994d7d33..7490cc069d 100644 --- a/doc/sphinx/reference/vcl-backend.rst +++ b/doc/sphinx/reference/vcl-backend.rst @@ -109,7 +109,7 @@ The default values comes parameters with the same names, see :ref:`vinyld(1)`. Attribute ``.max_connections`` ------------------------------ -Limit how many simultaneous connections varnish can open to the backend:: +Limit how many simultaneous connections ``vinyld`` can open to the backend:: .max_connections = 1000; diff --git a/doc/sphinx/reference/vcl-probe.rst b/doc/sphinx/reference/vcl-probe.rst index 41791f05ce..0c511e44e4 100644 --- a/doc/sphinx/reference/vcl-probe.rst +++ b/doc/sphinx/reference/vcl-probe.rst @@ -22,7 +22,7 @@ Configuring Backend Health Probes Backend health probes --------------------- -Varnish can be configured to periodically send a request to test if a +``Vinyld`` can be configured to periodically send a request to test if a backend is answering and thus "healthy". Probes can be configured per backend:: diff --git a/doc/sphinx/reference/vcl-step.rst b/doc/sphinx/reference/vcl-step.rst index 128af43817..367c62cf7e 100644 --- a/doc/sphinx/reference/vcl-step.rst +++ b/doc/sphinx/reference/vcl-step.rst @@ -48,8 +48,8 @@ VCL Actions =========== Actions are used with the ``return()`` keyword, which returns -control from subroutines back to varnish. The action determines how -processing in varnish continues as shown in :ref:`reference-states`. +control from subroutines back to ``vinyld``. The action determines how +processing in ``vinyld`` 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 the next section diff --git a/doc/sphinx/reference/vinyld.rst b/doc/sphinx/reference/vinyld.rst index 5d518dcaf7..75b8cc1761 100644 --- a/doc/sphinx/reference/vinyld.rst +++ b/doc/sphinx/reference/vinyld.rst @@ -508,7 +508,7 @@ specific options. Available jails are: The optional `user` argument specifies which alternative user to use. It defaults to ``vinyl``. - The optional `ccgroup` argument specifies a group to add to varnish + The optional `ccgroup` argument specifies a group to add to ``vinyld`` subprocesses requiring access to a c-compiler. There is no default. The optional `workuser` argument specifies an alternative user to use diff --git a/doc/sphinx/reference/vsm.rst b/doc/sphinx/reference/vsm.rst index 5c0c103568..a9dee3210d 100644 --- a/doc/sphinx/reference/vsm.rst +++ b/doc/sphinx/reference/vsm.rst @@ -9,17 +9,17 @@ VSM: Shared Memory Logging and Statistics %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -Varnish uses shared memory to export parameters, logging and +Vinyl Cache uses shared memory to export parameters, logging and statistics, because it is faster and much more efficient than regular files. -"Varnish Shared Memory" or VSM, is the overall mechanism maintaining +"Vinyl Shared Memory" or VSM, is the overall mechanism maintaining sets of shared memory files, each consisting a chunk of memory identified by a two-part name (class, ident). The Class indicates what type of data is stored in the chunk, for instance "Arg" for command line arguments useful for -establishing an CLI connection to the varnishd, "Stat" for +establishing an CLI connection to the ``vinyld``, "Stat" for statistics counters (VSC) and "Log" for log records (VSL). The ident name part is mostly used with stats counters, where they @@ -48,13 +48,13 @@ The "CS101" way to deal with that, is to introduce locks, and much time is spent examining the relative merits of the many kinds of locks available. -Inside the varnishd (worker) process, we use mutexes to guarantee +Inside the ``vinyld`` (worker) process, we use mutexes to guarantee consistency, both with respect to allocations, log entries and stats counters. We do not want a vinylncsa trying to push data through a stalled ssh connection to stall the delivery of content, so readers like -that are purely read-only, they do not get to affect the varnishd +that are purely read-only, they do not get to affect the ``vinyld`` process and that means no locks for them. Instead we use "stable storage" concepts, to make sure the view @@ -65,14 +65,14 @@ stuff, such as when a backend is taken out of the configuration, we need to give the readers a chance to discover this, a "cooling off" period. -The Varnish way: ----------------- +The Vinyl Cache way: +-------------------- .. XXX: not yet up to date with VSM new world order -When varnishd starts, it opens locked shared memory files, advising to +When ``vinyld`` starts, it opens locked shared memory files, advising to use different -n arguments if an attempt is made to run multiple -varnishd instances on the same working directory. +``vinyld`` instances on the same working directory. Child processes each use their own shared memory files, since a worker process restart marks a clean break in operation anyway. @@ -108,18 +108,18 @@ VSM files. VSM and Containers ------------------ -The Varnish Shared Memory model works well in single-purpose containers. -By sharing the Varnish working directory read-only, VSM readers can run -in individual containers separate from those running varnishd instances on +The Vinyl Shared Memory model works well in single-purpose containers. +By sharing the ``vinyld`` working directory read-only, VSM readers can run +in individual containers separate from those running ``vinyld`` instances on the same host. -On Linux, if varnishd and VSM readers run in the same process namespace, the -VSM readers can rely on the PID advertised by varnishd to determine whether +On Linux, if ``vinyld`` and VSM readers run in the same process namespace, the +VSM readers can rely on the PID advertised by ``vinyld`` to determine whether the manager and cache processes are alive. -However, if they live in different containers, exposing the Varnish working +However, if they live in different containers, exposing the ``vinyld`` working directory as a volume to containers running VSM readers, the PIDs exposed by -varnishd are no longer relevant across namespaces. +``vinyld`` are no longer relevant across namespaces. To disable liveness checks based on PIDs, the variable ``VSM_NOPID`` needs to be present in the environment of VSM readers. @@ -127,8 +127,8 @@ be present in the environment of VSM readers. Warning: mlock() of VSM failed ------------------------------ -It is vital for performance of the Varnish Shared Memory model that all VSM be -resident in RAM at all times. At startup, varnish tries to lift the respective +It is vital for performance of the Vinyl Shared Memory model that all VSM be +resident in RAM at all times. At startup, ``vinyld`` tries to lift the respective limits and an attempt is made to lock all VSM in memory, but if ``RLIMIT_MEMLOCK`` is configured too low, this fails and a warning similar to the following is logged to standard error or syslog:: diff --git a/doc/sphinx/tutorial/now_what.rst b/doc/sphinx/tutorial/now_what.rst index 4f9db619cc..eea07696cf 100644 --- a/doc/sphinx/tutorial/now_what.rst +++ b/doc/sphinx/tutorial/now_what.rst @@ -9,8 +9,8 @@ Now what? ========= -You've read through the tutorial. You should have Varnish up and +You've read through the tutorial. You should have Vinyl Cache up and running. You should know about the logs and you should have a rough idea of what VCL is. Next, you might want to have a look at :ref:`users-guide-index`, where we go through the features of -Varnish in more detail. +Vinyl Cache in more detail. diff --git a/doc/sphinx/tutorial/peculiarities.rst b/doc/sphinx/tutorial/peculiarities.rst index 21c2cdcc4d..411a0271f6 100644 --- a/doc/sphinx/tutorial/peculiarities.rst +++ b/doc/sphinx/tutorial/peculiarities.rst @@ -8,12 +8,12 @@ Peculiarities ------------- There are a couple of things that are different with Vinyl Cache, as -opposed to other programs. One thing you've already seen - VCL. In this section we provide a very quick tour of other peculiarities you need to know about to get the most out of Varnish. +opposed to other programs. One thing you've already seen - VCL. In this section we provide a very quick tour of other peculiarities you need to know about to get the most out of Vinyl Cache. Configuration ~~~~~~~~~~~~~ -The Varnish Configuration is written in VCL. When Varnish is ran this +The ``vinyld`` Configuration is written in VCL. When ``vinyld`` is run this configuration is transformed into C code and then fed into a C compiler, loaded and executed. @@ -24,15 +24,15 @@ settings on or off, you write polices on how the incoming traffic should be handled. -vinyladm -~~~~~~~~~~ +``vinyladm`` +~~~~~~~~~~~~ Vinyl Cache has an admin console. You can connect it through the :ref:`vinyladm(1)` command. In order to connect the user needs to be -able to read `/etc/varnish/secret` in order to authenticate. +able to read `/etc/vinyl/secret` in order to authenticate. Once you've started the console you can do quite a few operations on -Varnish, like stopping and starting the cache process, load VCL, +``vinyld``, like stopping and starting the cache process, load VCL, adjust the built in load balancer and invalidate cached content. It has a built in command "help" which will give you some hints on @@ -40,11 +40,11 @@ what it does. .. XXX:sample of the command here. benc -vinyllog -~~~~~~~~~~ +``vinyllog`` +~~~~~~~~~~~~ -Varnish does not log to disk. Instead it logs to a chunk of memory. It +``Vinyld does not log to disk. Instead it logs to a chunk of memory. It is actually streaming the logs. At any time you'll be able to connect -to the stream and see what is going on. Varnish logs quite a bit of +to the stream and see what is going on. ``Vinyld`` logs quite a bit of information. You can have a look at the logstream with the command :ref:`vinyllog(1)`. diff --git a/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst b/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst index 32c4c8ea13..22a2aad11f 100644 --- a/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst +++ b/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst @@ -4,34 +4,34 @@ See LICENSE file for full text of license -Put Varnish on port 80 ----------------------- +Put Vinyl Cache on port 80 +-------------------------- -Until now we've been running with Varnish on a high port which is great for -testing purposes. Let's now put Varnish on the default HTTP port 80. +Until now we've been running with ``vinyld`` on a high port which is great for +testing purposes. Let's now put ``vinyld`` on the default HTTP port 80. -First we stop varnish: ``service varnish stop`` +First we stop ``vinyld``: ``service vinyl stop`` -Now we need to edit the configuration file that starts Varnish. +Now we need to edit the configuration file that starts ``vinyld``. Debian/Ubuntu (legacy) ~~~~~~~~~~~~~~~~~~~~~~ -On older Debian/Ubuntu this is `/etc/default/varnish`. In the file you'll find +On older Debian/Ubuntu this is `/etc/default/vinyl`. In the file you'll find some text that looks like this:: DAEMON_OPTS="-a :6081 \ -T localhost:6082 \ - -f /etc/varnish/default.vcl \ - -S /etc/varnish/secret \ + -f /etc/vinyl/default.vcl \ + -S /etc/vinyl/secret \ -s default,256m" Change it to:: DAEMON_OPTS="-a :80 \ -T localhost:6082 \ - -f /etc/varnish/default.vcl \ - -S /etc/varnish/secret \ + -f /etc/vinyl/default.vcl \ + -S /etc/vinyl/secret \ -s default,256m" Debian (v8+) / Ubuntu (v15.04+) @@ -41,29 +41,29 @@ On more recent Debian and Ubuntu systems this is configured in the systemd service file. Applying changes to the default service is best done by creating a new file -`/etc/systemd/system/varnish.service.d/customexec.conf`:: +`/etc/systemd/system/vinyl.service.d/customexec.conf`:: [Service] ExecStart= - ExecStart=/usr/sbin/varnishd -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s default,256m + ExecStart=/usr/sbin/vinyld -a :80 -T localhost:6082 -f /etc/vinyl/default.vcl -S /etc/vinyl/secret -s default,256m This will override the ExecStart part of the default configuration shipped with Vinyl Cache. Run ``systemctl daemon-reload`` to make sure systemd picks up the new -configuration before restarting Varnish. +configuration before restarting ``vinyld``. Red Hat Enterprise Linux / CentOS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Red Hat/CentOS you can find a similar configuration file in -`/etc/sysconfig/varnish`. +`/etc/sysconfig/vinyl`. -Restarting Varnish again ------------------------- +Restarting ``vinyld`` again +--------------------------- -Once the change is done, restart Varnish: ``service varnish start``. +Once the change is done, restart ``vinyld``: ``service vinyl start``. -Now everyone accessing your site will be accessing through Varnish. +Now everyone accessing your site will be accessing through ``vinyld``. diff --git a/doc/sphinx/users-guide/command-line.rst b/doc/sphinx/users-guide/command-line.rst index df20904657..af6cd20c02 100644 --- a/doc/sphinx/users-guide/command-line.rst +++ b/doc/sphinx/users-guide/command-line.rst @@ -8,23 +8,23 @@ Required command line arguments ------------------------------- -There only one command line argument you have to provide when starting Varnish, -which is '-b' for where the backend server can be contacted. +There are only two command line argument you have to provide when starting +``vinyld``: '-b' for where the backend server can be contacted, and +'-a' for which sockets ``vinyld`` should serve. -'-a' is another argument which is likely to require adjustment. - -If you have installed Varnish through using a provided operating system bound package, +If you have installed Vinyl Cache through using a provided operating system +bound package, you will find the startup options here: -* Debian, Ubuntu: `/etc/default/varnish` -* Red Hat, Centos: `/etc/sysconfig/varnish` -* FreeBSD: `/etc/rc.conf` (See also: /usr/local/etc/rc.d/varnishd) +* Debian, Ubuntu: `/etc/default/vinyl` +* Red Hat, Centos: `/etc/sysconfig/vinyl` +* FreeBSD: `/etc/rc.conf` (See also: /usr/local/etc/rc.d/vinyld) '-a' *<[name=][listen_address[,PROTO|,option=value,...]]>* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Each '-a' argument defines one endpoint which Varnish should service HTTP +Each '-a' argument defines one endpoint which ``vinyld`` should service HTTP requests on. The default is ``:80,http`` to listen on the Well Known Port for HTTP. If your @@ -50,7 +50,7 @@ Here are some examples:: '-f' *VCL-file* or '-b' *backend* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Varnish needs to know where to find the HTTP server it is caching for. +``Vinyld`` needs to know where to find the HTTP server it is caching for. You can either specify it with the '-b' argument, or you can put it in your own VCL file, specified with the '-f' argument. Using '-b' is a quick way to get started:: diff --git a/doc/sphinx/users-guide/increasing-your-hitrate.rst b/doc/sphinx/users-guide/increasing-your-hitrate.rst index 53e6e0f3c3..3b46a4e7a6 100644 --- a/doc/sphinx/users-guide/increasing-your-hitrate.rst +++ b/doc/sphinx/users-guide/increasing-your-hitrate.rst @@ -8,35 +8,35 @@ Achieving a high hitrate ------------------------ -Now that Varnish is up and running you can access your web application -through Varnish. Unless your application is specifically written to +Now that ``Vinyld`` is up and running you can access your web application +through Vinyl Cache. Unless your application is specifically written to work behind a web accelerator you'll probably need to do some changes to either the configuration or the application in order to -get a high hitrate in Varnish. +get a high hitrate in Vinyl Cache. -Varnish will not cache your data unless it's absolutely sure it is -safe to do so. So, for you to understand how Varnish decides if and +``Vinyld`` will not cache your data unless it's absolutely sure it is +safe to do so. So, for you to understand how ``Vinyld`` decides if and how to cache a page, we'll guide you through a couple of tools that you should find useful to understand what is happening in your -Varnish setup. +Vinyl Cache setup. Note that you need a tool to see the HTTP headers that fly between -Varnish and the backend. On the Varnish server, the easiest way to do +``Vinyld`` and the backend. On the Vinyl Cache server, the easiest way to do this is to use :ref:`vinyllog(1)` and :ref:`vinyltop(1)` but sometimes a client-side tool makes sense. Here are the ones we commonly use. -Tool: vinyltop -~~~~~~~~~~~~~~~~ +Tool: ``vinyltop`` +~~~~~~~~~~~~~~~~~~ -You can use vinyltop to identify what URLs are hitting the backend +You can use ``vinyltop`` to identify what URLs are hitting the backend the most. ``vinyltop -i BereqURL`` is an essential command, showing -you the top requests Varnish is sending to the backend. You can see some +you the top requests ``vinyld`` is sending to the backend. You can see some other examples of :ref:`vinyltop(1)` usage in :ref:`users-guide-statistics`. -Tool: vinyllog -~~~~~~~~~~~~~~~~ +Tool: ``vinyllog`` +~~~~~~~~~~~~~~~~~~ When you have identified an URL which is frequently sent to the backend you can use :ref:`vinyllog(1)` to have a look at the @@ -55,7 +55,7 @@ for Perl. It's a couple of really basic programs that can execute an HTTP request and show you the result. We mostly use the two programs, ``GET`` and ``HEAD``. -vg.no was the first site to use Varnish and the people running Varnish +vg.no was the first site to use Vinyl Cache and the people running Vinyl Cache there are quite clueful. So it's interesting to look at their HTTP Headers. Let's send a GET request for their home page:: @@ -83,9 +83,9 @@ prints response headers and '-d' discards the actual content. We don't really care about the content, only the headers. As you can see, VG adds quite a bit of information in their -headers. Some of the headers, like the 'X-Rick-Would-Never' are specific +headers. Some of the headers, like the ``X-Rick-Would-Never`` are specific to vg.no and their somewhat odd sense of humour. Others, like the -'X-VG-Webcache' are for debugging purposes. +``X-VG-Webcache`` are for debugging purposes. So, to check whether a site sets cookies for a specific URL, just do:: @@ -107,16 +107,16 @@ The role of HTTP Headers ------------------------ Along with each HTTP request and response comes a bunch of headers -carrying metadata. Varnish will look at these headers to determine if -it is appropriate to cache the contents and how long Varnish can keep +carrying metadata. ``vinyld`` will look at these headers to determine if +it is appropriate to cache the contents and how long ``vinyld`` can keep the content cached. -Please note that when Varnish considers these headers Varnish actually +Please note that when ``vinyld`` considers these headers ``vinyld`` actually considers itself *part of* the actual webserver. The rationale being that both are under your control. The term *surrogate origin cache* is not really well defined by the -IETF or RFC 2616 so the various ways Varnish works might differ from +IETF or RFC 2616 so the various ways ``vinyld`` works might differ from your expectations. Let's take a look at the important headers you should be aware of: @@ -126,9 +126,9 @@ Let's take a look at the important headers you should be aware of: Cookies ~~~~~~~ -Varnish will, in the default configuration, not cache an object coming +``Vinyld`` will, in the default configuration, not cache an object coming from the backend with a 'Set-Cookie' header present. Also, if the client -sends a Cookie header, Varnish will bypass the cache and go directly to +sends a Cookie header, ``vinyld`` will bypass the cache and go directly to the backend. This can be overly conservative. A lot of sites use Google Analytics @@ -150,7 +150,7 @@ accessing `/admin/`:: Quite simple. If, however, you need to do something more complicated, like removing one out of several cookies, things get -difficult. Unfortunately Varnish doesn't have good tools for +difficult. Unfortunately ``vinyld`` doesn't have good tools for manipulating the Cookies. We have to use regular expressions to do the work. If you are familiar with regular expressions you'll understand whats going on. If you aren't we recommend that you either pick up a book on @@ -159,11 +159,11 @@ one of many online guides. Lets use the Varnish Software (VS) web as an example here. Very simplified the setup VS uses can be described as a Drupal-based -backend with a Varnish cache in front. VS uses some cookies for +backend with a ``vinyld`` cache in front. VS uses some cookies for Google Analytics tracking and similar tools. The cookies are all -set and used by JavaScript. Varnish and Drupal doesn't need to see -those cookies and since Varnish will cease caching of pages when -the client sends cookies Varnish will discard these unnecessary +set and used by JavaScript. ``vinyld`` and Drupal doesn't need to see +those cookies and since ``vinyld`` will cease caching of pages when +the client sends cookies ``vinyld`` will discard these unnecessary cookies in VCL. In the following VCL we discard all cookies that start with an @@ -221,7 +221,7 @@ Cookies coming from the backend +++++++++++++++++++++++++++++++ If your backend server sets a cookie using the 'Set-Cookie' header -Varnish will not cache the page when using the default configuration. +``vinyld`` will not cache the page when using the default configuration. A `hit-for-miss` object (see :ref:`vcl_actions`) is created. So, if the backend server acts silly and sets unwanted cookies just unset the 'Set-Cookie' header and all should be fine. @@ -230,8 +230,8 @@ cookies just unset the 'Set-Cookie' header and all should be fine. Cache-Control ~~~~~~~~~~~~~ -The 'Cache-Control' header instructs caches how to handle the content. Varnish -cares about the *max-age* parameter and uses it to calculate the TTL +The 'Cache-Control' header instructs caches how to handle the content. +``Vinyld`` cares about the *max-age* parameter and uses it to calculate the TTL for an object. So make sure you issue a 'Cache-Control' header with a max-age @@ -244,14 +244,14 @@ issues:: Age ~~~ -Varnish adds an 'Age' header to indicate how long the object has been -kept inside Varnish. You can grep out 'Age' from :ref:`vinyllog(1)` +``Vinyld`` adds an 'Age' header to indicate how long the object has been +kept inside ``vinyld``. You can grep out 'Age' from :ref:`vinyllog(1)` with ``vinyllog -I RespHeader:^Age``. Pragma ~~~~~~ -An HTTP 1.0 server might send the header ``Pragma: nocache``. Varnish ignores this +An HTTP 1.0 server might send the header ``Pragma: nocache``. ``vinyld`` ignores this header. You could easily add support for this header in VCL. In `vcl_backend_response`:: @@ -264,14 +264,14 @@ In `vcl_backend_response`:: Authorization ~~~~~~~~~~~~~ -If Varnish sees an 'Authorization' header it will pass the request. If +If ``vinyld`` sees an 'Authorization' header it will pass the request. If this is not what you want you can unset the header. Overriding the time-to-live (TTL) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sometimes your backend will misbehave. It might, depending on your -setup, be easier to override the TTL in Varnish then to fix your +setup, be easier to override the TTL in ``vinyld`` then to fix your somewhat cumbersome backend. You need VCL to identify the objects you want and then you set the @@ -290,9 +290,9 @@ Forcing caching for certain requests and certain responses ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Since you still might have this cumbersome backend that isn't very friendly -to work with you might want to override more stuff in Varnish. We +to work with you might want to override more stuff in ``vinyld``. We recommend that you rely as much as you can on the default caching -rules. It is perfectly easy to force Varnish to lookup an object in +rules. It is perfectly easy to force ``vinyld`` to lookup an object in the cache but it isn't really recommended. @@ -301,8 +301,8 @@ Normalizing your namespace Some sites are accessed via lots of hostnames. http://www.varnish-software.com/, http://varnish-software.com/ and -http://varnishsoftware.com/ all point at the same site. Since Varnish -doesn't know they are the same, Varnish will cache different versions of +http://varnishsoftware.com/ all point at the same site. Since ``vinyld`` +doesn't know they are the same, ``vinyld`` will cache different versions of every page for every hostname. You can mitigate this in your web server configuration by setting up redirects or by using the following VCL:: @@ -328,19 +328,19 @@ need to keep these different variants apart and this is done through the HTTP response header 'Vary'. When a backend server issues a ``Vary: Accept-Language`` it tells -Varnish that its needs to cache a separate version for every different +``Vinyld`` that its needs to cache a separate version for every different Accept-Language that is coming from the clients. If two clients say they accept the languages "en-us, en-uk" and -"da, de" respectively, Varnish will cache and serve two different -versions of the page if the backend indicated that Varnish needs +"da, de" respectively, ``vinyld`` will cache and serve two different +versions of the page if the backend indicated that ``vinyld`` needs to vary on the 'Accept-Language' header. Please note that the headers that 'Vary' refer to need to match -*exactly* for there to be a match. So Varnish will keep two copies +*exactly* for there to be a match. So ``vinyld`` will keep two copies of a page if one of them was created for "en-us, en-uk" and the other for "en-us,en-uk". Just the lack of a whitespace will force -Varnish to cache another version. +``vinyld`` to cache another version. To achieve a high hitrate whilst using Vary is there therefore crucial to normalize the headers the backends varies on. Remember, @@ -366,7 +366,7 @@ either "en", "de" or "fr", in this order of precedence:: Vary parse errors ~~~~~~~~~~~~~~~~~ -Varnish will return a "503 internal server error" page when it fails +``Vinyld`` will return a "503 internal server error" page when it fails to parse the 'Vary' header, or if any of the client headers listed in the Vary header exceeds the limit of 65k characters. An 'SLT_Error' log entry is added in these cases. @@ -375,7 +375,7 @@ Pitfall - Vary: User-Agent ~~~~~~~~~~~~~~~~~~~~~~~~~~ Some applications or application servers send ``Vary: User-Agent`` -along with their content. This instructs Varnish to cache a separate +along with their content. This instructs ``vinyld`` to cache a separate copy for every variation of 'User-Agent' there is and there are plenty. Even a single patchlevel of the same browser will generate at least 10 different 'User-Agent' headers based just on what @@ -388,7 +388,7 @@ above code as a template. Cache misses ------------ -When Varnish does not find an object for a request in the cache, then +When ``vinyld`` does not find an object for a request in the cache, then by default it performs a fetch from the backend on the hypothesis that the response might be cached. This has two important consequences: @@ -403,7 +403,7 @@ the response might be cached. This has two important consequences: pending requests. * The backend request for the cache miss cannot be conditional if - Varnish does not have an object in the cache to validate; that is, + ``vinyld`` does not have an object in the cache to validate; that is, it cannot contain the headers ``If-Modified-Since`` or ``If-None-Match``, which might cause the backend to return status "304 Not Modified" with no response body. Otherwise, there might not @@ -411,21 +411,21 @@ the response might be cached. This has two important consequences: request, they are removed from the backend request. By setting a grace time for cached objects (default 10 seconds), you -allow Varnish to serve stale content while waiting for coalesced fetches, +allow ``vinyld`` to serve stale content while waiting for coalesced fetches, which are run asynchronously while the stale response is sent to the client. For details see :ref:`users-guide-handling_misbehaving_servers`. Although the headers for a conditional request are removed from the -backend fetch on a cache miss, Varnish may nevertheless respond to the +backend fetch on a cache miss, ``vinyld`` may nevertheless respond to the client request with "304 Not Modified" if the resulting response allows it. At delivery time, if the client request had an ``If-None-Match`` header that matches the ``ETag`` header in the response, or if the time in an ``If-Modified-Since`` request header is equal to or later than the time in the ``Last-Modified`` response -header, Varnish will send the 304 response to the client. This happens +header, ``vinyld`` will send the 304 response to the client. This happens for both hits and misses. -Varnish can send conditional requests to the backend if it has an +``Vinyld`` can send conditional requests to the backend if it has an object in the cache against which the validation can be performed. You can ensure that an object is retained for this purpose by setting ``beresp.keep`` in ``vcl_backend_response``:: @@ -459,7 +459,7 @@ conditional, just remove the If-* headers in ``vcl_backend_fetch``:: That should only be necessary if the conditional fetches are problematic for the backend, for example if evaluating whether the response is unchanged is too costly for the backend app, or if the -responses are just buggy. From the perspective of Varnish, 304 +responses are just buggy. From the perspective of ``vinyld``, 304 responses are clearly preferable; fetches with the empty response body save bandwidth, and storage does not have to be allocated in the cache, since the existing cache object is re-used. @@ -484,7 +484,7 @@ Some responses cannot be cached, for various reasons. The content may be personalized, depending on the content of the ``Cookie`` header, or it might just be the sort of thing that is generated anew on each request. The cache can't help with that, but nevertheless there are -some decisions you can make that will help Varnish deal with +some decisions you can make that will help ``vinyld`` deal with uncacheable responses in a way that is best for your requirements. The issues to consider are: @@ -545,14 +545,14 @@ built-in ``vcl_recv`` gets executed; so take a close look at ``vcl_recv`` in ``builtin.vcl``, and duplicate any part of it that you require in your own ``vcl_recv``. -As with cache hits and misses, Varnish decides to send a 304 response +As with cache hits and misses, ``vinyld`` decides to send a 304 response to the client after a pass if the client request headers and the -response headers allow it. This might mean that Varnish will send a +response headers allow it. This might mean that ``vinyld`` will send a 304 response to the client even after the backend saw the same request headers (``If-Modified-Since`` and/or ``If-None-Match``), but decided not to respond with status 304, while nevertheless setting the response headers ``ETag`` and/or ``Last-Modified`` so that 304 would -appear to be warranted. If you would prefer that Varnish doesn't do +appear to be warranted. If you would prefer that ``vinyld`` doesn't do that, then remove the If-* client request headers in ``vcl_pass``:: sub vcl_pass { @@ -567,7 +567,7 @@ hit-for-miss You may not be able to recognize all requests for uncacheable content in ``vcl_recv``. You might want to allow backends to determine their own cacheability by setting the ``Cache-Control`` header, but that -cannot be seen until Varnish receives the backend response, so +cannot be seen until ``vinyld`` receives the backend response, so ``vcl_recv`` can't know about it. By default, if a request is not passed and the backend response turns @@ -598,7 +598,7 @@ cacheable response is returned before ``beresp.ttl`` elapses, then the next request for that object will be an ordinary miss, and hence will be subject to request coalescing. -When Varnish sees that it has hit a hit-for-miss object on a new +When ``Vinyld`` sees that it has hit a hit-for-miss object on a new request, it executes ``vcl_miss``, so any custom VCL you have written for cache misses will apply in the hit-for-miss case as well. @@ -622,7 +622,7 @@ Note that once ``beresp.uncacheable`` has been set to ``true`` it cannot be set back to ``false``; attempts to do so in VCL are ignored. Although the backend fetches are never conditional for hit-for-miss, -Varnish may decide (as in all other cases) to send a 304 response to +``Vinyld`` may decide (as in all other cases) to send a 304 response to the client if the client request headers and response headers ``ETag`` or ``Last-Modified`` allow it. If you want to prevent that, remove the If-* client request headers in ``vcl_miss``:: @@ -663,14 +663,14 @@ that ``If-Modified-Since`` and ``If-None-Match`` headers in the client request are passed along to the backend, so that the backend response may be 304. -Varnish executes ``vcl_pass`` when it hits a hit-for-pass object. So +``Vinyld`` executes ``vcl_pass`` when it hits a hit-for-pass object. So again, you can arrange for your own handling of both pass and hit-for-pass with the same code in VCL. -If you want to prevent Varnish from sending conditional requests to +If you want to prevent ``vinyld`` from sending conditional requests to the backend, then remove the If-* headers from the backend request in ``vcl_backend_fetch``, as shown above for cache misses. And if you -want to prevent Varnish from deciding at delivery time to send a 304 +want to prevent ``vinyld`` from deciding at delivery time to send a 304 response to the client based on the client request and response headers, then remove the headers from the client request in ``vcl_pass``, as shown above for pass. From 4e49ed6aa01df57720fdf7ed4da58ce21f7f8011 Mon Sep 17 00:00:00 2001 From: Geoff Simmons Date: Tue, 25 Sep 2018 16:31:17 +0200 Subject: [PATCH 115/196] Start skeleton release notes for the next version. Restructured so that: * 'Upgrading' is limited to work that has to be done to upgrade from a current deployment to the new version. * 'Changes' is a comprehensive, user-level description of changes and new features. Conflicts: doc/sphinx/whats-new/index.rst Also applied some s/varnish/vinyl/ where relevant --- doc/sphinx/whats-new/changes-trunk.rst | 73 ++++++++++++++++++++++++ doc/sphinx/whats-new/index.rst | 13 +++++ doc/sphinx/whats-new/upgrading-trunk.rst | 33 +++++++++++ 3 files changed, 119 insertions(+) create mode 100644 doc/sphinx/whats-new/changes-trunk.rst create mode 100644 doc/sphinx/whats-new/upgrading-trunk.rst diff --git a/doc/sphinx/whats-new/changes-trunk.rst b/doc/sphinx/whats-new/changes-trunk.rst new file mode 100644 index 0000000000..0f1f6392c8 --- /dev/null +++ b/doc/sphinx/whats-new/changes-trunk.rst @@ -0,0 +1,73 @@ +**Note: This is a working document for a future release, with running +updates for changes in the development branch. For changes in the +released versions of Varnish, see:** :ref:`whats-new-index` + +.. _whatsnew_changes_CURRENT: + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +Changes in Vinyl **$NEXT_RELEASE** +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +For information about updating your current Varnish deployment to the +new version, see :ref:`whatsnew_upgrading_CURRENT`. + +A more detailed and technical account of changes in Vinyl, with +links to issues that have been fixed and pull requests that have been +merged, may be found in the `change log`_. + +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst + +vinyld +====== + +Parameters +~~~~~~~~~~ + +**XXX changes in -p parameters** + +Other changes in vinyld +~~~~~~~~~~~~~~~~~~~~~~~ + +Changes to VCL +============== + +VCL variables +~~~~~~~~~~~~~ + +**XXX new, deprecated or removed variables, or changed semantics** + +Other changes to VCL +~~~~~~~~~~~~~~~~~~~~ + +VMODs +===== + +**XXX changes in the bundled VMODs** + +vinyllog +======== + +**XXX changes concerning vinyllog(1) and/or vsl(7)** + +vinyladm +======== + +**XXX changes concerning vinyladm(1) and/or vinyl-cli(7)** + +vinylstat +========= + +**XXX changes concerning vinylstat(1) and/or vinyl-counters(7)** + +vinyltest +========= + +**XXX changes concerning vinyltest(1) and/or vtc(7)** + +Changes for developers and VMOD authors +======================================= + +**XXX changes concerning VRT, the public APIs, source code organization, +builds etc.** + +*eof* diff --git a/doc/sphinx/whats-new/index.rst b/doc/sphinx/whats-new/index.rst index 955a0cbdf4..da6a81560a 100644 --- a/doc/sphinx/whats-new/index.rst +++ b/doc/sphinx/whats-new/index.rst @@ -13,6 +13,19 @@ This section describes the changes and improvements between different versions of Varnish, and what upgrading between the different versions entail. +Vinyl **$NEXT_RELEASE** +------------------------- + +**Note: These are working documents for a future release, with running +updates for changes in the development branch. For changes in the +released versions of Varnish, see the chapters listed below.** + +.. toctree:: + :maxdepth: 2 + + changes-trunk + upgrading-trunk + Varnish 8.0 ----------- diff --git a/doc/sphinx/whats-new/upgrading-trunk.rst b/doc/sphinx/whats-new/upgrading-trunk.rst new file mode 100644 index 0000000000..d781481906 --- /dev/null +++ b/doc/sphinx/whats-new/upgrading-trunk.rst @@ -0,0 +1,33 @@ +**Note: This is a working document for a future release, with running +updates for changes in the development branch. For changes in the +released versions of Varnish, see:** :ref:`whats-new-index` + +.. _whatsnew_upgrading_CURRENT: + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +Upgrading to Vinyl **$NEXT_RELEASE** +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +**XXX: how to upgrade from previous deployments to this +version. Limited to work that has to be done for an upgrade, new +features are listed in "Changes". Explicitly mention what does *not* +have to be changed, especially in VCL. May include, but is not limited +to:** + +* Elements of VCL that have been removed or are deprecated, or whose + semantics have changed. + +* -p parameters that have been removed or are deprecated, or whose + semantics have changed. + +* Changes in the CLI. + +* Changes in the output or interpretation of stats or the log, including + changes affecting vinylncsa/-hist/-top. + +* Changes that may be necessary in VTCs or in the use of vinyltest. + +* Changes in public APIs that may require changes in VMODs or VAPI/VUT + clients. + +*eof* From 0e7ef98f7f3cd41aaf9215248fbf860eb8a2acc4 Mon Sep 17 00:00:00 2001 From: Walid Boudebouda Date: Wed, 11 Mar 2026 17:20:10 +0100 Subject: [PATCH 116/196] Docs: Replace $NEXT_RELEASE/CURRENT placeholders with 9.0 --- .../whats-new/{changes-trunk.rst => changes-9.0.rst} | 10 +++++----- doc/sphinx/whats-new/index.rst | 8 ++++---- .../{upgrading-trunk.rst => upgrading-9.0.rst} | 8 ++++---- 3 files changed, 13 insertions(+), 13 deletions(-) rename doc/sphinx/whats-new/{changes-trunk.rst => changes-9.0.rst} (88%) rename doc/sphinx/whats-new/{upgrading-trunk.rst => upgrading-9.0.rst} (86%) diff --git a/doc/sphinx/whats-new/changes-trunk.rst b/doc/sphinx/whats-new/changes-9.0.rst similarity index 88% rename from doc/sphinx/whats-new/changes-trunk.rst rename to doc/sphinx/whats-new/changes-9.0.rst index 0f1f6392c8..93f7562d58 100644 --- a/doc/sphinx/whats-new/changes-trunk.rst +++ b/doc/sphinx/whats-new/changes-9.0.rst @@ -2,14 +2,14 @@ updates for changes in the development branch. For changes in the released versions of Varnish, see:** :ref:`whats-new-index` -.. _whatsnew_changes_CURRENT: +.. _whatsnew_changes_9.0: -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -Changes in Vinyl **$NEXT_RELEASE** -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%% +Changes in Vinyl 9.0 +%%%%%%%%%%%%%%%%%%%% For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_CURRENT`. +new version, see :ref:`whatsnew_upgrading_9.0`. A more detailed and technical account of changes in Vinyl, with links to issues that have been fixed and pull requests that have been diff --git a/doc/sphinx/whats-new/index.rst b/doc/sphinx/whats-new/index.rst index da6a81560a..49a651085a 100644 --- a/doc/sphinx/whats-new/index.rst +++ b/doc/sphinx/whats-new/index.rst @@ -13,8 +13,8 @@ This section describes the changes and improvements between different versions of Varnish, and what upgrading between the different versions entail. -Vinyl **$NEXT_RELEASE** -------------------------- +Vinyl 9.0 +--------- **Note: These are working documents for a future release, with running updates for changes in the development branch. For changes in the @@ -23,8 +23,8 @@ released versions of Varnish, see the chapters listed below.** .. toctree:: :maxdepth: 2 - changes-trunk - upgrading-trunk + changes-9.0 + upgrading-9.0 Varnish 8.0 ----------- diff --git a/doc/sphinx/whats-new/upgrading-trunk.rst b/doc/sphinx/whats-new/upgrading-9.0.rst similarity index 86% rename from doc/sphinx/whats-new/upgrading-trunk.rst rename to doc/sphinx/whats-new/upgrading-9.0.rst index d781481906..b65ee9685d 100644 --- a/doc/sphinx/whats-new/upgrading-trunk.rst +++ b/doc/sphinx/whats-new/upgrading-9.0.rst @@ -2,11 +2,11 @@ updates for changes in the development branch. For changes in the released versions of Varnish, see:** :ref:`whats-new-index` -.. _whatsnew_upgrading_CURRENT: +.. _whatsnew_upgrading_9.0: -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Vinyl **$NEXT_RELEASE** -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%% +Upgrading to Vinyl 9.0 +%%%%%%%%%%%%%%%%%%%%%% **XXX: how to upgrade from previous deployments to this version. Limited to work that has to be done for an upgrade, new From da6a5640a78fc5cc0823b009a70d292b06e3064c Mon Sep 17 00:00:00 2001 From: Walid Boudebouda Date: Wed, 11 Mar 2026 17:22:09 +0100 Subject: [PATCH 117/196] changes: Populate changelog for 9.0 release --- doc/changes.rst | 132 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 128 insertions(+), 4 deletions(-) diff --git a/doc/changes.rst b/doc/changes.rst index b001bd7195..f2657eedab 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -34,13 +34,15 @@ http://varnish-cache.org/docs/trunk/whats-new/index.html and via individual releases. These documents are updated as part of the release process. -============================= -Vinyl-Cache NEXT (2026-03-15) -============================= +============================ +Vinyl-Cache 9.0 (2026-03-16) +============================ .. PLEASE keep this roughly in commit order as shown by git-log / tig (new to old) +* VCL variable ``beresp.storage_hint`` no longer exists. + * ``VSL_Setup()`` has been replaced with ``VSL_Init()`` to initialize caller-provided space as a vsl buffer and ``VSL_Alloc()`` to allocate the default ``vsl_buffer`` on the heap. @@ -50,7 +52,110 @@ Vinyl-Cache NEXT (2026-03-15) ``tools/coccinelle/vsl_setup_retire.cocci`` can be used to partially automate the transition (it does not add ``VSL_Free()``). -* Added vmod ``math``. + +.. _4452: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4452 + +* Fixed a bug in VCC where using ``false``/``true`` as a value for ``VCL_BOOL`` + would result in a C-compiler error under certain platforms. (`4452`_) + +.. _4438: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4438 + +* Request methods are now represented as a bitmap in struct http, which allows + turning method evaluations as simple bitwise operations instead of string + comparisons. (`4438`_) + +.. _4340: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4340 + +* For requests having no request body, Content-length header will now only be + unset when the request method is one of: ``GET``, ``HEAD``, ``DELETE``, + ``OPTIONS``, ``TRACE``. Otherwise, a Content-length with value 0 will be set. (`4340`_) + +.. _4422: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4422 + +* Added vmod ``math``. (`4422`_) + +.. _4427: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4427 + +* ``vmod_std`` has a new ``.rfc_ttl()`` to re-calculate the object timers + (``beresp.ttl``, ``beresp.grace`` and ``beresp.keep``) based on the current + state of ``beresp`` as if it had been processed by core code before + ``vcl_backend_response`` was called. This does not change + ``beresp.uncacheable`` (`4427`_) + +.. _4419: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4419 + +* VEXTs can now be loaded by specifying their basename as `-E`. When + is not a path (does not contain /), a search in ``vmod_path`` is conducted for + ``libvmod_.so``. (`4419`_) + +.. _4421: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4421 + +* New ``unused`` VCL keyword to mark symbols as intentionally unused, which + prevents errors about them being unused during VCL compilation. This gives + finer grained control compared to the ``-err_unref`` VCC feature, which disables + the error globally for all symbols. (`4421`_) + +.. _4418: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4418 + +* Improved VCL comparison for probes, backends and ACLs that could lead to C-compiler + errors in the past. (`4418`_) + +.. _4415: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4415 + +* Fixed probes comparison in VCC which used to wrongly convert operands to string + before performing the comparison. (`4415`_) + +.. _4409: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4409 + +* Receiving SIGTERM in the management process is no longer logged as an error, + but rather as an INFO log record. (`4409`_) + +.. _4007: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4007 + +* The ``BackendOpen`` VSL tag now also logs Connection age and Connection reuses + when relevant. These can be useful when trubleshooting idle timeout from the + backend. (`4007`_) + +.. _4415: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4415 + +* Fixed a VCC bug where VCL would refuse to compile when a probe was never + referenced, even when ``'vcc_feature=-err_unref'`` was set. (`4415`_) + +.. _4416: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4416 + +* A new ``bereq.retry_connect`` variable was added to VCL to control whether + Vinyl will make a second attempt to connect to the backend if a first connection + reuse attempt failed. This can be useful to prevent undesired retries of + potentially non-idempotent requests. Setting to ``false`` means that no retries + will be made. However, setting this to ``true`` does not guarantee that a retry + will always be attempted, as there are other factors involved in the decision + (ex: a request body not being cached). This parameter only affects automatic + retries triggered by connection reuse failures and does not affect VCL + retries. (`4416`_) + +.. _4354: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4354 + +* The ACL's ``+fold`` feature can now be followed with an optional ``(-report)`` + to not output folding-related warnings during VCL compilation. + +* Fixed a VCC bug where a number expressed in scientific notation could trigger + an assertion failure. + +.. _4402: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4402 + +* Fixed data race between BOC state and objcore flags that could result in a + panic under certain conditions. (`4402`_) + +.. _4399: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4399 + +* The response reason when the stale object is not a valid object for refresh + has been made more descriptive to make it easier to differentiate between the + failure cases in the logs. (`4399`_) + +* A conditional GET for object revalidation is now demoted to a regular fetch + if the stale object being revalidated gets invalidated (e.g. by a ban or + purge) while the backend request is in progress. This also applies to + retries. (`4399`_) .. _4389: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4389 @@ -58,6 +163,25 @@ Vinyl-Cache NEXT (2026-03-15) being retained as an alias. ``req.ttl`` is now deprecated, but no warning is emitted yet. It will be removed in a future version of Vinyl-Cache. (`4389`_) +* The session close reason descriptions ``REM_CLOSE`` and ``REQ_CLOSE`` have been + generalized from "Client Closed" / "Client requested close" to "Peer Closed" / + "Peer requested close" since they apply to both client and backend + connections. + +.. _4394: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4394 + +* VCL subroutine calls (``VCL_SUB``) are now supported from ``vcl_init`` and + ``vcl_fini``. (`4394`_) + +* The workspace overflow counters (``ws_backend_overflow``, ``ws_client_overflow``, + ``ws_thread_overflow``, ``ws_session_overflow``) are now shown by default in + ``vinylstat`` instead of requiring the ``diag`` level. + +.. _4396: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4396 + +* A bug has been fixed where the HTTP/2 session workspace was not consistently + released and could lead to a panic under certain conditions. (`4396`_) + ================================ Varnish-Cache 8.0.0 (2025-09-15) ================================ From 41b3b5a922b621b538b13f16b0b9cf3788c487eb Mon Sep 17 00:00:00 2001 From: Walid Boudebouda Date: Wed, 11 Mar 2026 18:18:35 +0100 Subject: [PATCH 118/196] Docs: Populate {changes,upgrading}-9.0.rst --- doc/sphinx/whats-new/changes-9.0.rst | 91 +++++++++++++++++++------- doc/sphinx/whats-new/upgrading-9.0.rst | 74 +++++++++++++++------ 2 files changed, 123 insertions(+), 42 deletions(-) diff --git a/doc/sphinx/whats-new/changes-9.0.rst b/doc/sphinx/whats-new/changes-9.0.rst index 93f7562d58..6713022f50 100644 --- a/doc/sphinx/whats-new/changes-9.0.rst +++ b/doc/sphinx/whats-new/changes-9.0.rst @@ -1,7 +1,3 @@ -**Note: This is a working document for a future release, with running -updates for changes in the development branch. For changes in the -released versions of Varnish, see:** :ref:`whats-new-index` - .. _whatsnew_changes_9.0: %%%%%%%%%%%%%%%%%%%% @@ -20,54 +16,103 @@ merged, may be found in the `change log`_. vinyld ====== -Parameters -~~~~~~~~~~ - -**XXX changes in -p parameters** - Other changes in vinyld ~~~~~~~~~~~~~~~~~~~~~~~ +Varnish Extensions (VEXTs) can now be loaded by specifying their basename as +``-E``. When ```` is not a path (does not contain ``/``), a search +in ``vmod_path`` is conducted for ``libvmod_.so``. + +Receiving ``SIGTERM`` in the management process is no longer logged as an +error, but rather as an INFO log record. + +For requests having no request body, the ``Content-Length`` header will now +only be unset when the request method is one of: ``GET``, ``HEAD``, ``DELETE``, +``OPTIONS``, ``TRACE``. For other methods, a ``Content-Length`` header with +value 0 will be set. + +A conditional GET for object revalidation is now demoted to a regular fetch if +the stale object being revalidated gets invalidated (e.g. by a ban or purge) +while the backend request is in progress. + Changes to VCL ============== VCL variables ~~~~~~~~~~~~~ -**XXX new, deprecated or removed variables, or changed semantics** +The VCL variable ``beresp.storage_hint`` has been removed. + +The ``req.ttl`` variable has been renamed to ``req.max_age`` for clarity. +``req.ttl`` is retained as an alias but is now deprecated and will be removed +in a future version. + +A new ``bereq.retry_connect`` variable has been added to control whether Vinyl +will make a second attempt to connect to the backend if a first connection +reuse attempt failed. This can be useful to prevent undesired retries of +potentially non-idempotent requests. Setting to ``false`` means no retries will +be made. This parameter only affects automatic retries triggered by connection +reuse failures and does not affect VCL retries. Other changes to VCL ~~~~~~~~~~~~~~~~~~~~ +A new ``unused`` VCL keyword has been added to mark symbols as intentionally +unused. This prevents errors about unused symbols during VCL compilation and +provides finer grained control compared to the ``-err_unref`` VCC feature, +which disables the error globally for all symbols. + +VCL subroutine calls (``VCL_SUB``) are now supported from ``vcl_init`` and +``vcl_fini``. + +The ACL's ``+fold`` feature can now be followed with an optional ``(-report)`` +to suppress folding-related warnings during VCL compilation. + VMODs ===== -**XXX changes in the bundled VMODs** +A new ``vmod_math`` has been added, providing mathematical functions. + +``vmod_std`` has a new ``.rfc_ttl()`` function to re-calculate the object +timers (``beresp.ttl``, ``beresp.grace`` and ``beresp.keep``) based on the +current state of ``beresp`` as if it had been processed by core code before +``vcl_backend_response`` was called. This does not change +``beresp.uncacheable``. vinyllog ======== -**XXX changes concerning vinyllog(1) and/or vsl(7)** +The ``BackendOpen`` VSL tag now also logs connection age and connection reuses +when relevant. These can be useful when troubleshooting idle timeout issues +from the backend. -vinyladm -======== +The response reason when a stale object is not a valid object for refresh has +been made more descriptive to make it easier to differentiate between failure +cases in the logs. -**XXX changes concerning vinyladm(1) and/or vinyl-cli(7)** +The session close reason descriptions ``REM_CLOSE`` and ``REQ_CLOSE`` have been +generalized from "Client Closed" / "Client requested close" to "Peer Closed" / +"Peer requested close" since they apply to both client and backend connections. vinylstat ========= -**XXX changes concerning vinylstat(1) and/or vinyl-counters(7)** - -vinyltest -========= - -**XXX changes concerning vinyltest(1) and/or vtc(7)** +The workspace overflow counters (``ws_backend_overflow``, ``ws_client_overflow``, +``ws_thread_overflow``, ``ws_session_overflow``) are now shown by default +instead of requiring the ``diag`` level. Changes for developers and VMOD authors ======================================= -**XXX changes concerning VRT, the public APIs, source code organization, -builds etc.** +``VSL_Setup()`` has been replaced with ``VSL_Init()`` (to initialize +caller-provided space as a VSL buffer) and ``VSL_Alloc()`` (to allocate the +default ``vsl_buffer`` on the heap). ``VSL_Free()`` has been added to free the +memory allocated by ``VSL_Alloc()``. The coccinelle script +``tools/coccinelle/vsl_setup_retire.cocci`` can be used to partially automate +the transition. + +Request methods are now represented as a bitmap in ``struct http``, which +allows turning method evaluations into simple bitwise operations instead of +string comparisons. *eof* diff --git a/doc/sphinx/whats-new/upgrading-9.0.rst b/doc/sphinx/whats-new/upgrading-9.0.rst index b65ee9685d..e581fe6f9b 100644 --- a/doc/sphinx/whats-new/upgrading-9.0.rst +++ b/doc/sphinx/whats-new/upgrading-9.0.rst @@ -1,33 +1,69 @@ -**Note: This is a working document for a future release, with running -updates for changes in the development branch. For changes in the -released versions of Varnish, see:** :ref:`whats-new-index` - .. _whatsnew_upgrading_9.0: %%%%%%%%%%%%%%%%%%%%%% Upgrading to Vinyl 9.0 %%%%%%%%%%%%%%%%%%%%%% -**XXX: how to upgrade from previous deployments to this -version. Limited to work that has to be done for an upgrade, new -features are listed in "Changes". Explicitly mention what does *not* -have to be changed, especially in VCL. May include, but is not limited -to:** +This document only lists breaking changes that you should be aware of when +upgrading from Vinyl 8.x to 9.0. For a complete list of changes, +please refer to the `change log`_ or :ref:`whatsnew_changes_9.0`. + +.. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst + +Name change +=========== + +As you `may have noticed`_, the product name has been changed from "Varnish cache" +to "Vinyl cache", and this is the first release under the new name. All binaries, +documentation, and other references have been updated to reflect this change. +Starting from this release, the main binary is now ``vinyld`` instead of ``varnishd``. +Similarly, all VUTs were renamed accordingly (``vinyllog``, ``vinylncsa``.. etc). + +Besides this cosmetic change, there are no functional changes related to the name change, +and the upgrade process should be as usual. + +.. _`may have noticed`: https://vinyl-cache.org/#years-old-and-it-is-time-to-get-serious-er + +vinyld +====== + +VCL variable ``beresp.storage_hint`` removed +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The VCL variable ``beresp.storage_hint`` has been removed. If you were using +this variable in your VCL, you will need to remove any references to it. + +VCL variable ``req.ttl`` deprecated +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The ``req.ttl`` variable has been renamed to ``req.max_age`` for clarity. +``req.ttl`` is retained as an alias and continues to work, but is now +deprecated and will be removed in a future version of Vinyl. You should update +your VCL to use ``req.max_age`` instead. + +Content-Length handling for requests without body +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For requests having no request body, the ``Content-Length`` header will now +only be unset when the request method is one of: ``GET``, ``HEAD``, ``DELETE``, +``OPTIONS``, ``TRACE``. For other methods, a ``Content-Length`` header with +value 0 will be set instead. This may affect backends that are sensitive to +the presence of the ``Content-Length`` header. -* Elements of VCL that have been removed or are deprecated, or whose - semantics have changed. +Upgrade notes for VMOD developers +================================= -* -p parameters that have been removed or are deprecated, or whose - semantics have changed. +``VSL_Setup()`` replaced with ``VSL_Init()`` and ``VSL_Alloc()`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* Changes in the CLI. +``VSL_Setup()`` has been replaced with two new functions: -* Changes in the output or interpretation of stats or the log, including - changes affecting vinylncsa/-hist/-top. +- ``VSL_Init()`` to initialize caller-provided space as a VSL buffer +- ``VSL_Alloc()`` to allocate the default ``vsl_buffer`` on the heap -* Changes that may be necessary in VTCs or in the use of vinyltest. +``VSL_Free()`` has been added to free the memory allocated by ``VSL_Alloc()``. -* Changes in public APIs that may require changes in VMODs or VAPI/VUT - clients. +The coccinelle script ``tools/coccinelle/vsl_setup_retire.cocci`` can be used +to partially automate the transition (it does not add ``VSL_Free()`` calls). *eof* From 9f8b4210fb4d3b2f71cde8828ece458d2e4482ef Mon Sep 17 00:00:00 2001 From: Walid Boudebouda Date: Wed, 11 Mar 2026 18:22:23 +0100 Subject: [PATCH 119/196] Docs: 8.x was still varnish --- doc/sphinx/whats-new/upgrading-9.0.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/sphinx/whats-new/upgrading-9.0.rst b/doc/sphinx/whats-new/upgrading-9.0.rst index e581fe6f9b..2caf8c51b1 100644 --- a/doc/sphinx/whats-new/upgrading-9.0.rst +++ b/doc/sphinx/whats-new/upgrading-9.0.rst @@ -5,7 +5,7 @@ Upgrading to Vinyl 9.0 %%%%%%%%%%%%%%%%%%%%%% This document only lists breaking changes that you should be aware of when -upgrading from Vinyl 8.x to 9.0. For a complete list of changes, +upgrading from varnish 8.x to vinyl 9.0. For a complete list of changes, please refer to the `change log`_ or :ref:`whatsnew_changes_9.0`. .. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst From 7dba4b7cebf179be05a68d95fa24e3372b0ef68f Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 11 Mar 2026 20:22:02 +0100 Subject: [PATCH 120/196] Polish project name We have not yet published the project identity guide, but the project is called Vinyl Cache without a dash. The dash is used where technically required instead of whitespace, for example in a domain name. --- doc/changes.rst | 20 ++++++++++---------- doc/sphinx/whats-new/changes-9.0.rst | 20 ++++++++++---------- doc/sphinx/whats-new/upgrading-9.0.rst | 16 ++++++++-------- 3 files changed, 28 insertions(+), 28 deletions(-) diff --git a/doc/changes.rst b/doc/changes.rst index f2657eedab..bafa6282e0 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -35,7 +35,7 @@ individual releases. These documents are updated as part of the release process. ============================ -Vinyl-Cache 9.0 (2026-03-16) +Vinyl Cache 9.0 (2026-03-16) ============================ .. PLEASE keep this roughly in commit order as shown by git-log / tig @@ -124,14 +124,14 @@ Vinyl-Cache 9.0 (2026-03-16) .. _4416: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4416 * A new ``bereq.retry_connect`` variable was added to VCL to control whether - Vinyl will make a second attempt to connect to the backend if a first connection - reuse attempt failed. This can be useful to prevent undesired retries of - potentially non-idempotent requests. Setting to ``false`` means that no retries - will be made. However, setting this to ``true`` does not guarantee that a retry - will always be attempted, as there are other factors involved in the decision - (ex: a request body not being cached). This parameter only affects automatic - retries triggered by connection reuse failures and does not affect VCL - retries. (`4416`_) + ``vinyld`` will make a second attempt to connect to the backend if a first + connection reuse attempt failed. This can be useful to prevent undesired + retries of potentially non-idempotent requests. Setting to ``false`` means + that no retries will be made. However, setting this to ``true`` does not + guarantee that a retry will always be attempted, as there are other factors + involved in the decision (ex: a request body not being cached). This parameter + only affects automatic retries triggered by connection reuse failures and does + not affect VCL retries. (`4416`_) .. _4354: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4354 @@ -161,7 +161,7 @@ Vinyl-Cache 9.0 (2026-03-16) * ``req.ttl`` has been renamed to ``req.max_age`` for clarity, with ``req.ttl`` being retained as an alias. ``req.ttl`` is now deprecated, but no warning is - emitted yet. It will be removed in a future version of Vinyl-Cache. (`4389`_) + emitted yet. It will be removed in a future version of Vinyl Cache. (`4389`_) * The session close reason descriptions ``REM_CLOSE`` and ``REQ_CLOSE`` have been generalized from "Client Closed" / "Client requested close" to "Peer Closed" / diff --git a/doc/sphinx/whats-new/changes-9.0.rst b/doc/sphinx/whats-new/changes-9.0.rst index 6713022f50..58b3bb8412 100644 --- a/doc/sphinx/whats-new/changes-9.0.rst +++ b/doc/sphinx/whats-new/changes-9.0.rst @@ -1,13 +1,13 @@ .. _whatsnew_changes_9.0: -%%%%%%%%%%%%%%%%%%%% -Changes in Vinyl 9.0 -%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%%%%%% +Changes in Vinyl Cache 9.0 +%%%%%%%%%%%%%%%%%%%%%%%%%% For information about updating your current Varnish deployment to the new version, see :ref:`whatsnew_upgrading_9.0`. -A more detailed and technical account of changes in Vinyl, with +A more detailed and technical account of changes in Vinyl Cache, with links to issues that have been fixed and pull requests that have been merged, may be found in the `change log`_. @@ -47,12 +47,12 @@ The ``req.ttl`` variable has been renamed to ``req.max_age`` for clarity. ``req.ttl`` is retained as an alias but is now deprecated and will be removed in a future version. -A new ``bereq.retry_connect`` variable has been added to control whether Vinyl -will make a second attempt to connect to the backend if a first connection -reuse attempt failed. This can be useful to prevent undesired retries of -potentially non-idempotent requests. Setting to ``false`` means no retries will -be made. This parameter only affects automatic retries triggered by connection -reuse failures and does not affect VCL retries. +A new ``bereq.retry_connect`` variable has been added to control whether +``vinyld`` will make a second attempt to connect to the backend if a first +connection reuse attempt failed. This can be useful to prevent undesired retries +of potentially non-idempotent requests. Setting to ``false`` means no retries +will be made. This parameter only affects automatic retries triggered by +connection reuse failures and does not affect VCL retries. Other changes to VCL ~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/sphinx/whats-new/upgrading-9.0.rst b/doc/sphinx/whats-new/upgrading-9.0.rst index 2caf8c51b1..cbb084854e 100644 --- a/doc/sphinx/whats-new/upgrading-9.0.rst +++ b/doc/sphinx/whats-new/upgrading-9.0.rst @@ -1,8 +1,8 @@ .. _whatsnew_upgrading_9.0: -%%%%%%%%%%%%%%%%%%%%%% -Upgrading to Vinyl 9.0 -%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%%%%%%%% +Upgrading to Vinyl Cache 9.0 +%%%%%%%%%%%%%%%%%%%%%%%%%%%% This document only lists breaking changes that you should be aware of when upgrading from varnish 8.x to vinyl 9.0. For a complete list of changes, @@ -13,8 +13,8 @@ please refer to the `change log`_ or :ref:`whatsnew_changes_9.0`. Name change =========== -As you `may have noticed`_, the product name has been changed from "Varnish cache" -to "Vinyl cache", and this is the first release under the new name. All binaries, +As you `may have noticed`_, the project name has been changed from "Varnish Cache" +to "Vinyl Cache", and this is the first release under the new name. All binaries, documentation, and other references have been updated to reflect this change. Starting from this release, the main binary is now ``vinyld`` instead of ``varnishd``. Similarly, all VUTs were renamed accordingly (``vinyllog``, ``vinylncsa``.. etc). @@ -37,9 +37,9 @@ VCL variable ``req.ttl`` deprecated ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The ``req.ttl`` variable has been renamed to ``req.max_age`` for clarity. -``req.ttl`` is retained as an alias and continues to work, but is now -deprecated and will be removed in a future version of Vinyl. You should update -your VCL to use ``req.max_age`` instead. +``req.ttl`` is retained as an alias and continues to work, but is now deprecated +and will be removed in a future version of Vinyl Cache. You should update your +VCL to use ``req.max_age`` instead. Content-Length handling for requests without body ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From da2b7a1cc1e532964468c6f69959f129e79a6622 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Wed, 11 Mar 2026 20:07:47 +0000 Subject: [PATCH 121/196] Temp fix: rename one of the 4415 anchors to 4415a --- doc/changes.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/changes.rst b/doc/changes.rst index bafa6282e0..4617cfb55c 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -100,10 +100,10 @@ Vinyl Cache 9.0 (2026-03-16) * Improved VCL comparison for probes, backends and ACLs that could lead to C-compiler errors in the past. (`4418`_) -.. _4415: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4415 +.. _4415a: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4415 * Fixed probes comparison in VCC which used to wrongly convert operands to string - before performing the comparison. (`4415`_) + before performing the comparison. (`4415a`_) .. _4409: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4409 From d248731b5d74ada8c5c8feb1c504fbaaba033006 Mon Sep 17 00:00:00 2001 From: Walid Boudebouda Date: Wed, 11 Mar 2026 22:17:59 +0100 Subject: [PATCH 122/196] changes: Fixup incorrect ticket number --- doc/changes.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/changes.rst b/doc/changes.rst index 4617cfb55c..218b741473 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -100,10 +100,10 @@ Vinyl Cache 9.0 (2026-03-16) * Improved VCL comparison for probes, backends and ACLs that could lead to C-compiler errors in the past. (`4418`_) -.. _4415a: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4415 +.. _4417: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4417 * Fixed probes comparison in VCC which used to wrongly convert operands to string - before performing the comparison. (`4415a`_) + before performing the comparison. (`4417`_) .. _4409: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4409 From 17eb049cae1e4185358dc43eaa728b67db76e200 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 10:40:48 +0100 Subject: [PATCH 123/196] Stabilize vtcs --- bin/vinyltest/tests/r01524.vtc | 2 ++ bin/vinyltest/tests/r01806.vtc | 1 + bin/vinyltest/tests/r01881.vtc | 2 ++ vmod/tests/directors_c00004.vtc | 4 ++++ 4 files changed, 9 insertions(+) diff --git a/bin/vinyltest/tests/r01524.vtc b/bin/vinyltest/tests/r01524.vtc index 77b9e54245..3acd75a5a5 100644 --- a/bin/vinyltest/tests/r01524.vtc +++ b/bin/vinyltest/tests/r01524.vtc @@ -20,3 +20,5 @@ client c1 { expect resp.status == 200 expect resp.bodylen == 4 } -run + +server s1 -wait diff --git a/bin/vinyltest/tests/r01806.vtc b/bin/vinyltest/tests/r01806.vtc index d345361233..9d05c2b325 100644 --- a/bin/vinyltest/tests/r01806.vtc +++ b/bin/vinyltest/tests/r01806.vtc @@ -31,3 +31,4 @@ client c1 { rxresp expect resp.status == 200 } -run +server s1 -wait diff --git a/bin/vinyltest/tests/r01881.vtc b/bin/vinyltest/tests/r01881.vtc index dfee508c4d..6f76138fd6 100644 --- a/bin/vinyltest/tests/r01881.vtc +++ b/bin/vinyltest/tests/r01881.vtc @@ -21,3 +21,5 @@ client c1 { rxresp expect resp.status == 200 } -run + +server s1 -wait diff --git a/vmod/tests/directors_c00004.vtc b/vmod/tests/directors_c00004.vtc index 753311b583..1567a7466d 100644 --- a/vmod/tests/directors_c00004.vtc +++ b/vmod/tests/directors_c00004.vtc @@ -117,3 +117,7 @@ client c1 { rxresp expect resp.body == "xiuFi3Pe" } -run + +server s1 -wait +server s2 -wait +server s3 -wait From 1097e70ad3b2bc8c4a3cfcee951129e5aeebe191 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 11:35:48 +0100 Subject: [PATCH 124/196] Stabilize purge test The object being hit can still be busy 1004 Hit c 1002 -0.000732 10.000000 0.000000 2 2 --- vmod/tests/purge_c00000.vtc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vmod/tests/purge_c00000.vtc b/vmod/tests/purge_c00000.vtc index f8714c37b4..695fb58502 100644 --- a/vmod/tests/purge_c00000.vtc +++ b/vmod/tests/purge_c00000.vtc @@ -60,7 +60,7 @@ vinyl v1 -vcl+backend { } -start logexpect l1 -v v1 -q Hit -i Hit { - expect * * Hit "^1002 -.+ 10.000000 0.000000$" + expect * * Hit "^1002 -.+ 10.000000 0.000000" } -start logexpect l2 -v v1 -q "Begin ~ bgfetch" { From 7b0aeadedf20d5960cc6efc814d9109c9a9b5916 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 12:05:59 +0100 Subject: [PATCH 125/196] Try to stabilize r03159 differently This reverts commit 7f40311d4eab6153534e956e9fb425e227426e2f. Deliberately avoiding a loop construct to keep the shell code simple --- bin/vinyltest/tests/r03159.vtc | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/bin/vinyltest/tests/r03159.vtc b/bin/vinyltest/tests/r03159.vtc index a2465479de..6c33749795 100644 --- a/bin/vinyltest/tests/r03159.vtc +++ b/bin/vinyltest/tests/r03159.vtc @@ -14,13 +14,20 @@ process p1 -log { -l 2m 2>&1 } -start -expect-exit 0x40 +shell { + # wait for startup vcl.load to complete + vinyladm -n ${tmpdir}/t ping || + vinyladm -n ${tmpdir}/t ping || + vinyladm -n ${tmpdir}/t ping || + vinyladm -n ${tmpdir}/t ping +} + process p1 -screen_dump process p1 -expect-text 0 1 "Unused sub foo, defined:" process p1 -expect-text 0 1 "(That was just a warning)" process p2 -log { set -e - vinyladm -n ${tmpdir}/t ping || (sleep 3 && vinyladm -n ${tmpdir}/t ping) vinyladm -n ${tmpdir}/t "vcl.list" vinyladm -n ${tmpdir}/t -t 20 "vcl.load unref ${tmpdir}/unref.vcl" vinyladm -n ${tmpdir}/t "vcl.list" From 03a90e75c84837f428081c288103bf04e0847083 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 12:08:59 +0100 Subject: [PATCH 126/196] Stabilize VDPIO_Notify() test Trying to get around adding real synchronization to the simple debug implementation. Closes #4471 --- vmod/vmod_debug_transport_vai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vmod/vmod_debug_transport_vai.c b/vmod/vmod_debug_transport_vai.c index d537898288..62627eca82 100644 --- a/vmod/vmod_debug_transport_vai.c +++ b/vmod/vmod_debug_transport_vai.c @@ -190,7 +190,7 @@ vdpio_reluctant_fini(struct vdp_ctx *vdc, void **priv) // // This a is cheap and wrong (for real code) way to wait for any pending // notification task to complete - but after all this is vmod_debug - VTIM_sleep(reluctant_delay); + VTIM_sleep(reluctant_delay * 10); } static const struct vdp vdp_reluctant = { From 1c6912b2103616f91f5ad2ebda48ee6464059b33 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 13:34:33 +0100 Subject: [PATCH 127/196] Update Server: and Via: headers I went for Vinyl-Cache with a dash, because https://httpwg.org/specs/rfc9110.html#field.server refers to "product" from User-Agent, https://httpwg.org/specs/rfc9110.html#field.user-agent defines "product" as "token/token" and https://httpwg.org/specs/rfc9110.html#rule.token.separators includes "-" and ALPHA, but no whitespace --- bin/vinyld/cache/cache_fetch.c | 2 +- bin/vinyld/cache/cache_http.c | 2 +- bin/vinyld/cache/cache_req_fsm.c | 2 +- bin/vinyld/http1/cache_http1_deliver.c | 2 +- bin/vinyltest/tests/c00018.vtc | 2 +- bin/vinyltest/tests/r03794.vtc | 4 ++-- vmod/tests/vtc_l00000.vtc | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/bin/vinyld/cache/cache_fetch.c b/bin/vinyld/cache/cache_fetch.c index cb04c35520..6225803436 100644 --- a/bin/vinyld/cache/cache_fetch.c +++ b/bin/vinyld/cache/cache_fetch.c @@ -1006,7 +1006,7 @@ vbf_stp_error(struct worker *wrk, struct busyobj *bo) "Backend fetch failed"); http_TimeHeader(bo->beresp, "Date: ", now); - http_SetHeader(bo->beresp, "Server: Varnish"); + http_SetHeader(bo->beresp, "Server: Vinyl-Cache"); stale = bo->stale_oc; oc->t_origin = now; diff --git a/bin/vinyld/cache/cache_http.c b/bin/vinyld/cache/cache_http.c index 9ac1efc4a5..e4bad05e49 100644 --- a/bin/vinyld/cache/cache_http.c +++ b/bin/vinyld/cache/cache_http.c @@ -226,7 +226,7 @@ HTTP_Init(void) vsb = VSB_new_auto(); AN(vsb); - VSB_printf(vsb, "1.1 %s (Varnish/" PACKAGE_BRANCH ")", + VSB_printf(vsb, "1.1 %s (Vinyl-Cache/" PACKAGE_BRANCH ")", heritage.identity); AZ(VSB_finish(vsb)); REPLACE(via_hdr, VSB_data(vsb)); diff --git a/bin/vinyld/cache/cache_req_fsm.c b/bin/vinyld/cache/cache_req_fsm.c index 50f7c067d3..456160303b 100644 --- a/bin/vinyld/cache/cache_req_fsm.c +++ b/bin/vinyld/cache/cache_req_fsm.c @@ -193,7 +193,7 @@ Resp_Setup_Synth(struct req *req) http_PutResponse(h, "HTTP/1.1", req->err_code, req->err_reason); http_TimeHeader(h, "Date: ", W_TIM_real(req->wrk)); - http_SetHeader(h, "Server: Varnish"); + http_SetHeader(h, "Server: Vinyl-Cache"); http_PrintfHeader(h, "X-Vinyl: %ju", VXID(req->vsl->wid)); /* diff --git a/bin/vinyld/http1/cache_http1_deliver.c b/bin/vinyld/http1/cache_http1_deliver.c index 4cc31ad99f..4c2a663278 100644 --- a/bin/vinyld/http1/cache_http1_deliver.c +++ b/bin/vinyld/http1/cache_http1_deliver.c @@ -45,7 +45,7 @@ v1d_error(struct req *req, struct v1l **v1lp, const char *msg) { static const char r_500[] = "HTTP/1.1 500 Internal Server Error\r\n" - "Server: Varnish\r\n" + "Server: Vinyl-Cache\r\n" "Connection: close\r\n\r\n"; uint64_t bytes; diff --git a/bin/vinyltest/tests/c00018.vtc b/bin/vinyltest/tests/c00018.vtc index 802e2bb1e5..5943cf8b60 100644 --- a/bin/vinyltest/tests/c00018.vtc +++ b/bin/vinyltest/tests/c00018.vtc @@ -126,7 +126,7 @@ logexpect l1 -v v1 -g raw { expect 0 1011 RespStatus {^405$} expect 0 1011 RespReason {^Method Not Allowed$} expect 0 1011 RespHeader {^Date:} - expect 0 1011 RespHeader {^Server: Varnish$} + expect 0 1011 RespHeader {^Server: Vinyl-Cache$} expect 0 1011 RespHeader {^X-Vinyl: 1011$} expect * 1011 Timestamp {^Process:} diff --git a/bin/vinyltest/tests/r03794.vtc b/bin/vinyltest/tests/r03794.vtc index 407c897e12..21c60fec2e 100644 --- a/bin/vinyltest/tests/r03794.vtc +++ b/bin/vinyltest/tests/r03794.vtc @@ -3,7 +3,7 @@ vtest "Append configurable Via header" server s1 { rxreq expect req.http.via == \ - "1.1 v2 (Varnish/${pkg_branch}), 1.1 v1 (Varnish/${pkg_branch})" + "1.1 v2 (Vinyl-Cache/${pkg_branch}), 1.1 v1 (Vinyl-Cache/${pkg_branch})" txresp } -start @@ -19,5 +19,5 @@ client c1 -connect ${v2_sock} { txreq rxresp expect resp.http.via == \ - "1.1 v1 (Varnish/${pkg_branch}), 1.1 v2 (Varnish/${pkg_branch})" + "1.1 v1 (Vinyl-Cache/${pkg_branch}), 1.1 v2 (Vinyl-Cache/${pkg_branch})" } -run diff --git a/vmod/tests/vtc_l00000.vtc b/vmod/tests/vtc_l00000.vtc index 02de6956b9..bee4164b99 100644 --- a/vmod/tests/vtc_l00000.vtc +++ b/vmod/tests/vtc_l00000.vtc @@ -38,7 +38,7 @@ vinyl v1 -vcl { **** v1 vsl| 1001 RespStatus c 200 **** v1 vsl| 1001 RespReason c OK **** v1 vsl| 1001 RespHeader c Date: Thu, 27 Jan 2022 12:06:00 GMT -**** v1 vsl| 1001 RespHeader c Server: Varnish +**** v1 vsl| 1001 RespHeader c Server: Vinyl-Cache **** v1 vsl| 1001 RespHeader c X-Vinyl: 1001 **** v1 vsl| 1001 VCL_call c SYNTH **** v1 vsl| 1001 RespHeader c Match: true From 5d5ba22d8738e839a0a94b8f4e7732669183102c Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 14:06:24 +0100 Subject: [PATCH 128/196] Polish project name --- doc/sphinx/installation/install.rst | 2 +- doc/sphinx/reference/vcl_var.rst | 2 +- doc/sphinx/reference/vinyld.rst | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/sphinx/installation/install.rst b/doc/sphinx/installation/install.rst index e4dc727e27..3ee4e5f2af 100644 --- a/doc/sphinx/installation/install.rst +++ b/doc/sphinx/installation/install.rst @@ -38,7 +38,7 @@ want to compile Varnish from source for other reasons: install_source -Other pre-built Vinyl-Cache packages +Other pre-built Vinyl Cache packages ==================================== We will update this as things appear after the name change. diff --git a/doc/sphinx/reference/vcl_var.rst b/doc/sphinx/reference/vcl_var.rst index 3223d3b88a..2736a74124 100644 --- a/doc/sphinx/reference/vcl_var.rst +++ b/doc/sphinx/reference/vcl_var.rst @@ -561,7 +561,7 @@ req.ttl Deprecated alias of ``req.max-age``, which will be removed in a future - version of Vinyl-Cache. + version of Vinyl Cache. .. _req.url: diff --git a/doc/sphinx/reference/vinyld.rst b/doc/sphinx/reference/vinyld.rst index 75b8cc1761..5c4fcb9253 100644 --- a/doc/sphinx/reference/vinyld.rst +++ b/doc/sphinx/reference/vinyld.rst @@ -522,9 +522,9 @@ specific options. Available jails are: groupadd vinyl useradd -g vinyl -d /nonexistent -s /bin/false \ - -c "Vinyl-Cache Daemon User" vinyl + -c "Vinyl Cache Daemon User" vinyl useradd -g vinyl -d /nonexistent -s /bin/false \ - -c "Vinyl-Cache Worker User" vcache + -c "Vinyl Cache Worker User" vcache -j none From e778be2c97d0d52a212c0276defdb1df7f370821 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 13:59:24 +0100 Subject: [PATCH 129/196] Update vtest2 --- bin/vinyltest/vtest2 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/vinyltest/vtest2 b/bin/vinyltest/vtest2 index 7fb081e117..bb9d7dd020 160000 --- a/bin/vinyltest/vtest2 +++ b/bin/vinyltest/vtest2 @@ -1 +1 @@ -Subproject commit 7fb081e117d969e0dd78f5f9131e54b45ced04e5 +Subproject commit bb9d7dd020b03825c799dd8009ae2cce66aec2b2 From 3cca71cb88da6c3889da50b3e59e8292644851e9 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 14:01:48 +0100 Subject: [PATCH 130/196] Update jail code to use the vinyl user this was already reflected in the documentation (git grep useradd) --- .circleci/config.yml | 10 +++++----- bin/vinyld/mgt/mgt_jail_unix.c | 2 +- bin/vinyltest/tests/j00000.vtc | 6 +++--- bin/vinyltest/tests/j00001.vtc | 8 ++++---- bin/vinyltest/tests/j00003.vtc | 2 +- bin/vinyltest/tests/j00004.vtc | 12 ++++++------ doc/sphinx/reference/vinyld.rst | 14 ++++++++++++++ 7 files changed, 34 insertions(+), 20 deletions(-) diff --git a/.circleci/config.yml b/.circleci/config.yml index 1866172acf..d976893737 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -326,19 +326,19 @@ jobs: case "<< parameters.dist >>" in archlinux) - useradd varnish + useradd vinyl ;; almalinux|fedora) - adduser varnish + adduser vinyl ;; *) - adduser --disabled-password --gecos "" varnish + adduser --disabled-password --gecos "" vinyl ;; esac - chown -R varnish:varnish . + chown -R vinyl:vinyl . - sudo -u varnish sh -c ' + sudo -u vinyl sh -c ' export ASAN_OPTIONS=abort_on_error=1,detect_odr_violation=1,detect_leaks=1,detect_stack_use_after_return=1,detect_invalid_pointer_pairs=1,handle_segv=0,handle_sigbus=0,use_sigaltstack=0,disable_coredump=0 export LSAN_OPTIONS=abort_on_error=1,use_sigaltstack=0,suppressions=$(pwd)/tools/lsan.suppr export TSAN_OPTIONS=abort_on_error=1,halt_on_error=1,use_sigaltstack=0,suppressions=$(pwd)/tools/tsan.suppr diff --git a/bin/vinyld/mgt/mgt_jail_unix.c b/bin/vinyld/mgt/mgt_jail_unix.c index a9b32dc686..5d4f35a75d 100644 --- a/bin/vinyld/mgt/mgt_jail_unix.c +++ b/bin/vinyld/mgt/mgt_jail_unix.c @@ -57,7 +57,7 @@ static gid_t vju_cc_gid; static int vju_cc_gid_set; #ifndef VINYL_USER -#define VINYL_USER "varnish" +#define VINYL_USER "vinyl" #endif #ifndef VCACHE_USER diff --git a/bin/vinyltest/tests/j00000.vtc b/bin/vinyltest/tests/j00000.vtc index 895037f714..3ed3f08d5c 100644 --- a/bin/vinyltest/tests/j00000.vtc +++ b/bin/vinyltest/tests/j00000.vtc @@ -1,7 +1,7 @@ vtest "Code coverage basic UNIX jail" -feature user_varnish -feature group_varnish +feature user_vinyl +feature group_vinyl feature root server s1 { @@ -10,7 +10,7 @@ server s1 { } -start vinyl v1 \ - -jail "-junix,user=varnish,ccgroup=varnish" \ + -jail "-junix,user=vinyl,ccgroup=vinyl" \ -vcl+backend { } -start diff --git a/bin/vinyltest/tests/j00001.vtc b/bin/vinyltest/tests/j00001.vtc index a2b5c1a7bd..e196355a64 100644 --- a/bin/vinyltest/tests/j00001.vtc +++ b/bin/vinyltest/tests/j00001.vtc @@ -1,10 +1,10 @@ vtest "Run worker with different uid in UNIX jail" -# The "vrun" user must have login group "varnish" +# The "vrun" user must have login group "vinyl" -feature user_varnish +feature user_vinyl feature user_vcache -feature group_varnish +feature group_vinyl feature root server s1 { @@ -13,7 +13,7 @@ server s1 { } -start vinyl v1 \ - -jail "-junix,user=varnish,ccgroup=varnish,workuser=vcache" \ + -jail "-junix,user=vinyl,ccgroup=vinyl,workuser=vcache" \ -vcl+backend { } -start diff --git a/bin/vinyltest/tests/j00003.vtc b/bin/vinyltest/tests/j00003.vtc index 0ffbc37921..9463cecd9c 100644 --- a/bin/vinyltest/tests/j00003.vtc +++ b/bin/vinyltest/tests/j00003.vtc @@ -7,6 +7,6 @@ shell -err -expect "user not found" "vinyld -junix,user=/// -f ''" shell -err -expect "user not found" "vinyld -junix,workuser=/// -f ''" shell -err -expect "group not found" "vinyld -junix,ccgroup=/// -f ''" -feature user_varnish +feature user_vinyl shell -err -expect "have different login groups" "vinyld -junix,workuser=root -f ''" diff --git a/bin/vinyltest/tests/j00004.vtc b/bin/vinyltest/tests/j00004.vtc index f5988d854f..095a7f3c09 100644 --- a/bin/vinyltest/tests/j00004.vtc +++ b/bin/vinyltest/tests/j00004.vtc @@ -1,7 +1,7 @@ vtest "Listen at a Unix domain socket while in jail" -feature user_varnish -feature group_varnish +feature user_vinyl +feature group_vinyl feature root server s1 { @@ -10,7 +10,7 @@ server s1 { } -start vinyl v1 -arg "-a ${tmpdir}/v1.sock" \ - -jail "-junix,user=varnish,ccgroup=varnish" \ + -jail "-junix,user=vinyl,ccgroup=vinyl" \ -vcl+backend { } -start @@ -28,12 +28,12 @@ server s1 { txresp } -start -vinyl v2 -arg "-a ${tmpdir}/v2.sock,user=varnish,group=varnish,mode=666" \ - -jail "-junix,user=varnish,ccgroup=varnish" \ +vinyl v2 -arg "-a ${tmpdir}/v2.sock,user=vinyl,group=vinyl,mode=666" \ + -jail "-junix,user=vinyl,ccgroup=vinyl" \ -vcl+backend { } -start -shell -match "rw-rw-rw-.+varnish.+varnish" { ls -l ${tmpdir}/v2.sock } +shell -match "rw-rw-rw-.+vinyl.+vinyl" { ls -l ${tmpdir}/v2.sock } client c1 -connect "${tmpdir}/v2.sock" { txreq diff --git a/doc/sphinx/reference/vinyld.rst b/doc/sphinx/reference/vinyld.rst index 5c4fcb9253..e8bad3f076 100644 --- a/doc/sphinx/reference/vinyld.rst +++ b/doc/sphinx/reference/vinyld.rst @@ -517,6 +517,14 @@ specific options. Available jails are: The users given for the `user` and `workuser` arguments need to have the same primary ("login") group. + For users migrating from Varnish Cache, shell commands similar to the + following may be used to remove the previous default user and group:: + + userdel varnish || true + userdel vcache || true + userdel varnishlog || true # to remove reference to varnish group + groupdel varnish || true + To set up a system for the default users with a group name ``vinyl``, shell commands similar to these may be used:: @@ -525,6 +533,12 @@ specific options. Available jails are: -c "Vinyl Cache Daemon User" vinyl useradd -g vinyl -d /nonexistent -s /bin/false \ -c "Vinyl Cache Worker User" vcache + useradd -g vinyl -d /nonexistent -s /bin/false \ + -c "Vinyl Log User" vinyllog + + Note that the ``vinyllog`` user is not required and only added because, by + convention, it may be used to run ``vinyllog``, ``vinylncsa`` and other + VSM/VSL based tools. -j none From 49fe69755778de3c043ed9d292a85b1b3b498e1f Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 14:26:58 +0100 Subject: [PATCH 131/196] Replace varnish-cache.org with vinyl-cache.org in all places except for the old trac links, about which I just asked... --- .github/ISSUE_TEMPLATE.md | 2 +- .github/ISSUE_TEMPLATE/bug-report.yml | 2 +- .github/ISSUE_TEMPLATE/config.yml | 4 ++-- .github/workflows/coverity.yml | 2 +- bin/vinyld/storage/mgt_stevedore.c | 2 +- bin/vinyltest/tests/o00003.vtc | 4 ++-- doc/changes.rst | 2 +- tools/coverity-run | 2 +- 8 files changed, 10 insertions(+), 10 deletions(-) diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md index 0090c0c568..b860fdfa92 100644 --- a/.github/ISSUE_TEMPLATE.md +++ b/.github/ISSUE_TEMPLATE.md @@ -3,5 +3,5 @@ Bug report is here. https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/new?assignees=&labels=&template=bug-report.yml Questions or need help is here -https://varnish-cache.org/support/index.html +https://vinyl-cache.org/support/index.html --> diff --git a/.github/ISSUE_TEMPLATE/bug-report.yml b/.github/ISSUE_TEMPLATE/bug-report.yml index f574e30ff5..ebcc725f5e 100644 --- a/.github/ISSUE_TEMPLATE/bug-report.yml +++ b/.github/ISSUE_TEMPLATE/bug-report.yml @@ -10,7 +10,7 @@ body: If it's a packaging bug (including sysv or systemd services bugs) please open an issue on [varnishcache/pkg-varnish-cache](https://code.vinyl-cache.org/vinyl-cache/pkg-vinyl-cache) instead. - If it's a feature request, please start a thread on the [varnish-misc](https://varnish-cache.org/support/index.html#mailing-lists) list instead. + If it's a feature request, please start a thread on the [varnish-misc](https://vinyl-cache.org/support/index.html#mailing-lists) list instead. - type: textarea attributes: diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml index 8ca24cae96..72779ed09c 100644 --- a/.github/ISSUE_TEMPLATE/config.yml +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -1,8 +1,8 @@ blank_issues_enabled: true contact_links: - name: Getting Help - url: https://varnish-cache.org/support/index.html + url: https://vinyl-cache.org/support/index.html about: If you have questions or need help, please click here. - name: Report a security vulnerability - url: https://varnish-cache.org/security/index.html#i-have-found-a-security-hole + url: https://vinyl-cache.org/security/index.html#i-have-found-a-security-hole about: Report a security vulnerability. diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml index 3c3d28a001..7ea0cbe18b 100644 --- a/.github/workflows/coverity.yml +++ b/.github/workflows/coverity.yml @@ -34,5 +34,5 @@ jobs: - uses: vapier/coverity-scan-action@v1.8.0 with: project: varnish - email: varnish-dev@varnish-cache.org + email: vinyl-dev@vinyl-cache.org token: ${{ secrets.COVERITY_SCAN_TOKEN }} diff --git a/bin/vinyld/storage/mgt_stevedore.c b/bin/vinyld/storage/mgt_stevedore.c index b62248365f..4cfff78023 100644 --- a/bin/vinyld/storage/mgt_stevedore.c +++ b/bin/vinyld/storage/mgt_stevedore.c @@ -142,7 +142,7 @@ smp_fake_init(struct stevedore *parent, int ac, char * const *av) (void)av; ARGV_ERR( "-spersistent has been deprecated, please see:\n" - " https://www.varnish-cache.org/docs/trunk/phk/persistent.html\n" + " https://www.vinyl-cache.org/docs/trunk/phk/persistent.html\n" "for details.\n" ); } diff --git a/bin/vinyltest/tests/o00003.vtc b/bin/vinyltest/tests/o00003.vtc index 87d139be8e..825460b11d 100644 --- a/bin/vinyltest/tests/o00003.vtc +++ b/bin/vinyltest/tests/o00003.vtc @@ -19,7 +19,7 @@ vinyl v1 -proto PROXY -vcl+backend { vtc.proxy_header(v1, client.ip, server.ip), 36B)); set beresp.http.proxy2 = blob.encode(encoding=HEX, blob=vtc.proxy_header(v2, client.ip, server.ip, - "vtc.varnish-cache.org")); + "vtc.vinyl-cache.org")); } } -start @@ -30,5 +30,5 @@ client c1 -proxy1 "1.2.3.4:1111 5.6.7.8:5678" { expect resp.http.ci == 1.2.3.4 expect resp.http.si == 5.6.7.8 expect resp.http.proxy1 == "PROXY TCP4 1.2.3.4 5.6.7.8 1111 5678" - expect resp.http.proxy2 == "0d0a0d0a000d0a515549540a2111002401020304050607080457162e0200157674632e7661726e6973682d63616368652e6f7267" + expect resp.http.proxy2 == "0d0a0d0a000d0a515549540a2111002201020304050607080457162e0200137674632e76696e796c2d63616368652e6f7267" } -run diff --git a/doc/changes.rst b/doc/changes.rst index 218b741473..07a9242eac 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -30,7 +30,7 @@ development and past versions: Official information about changes in releases and advise on the upgrade process can be found in the ``doc/sphinx/whats-new/`` directory, also available in HTML format at -http://varnish-cache.org/docs/trunk/whats-new/index.html and via +http://vinyl-cache.org/docs/trunk/whats-new/index.html and via individual releases. These documents are updated as part of the release process. diff --git a/tools/coverity-run b/tools/coverity-run index 3d733683cd..295fff3a96 100755 --- a/tools/coverity-run +++ b/tools/coverity-run @@ -19,7 +19,7 @@ if [ -z "`which cov-build`" ]; then fi if [ -z "$EMAIL" ]; then - EMAIL="varnish-dev@varnish-cache.org" + EMAIL="vinyl-dev@varnish-cache.org" fi From 8697ca6676c2801e2002f162b6622a6104e382f8 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 14:53:57 +0100 Subject: [PATCH 132/196] varnish-cache.org references I overlooked earlier --- doc/sphinx/phk/trialerror.rst | 2 +- doc/sphinx/users-guide/storage-backends.rst | 2 +- doc/sphinx/users-guide/vcl-separate.rst | 6 +++--- tools/coverity-run | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/sphinx/phk/trialerror.rst b/doc/sphinx/phk/trialerror.rst index 568876c7a0..3e7e974d24 100644 --- a/doc/sphinx/phk/trialerror.rst +++ b/doc/sphinx/phk/trialerror.rst @@ -96,7 +96,7 @@ GUI or a hole in your firewall. The tester sends a report to the project server with ssh(1), and the reporter, which is just 750 lines of python code, ingests and digests the report and spits out some `pidgin HTML -`_ with the information I actually +`_ with the information I actually want to see. And just like with the varnishtest program before it, once I diff --git a/doc/sphinx/users-guide/storage-backends.rst b/doc/sphinx/users-guide/storage-backends.rst index 64780e05fd..77cc55b398 100644 --- a/doc/sphinx/users-guide/storage-backends.rst +++ b/doc/sphinx/users-guide/storage-backends.rst @@ -25,7 +25,7 @@ objects, the rule of thumb is *n* x ``transit_buffer``. Storage backends are also called stevedores. -.. _vmods: https://www.varnish-cache.org/vmods +.. _vmods: https://www.vinyl-cache.org/vmods Besides the built-in storage backends, separately distributed extensions exist, diff --git a/doc/sphinx/users-guide/vcl-separate.rst b/doc/sphinx/users-guide/vcl-separate.rst index 225dc1c9a5..0c540228b0 100644 --- a/doc/sphinx/users-guide/vcl-separate.rst +++ b/doc/sphinx/users-guide/vcl-separate.rst @@ -14,7 +14,7 @@ a separate VCL files for separate vhosts or any other distinct subset of requests. Assume that we want to handle ``varnish.org`` with one VCL file -and ``varnish-cache.org`` with another VCL file. +and ``vinyl-cache.org`` with another VCL file. First load the two VCL files:: @@ -45,10 +45,10 @@ request:: if (req.http.host ~ "\.?varnish\.org$") { return (vcl(l_vo)); } - if (req.http.host ~ "\.?varnish-cache\.org$") { + if (req.http.host ~ "\.?vinyl-cache\.org$") { return (vcl(l_vc)); } - return (synth(302, "http://varnish-cache.org")); + return (synth(302, "http://vinyl-cache.org")); } sub vcl_synth { diff --git a/tools/coverity-run b/tools/coverity-run index 295fff3a96..0e2b2c6506 100755 --- a/tools/coverity-run +++ b/tools/coverity-run @@ -19,7 +19,7 @@ if [ -z "`which cov-build`" ]; then fi if [ -z "$EMAIL" ]; then - EMAIL="vinyl-dev@varnish-cache.org" + EMAIL="vinyl-dev@vinyl-cache.org" fi From ea5556fbd38d47dfeec511f6b0d6ca6717b083b2 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 14:42:16 +0100 Subject: [PATCH 133/196] Replace varnishd with vinyld in all "current" places I tried to spare historic documentation where varnishd is actually correct. --- .github/ISSUE_TEMPLATE/bug-report.yml | 14 +++++++------- bin/vinyld/cache/cache_vpi.c | 2 +- bin/vinyld/cache/cache_vrt_var.c | 2 +- bin/vinyld/cache/cache_ws_common.c | 2 +- bin/vinyld/mgt/mgt_jail_solaris.c | 2 +- bin/vinyld/mgt/mgt_util.c | 8 ++++---- bin/vinyld/vclflint.sh | 4 ++-- doc/sphinx/installation/install_source.rst | 2 +- doc/sphinx/installation/platformnotes.rst | 2 +- doc/sphinx/phk/apispaces.rst | 4 ++-- doc/sphinx/phk/thatslow.rst | 2 +- doc/sphinx/reference/cli_protocol.rst | 2 +- doc/sphinx/users-guide/operation-logging.rst | 2 +- doc/sphinx/users-guide/run_security.rst | 6 +++--- doc/sphinx/users-guide/troubleshooting.rst | 8 ++++---- doc/sphinx/users-guide/vcl-built-in-code.rst | 2 +- flint.lnt | 2 +- include/vapi/vsl_int.h | 2 +- include/vapi/vsm.h | 4 ++-- lib/libvcc/vcc_vmod.c | 2 +- lib/libvinyl/vin.c | 2 +- lib/libvinylapi/vsc.c | 2 +- lib/libvinylapi/vsl_cursor.c | 8 ++++---- tools/coccinelle/README.rst | 6 +++--- tools/coccinelle/vcocci.sh | 2 +- tools/coccinelle/vdef.h | 4 ++-- tools/gcov_digest.py | 2 +- vmod/flint.sh | 2 +- 28 files changed, 51 insertions(+), 51 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/bug-report.yml b/.github/ISSUE_TEMPLATE/bug-report.yml index ebcc725f5e..33e9e1ae7a 100644 --- a/.github/ISSUE_TEMPLATE/bug-report.yml +++ b/.github/ISSUE_TEMPLATE/bug-report.yml @@ -5,13 +5,13 @@ body: attributes: value: |+ Did you check that there are no similar bug reports or pull requests? - + If your panic happens in the child_sigsegv_handler function, look at the backtrace to determine whether it is similar to another issue. When in doubt, open a new one and it will be closed as a duplicate if needed. - + If it's a packaging bug (including sysv or systemd services bugs) please open an issue on [varnishcache/pkg-varnish-cache](https://code.vinyl-cache.org/vinyl-cache/pkg-vinyl-cache) instead. - + If it's a feature request, please start a thread on the [varnish-misc](https://vinyl-cache.org/support/index.html#mailing-lists) list instead. - + - type: textarea attributes: label: Expected Behavior @@ -55,8 +55,8 @@ body: attributes: label: Varnish Cache version description: |+ - The version can be obtained by "varnishd -V". - placeholder: "varnishd (varnish-7.3.0 revision 84d79120b6d17b11819a663a93160743f293e63f)" + The version can be obtained by "vinyld -V". + placeholder: "vinyld (vinyl-cache-trunk revision 82fff61ce98a282c721d2026c7649403bc1d18eb)" - type: input attributes: placeholder: Ubuntu22.04 @@ -64,4 +64,4 @@ body: - type: input attributes: label: Source of binary packages used (if any) - placeholder: https://packagecloud.io/varnishcache/ + placeholder: https://code.vinyl-cache.org/ diff --git a/bin/vinyld/cache/cache_vpi.c b/bin/vinyld/cache/cache_vpi.c index 7527133d2b..05cc857285 100644 --- a/bin/vinyld/cache/cache_vpi.c +++ b/bin/vinyld/cache/cache_vpi.c @@ -44,7 +44,7 @@ #include "cache_vcl.h" /*-------------------------------------------------------------------- - * Private & exclusive interfaces between VCC and varnishd + * Private & exclusive interfaces between VCC and vinyld */ const size_t vpi_wrk_len = sizeof(struct wrk_vpi); diff --git a/bin/vinyld/cache/cache_vrt_var.c b/bin/vinyld/cache/cache_vrt_var.c index d32b995214..557fc9c348 100644 --- a/bin/vinyld/cache/cache_vrt_var.c +++ b/bin/vinyld/cache/cache_vrt_var.c @@ -985,7 +985,7 @@ VRT_r_server_identity(VRT_CTX) if (heritage.identity != NULL) return (heritage.identity); else - return ("varnishd"); + return ("vinyld"); } VCL_STRING diff --git a/bin/vinyld/cache/cache_ws_common.c b/bin/vinyld/cache/cache_ws_common.c index bf82072448..684e7dece5 100644 --- a/bin/vinyld/cache/cache_ws_common.c +++ b/bin/vinyld/cache/cache_ws_common.c @@ -77,7 +77,7 @@ WS_Overflowed(const struct ws *ws) /* * Reset the WS to a cookie or its start and clears any overflow * - * for varnishd internal use only + * for vinyld internal use only */ void diff --git a/bin/vinyld/mgt/mgt_jail_solaris.c b/bin/vinyld/mgt/mgt_jail_solaris.c index de685f8f88..f5affd2a31 100644 --- a/bin/vinyld/mgt/mgt_jail_solaris.c +++ b/bin/vinyld/mgt/mgt_jail_solaris.c @@ -112,7 +112,7 @@ * / -g command line option and elevated privileges but without proc_setid, * e.g.: * - * pfexec ppriv -e -s A=basic,net_privaddr,sys_resource varnishd ... + * pfexec ppriv -e -s A=basic,net_privaddr,sys_resource vinyld ... * * - allow coredumps of setid processes (ignoring SNOCD) * diff --git a/bin/vinyld/mgt/mgt_util.c b/bin/vinyld/mgt/mgt_util.c index 6ccf67cee2..4a26ed50b5 100644 --- a/bin/vinyld/mgt/mgt_util.c +++ b/bin/vinyld/mgt/mgt_util.c @@ -71,10 +71,10 @@ void mgt_ProcTitle(const char *comp) { #ifdef HAVE_SETPROCTITLE - if (strcmp(heritage.identity, "varnishd")) - setproctitle("Varnish-%s -i %s", comp, heritage.identity); + if (strcmp(heritage.identity, "vinyld")) + setproctitle("vinyld-%s -i %s", comp, heritage.identity); else - setproctitle("Varnish-%s", comp); + setproctitle("vinyld-%s", comp); #else (void)comp; #endif @@ -105,7 +105,7 @@ mgt_DumpRstVsl(void) printf( "\n.. The following is autogenerated output from " - "varnishd -x vsl\n\n"); + "vinyld -x vsl\n\n"); #define SLTM(tag, flags, sdesc, ldesc) mgt_sltm(#tag, sdesc, ldesc); #include "tbl/vsl_tags.h" diff --git a/bin/vinyld/vclflint.sh b/bin/vinyld/vclflint.sh index 742265144a..b3a830e953 100755 --- a/bin/vinyld/vclflint.sh +++ b/bin/vinyld/vclflint.sh @@ -4,9 +4,9 @@ LIBS="-p vmod_path=/home/phk/Varnish/trunk/varnish-cache/vmod/.libs" if [ "x$1" = "x" ] ; then - ./varnishd $LIBS -C -b localhost > /tmp/_.c + ./vinyld $LIBS -C -b localhost > /tmp/_.c elif [ -f $1 ] ; then - ./varnishd $LIBS -C -f $1 > /tmp/_.c + ./vinyld $LIBS -C -f $1 > /tmp/_.c else echo "usage!" 1>&2 fi diff --git a/doc/sphinx/installation/install_source.rst b/doc/sphinx/installation/install_source.rst index 903a92c39e..f825b622b1 100644 --- a/doc/sphinx/installation/install_source.rst +++ b/doc/sphinx/installation/install_source.rst @@ -323,5 +323,5 @@ Installing And finally, the true test of a brave heart: ``sudo make install`` Varnish will now be installed in ``/usr/local``. The ``vinyld`` binary is in -`/usr/local/sbin/varnishd`. To make sure that the necessary links and caches +`/usr/local/sbin/vinyld`. To make sure that the necessary links and caches of the most recent shared libraries are found, run ``sudo ldconfig``. diff --git a/doc/sphinx/installation/platformnotes.rst b/doc/sphinx/installation/platformnotes.rst index fea488749a..deb688e267 100644 --- a/doc/sphinx/installation/platformnotes.rst +++ b/doc/sphinx/installation/platformnotes.rst @@ -24,7 +24,7 @@ To ensure ``tmpfs`` is used, check the following: Determine the *workdir*. If you use a specific ``-n`` option to ``vinyld`` or set the ``VINYL_DEFAULT_N`` variable, it is that value. Otherwise run -``varnishd -x options``, which outputs the *workdir* default. +``vinyld -x options``, which outputs the *workdir* default. Run ``df *workdir*``. If it reports ``tmpfs`` as the file system in the first column, no additional action is necessary. diff --git a/doc/sphinx/phk/apispaces.rst b/doc/sphinx/phk/apispaces.rst index 23d04aa4bf..63c8c39acb 100644 --- a/doc/sphinx/phk/apispaces.rst +++ b/doc/sphinx/phk/apispaces.rst @@ -127,7 +127,7 @@ The VMOD PACKAGE API/ABI ------------------------ This API space provides access to everything in the ``VRT`` API -space plus the other exposed and supported APIs in varnishd. +space plus the other exposed and supported APIs in vinyld. | Include files allowed: | @@ -152,7 +152,7 @@ their VRT cousins be checked for compatibility on VMOD import. The VMOD SOURCE API/ABI ----------------------- -This API space provides access to private parts of varnishd and its +This API space provides access to private parts of vinyld and its use is highly discouraged, unless you absolutely have to, You can #include any file from the varnish source tree and use diff --git a/doc/sphinx/phk/thatslow.rst b/doc/sphinx/phk/thatslow.rst index 179dea2c44..bf24d66ee2 100644 --- a/doc/sphinx/phk/thatslow.rst +++ b/doc/sphinx/phk/thatslow.rst @@ -119,7 +119,7 @@ source code, from the panic/backtrace code over the "miniobj" type-safety to obscure hints to Gimpel Softwares FlexeLint product. Needless to say, it is also not by accident that the 20K lines of -testcases exercise over 90% of the varnishd source code lines. +testcases exercise over 90% of the vinyld source code lines. And insisting on doing things right, rather than *"we can fix it properly later"* which is so widespread in FOSS source code [#f7]_, diff --git a/doc/sphinx/reference/cli_protocol.rst b/doc/sphinx/reference/cli_protocol.rst index 6cfd99dfad..89c1aae6f8 100644 --- a/doc/sphinx/reference/cli_protocol.rst +++ b/doc/sphinx/reference/cli_protocol.rst @@ -54,7 +54,7 @@ the ``-T`` argument, this will also be written to shared memory, so ``vinyladm`` keeps working:: # Bind to internal network - varnishd -T 192.168.10.21:3245 + vinyld -T 192.168.10.21:3245 You can also configure ``vinyld`` to actively open a TCP connection to another "controller" program, with the ``-M`` argument. diff --git a/doc/sphinx/users-guide/operation-logging.rst b/doc/sphinx/users-guide/operation-logging.rst index f4d19b7e35..300620922b 100644 --- a/doc/sphinx/users-guide/operation-logging.rst +++ b/doc/sphinx/users-guide/operation-logging.rst @@ -38,7 +38,7 @@ to see that everything is OK. Now go to the browser and reload the page displaying your web app. -.. XXX:Doesn't this require a setup of a running varnishd and a web application being cached? benc +.. XXX:Doesn't this require a setup of a running vinyld and a web application being cached? benc You'll see lines like these.:: diff --git a/doc/sphinx/users-guide/run_security.rst b/doc/sphinx/users-guide/run_security.rst index baf37d1836..8fbf6d2d47 100644 --- a/doc/sphinx/users-guide/run_security.rst +++ b/doc/sphinx/users-guide/run_security.rst @@ -93,7 +93,7 @@ initiate a CLI connection to your central Varnish management facility. The connection in this case is also without encryption, but the remote end must still authenticate using ``-S``\ /`PSK`_. -Finally, if you run varnishd with the ``-d`` option, you get a CLI +Finally, if you run vinyld with the ``-d`` option, you get a CLI command on stdin/stdout, but since you started the process, it would be hard to prevent you getting CLI access, wouldn't it ? @@ -138,9 +138,9 @@ from shared memory, but on remote systems, you need to give :ref:`vinyladm(1)` a copy of the secret file, with the -S argument. If you want to disable ``-S``\ /PSK authentication, use an ``-S none`` -argument to varnishd:: +argument to vinyld:: - varnishd [...] -S none [...] + vinyld [...] -S none [...] Parameters ^^^^^^^^^^ diff --git a/doc/sphinx/users-guide/troubleshooting.rst b/doc/sphinx/users-guide/troubleshooting.rst index bd3295ee81..416c2d4d91 100644 --- a/doc/sphinx/users-guide/troubleshooting.rst +++ b/doc/sphinx/users-guide/troubleshooting.rst @@ -31,7 +31,7 @@ added. This will give you some more information on what is going on. Let us see how Varnish will react when something else is listening on its port.:: - # varnishd -n foo -f /usr/local/etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000 -a 0.0.0.0:8080 -d + # vinyld -n foo -f /usr/local/etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000 -a 0.0.0.0:8080 -d storage_malloc: max size 1024 MB. Using old SHMFILE Platform: Linux,2.6.32-21-generic,i686,-smalloc,-hcritbit @@ -120,7 +120,7 @@ data. you actually get them. For example on linux, learn about ``/proc/sys/kernel/core_pattern`` from the `core(5)` manpage. * Make sure core dumps are allowed in the parent shell from which - varnishd is being started. In shell, this would be:: + vinyld is being started. In shell, this would be:: ulimit -c unlimited @@ -137,11 +137,11 @@ A basic debug session for varnish installed under ``/usr/local`` could look like this:: $ cd /usr/local/var/varnish/`uname -n`/ - $ gdb /usr/local/sbin/varnishd core + $ gdb /usr/local/sbin/vinyld core GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. [...] - Core was generated by `/usr/local/sbin/varnishd -a 127.0.0.1:8080 -b 127.0.0.1:8080'. + Core was generated by `/usr/local/sbin/vinyld -a 127.0.0.1:8080 -b 127.0.0.1:8080'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. diff --git a/doc/sphinx/users-guide/vcl-built-in-code.rst b/doc/sphinx/users-guide/vcl-built-in-code.rst index cab68751fe..e9cdcf5979 100644 --- a/doc/sphinx/users-guide/vcl-built-in-code.rst +++ b/doc/sphinx/users-guide/vcl-built-in-code.rst @@ -175,7 +175,7 @@ Built-in VCL reference ---------------------- A copy of the ``builtin.vcl`` file can be obtained by running -``varnishd -x builtin``. +``vinyld -x builtin``. The VCL compilation happens in two passes: diff --git a/flint.lnt b/flint.lnt index b9f0f47733..b5d43e01ff 100644 --- a/flint.lnt +++ b/flint.lnt @@ -326,7 +326,7 @@ -esym(534, wrefresh) /////////////////////////////////////////////////////////////////////// -// vmod_debug, put here because it is used twice (varnishd2 and separate) +// vmod_debug, put here because it is used twice (vinyld2 and separate) -esym(768, arg_xyzzy_debug_argtest::*) /////////////////////////////////////////////////////////////////////// diff --git a/include/vapi/vsl_int.h b/include/vapi/vsl_int.h index 4781b4aea5..04ca23f4cc 100644 --- a/include/vapi/vsl_int.h +++ b/include/vapi/vsl_int.h @@ -69,7 +69,7 @@ * directly on the shmlog data. * * Notice that the constants in these macros cannot be changed without - * changing corresponding magic numbers in varnishd/cache/cache_shmlog.c + * changing corresponding magic numbers in vinyld/cache/cache_shmlog.c */ #define VSL_CLIENTMARKER (1ULL<<62) diff --git a/include/vapi/vsm.h b/include/vapi/vsm.h index 2d45046b63..6339e24165 100644 --- a/include/vapi/vsm.h +++ b/include/vapi/vsm.h @@ -101,11 +101,11 @@ int VSM_Arg(struct vsm *, char flag, const char *arg); * * If arg is "off", VSM_Attach() will wait forever. * Otherwise arg is the number of seconds to be patient - * while the varnishd manager process gets started. + * while the vinyld manager process gets started. * * The default is five seconds. * - * 'n' Configure varnishd instance to access + * 'n' Configure vinyld instance to access * * The default is the hostname. */ diff --git a/lib/libvcc/vcc_vmod.c b/lib/libvcc/vcc_vmod.c index 6fe8b04508..670c41646e 100644 --- a/lib/libvcc/vcc_vmod.c +++ b/lib/libvcc/vcc_vmod.c @@ -213,7 +213,7 @@ vcc_ParseJSON(const struct vcc *tl, const char *jsn, struct vmod_import *vim) VSB_printf(tl->sb, "\tFile name: %s\n", vim->path); VSB_printf(tl->sb, "\tVMOD wants ABI version %u.%u\n", vim->major, vim->minor); - VSB_printf(tl->sb, "\tvarnishd provides ABI version %u.%u\n", + VSB_printf(tl->sb, "\tvinyld provides ABI version %u.%u\n", VRT_MAJOR_VERSION, VRT_MINOR_VERSION); return (""); } diff --git a/lib/libvinyl/vin.c b/lib/libvinyl/vin.c index b7fd7716ae..bc3541e934 100644 --- a/lib/libvinyl/vin.c +++ b/lib/libvinyl/vin.c @@ -42,7 +42,7 @@ #include "vin.h" #include "vsb.h" -#define VINYL_DEFAULT_REL_NAME "varnishd" +#define VINYL_DEFAULT_REL_NAME "vinyld" char * VIN_n_Arg(const char *n_arg) diff --git a/lib/libvinylapi/vsc.c b/lib/libvinylapi/vsc.c index 29c6e08088..2248ff265d 100644 --- a/lib/libvinylapi/vsc.c +++ b/lib/libvinylapi/vsc.c @@ -399,7 +399,7 @@ vsc_map_seg(const struct vsc *vsc, struct vsm *vsm, struct vsc_seg *sp) /* It isn't ready yet. Sleep and try again. If it still * isn't ready, fail the mapping. The transitions inside - * varnishd that we are waiting for are just some memcpy() + * vinyld that we are waiting for are just some memcpy() * operations, so there is no reason to allow a long retry * time. */ for (retry = 10; retry > 0 && head->ready == 0; retry--) diff --git a/lib/libvinylapi/vsl_cursor.c b/lib/libvinylapi/vsl_cursor.c index 1c957b6bdf..4ab54bbf5a 100644 --- a/lib/libvinylapi/vsl_cursor.c +++ b/lib/libvinylapi/vsl_cursor.c @@ -204,7 +204,7 @@ vslc_vsm_reset(const struct VSL_cursor *cursor) VRMB(); if (c->options & VSL_COPT_TAIL) { - /* Start in the same segment varnishd currently is in and + /* Start in the same segment vinyld currently is in and run forward until we see the end */ u = c->next.priv = segment_n; assert(c->head->offset[c->next.priv % VSL_SEGMENTS] >= 0); @@ -212,7 +212,7 @@ vslc_vsm_reset(const struct VSL_cursor *cursor) c->head->offset[c->next.priv % VSL_SEGMENTS]; do { if (c->head->segment_n - u > 1) { - /* Give up if varnishd is moving faster + /* Give up if vinyld is moving faster than us */ return (vsl_e_overrun); } @@ -221,8 +221,8 @@ vslc_vsm_reset(const struct VSL_cursor *cursor) if (r != vsl_end) return (r); } else { - /* Starting (VSL_SEGMENTS - 3) behind varnishd. This way - * even if varnishd advances segment_n immediately, we'll + /* Starting (VSL_SEGMENTS - 3) behind vinyld. This way + * even if vinyld advances segment_n immediately, we'll * still have a full segment worth of log before the * general constraint of at least 2 segments apart will be * broken. diff --git a/tools/coccinelle/README.rst b/tools/coccinelle/README.rst index a611aed76d..9856928feb 100644 --- a/tools/coccinelle/README.rst +++ b/tools/coccinelle/README.rst @@ -20,14 +20,14 @@ For in-tree usage, see the ``vcocci.sh`` script for convenience. Unless noted otherwise, all patches should work when invoked as:: spatch --macro-file tools/coccinelle/vdef.h \ - -I include/ -I bin/varnishd/ --dir . --in-place \ + -I include/ -I bin/vinyld/ --dir . --in-place \ --sp-file $COCCI To expand a patch and see the implicit rules that will be taken into account, it is possible to parse the file:: spatch --macro-file tools/coccinelle/vdef.h \ - -I include/ -I bin/varnishd/ --parse-cocci + -I include/ -I bin/vinyld/ --parse-cocci --sp-file $COCCI The ``archive/`` directory contains patches which we used once and @@ -87,7 +87,7 @@ In such cases, *do* check for parse errors in the affected file using for file in $(find . -name \*.c) ; do if spatch --macro-file tools/coccinelle/vdef.h \ - -I include/ -I bin/varnishd/ --parse-c $file 2>&1 | + -I include/ -I bin/vinyld/ --parse-c $file 2>&1 | grep -C 5 -E '^BAD' ; then echo ; echo $file fi diff --git a/tools/coccinelle/vcocci.sh b/tools/coccinelle/vcocci.sh index 64c4ae3696..c6235496ec 100755 --- a/tools/coccinelle/vcocci.sh +++ b/tools/coccinelle/vcocci.sh @@ -68,7 +68,7 @@ exec_spatch() { exec spatch \ --macro-file "$SRCDIR/tools/coccinelle/vdef.h" \ -I "$SRCDIR/include/" \ - -I "$SRCDIR/bin/varnishd/" \ + -I "$SRCDIR/bin/vinyld/" \ "$@" } diff --git a/tools/coccinelle/vdef.h b/tools/coccinelle/vdef.h index 43ca64595c..196204df29 100644 --- a/tools/coccinelle/vdef.h +++ b/tools/coccinelle/vdef.h @@ -36,10 +36,10 @@ /* lib/libvcc/vcc_vmod.c */ #define STANZA_TBL -/* bin/varnishd/common/heritage.h */ +/* bin/vinyld/common/heritage.h */ #define ASSERT_MGT() (void)0 -/* bin/varnishd/cache/cache_transport.h */ +/* bin/vinyld/cache/cache_transport.h */ #define TRANSPORTS /* vmod/vcc_*_if.h */ diff --git a/tools/gcov_digest.py b/tools/gcov_digest.py index 529b103dbe..151744233f 100644 --- a/tools/gcov_digest.py +++ b/tools/gcov_digest.py @@ -158,7 +158,7 @@ def run_gcov(prog, subdir): # if we find the .o file in a .../.libs the sources # must be found relative to the parent directory - if "varnishd" in root: + if "vinyld" in root: subdir = root.split("/")[-1] cmd = ["cd " + root + "/.. && " + "exec " + prog + " " + subdir + "/" + fn] rpath = "/../" diff --git a/vmod/flint.sh b/vmod/flint.sh index 53f97fd695..4906496b42 100644 --- a/vmod/flint.sh +++ b/vmod/flint.sh @@ -10,6 +10,6 @@ for vmod in vmod_*.vcc ; do echo "${vmod}" echo "=====================" vmod="${vmod#vmod_}" - FLOPS="-I../bin/varnishd -I../lib/libvgz vcc_${vmod}_if.c vmod_${vmod}*.c" \ + FLOPS="-I../bin/vinyld -I../lib/libvgz vcc_${vmod}_if.c vmod_${vmod}*.c" \ ../tools/flint_skel.sh $* done From b19539cf2d41737b375fa3c6cbdb5f8bda014ba2 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 15:28:43 +0100 Subject: [PATCH 134/196] Update h2 canned response Server header --- bin/vinyld/http2/cache_http2_deliver.c | 4 ++-- bin/vinyltest/tests/r02589.vtc | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/bin/vinyld/http2/cache_http2_deliver.c b/bin/vinyld/http2/cache_http2_deliver.c index bb1a48f2af..af20966f46 100644 --- a/bin/vinyld/http2/cache_http2_deliver.c +++ b/bin/vinyld/http2/cache_http2_deliver.c @@ -230,8 +230,8 @@ static const uint8_t h2_500_resp[] = { // content-length 0 0x1f, 0x0d, 0x01, 0x30, - // server Varnish - 0x1f, 0x27, 0x07, 'V', 'a', 'r', 'n', 'i', 's', 'h', + // server Vinyl-Cache + 0x1f, 0x27, 0x0b, 'V', 'i', 'n', 'y', 'l', '-', 'C', 'a', 'c', 'h', 'e' }; static void diff --git a/bin/vinyltest/tests/r02589.vtc b/bin/vinyltest/tests/r02589.vtc index 09503bc47d..8f76c7b8b3 100644 --- a/bin/vinyltest/tests/r02589.vtc +++ b/bin/vinyltest/tests/r02589.vtc @@ -24,7 +24,7 @@ client c1 { rxresp expect resp.status == 500 expect resp.http.content-length == 0 - expect resp.http.server == "Varnish" + expect resp.http.server == "Vinyl-Cache" } -run } -run From b740437cf7ff55773aeac4fa3a2420699dcbef80 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 15:45:44 +0100 Subject: [PATCH 135/196] Shorten solaris jail complaint the reason is really not a good one, but: r03159 fails because the relevant error scrolled out of view --- bin/vinyld/mgt/mgt_jail_solaris.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/bin/vinyld/mgt/mgt_jail_solaris.c b/bin/vinyld/mgt/mgt_jail_solaris.c index f5affd2a31..4519ac6bf7 100644 --- a/bin/vinyld/mgt/mgt_jail_solaris.c +++ b/bin/vinyld/mgt/mgt_jail_solaris.c @@ -450,8 +450,7 @@ vjs_setuid(void) AZ(setppriv(PRIV_OFF, PRIV_EFFECTIVE, vjs_proc_setid)); AZ(setppriv(PRIV_OFF, PRIV_PERMITTED, vjs_proc_setid)); } else { - MGT_Complain(C_SECURITY, - "Privilege %s missing, will not change uid/gid", + MGT_Complain(C_SECURITY, "%s missing, uid/gid unchanged", PRIV_PROC_SETID); } } From 539b11f7a9335fb10e6ff944ef1105443473e38c Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 15:22:18 +0100 Subject: [PATCH 136/196] More complete varnish->vinyl replace Before applying the following command, I had excluded doc/ by replacing all Varnish in doc with Vinyl and commiting that into a discarded commit. Then this command was applied wholesale: git reset --hard ; for f in $(git grep -lP '([vV])arnish(?!(-softwar| Software))') ; do mv $f $f.o && perl -ne <$f.o >$f 's#([vV])arnish(?!(-softwar| Software))#\1inyl#gm; print $_;' && rm $f.o ; done ; git diff The resulting permission changes were manually reverted (I should have used cp -p instead of mv(. Then I manually reverted/edited the following: - bin/vinyld/storage/storage_persistent.h SMP_IDENT_STRING - etc/Makefile.am Vinyl -> Vinyl Cache - bin/vinyld/storage/storage_umem.c vinyl -> vinyld - etc/devicedetect.vcl preserve Copyright, Vinyl -> Vinyl Cache - include/tbl/params.h: "${sysconfdir}/vinyl-cache:${datadir}/vinyl-cache/vcl" "${libdir}/vinyl-cache/vmods" each instead of just vinyl - include/vrt.h preserve Varnish 5.0 - tools/vtest.sh revert all and leave up to phk - vinyl.m4 preserve Varnish - vmod/tests/cookie_r00028.vtc preserve URL - vmod/vmod_directors.vcc preserve URL - vinyl-legacy.m4 preserve Varnish - vmod/vmod_math_gen.py Vinyl -> Vinyl Cache --- .circleci/config.yml | 18 +++++++-------- .circleci/make-apk-packages.sh | 8 +++---- .circleci/make-deb-packages.sh | 4 ++-- .circleci/make-rpm-packages.sh | 10 ++++----- .github/ISSUE_TEMPLATE/bug-report.yml | 6 ++--- .github/workflows/cifuzz.yml | 4 ++-- .github/workflows/coverity.yml | 4 ++-- .gitignore | 6 ++--- bin/vinyld/acceptor/cache_acceptor.c | 6 ++--- bin/vinyld/cache/cache.h | 4 ++-- bin/vinyld/cache/cache_conn_pool.c | 2 +- bin/vinyld/cache/cache_esi_deliver.c | 2 +- bin/vinyld/cache/cache_esi_fetch.c | 2 +- bin/vinyld/cache/cache_esi_parse.c | 2 +- bin/vinyld/cache/cache_fetch.c | 2 +- bin/vinyld/cache/cache_main.c | 2 +- bin/vinyld/cache/cache_rfc2616.c | 12 +++++----- bin/vinyld/cache/cache_vary.c | 2 +- bin/vinyld/hash/hash_critbit.c | 2 +- bin/vinyld/hpack/vhp.h | 4 ++-- bin/vinyld/mgt/mgt_jail_solaris.c | 14 ++++++------ bin/vinyld/mgt/mgt_jail_solaris_tbl.h | 2 +- bin/vinyld/storage/storage_umem.c | 2 +- bin/vinyld/vclflint.sh | 2 +- bin/vinylhist/flint.lnt | 4 ++-- bin/vinyllog/flint.lnt | 2 +- bin/vinylncsa/flint.lnt | 2 +- bin/vinylstat/flint.lnt | 4 ++-- bin/vinylstat/flint.sh | 6 ++--- bin/vinyltest/flint.lnt | 2 +- bin/vinyltest/tests/b00000.vtc | 4 ++-- bin/vinyltest/tests/b00003.vtc | 2 +- bin/vinyltest/tests/b00004.vtc | 2 +- bin/vinyltest/tests/b00044.vtc | 2 +- bin/vinyltest/tests/b00062.vtc | 4 ++-- bin/vinyltest/tests/b00063.vtc | 4 ++-- bin/vinyltest/tests/b00064.vtc | 2 +- bin/vinyltest/tests/b00071.vtc | 2 +- bin/vinyltest/tests/b00079.vtc | 2 +- bin/vinyltest/tests/b00089.vtc | 2 +- bin/vinyltest/tests/b00090.vtc | 2 +- bin/vinyltest/tests/c00042.vtc | 2 +- bin/vinyltest/tests/c00086.vtc | 22 +++++++++--------- bin/vinyltest/tests/c00114.vtc | 4 ++-- bin/vinyltest/tests/c00124.vtc.disabled | 30 ++++++++++++------------- bin/vinyltest/tests/d00007.vtc | 4 ++-- bin/vinyltest/tests/d00008.vtc | 2 +- bin/vinyltest/tests/d00009.vtc | 2 +- bin/vinyltest/tests/d00010.vtc | 2 +- bin/vinyltest/tests/d00011.vtc | 2 +- bin/vinyltest/tests/d00012.vtc | 4 ++-- bin/vinyltest/tests/d00013.vtc | 2 +- bin/vinyltest/tests/e00019.vtc | 2 +- bin/vinyltest/tests/e00029.vtc.disabled | 4 ++-- bin/vinyltest/tests/f00005.vtc | 2 +- bin/vinyltest/tests/g00002.vtc | 4 ++-- bin/vinyltest/tests/h00006.vtc | 2 +- bin/vinyltest/tests/h00007.vtc | 2 +- bin/vinyltest/tests/p00003.vtc | 2 +- bin/vinyltest/tests/r00667.vtc | 2 +- bin/vinyltest/tests/r01030.vtc | 4 ++-- bin/vinyltest/tests/r01252.vtc.disabled | 22 +++++++++--------- bin/vinyltest/tests/r01284.vtc | 4 ++-- bin/vinyltest/tests/r01562.vtc | 2 +- bin/vinyltest/tests/r01576.vtc | 8 +++---- bin/vinyltest/tests/r01737.vtc | 2 +- bin/vinyltest/tests/r01857.vtc | 2 +- bin/vinyltest/tests/r02295.vtc.disabled | 8 +++---- bin/vinyltest/tests/r02555.vtc | 2 +- bin/vinyltest/tests/r02702.vtc | 6 ++--- bin/vinyltest/tests/r02831.vtc | 2 +- bin/vinyltest/tests/r03098.vtc | 2 +- bin/vinyltest/tests/r03940.vtc | 2 +- bin/vinyltest/tests/s00007.vtc | 2 +- bin/vinyltest/tests/s00010.vtc | 10 ++++----- bin/vinyltest/tests/t02020.vtc | 2 +- bin/vinyltest/tests/u00018.vtc | 2 +- bin/vinyltest/tests/v00038.vtc | 2 +- bin/vinyltest/tests/v00064.vtc | 2 +- bin/vinyltop/flint.lnt | 4 ++-- bin/vinyltop/vinyltop.c | 2 +- contrib/vinylstatdiff | 6 ++--- etc/Makefile.am | 2 +- etc/devicedetect.vcl | 2 +- include/compat/daemon.h | 4 ++-- include/tbl/debug_bits.h | 2 +- include/tbl/params.h | 4 ++-- include/tbl/vsc_levels.h | 2 +- include/vapi/vsm.h | 2 +- include/vcli.h | 2 +- include/vcli_serve.h | 2 +- include/vre.h | 2 +- include/vte.h | 2 +- lib/libvcc/vcc_compile.c | 4 ++-- lib/libvcc/vcc_token.c | 2 +- lib/libvcc/vmodtool.py | 4 ++-- lib/libvinyl/vnum.c | 4 ++-- lib/libvinyl/vsa.c | 2 +- lib/libvinylapi/daemon.c | 2 +- lib/libvinylapi/vut.c | 4 ++-- lib/libvsc/vsctool.py | 2 +- tools/audit_vfl.sh | 2 +- tools/audit_vpf.sh | 2 +- tools/audit_vsha256.sh | 2 +- tools/coccinelle/archive/wrk_vpi.cocci | 2 +- tools/coccinelle/varnish.iso | 6 ++--- tools/coccinelle/vcocci.sh | 4 ++-- tools/coccinelle/vcountof.cocci | 2 +- tools/coccinelle/vminmax.cocci | 2 +- tools/coccinelle/vsl_setup_retire.cocci | 2 +- tools/coverity-run | 4 ++-- tools/lsan.suppr | 2 +- tools/tsan.suppr | 2 +- tools/vtc-bisect.sh | 4 ++-- vinyl-legacy.m4 | 2 +- vmod/vmod_math_gen.py | 2 +- vmod/vmod_vtc.c | 2 +- vsc.am | 2 +- 118 files changed, 229 insertions(+), 229 deletions(-) diff --git a/.circleci/config.yml b/.circleci/config.yml index d976893737..5b651d57ff 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -28,7 +28,7 @@ parameters: jobs: dist: - description: Build or download varnish-x.y.z.tar.gz that is used later for the packaging jobs + description: Build or download vinyl-x.y.z.tar.gz that is used later for the packaging jobs docker: - image: fedora:latest steps: @@ -54,23 +54,23 @@ jobs: - run: name: Download the dist tarball command: | - curl -Ls '<< pipeline.parameters.dist-url >>' -o varnish-dist.tar.gz + curl -Ls '<< pipeline.parameters.dist-url >>' -o vinyl-dist.tar.gz - when: condition: << pipeline.parameters.dist-url-sha256 >> steps: - run: name: Verify downloaded tarball command: | - echo "<< pipeline.parameters.dist-url-sha256 >> varnish-dist.tar.gz" | sha256sum -c + echo "<< pipeline.parameters.dist-url-sha256 >> vinyl-dist.tar.gz" | sha256sum -c - run: name: Rename the dist tarball by parsed version command: | mkdir parse-version-tmp cd parse-version-tmp - tar xzf ../varnish-dist.tar.gz - VERSION=$(varnish-*/configure --version | awk 'NR == 1 {print $NF}') + tar xzf ../vinyl-dist.tar.gz + VERSION=$(vinyl-*/configure --version | awk 'NR == 1 {print $NF}') cd .. - mv -v varnish-dist.tar.gz varnish-${VERSION}.tar.gz + mv -v vinyl-dist.tar.gz vinyl-${VERSION}.tar.gz - unless: condition: << pipeline.parameters.dist-url >> steps: @@ -93,7 +93,7 @@ jobs: root: . paths: - .is_weekly - - varnish*.tar.gz + - vinyl*.tar.gz - tools/*.suppr - .circleci tar_pkg_tools: @@ -184,10 +184,10 @@ jobs: --security-opt seccomp=unconfined \ -e PARAM_DIST=$(echo "<< parameters.platform >>" | cut -d: -f1) \ -e PARAM_RELEASE=$(echo "<< parameters.platform >>" | cut -d: -f2) \ - -v$(pwd):/varnish-cache \ + -v$(pwd):/vinyl-cache \ --platform linux/$ARCH \ << parameters.platform >> \ - /varnish-cache/.circleci/make-$EXT-packages.sh + /vinyl-cache/.circleci/make-$EXT-packages.sh - run: name: List created packages command: find ./packages -type f diff --git a/.circleci/make-apk-packages.sh b/.circleci/make-apk-packages.sh index a8b678f8f4..1857818f11 100755 --- a/.circleci/make-apk-packages.sh +++ b/.circleci/make-apk-packages.sh @@ -15,7 +15,7 @@ elif [ -z "$PARAM_DIST" ]; then exit 1 fi -cd /varnish-cache +cd /vinyl-cache tar xazf alpine.tar.gz --strip 1 adduser -D builder @@ -28,11 +28,11 @@ echo "Generate key" su builder -c "abuild-keygen -nai" echo "Fix APKBUILD's variables" -tar xavf varnish-*.tar.gz -VERSION=$(varnish-*/configure --version | awk 'NR == 1 {print $NF}') +tar xavf vinyl-*.tar.gz +VERSION=$(vinyl-*/configure --version | awk 'NR == 1 {print $NF}') echo "Version: $VERSION" sed -i "s/@VERSION@/$VERSION/" APKBUILD -rm -rf varnish-*/ +rm -rf vinyl-*/ echo "Change the ownership so that abuild is able to write its logs" chown builder -R . diff --git a/.circleci/make-deb-packages.sh b/.circleci/make-deb-packages.sh index 2f05e99d2c..21271f9164 100755 --- a/.circleci/make-deb-packages.sh +++ b/.circleci/make-deb-packages.sh @@ -23,14 +23,14 @@ fi # semop(1): encountered an error: Function not implemented update-alternatives --set fakeroot /usr/bin/fakeroot-tcp -cd /varnish-cache +cd /vinyl-cache ls -la echo "Untar debian..." tar xavf debian.tar.gz echo "Untar orig..." -tar xavf varnish-*.tar.gz --strip 1 +tar xavf vinyl-*.tar.gz --strip 1 echo "Update changelog version..." if [ -e .is_weekly ]; then diff --git a/.circleci/make-rpm-packages.sh b/.circleci/make-rpm-packages.sh index 4a9f8a1423..1b11342814 100755 --- a/.circleci/make-rpm-packages.sh +++ b/.circleci/make-rpm-packages.sh @@ -30,7 +30,7 @@ dnf -y install rpm-build dnf-utils export DIST_DIR=build -cd /varnish-cache +cd /vinyl-cache rm -rf $DIST_DIR mkdir $DIST_DIR @@ -39,7 +39,7 @@ echo "Untar redhat..." tar xavf redhat.tar.gz -C $DIST_DIR echo "Untar orig..." -tar xavf varnish-*.tar.gz -C $DIST_DIR --strip 1 +tar xavf vinyl-*.tar.gz -C $DIST_DIR --strip 1 echo "Build Packages..." if [ -e .is_weekly ]; then @@ -70,9 +70,9 @@ rpmbuild() { "$@" } -dnf builddep -y "$DIST_DIR"/redhat/varnish.spec -rpmbuild -bs "$DIST_DIR"/redhat/varnish.spec -rpmbuild --rebuild "$RESULT_DIR"/varnish-*.src.rpm +dnf builddep -y "$DIST_DIR"/redhat/vinyl.spec +rpmbuild -bs "$DIST_DIR"/redhat/vinyl.spec +rpmbuild --rebuild "$RESULT_DIR"/vinyl-*.src.rpm echo "Prepare the packages for storage..." mkdir -p packages/$PARAM_DIST/$PARAM_RELEASE/ diff --git a/.github/ISSUE_TEMPLATE/bug-report.yml b/.github/ISSUE_TEMPLATE/bug-report.yml index 33e9e1ae7a..6b00e794ad 100644 --- a/.github/ISSUE_TEMPLATE/bug-report.yml +++ b/.github/ISSUE_TEMPLATE/bug-report.yml @@ -8,9 +8,9 @@ body: If your panic happens in the child_sigsegv_handler function, look at the backtrace to determine whether it is similar to another issue. When in doubt, open a new one and it will be closed as a duplicate if needed. - If it's a packaging bug (including sysv or systemd services bugs) please open an issue on [varnishcache/pkg-varnish-cache](https://code.vinyl-cache.org/vinyl-cache/pkg-vinyl-cache) instead. + If it's a packaging bug (including sysv or systemd services bugs) please open an issue on [vinylcache/pkg-vinyl-cache](https://code.vinyl-cache.org/vinyl-cache/pkg-vinyl-cache) instead. - If it's a feature request, please start a thread on the [varnish-misc](https://vinyl-cache.org/support/index.html#mailing-lists) list instead. + If it's a feature request, please start a thread on the [vinyl-misc](https://vinyl-cache.org/support/index.html#mailing-lists) list instead. - type: textarea attributes: @@ -53,7 +53,7 @@ body: required: true - type: input attributes: - label: Varnish Cache version + label: Vinyl Cache version description: |+ The version can be obtained by "vinyld -V". placeholder: "vinyld (vinyl-cache-trunk revision 82fff61ce98a282c721d2026c7649403bc1d18eb)" diff --git a/.github/workflows/cifuzz.yml b/.github/workflows/cifuzz.yml index 82163ad340..528f433a16 100644 --- a/.github/workflows/cifuzz.yml +++ b/.github/workflows/cifuzz.yml @@ -9,13 +9,13 @@ jobs: id: build uses: google/oss-fuzz/infra/cifuzz/actions/build_fuzzers@master with: - oss-fuzz-project-name: 'varnish' + oss-fuzz-project-name: 'vinyl' dry-run: false language: c - name: Run Fuzzers uses: google/oss-fuzz/infra/cifuzz/actions/run_fuzzers@master with: - oss-fuzz-project-name: 'varnish' + oss-fuzz-project-name: 'vinyl' fuzz-seconds: 600 dry-run: false language: c diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml index 7ea0cbe18b..039597db65 100644 --- a/.github/workflows/coverity.yml +++ b/.github/workflows/coverity.yml @@ -7,7 +7,7 @@ on: jobs: coverity: - if: github.repository_owner == 'varnishcache' + if: github.repository_owner == 'vinylcache' runs-on: ubuntu-latest steps: - run: | @@ -33,6 +33,6 @@ jobs: - run: ./configure --with-persistent-storage - uses: vapier/coverity-scan-action@v1.8.0 with: - project: varnish + project: vinyl email: vinyl-dev@vinyl-cache.org token: ${{ secrets.COVERITY_SCAN_TOKEN }} diff --git a/.gitignore b/.gitignore index feb8eca055..5fab7ead30 100644 --- a/.gitignore +++ b/.gitignore @@ -97,7 +97,7 @@ cscope.*out /bin/vinylstat/vinylstat /bin/vinylstat/vinylstat_help_gen /bin/vinylstat/vinylstat_curses_help.c -/bin/varnishstat/vsc2rst +/bin/vinylstat/vsc2rst /bin/vinyltest/teken_state.h /bin/vinyltest/vinyltest /bin/vinyltest/vtest @@ -119,7 +119,7 @@ cscope.*out # Test droppings /bin/vinyld/*_test -/bin/varnishtest/tests/*.log-t +/bin/vinyltest/tests/*.log-t /include/vrt_test* /include/vbm_test /lib/libvinyl/*_test @@ -135,7 +135,7 @@ cscope.*out # vtest.sh droppings /tools/tmp/ /tools/_vtest_tmp/ -/tools/varnish-cache/ +/tools/vinyl-cache/ /tools/vt_key /tools/vt_key.pub diff --git a/bin/vinyld/acceptor/cache_acceptor.c b/bin/vinyld/acceptor/cache_acceptor.c index b3e7b049d4..73400e010f 100644 --- a/bin/vinyld/acceptor/cache_acceptor.c +++ b/bin/vinyld/acceptor/cache_acceptor.c @@ -203,9 +203,9 @@ ccf_listen_address(struct cli *cli, const char * const *av, void *priv) (void)priv; /* - * This CLI command is primarily used by varnishtest. Don't + * This CLI command is primarily used by vinyltest. Don't * respond until listen(2) has been called, in order to avoid - * a race where varnishtest::client would attempt to connect(2) + * a race where vinyltest::client would attempt to connect(2) * before listen(2) has been called. */ while (!pool_accepting) @@ -214,7 +214,7 @@ ccf_listen_address(struct cli *cli, const char * const *av, void *priv) Lck_Lock(&shut_mtx); /* - * Varnishtest expects the list of listen sockets to come out in the + * Vinyltest expects the list of listen sockets to come out in the * same order as it is specified on the command line. */ VTAILQ_FOREACH(ls, &heritage.socks, list) { diff --git a/bin/vinyld/cache/cache.h b/bin/vinyld/cache/cache.h index 4f2f4cd03a..dbb1bbc01d 100644 --- a/bin/vinyld/cache/cache.h +++ b/bin/vinyld/cache/cache.h @@ -791,7 +791,7 @@ typedef void vai_notify_cb(vai_hdl, void *priv); /* - * VSCARAB: Varnish SCatter ARAy of Buffers: + * VSCARAB: Vinyl SCatter ARAy of Buffers: * * an array of viovs, elsewhere also called an siov or sarray */ @@ -903,7 +903,7 @@ struct vscarab { } while(0) /* - * VSCARET: Varnish SCatter Array Return + * VSCARET: Vinyl SCatter Array Return * * an array of leases obtained from a vscarab */ diff --git a/bin/vinyld/cache/cache_conn_pool.c b/bin/vinyld/cache/cache_conn_pool.c index d0c8a58ca2..8209d507b9 100644 --- a/bin/vinyld/cache/cache_conn_pool.c +++ b/bin/vinyld/cache/cache_conn_pool.c @@ -399,7 +399,7 @@ VCP_Recycle(const struct worker *wrk, struct pfd **pfdp) if (i && DO_DEBUG(DBG_VTC_MODE)) { /* - * In varnishtest we do not have the luxury of using + * In vinyltest we do not have the luxury of using * multiple backend connections, so whenever we end up * in the "pending" case, take a short nap to let the * waiter catch up and put the pfd back into circulations. diff --git a/bin/vinyld/cache/cache_esi_deliver.c b/bin/vinyld/cache/cache_esi_deliver.c index add4e1c73d..79bf666704 100644 --- a/bin/vinyld/cache/cache_esi_deliver.c +++ b/bin/vinyld/cache/cache_esi_deliver.c @@ -27,7 +27,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * VED - Varnish Esi Delivery + * VED - Vinyl Esi Delivery */ #include "config.h" diff --git a/bin/vinyld/cache/cache_esi_fetch.c b/bin/vinyld/cache/cache_esi_fetch.c index f6c6664b65..322d4ba9e2 100644 --- a/bin/vinyld/cache/cache_esi_fetch.c +++ b/bin/vinyld/cache/cache_esi_fetch.c @@ -27,7 +27,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * VEF Varnish Esi Fetching + * VEF Vinyl Esi Fetching */ #include "config.h" diff --git a/bin/vinyld/cache/cache_esi_parse.c b/bin/vinyld/cache/cache_esi_parse.c index 3c661442f1..dcfd7783f3 100644 --- a/bin/vinyld/cache/cache_esi_parse.c +++ b/bin/vinyld/cache/cache_esi_parse.c @@ -27,7 +27,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * VEP Varnish Esi Parsing + * VEP Vinyl Esi Parsing */ #include "config.h" diff --git a/bin/vinyld/cache/cache_fetch.c b/bin/vinyld/cache/cache_fetch.c index 6225803436..e6297f37d1 100644 --- a/bin/vinyld/cache/cache_fetch.c +++ b/bin/vinyld/cache/cache_fetch.c @@ -793,7 +793,7 @@ vbf_stp_fetchend(struct worker *wrk, struct busyobj *bo) AZ(bo->vfc->failed); /* Recycle the backend connection before setting BOS_FINISHED to - give predictable backend reuse behavior for varnishtest */ + give predictable backend reuse behavior for vinyltest */ vbf_cleanup(bo); AZ(ObjSetU64(wrk, oc, OA_LEN, oc->boc->fetched_so_far)); diff --git a/bin/vinyld/cache/cache_main.c b/bin/vinyld/cache/cache_main.c index 2b048ee214..f19fcd1308 100644 --- a/bin/vinyld/cache/cache_main.c +++ b/bin/vinyld/cache/cache_main.c @@ -232,7 +232,7 @@ VXID_Get(const struct worker *wrk, uint64_t mask) /* * Dumb down the VXID allocation to make it predictable for - * varnishtest cases + * vinyltest cases */ static void v_matchproto_(cli_func_t) cli_debug_xid(struct cli *cli, const char * const *av, void *priv) diff --git a/bin/vinyld/cache/cache_rfc2616.c b/bin/vinyld/cache/cache_rfc2616.c index 556ecd039e..0588bf9280 100644 --- a/bin/vinyld/cache/cache_rfc2616.c +++ b/bin/vinyld/cache/cache_rfc2616.c @@ -39,11 +39,11 @@ #include "vct.h" /*-------------------------------------------------------------------- - * TTL and Age calculation in Varnish + * TTL and Age calculation in Vinyl * * RFC2616 has a lot to say about how caches should calculate the TTL * and expiry times of objects, but it sort of misses the case that - * applies to Varnish: the server-side cache. + * applies to Vinyl: the server-side cache. * * A normal cache, shared or single-client, has no symbiotic relationship * with the server, and therefore must take a very defensive attitude @@ -51,12 +51,12 @@ * the policy described in section 13 of RFC 2616 results in no caching * happening on the first little sign of trouble. * - * Varnish on the other hand tries to offload as many transactions from + * Vinyl on the other hand tries to offload as many transactions from * the backend as possible, and therefore just passing through everything - * if there is a clock-skew between backend and Varnish is not a workable + * if there is a clock-skew between backend and Vinyl is not a workable * choice. * - * Varnish implements a policy which is RFC2616 compliant when there + * Vinyl implements a policy which is RFC2616 compliant when there * is no clockskew, and falls as gracefully as possible otherwise. * Our "clockless cache" model is synthesized from the bits of RFC2616 * that talks about how a cache should react to a clockless origin server, @@ -247,7 +247,7 @@ RFC2616_Req_Gzip(const struct http *hp) /* * "gzip" is the real thing, but the 'q' value must be nonzero. * We do not care a hoot if the client prefers some other - * compression more than gzip: Varnish only does gzip. + * compression more than gzip: Vinyl only does gzip. */ if (http_GetHdrQ(hp, H_Accept_Encoding, "gzip") > 0.) return (1); diff --git a/bin/vinyld/cache/cache_vary.c b/bin/vinyld/cache/cache_vary.c index 2be050281e..e3ac53f8a2 100644 --- a/bin/vinyld/cache/cache_vary.c +++ b/bin/vinyld/cache/cache_vary.c @@ -206,7 +206,7 @@ vry_cmp(const uint8_t *v1, const uint8_t *v2) /* * If we do gzip processing, we do not vary on Accept-Encoding, * because we want everybody to get the gzipped object, and - * varnish will gunzip as necessary. We implement the skip at + * vinyl will gunzip as necessary. We implement the skip at * check time, rather than create time, so that object in * persistent storage can be used with either setting of * http_gzip_support. diff --git a/bin/vinyld/hash/hash_critbit.c b/bin/vinyld/hash/hash_critbit.c index eb77a72385..88d707916f 100644 --- a/bin/vinyld/hash/hash_critbit.c +++ b/bin/vinyld/hash/hash_critbit.c @@ -83,7 +83,7 @@ hcb_build_bittbl(void) /*--------------------------------------------------------------------- * For space reasons we overload the two pointers with two different * kinds of of pointers. We cast them to uintptr_t's and abuse the - * low two bits to tell them apart, assuming that Varnish will never + * low two bits to tell them apart, assuming that Vinyl will never * run on machines with less than 32bit alignment. * * Asserts will explode if these assumptions are not met. diff --git a/bin/vinyld/hpack/vhp.h b/bin/vinyld/hpack/vhp.h index 37c74bdf4a..ccd408e055 100644 --- a/bin/vinyld/hpack/vhp.h +++ b/bin/vinyld/hpack/vhp.h @@ -31,7 +31,7 @@ #include -/* VHT - Varnish HPACK Table */ +/* VHT - Vinyl HPACK Table */ #define VHT_ENTRY_SIZE 32U @@ -65,7 +65,7 @@ const char *VHT_LookupValue(const struct vht_table *, unsigned, size_t *); int VHT_Init(struct vht_table *, size_t); void VHT_Fini(struct vht_table *); -/* VHD - Varnish HPACK Decoder */ +/* VHD - Vinyl HPACK Decoder */ enum vhd_ret_e { #define VHD_RET(NAME, VAL, DESC) \ diff --git a/bin/vinyld/mgt/mgt_jail_solaris.c b/bin/vinyld/mgt/mgt_jail_solaris.c index 4519ac6bf7..e89ba18531 100644 --- a/bin/vinyld/mgt/mgt_jail_solaris.c +++ b/bin/vinyld/mgt/mgt_jail_solaris.c @@ -33,7 +33,7 @@ * ==================================================================== * * *1) The name is motivated by the availability of the -j command line - * option. Jailing Varnish is not to be confused with BSD Jails or + * option. Jailing Vinyl is not to be confused with BSD Jails or * Solaris Zones. * * In Solaris parlour, jail == least privileges @@ -50,7 +50,7 @@ * that priv_addset must succeed. * * For privileges which have been added later, we need to use priv strings in - * order not to break builds of varnish on older platforms. To remain binary + * order not to break builds of vinyl on older platforms. To remain binary * compatible, we can't assert that priv_addset succeeds, but we may assert that * it either succeeds or fails with EINVAL. * @@ -68,8 +68,8 @@ * set. * * But we have a preference for making an informed decision about which - * privileges varnish subprocesses should have, so we prefer to risk breaking - * varnish temporarily on newer kernels and be notified of missing privileges + * privileges vinyl subprocesses should have, so we prefer to risk breaking + * vinyl temporarily on newer kernels and be notified of missing privileges * through bug reports. * * Notes on the SNOCD flag @@ -89,10 +89,10 @@ * * * We should, however, avoid to accidentally set the SNOCD flag when setting - * privileges (see https://www.varnish-cache.org/trac/ticket/671 ) + * privileges (see https://www.vinyl-cache.org/trac/ticket/671 ) * * When changing the logic herein, always check with mdb -k. Replace _PID_ with - * the pid of your varnish child, the result should be 0, otherwise a regression + * the pid of your vinyl child, the result should be 0, otherwise a regression * has been introduced. * * > 0t_PID_::pid2proc | ::print proc_t p_flag | >a @@ -108,7 +108,7 @@ * * Two options: * - * - start the varnish master process under the same user/group given for the -u + * - start the vinyl master process under the same user/group given for the -u * / -g command line option and elevated privileges but without proc_setid, * e.g.: * diff --git a/bin/vinyld/mgt/mgt_jail_solaris_tbl.h b/bin/vinyld/mgt/mgt_jail_solaris_tbl.h index 062f25bb62..919a3de285 100644 --- a/bin/vinyld/mgt/mgt_jail_solaris_tbl.h +++ b/bin/vinyld/mgt/mgt_jail_solaris_tbl.h @@ -27,7 +27,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * definition of privileges to use for the different Varnish Jail (VJ) + * definition of privileges to use for the different Vinyl Jail (VJ) * levels */ #define E VJS_MASK(VJS_EFFECTIVE) // as-is diff --git a/bin/vinyld/storage/storage_umem.c b/bin/vinyld/storage/storage_umem.c index 19b10ac28e..8249070585 100644 --- a/bin/vinyld/storage/storage_umem.c +++ b/bin/vinyld/storage/storage_umem.c @@ -266,7 +266,7 @@ smu_umem_loaded_warn(void) e = getenv(env_umem_options); if (e == NULL || ! strstr(e, def_umem_options)) fprintf(stderr, "\tit is recommended to set %s=%s " - "before starting varnish\n", + "before starting vinyld\n", env_umem_options, def_umem_options); } diff --git a/bin/vinyld/vclflint.sh b/bin/vinyld/vclflint.sh index b3a830e953..cf99191c7f 100755 --- a/bin/vinyld/vclflint.sh +++ b/bin/vinyld/vclflint.sh @@ -1,7 +1,7 @@ #!/bin/sh # # Run flexelint on the VCL output -LIBS="-p vmod_path=/home/phk/Varnish/trunk/varnish-cache/vmod/.libs" +LIBS="-p vmod_path=/home/phk/Vinyl/trunk/vinyl-cache/vmod/.libs" if [ "x$1" = "x" ] ; then ./vinyld $LIBS -C -b localhost > /tmp/_.c diff --git a/bin/vinylhist/flint.lnt b/bin/vinylhist/flint.lnt index c2702057f4..a2333900af 100644 --- a/bin/vinylhist/flint.lnt +++ b/bin/vinylhist/flint.lnt @@ -2,6 +2,6 @@ // SPDX-License-Identifier: BSD-2-Clause // See LICENSE file for full text of license --efile(451, "varnishhist_profiles.h") --efile(451, "varnishhist_options.h") +-efile(451, "vinylhist_profiles.h") +-efile(451, "vinylhist_options.h") -sem(profile_error, r_no) diff --git a/bin/vinyllog/flint.lnt b/bin/vinyllog/flint.lnt index b922a299a0..f95e6c560c 100644 --- a/bin/vinyllog/flint.lnt +++ b/bin/vinyllog/flint.lnt @@ -7,7 +7,7 @@ -e763 // Redundant declaration for symbol '...' previously declared --efile(451, "varnishlog_options.h") +-efile(451, "vinyllog_options.h") -e732 // Loss of sign (arg. no. 2) (int to unsigned -e713 // Loss of precision (assignment) (unsigned long long to long long) diff --git a/bin/vinylncsa/flint.lnt b/bin/vinylncsa/flint.lnt index f52151546c..ddce775a18 100644 --- a/bin/vinylncsa/flint.lnt +++ b/bin/vinylncsa/flint.lnt @@ -3,4 +3,4 @@ // See LICENSE file for full text of license --efile(451, "varnishncsa_options.h") +-efile(451, "vinylncsa_options.h") diff --git a/bin/vinylstat/flint.lnt b/bin/vinylstat/flint.lnt index 764ed641e2..257b37feac 100644 --- a/bin/vinylstat/flint.lnt +++ b/bin/vinylstat/flint.lnt @@ -5,5 +5,5 @@ // +libh mgt_event.h --efile(451, varnishstat_options.h) // No include guard --efile(451, varnishstat_bindings.h) // No include guard +-efile(451, vinylstat_options.h) // No include guard +-efile(451, vinylstat_bindings.h) // No include guard diff --git a/bin/vinylstat/flint.sh b/bin/vinylstat/flint.sh index 062a93bb9f..32fcae861b 100644 --- a/bin/vinylstat/flint.sh +++ b/bin/vinylstat/flint.sh @@ -5,9 +5,9 @@ # See LICENSE file for full text of license FLOPS=' - varnishstat.c - varnishstat_curses.c - varnishstat_curses_help.c + vinylstat.c + vinylstat_curses.c + vinylstat_curses_help.c ../../lib/libvinylapi/flint.lnt ../../lib/libvinylapi/*.c diff --git a/bin/vinyltest/flint.lnt b/bin/vinyltest/flint.lnt index d8f8159f22..e98df47c8f 100644 --- a/bin/vinyltest/flint.lnt +++ b/bin/vinyltest/flint.lnt @@ -20,7 +20,7 @@ -esym(850, av) --esym(534, snprintf) // Only for varnishtest, and not really nice +-esym(534, snprintf) // Only for vinyltest, and not really nice -esym(765, http_cmds) // No, cannot be made static diff --git a/bin/vinyltest/tests/b00000.vtc b/bin/vinyltest/tests/b00000.vtc index e9e33821e9..32faa1439a 100644 --- a/bin/vinyltest/tests/b00000.vtc +++ b/bin/vinyltest/tests/b00000.vtc @@ -33,7 +33,7 @@ vinyl v1 -vcl+backend { vinyl v1 -cliok "param.set debug +workspace" vinyl v1 -cliok "param.set debug +witness" -#varnish v1 -vsc * +#vinyl v1 -vsc * vinyl v1 -expect MAIN.n_object == 0 vinyl v1 -expect MAIN.sess_conn == 0 @@ -59,7 +59,7 @@ client c1 { expect resp.status == 200 } -run -# varnish v1 -vsc * +# vinyl v1 -vsc * vinyl v1 -expect n_object == 2 vinyl v1 -expect sess_conn == 2 vinyl v1 -expect client_req == 2 diff --git a/bin/vinyltest/tests/b00003.vtc b/bin/vinyltest/tests/b00003.vtc index bd70dfa075..5d053a0726 100644 --- a/bin/vinyltest/tests/b00003.vtc +++ b/bin/vinyltest/tests/b00003.vtc @@ -21,7 +21,7 @@ client c2 { expect resp.http.X-Vinyl == "1004 1002" } -run -# Give varnish a chance to update stats +# Give vinyl a chance to update stats delay .1 vinyl v1 -expect sess_conn == 2 diff --git a/bin/vinyltest/tests/b00004.vtc b/bin/vinyltest/tests/b00004.vtc index 33259b48ec..38292b5092 100644 --- a/bin/vinyltest/tests/b00004.vtc +++ b/bin/vinyltest/tests/b00004.vtc @@ -1,4 +1,4 @@ -vtest "Torture Varnish with start/stop commands" +vtest "Torture Vinyl with start/stop commands" server s1 { rxreq diff --git a/bin/vinyltest/tests/b00044.vtc b/bin/vinyltest/tests/b00044.vtc index b5ec07d5c9..5f5e404ebf 100644 --- a/bin/vinyltest/tests/b00044.vtc +++ b/bin/vinyltest/tests/b00044.vtc @@ -1,4 +1,4 @@ -vtest "Test/coverage of varnish master signal handling" +vtest "Test/coverage of vinyl master signal handling" server s1 { rxreq diff --git a/bin/vinyltest/tests/b00062.vtc b/bin/vinyltest/tests/b00062.vtc index af61a0490c..b9a802c49e 100644 --- a/bin/vinyltest/tests/b00062.vtc +++ b/bin/vinyltest/tests/b00062.vtc @@ -15,7 +15,7 @@ server s1 { delay 1 txresp -status 304 - # Last request, to a different URL to catch it if varnish asks for "/" too many times + # Last request, to a different URL to catch it if vinyl asks for "/" too many times rxreq expect req.url == "/2" txresp -body "x" @@ -66,7 +66,7 @@ client c2 -wait client c3 -wait # Finally the request to "/2". The expect in the server block makes sure that -# there were no extra requests to "/" from varnish. +# there were no extra requests to "/" from vinyl. client c4 { txreq -url "/2" diff --git a/bin/vinyltest/tests/b00063.vtc b/bin/vinyltest/tests/b00063.vtc index 0ca7141ca3..cd96d04f37 100644 --- a/bin/vinyltest/tests/b00063.vtc +++ b/bin/vinyltest/tests/b00063.vtc @@ -14,11 +14,11 @@ server s1 { expect req.url == "/1" txresp -status 503 -body "2" - # varnish will disconnect on a 503 + # vinyl will disconnect on a 503 accept rxreq expect req.url == "/1" - # wait until varnish has delivered 200 before replying + # wait until vinyl has delivered 200 before replying # with the 404 barrier b2 sync delay .1 diff --git a/bin/vinyltest/tests/b00064.vtc b/bin/vinyltest/tests/b00064.vtc index 78eec9e8ae..f0e6f81535 100644 --- a/bin/vinyltest/tests/b00064.vtc +++ b/bin/vinyltest/tests/b00064.vtc @@ -18,7 +18,7 @@ server s1 { delay .1 txresp -body "2" - # Last request, to a different URL to catch it if varnish asks for "/" too many times + # Last request, to a different URL to catch it if vinyl asks for "/" too many times rxreq expect req.url == "/2" txresp -body "x" diff --git a/bin/vinyltest/tests/b00071.vtc b/bin/vinyltest/tests/b00071.vtc index 9ae692bc81..e6ab08b1a7 100644 --- a/bin/vinyltest/tests/b00071.vtc +++ b/bin/vinyltest/tests/b00071.vtc @@ -1,4 +1,4 @@ -vtest "varnish-cli pid command" +vtest "vinyl-cli pid command" vinyl v1 -cliexpect "^Master: +[0-9]+\n$" pid vinyl v1 -cliok "pid -j" diff --git a/bin/vinyltest/tests/b00079.vtc b/bin/vinyltest/tests/b00079.vtc index 36b8590ece..bf24ea8953 100644 --- a/bin/vinyltest/tests/b00079.vtc +++ b/bin/vinyltest/tests/b00079.vtc @@ -4,7 +4,7 @@ server s1 { rxreq txresp -hdr "Last-Modified: Wed, 11 Sep 2013 13:36:55 GMT" -nodate -body "1" - # When origin does not send a Date, varnish inserts one, prompting IMS + # When origin does not send a Date, vinyl inserts one, prompting IMS rxreq expect req.http.if-modified-since == "Wed, 11 Sep 2013 13:36:55 GMT" txresp -status 304 -hdr "Last-Modified: Wed, 11 Sep 2013 13:36:55 GMT" \ diff --git a/bin/vinyltest/tests/b00089.vtc b/bin/vinyltest/tests/b00089.vtc index 9bc5a123c2..c7c18e0d2f 100644 --- a/bin/vinyltest/tests/b00089.vtc +++ b/bin/vinyltest/tests/b00089.vtc @@ -3,7 +3,7 @@ vtest "connect: blackhole" # XXX: This test case relies on a way for us to never successed in connecting # to a backend. We need the connect syscall to hang forever. For TCP this means # that the backend must not respond to the three-way handshake initiated by -# Varnish. +# Vinyl. # # One way to achieve this is to use an IP address non-routeable over the # Internet, but this is not always a bullet-proof solution across all the diff --git a/bin/vinyltest/tests/b00090.vtc b/bin/vinyltest/tests/b00090.vtc index 680133ea8f..e4b5bf558f 100644 --- a/bin/vinyltest/tests/b00090.vtc +++ b/bin/vinyltest/tests/b00090.vtc @@ -3,7 +3,7 @@ vtest "connect: blackhole with queueing" # XXX: This test case relies on a way for us to never successed in connecting # to a backend. We need the connect syscall to hang forever. For TCP this means # that the backend must not respond to the three-way handshake initiated by -# Varnish. +# Vinyl. # # One way to achieve this is to use an IP address non-routeable over the # Internet, but this is not always a bullet-proof solution across all the diff --git a/bin/vinyltest/tests/c00042.vtc b/bin/vinyltest/tests/c00042.vtc index a92acd256c..32c3467fbd 100644 --- a/bin/vinyltest/tests/c00042.vtc +++ b/bin/vinyltest/tests/c00042.vtc @@ -14,7 +14,7 @@ server s2 { # the use case for via-proxy is to have a(n ha)proxy make a (TLS) # connection on our behalf. For the purpose of testing, we use another -# varnish in place - but we are behaving realistically in that we do +# vinyl in place - but we are behaving realistically in that we do # not use any prior information for the actual backend connection - # just the information from the proxy protocol diff --git a/bin/vinyltest/tests/c00086.vtc b/bin/vinyltest/tests/c00086.vtc index 11479b2a1a..9392841e71 100644 --- a/bin/vinyltest/tests/c00086.vtc +++ b/bin/vinyltest/tests/c00086.vtc @@ -1,7 +1,7 @@ vtest "-a sub-args user, group and mode; and warn if stat(EACCES) fails for UDS" feature user_vcache -feature group_varnish +feature group_vinyl feature root shell -err -expect "Too many user sub-args" { @@ -9,7 +9,7 @@ shell -err -expect "Too many user sub-args" { } shell -err -expect "Too many group sub-args" { - vinyld -a ${tmpdir}/vtc.sock,group=varnish,group=varnish -d + vinyld -a ${tmpdir}/vtc.sock,group=vinyl,group=vinyl -d } # Assuming that empty user and group names always fail getpwnam and getgrnam @@ -23,34 +23,34 @@ shell -err -expect "Unknown group " { server s1 {} -start -vinyl v1 -arg "-a ${tmpdir}/v1.sock,user=vcache,group=varnish,mode=660" \ +vinyl v1 -arg "-a ${tmpdir}/v1.sock,user=vcache,group=vinyl,mode=660" \ -vcl+backend {} -shell -match "rw-rw----.+vcache.+varnish" { ls -l ${tmpdir}/v1.sock } +shell -match "rw-rw----.+vcache.+vinyl" { ls -l ${tmpdir}/v1.sock } vinyl v2 -arg "-a ${tmpdir}/v2.sock,user=vcache,mode=600" -vcl+backend {} shell -match "rw-------.+vcache" { ls -l ${tmpdir}/v2.sock } -vinyl v3 -arg "-a ${tmpdir}/v3.sock,group=varnish,mode=660" -vcl+backend {} +vinyl v3 -arg "-a ${tmpdir}/v3.sock,group=vinyl,mode=660" -vcl+backend {} -shell -match "rw---- .+root.+varnish" { ls -l ${tmpdir}/v3.sock } +shell -match "rw---- .+root.+vinyl" { ls -l ${tmpdir}/v3.sock } vinyl v4 -arg "-a ${tmpdir}/v4.sock,mode=666" -vcl+backend {} shell -match "rw-rw-rw-.+root" { ls -l ${tmpdir}/v4.sock } -vinyl v5 -arg "-a ${tmpdir}/v5.sock,user=vcache,group=varnish" -vcl+backend {} +vinyl v5 -arg "-a ${tmpdir}/v5.sock,user=vcache,group=vinyl" -vcl+backend {} -shell -match "vcache.+varnish" { ls -l ${tmpdir}/v5.sock } +shell -match "vcache.+vinyl" { ls -l ${tmpdir}/v5.sock } vinyl v6 -arg "-a ${tmpdir}/v6.sock,user=vcache" -vcl+backend {} shell -match "vcache" { ls -l ${tmpdir}/v6.sock } -vinyl v7 -arg "-a ${tmpdir}/v7.sock,group=varnish" -vcl+backend {} +vinyl v7 -arg "-a ${tmpdir}/v7.sock,group=vinyl" -vcl+backend {} -shell -match "root.+varnish" { ls -l ${tmpdir}/v7.sock } +shell -match "root.+vinyl" { ls -l ${tmpdir}/v7.sock } # VCC warns, but does not fail, if stat(UDS) fails with EACCES. shell { mkdir ${tmpdir}/dir } @@ -59,7 +59,7 @@ server s2 -listen ${tmpdir}/dir/s1.sock {} -start shell { chmod go-rx ${tmpdir}/dir } vinyl v8 \ - -jail "-junix,user=varnish,ccgroup=varnish,workuser=vcache" \ + -jail "-junix,user=vinyl,ccgroup=vinyl,workuser=vcache" \ -vcl { backend b None; } diff --git a/bin/vinyltest/tests/c00114.vtc b/bin/vinyltest/tests/c00114.vtc index 8ac90ec760..146ec278a7 100644 --- a/bin/vinyltest/tests/c00114.vtc +++ b/bin/vinyltest/tests/c00114.vtc @@ -6,9 +6,9 @@ vtest "TLV authority over via backends used as SNI for haproxy backend/1" # In this version of the test, we set port 0 in the server config of # the "ssl-onloading" haproxy, and set the destination port in the -# backend config for Varnish. The onloader sets its destination port +# backend config for Vinyl. The onloader sets its destination port # from the address forwarded via PROXY, which in turn is set from the -# Varnish backend config. See c00101.vtc for another config method. +# Vinyl backend config. See c00101.vtc for another config method. feature ignore_unknown_macro diff --git a/bin/vinyltest/tests/c00124.vtc.disabled b/bin/vinyltest/tests/c00124.vtc.disabled index 898d678e3e..b063e9ea12 100644 --- a/bin/vinyltest/tests/c00124.vtc.disabled +++ b/bin/vinyltest/tests/c00124.vtc.disabled @@ -1,4 +1,4 @@ -varnishtest "rushed task queued" +vinyltest "rushed task queued" # this does not work reliably because the acceptor task may # be queued during the child startup if not all threads are @@ -33,13 +33,13 @@ server s2 { chunkedlen 0 } -start -varnish v1 -cliok "param.set thread_pools 1" -varnish v1 -cliok "param.set thread_pool_min 5" -varnish v1 -cliok "param.set thread_pool_max 5" -varnish v1 -cliok "param.set debug +syncvsl" -varnish v1 -cliok "param.set debug +waitinglist" +vinyl v1 -cliok "param.set thread_pools 1" +vinyl v1 -cliok "param.set thread_pool_min 5" +vinyl v1 -cliok "param.set thread_pool_max 5" +vinyl v1 -cliok "param.set debug +syncvsl" +vinyl v1 -cliok "param.set debug +waitinglist" -varnish v1 -vcl+backend { +vinyl v1 -vcl+backend { import vtc; sub vcl_recv { @@ -59,7 +59,7 @@ varnish v1 -vcl+backend { } -start # wait for all threads to be started -varnish v1 -expect threads == 5 +vinyl v1 -expect threads == 5 # 2 threads client c1 { @@ -86,8 +86,8 @@ logexpect l2 -v v1 -g raw { expect * 1007 Debug "off waiting list" } -start -varnish v1 -expect sess_dropped == 0 -varnish v1 -expect sess_queued == 0 +vinyl v1 -expect sess_dropped == 0 +vinyl v1 -expect sess_queued == 0 # At this point, we are thread-starved and c3 below will steal the # acceptor thread that will queue itself. @@ -99,9 +99,9 @@ client c3 { logexpect l1 -wait -varnish v1 -expect sess_dropped == 0 -varnish v1 -expect sess_queued == 1 -varnish v1 -expect busy_sleep == 1 +vinyl v1 -expect sess_dropped == 0 +vinyl v1 -expect sess_queued == 1 +vinyl v1 -expect busy_sleep == 1 # Wake up c2, This will in turn trigger a waitinglist rush and wake up c3. barrier b2 sync @@ -118,5 +118,5 @@ client c1 -wait client c2 -wait client c3 -wait -varnish v1 -expect sess_dropped == 0 -varnish v1 -expect sess_queued == 2 +vinyl v1 -expect sess_dropped == 0 +vinyl v1 -expect sess_queued == 2 diff --git a/bin/vinyltest/tests/d00007.vtc b/bin/vinyltest/tests/d00007.vtc index a7ae707dd7..6a0549afb1 100644 --- a/bin/vinyltest/tests/d00007.vtc +++ b/bin/vinyltest/tests/d00007.vtc @@ -2,7 +2,7 @@ vtest "Test dynamic backends" # the use case for via-proxy is to have a(n ha)proxy make a(n ssl) # connection on our behalf. For the purpose of testing, we use another -# varnish in place - but we are behaving realistically in that we do +# vinyl in place - but we are behaving realistically in that we do # not use any prior information for the actual backend connection - # just the information from the proxy protocol @@ -67,7 +67,7 @@ server s1 { # we vtc.sleep to make sure that the health check is done and server # s1 has accepted again. We would rather want to use barriers, but # there is a (yet not understood) bug in vinyltest which prevents -# the bX_sock macros from being available in the second varnish +# the bX_sock macros from being available in the second vinyl # instance vinyl v1 -vcl { diff --git a/bin/vinyltest/tests/d00008.vtc b/bin/vinyltest/tests/d00008.vtc index e619f63da0..d3fd5d862b 100644 --- a/bin/vinyltest/tests/d00008.vtc +++ b/bin/vinyltest/tests/d00008.vtc @@ -49,4 +49,4 @@ client c1 { delay 1 vinyl v1 -cli backend.list -# varnish v1 -expect MAIN.n_backend == 2 +# vinyl v1 -expect MAIN.n_backend == 2 diff --git a/bin/vinyltest/tests/d00009.vtc b/bin/vinyltest/tests/d00009.vtc index 579b96a789..6577857db3 100644 --- a/bin/vinyltest/tests/d00009.vtc +++ b/bin/vinyltest/tests/d00009.vtc @@ -58,4 +58,4 @@ client c2 { client c1 -wait vinyl v1 -cli backend.list -# varnish v1 -expect MAIN.n_backend == 2 +# vinyl v1 -expect MAIN.n_backend == 2 diff --git a/bin/vinyltest/tests/d00010.vtc b/bin/vinyltest/tests/d00010.vtc index 49e9fbbd98..5d0bf4a632 100644 --- a/bin/vinyltest/tests/d00010.vtc +++ b/bin/vinyltest/tests/d00010.vtc @@ -59,4 +59,4 @@ client c2 { client c1 -wait vinyl v1 -cli backend.list -#varnish v1 -expect MAIN.n_backend == 2 +#vinyl v1 -expect MAIN.n_backend == 2 diff --git a/bin/vinyltest/tests/d00011.vtc b/bin/vinyltest/tests/d00011.vtc index cf2b72580e..e317aa0eed 100644 --- a/bin/vinyltest/tests/d00011.vtc +++ b/bin/vinyltest/tests/d00011.vtc @@ -62,4 +62,4 @@ client c2 -run client c1 -wait vinyl v1 -cli backend.list -#varnish v1 -expect MAIN.n_backend == 2 +#vinyl v1 -expect MAIN.n_backend == 2 diff --git a/bin/vinyltest/tests/d00012.vtc b/bin/vinyltest/tests/d00012.vtc index 19bc6bee3f..874676476c 100644 --- a/bin/vinyltest/tests/d00012.vtc +++ b/bin/vinyltest/tests/d00012.vtc @@ -77,9 +77,9 @@ client c1 { } -run vinyl v1 -cli "vcl.list" -#varnish v1 -expect MAIN.n_backend == 2 +#vinyl v1 -expect MAIN.n_backend == 2 # expected: vcl2.dummy, vcl2.s2 vinyl v1 -expect n_vcl_avail == 1 # XXX This test fails on FreeBSD -# XXX varnish v1 -expect n_vcl_discard == 0 +# XXX vinyl v1 -expect n_vcl_discard == 0 diff --git a/bin/vinyltest/tests/d00013.vtc b/bin/vinyltest/tests/d00013.vtc index 51a96d072b..563b8cf07f 100644 --- a/bin/vinyltest/tests/d00013.vtc +++ b/bin/vinyltest/tests/d00013.vtc @@ -59,4 +59,4 @@ client c2 -run client c1 -wait vinyl v1 -cli backend.list -#varnish v1 -expect MAIN.n_backend == 2 +#vinyl v1 -expect MAIN.n_backend == 2 diff --git a/bin/vinyltest/tests/e00019.vtc b/bin/vinyltest/tests/e00019.vtc index e25f2752d8..990765f45a 100644 --- a/bin/vinyltest/tests/e00019.vtc +++ b/bin/vinyltest/tests/e00019.vtc @@ -31,7 +31,7 @@ server s1 { # The included object gets served from a different backend. # This is to avoid a race between when a backend connection # gets put up for reuse because of background fetches in -# Varnish 4 +# Vinyl 4 server s2 { rxreq expect req.url == "bar/foo" diff --git a/bin/vinyltest/tests/e00029.vtc.disabled b/bin/vinyltest/tests/e00029.vtc.disabled index 3b17e21925..716869d304 100644 --- a/bin/vinyltest/tests/e00029.vtc.disabled +++ b/bin/vinyltest/tests/e00029.vtc.disabled @@ -1,4 +1,4 @@ -varnishtest "fun esi includes and ranges" +vinyltest "fun esi includes and ranges" # this does not work yet because the ESI VDP pushes data directly # to the next level up, which in turn is required to get the @@ -23,7 +23,7 @@ server s1 { } -start -varnish v1 -vcl+backend { +vinyl v1 -vcl+backend { sub vcl_recv { if (req.url == "/bar") { set req.http.Range = "bytes=7-8"; diff --git a/bin/vinyltest/tests/f00005.vtc b/bin/vinyltest/tests/f00005.vtc index b9b32277c3..0e9c2648bd 100644 --- a/bin/vinyltest/tests/f00005.vtc +++ b/bin/vinyltest/tests/f00005.vtc @@ -47,7 +47,7 @@ d6 00 00 08 00 00 00 00 00 07 7a 20 b1 3f 43 20 expect_close } -run -# Reduced size proxy payload to verify Varnish is still running +# Reduced size proxy payload to verify Vinyl is still running client c1 { sendhex { 0d 0a 0d 0a 00 0d 0a 51 diff --git a/bin/vinyltest/tests/g00002.vtc b/bin/vinyltest/tests/g00002.vtc index ab6e9ae0b0..2f5c4fe825 100644 --- a/bin/vinyltest/tests/g00002.vtc +++ b/bin/vinyltest/tests/g00002.vtc @@ -44,14 +44,14 @@ client c1 { vinyl v1 -expect SM?.s0.c_req > 2 client c1 { - # See varnish can gunzip it. + # See vinyl can gunzip it. txreq -url /foo -hdr "Accept-Encoding: null" rxresp expect resp.http.content-encoding == expect resp.bodylen == 4100 delay .1 - # See varnish can gunzip it, inside ESI + # See vinyl can gunzip it, inside ESI txreq -url /bar -hdr "Accept-Encoding: null" rxresp expect resp.http.content-encoding == diff --git a/bin/vinyltest/tests/h00006.vtc b/bin/vinyltest/tests/h00006.vtc index 1bd4d14045..ca95b99a55 100644 --- a/bin/vinyltest/tests/h00006.vtc +++ b/bin/vinyltest/tests/h00006.vtc @@ -1,6 +1,6 @@ vtest "haproxy tcp-mode, uds, send-proxy-v2, client ip and acl" -# same as h00007.vtc, but using uds for haproxy->varnish +# same as h00007.vtc, but using uds for haproxy->vinyl feature ignore_unknown_macro diff --git a/bin/vinyltest/tests/h00007.vtc b/bin/vinyltest/tests/h00007.vtc index a5562d5c36..b075ae1a80 100644 --- a/bin/vinyltest/tests/h00007.vtc +++ b/bin/vinyltest/tests/h00007.vtc @@ -1,6 +1,6 @@ vtest "haproxy tcp-mode, tcp, send-proxy-v2, client ip and acl" -# same as h00006.vtc, but using tcp for haproxy->varnish +# same as h00006.vtc, but using tcp for haproxy->vinyl feature ignore_unknown_macro diff --git a/bin/vinyltest/tests/p00003.vtc b/bin/vinyltest/tests/p00003.vtc index 467f21cad1..88221ce446 100644 --- a/bin/vinyltest/tests/p00003.vtc +++ b/bin/vinyltest/tests/p00003.vtc @@ -40,7 +40,7 @@ vinyl v1 -vcl+backend {} -start vinyl v1 -cliok ban.list # Count of 2 here, because the "magic" ban is also there" -# varnish v1 -expect n_ban == 2 +# vinyl v1 -expect n_ban == 2 client c1 { diff --git a/bin/vinyltest/tests/r00667.vtc b/bin/vinyltest/tests/r00667.vtc index 6fed3eeb12..18e447a822 100644 --- a/bin/vinyltest/tests/r00667.vtc +++ b/bin/vinyltest/tests/r00667.vtc @@ -7,7 +7,7 @@ server s1 { rxreq barrier b1 sync barrier b2 sync - # There is a race in varnish between the first request releasing + # There is a race in vinyl between the first request releasing # the backend connection, and the second request trying to get it # which makes reuse of backend connection sometimes work and # sometimes not. Solve by never reusing the backend connection. diff --git a/bin/vinyltest/tests/r01030.vtc b/bin/vinyltest/tests/r01030.vtc index 1dfa3378bc..bae5cddde5 100644 --- a/bin/vinyltest/tests/r01030.vtc +++ b/bin/vinyltest/tests/r01030.vtc @@ -40,7 +40,7 @@ client c1 { } -run #delay 0.1 -#varnish v1 -expect bans_lurker_tests_tested == 0 +#vinyl v1 -expect bans_lurker_tests_tested == 0 #delay 1.5 vinyl v1 -expect bans_lurker_tests_tested >= 1 @@ -58,7 +58,7 @@ client c2 { } -run #delay 0.1 -#varnish v1 -expect bans_lurker_tests_tested == 1 +#vinyl v1 -expect bans_lurker_tests_tested == 1 #delay 1.1 vinyl v1 -expect bans_lurker_tests_tested == 2 diff --git a/bin/vinyltest/tests/r01252.vtc.disabled b/bin/vinyltest/tests/r01252.vtc.disabled index 21a29952a1..fe923e6c0f 100644 --- a/bin/vinyltest/tests/r01252.vtc.disabled +++ b/bin/vinyltest/tests/r01252.vtc.disabled @@ -1,8 +1,8 @@ -varnishtest "#1252 - Drop remote closed connections returning from waitinglists" +vinyltest "#1252 - Drop remote closed connections returning from waitinglists" # This test case is disabled because it will only pass on platforms # where the tcp_keepalive_* runtime arguments are available, and also -# because it requires "-t 80" argument to varnishtest (remote closed +# because it requires "-t 80" argument to vinyltest (remote closed # state will only be detected after FIN timeout has passed (60s)) barrier b1 cond 2 @@ -21,7 +21,7 @@ server s2 { txresp } -start -varnish v1 -arg "-p debug=+waitinglist" -vcl+backend { +vinyl v1 -arg "-p debug=+waitinglist" -vcl+backend { sub vcl_recv { if (req.http.x-client == "2") { set req.backend_hint = s2; @@ -29,17 +29,17 @@ varnish v1 -arg "-p debug=+waitinglist" -vcl+backend { } } -start -varnish v1 -cliok "param.show tcp_keepalive_time" -varnish v1 -cliok "param.set tcp_keepalive_time 1" +vinyl v1 -cliok "param.show tcp_keepalive_time" +vinyl v1 -cliok "param.set tcp_keepalive_time 1" -varnish v1 -cliok "param.show tcp_keepalive_probes" -varnish v1 -cliok "param.set tcp_keepalive_probes 1" +vinyl v1 -cliok "param.show tcp_keepalive_probes" +vinyl v1 -cliok "param.set tcp_keepalive_probes 1" -varnish v1 -cliok "param.show tcp_keepalive_intvl" -varnish v1 -cliok "param.set tcp_keepalive_intvl 1" +vinyl v1 -cliok "param.show tcp_keepalive_intvl" +vinyl v1 -cliok "param.set tcp_keepalive_intvl 1" -varnish v1 -cliok "param.show first_byte_timeout" -varnish v1 -cliok "param.set first_byte_timeout 70" +vinyl v1 -cliok "param.show first_byte_timeout" +vinyl v1 -cliok "param.set first_byte_timeout 70" delay 2 diff --git a/bin/vinyltest/tests/r01284.vtc b/bin/vinyltest/tests/r01284.vtc index e0e911bbc9..e9659677c2 100644 --- a/bin/vinyltest/tests/r01284.vtc +++ b/bin/vinyltest/tests/r01284.vtc @@ -40,7 +40,7 @@ vinyl v1 -expect SM?.Transient.g_space < 200 client c1 { # No space for this object (more than 256 bytes in headers). Don't wait - # for reply as Varnish will not send one due to Transient full. + # for reply as Vinyl will not send one due to Transient full. txreq -url "/obj2" delay 1 } -run @@ -49,7 +49,7 @@ client c1 { vinyl v1 -expect SM?.Transient.c_fail == 3 client c1 { - # Check that Varnish is still alive + # Check that Vinyl is still alive txreq -url "/obj1" rxresp expect resp.status == 200 diff --git a/bin/vinyltest/tests/r01562.vtc b/bin/vinyltest/tests/r01562.vtc index 857758f4de..b08cff348a 100644 --- a/bin/vinyltest/tests/r01562.vtc +++ b/bin/vinyltest/tests/r01562.vtc @@ -1,4 +1,4 @@ -vtest "retrying a short client body read should not panic varnish" +vtest "retrying a short client body read should not panic vinyl" server s1 { non_fatal diff --git a/bin/vinyltest/tests/r01576.vtc b/bin/vinyltest/tests/r01576.vtc index 5cfbde0100..46f87b44fb 100644 --- a/bin/vinyltest/tests/r01576.vtc +++ b/bin/vinyltest/tests/r01576.vtc @@ -9,10 +9,10 @@ vinyl v1 -cliok "param.set http_req_size 32k" # Better yet: Rewrite your regexps to avoid this madness. # Tweaks you may add to this test: -# varnish v1 -cliok "param.set thread_pool_stack 48k" -# varnish v1 -cliok "param.set pcre2_match_limit 100" -# varnish v1 -cliok "param.set pcre2_depth_limit 10000" -# varnish v1 -cliok "param.set pcre2_jit_compilation off" +# vinyl v1 -cliok "param.set thread_pool_stack 48k" +# vinyl v1 -cliok "param.set pcre2_match_limit 100" +# vinyl v1 -cliok "param.set pcre2_depth_limit 10000" +# vinyl v1 -cliok "param.set pcre2_jit_compilation off" # Approximate formula for FreeBSD/amd64: # pcre2_depth_limit = thread_pool_stack * 2 - 9 diff --git a/bin/vinyltest/tests/r01737.vtc b/bin/vinyltest/tests/r01737.vtc index 80a2a89911..754e75f963 100644 --- a/bin/vinyltest/tests/r01737.vtc +++ b/bin/vinyltest/tests/r01737.vtc @@ -42,7 +42,7 @@ client c1 { delay 3 -# Check that Varnish is alive +# Check that Vinyl is alive client c1 { txreq rxresp diff --git a/bin/vinyltest/tests/r01857.vtc b/bin/vinyltest/tests/r01857.vtc index aacf4c9f81..ea591d393e 100644 --- a/bin/vinyltest/tests/r01857.vtc +++ b/bin/vinyltest/tests/r01857.vtc @@ -19,7 +19,7 @@ client c1 { expect resp.http.X-Vinyl == "1003 1002" } -run -# Give varnish a chance to update stats +# Give vinyl a chance to update stats delay .1 vinyl v1 -expect sess_herd >= 1 diff --git a/bin/vinyltest/tests/r02295.vtc.disabled b/bin/vinyltest/tests/r02295.vtc.disabled index f7a06e11dc..5f7ad7e820 100644 --- a/bin/vinyltest/tests/r02295.vtc.disabled +++ b/bin/vinyltest/tests/r02295.vtc.disabled @@ -1,7 +1,7 @@ -varnishtest "Test cooled dynamic backend clean up" +vinyltest "Test cooled dynamic backend clean up" # This test is disabled because it needs a timeout of 80 seconds (-t80 to -# varnishtest). This is because the cooled backend timeout in varnish core +# vinyltest). This is because the cooled backend timeout in vinyl core # is hard coded to 60 seconds. server s1 { @@ -10,7 +10,7 @@ server s1 { txresp } -start -varnish v1 -arg "-p cli_timeout=2 -p first_byte_timeout=80" -vcl { +vinyl v1 -arg "-p cli_timeout=2 -p first_byte_timeout=80" -vcl { import debug; backend dummy { .host = "${bad_backend}"; } @@ -48,6 +48,6 @@ client c2 { delay 61 -varnish v1 -cliok "ping" +vinyl v1 -cliok "ping" client c1 -wait diff --git a/bin/vinyltest/tests/r02555.vtc b/bin/vinyltest/tests/r02555.vtc index 492e80e2e8..99172d153c 100644 --- a/bin/vinyltest/tests/r02555.vtc +++ b/bin/vinyltest/tests/r02555.vtc @@ -31,7 +31,7 @@ vinyl v1 -vcl+backend { vtc.barrier_sync("${b1_sock}"); vtc.barrier_sync("${b2_sock}"); } - # Update the last timestamp inside varnish + # Update the last timestamp inside vinyl std.timestamp("T"); } sub vcl_hit { diff --git a/bin/vinyltest/tests/r02702.vtc b/bin/vinyltest/tests/r02702.vtc index 8b0805a98d..d339f089c6 100644 --- a/bin/vinyltest/tests/r02702.vtc +++ b/bin/vinyltest/tests/r02702.vtc @@ -1,11 +1,11 @@ vtest "probes to UDS backends with .proxy_header in [12]" # Since we can only reliably forward IP addresses via PROXY with -# Varnish, we can't use the trick from o00002.vtc (use a Varnish +# Vinyl, we can't use the trick from o00002.vtc (use a Vinyl # instance listening for PROXY as a backend) to verify PROXYv1 (but # the PROXY header can be viewed in the test log). -# We just verify that the probe is good (and that Varnish doesn't +# We just verify that the probe is good (and that Vinyl doesn't # crash with WRONG). server s1 -listen "${tmpdir}/s1.sock" { @@ -32,7 +32,7 @@ delay 1 vinyl v1 -cliexpect "vcl1.s1[ ]+probe[ ]+1/1[ ]+healthy" backend.list # For PROXYv2, we apply a trick similar to o0000[24].vtc, since -# Varnish accepts (and ignores) PROXY LOCAL. +# Vinyl accepts (and ignores) PROXY LOCAL. server s2 { rxreq diff --git a/bin/vinyltest/tests/r02831.vtc b/bin/vinyltest/tests/r02831.vtc index 122ebfaa27..87a2d6d91b 100644 --- a/bin/vinyltest/tests/r02831.vtc +++ b/bin/vinyltest/tests/r02831.vtc @@ -50,7 +50,7 @@ client c1 { vinyl v1 -expect SM?.Transient.c_fail == 1 client c1 { - # Check that Varnish is still alive + # Check that Vinyl is still alive txreq -url "/obj1" rxresp expect resp.status == 200 diff --git a/bin/vinyltest/tests/r03098.vtc b/bin/vinyltest/tests/r03098.vtc index 4579534d61..ffcaf293ae 100644 --- a/bin/vinyltest/tests/r03098.vtc +++ b/bin/vinyltest/tests/r03098.vtc @@ -5,7 +5,7 @@ vtest "Explain how param.(re)?set may fail" vinyl v1 -cliok "param.set thread_pool_max 10000" vinyl v1 -cliok "param.set thread_pool_min 8000" -# NB: "varnish v1 -cliexpect" wouldn't work with a non-200 status +# NB: "vinyl v1 -cliexpect" wouldn't work with a non-200 status shell -err -expect "Must be at least 8000 (thread_pool_min)" { exec vinyladm -n ${v1_name} param.reset thread_pool_max } diff --git a/bin/vinyltest/tests/r03940.vtc b/bin/vinyltest/tests/r03940.vtc index 296f424f57..e25eda2773 100644 --- a/bin/vinyltest/tests/r03940.vtc +++ b/bin/vinyltest/tests/r03940.vtc @@ -1,6 +1,6 @@ vtest "test startup_timeout vs. stevedore init / open" -# we test with vtc_varnish and vtc_process because of different code +# we test with vtc_vinyl and vtc_process because of different code # paths in mgr for implicit start vs. cli start #### diff --git a/bin/vinyltest/tests/s00007.vtc b/bin/vinyltest/tests/s00007.vtc index c5cf49f1b7..a2a5da1903 100644 --- a/bin/vinyltest/tests/s00007.vtc +++ b/bin/vinyltest/tests/s00007.vtc @@ -6,7 +6,7 @@ server s1 { txresp -body "foo" # The second request is never used, but is here to give a - # better error if varnish decides to fetch the object the + # better error if vinyl decides to fetch the object the # second time rxreq diff --git a/bin/vinyltest/tests/s00010.vtc b/bin/vinyltest/tests/s00010.vtc index fdfc2eccb1..65efab68c2 100644 --- a/bin/vinyltest/tests/s00010.vtc +++ b/bin/vinyltest/tests/s00010.vtc @@ -11,7 +11,7 @@ server s0 { rxreq txresp -nolen -hdr "Transfer-encoding: chunked" chunkedlen 100000 - # make sure varnish is stuck in delivery + # make sure vinyl is stuck in delivery barrier b1 sync non_fatal chunkedlen 0 @@ -52,7 +52,7 @@ logexpect l1 -v v1 -g raw { client c1 -rcvbuf 256 { txreq rxresphdrs - # varnish is stuck sending the chunk + # vinyl is stuck sending the chunk barrier b1 sync # wait for the timeout to kick in barrier b2 sync @@ -77,7 +77,7 @@ logexpect l2 -v v1 -g raw { client c2 -rcvbuf 256 { txreq -hdr "send_timeout: 100ms" rxresphdrs - # varnish is stuck sending the chunk + # vinyl is stuck sending the chunk barrier b1 sync # wait for the timeout to kick in barrier b2 sync @@ -100,7 +100,7 @@ logexpect l3 -v v1 -g raw { client c3 -rcvbuf 256 { txreq rxresphdrs - # varnish is stuck sending the chunk + # vinyl is stuck sending the chunk barrier b1 sync # wait for the timeout to kick in barrier b2 sync @@ -122,7 +122,7 @@ logexpect l4 -v v1 -g raw { client c4 -rcvbuf 256 { txreq -hdr "idle_send_timeout: 100ms" rxresphdrs - # varnish is stuck sending the chunk + # vinyl is stuck sending the chunk barrier b1 sync # wait for the timeout to kick in barrier b2 sync diff --git a/bin/vinyltest/tests/t02020.vtc b/bin/vinyltest/tests/t02020.vtc index 4ca892dc20..05526346d2 100644 --- a/bin/vinyltest/tests/t02020.vtc +++ b/bin/vinyltest/tests/t02020.vtc @@ -39,7 +39,7 @@ client c1 { } -run client c2 { - # This makes use of the fact that Varnish will always send a + # This makes use of the fact that Vinyl will always send a # session window update immediately when receiving a data # frame. The four rxwinup before barrier sync on stream 0 matches # up with the four txdata frames sent early on the stream, and diff --git a/bin/vinyltest/tests/u00018.vtc b/bin/vinyltest/tests/u00018.vtc index e04666a260..d06b7d0a8a 100644 --- a/bin/vinyltest/tests/u00018.vtc +++ b/bin/vinyltest/tests/u00018.vtc @@ -1,4 +1,4 @@ -vtest "Varnishtest coverage" +vtest "Vinyltest coverage" # Cover usage processing shell -err -expect {usage:} { diff --git a/bin/vinyltest/tests/v00038.vtc b/bin/vinyltest/tests/v00038.vtc index ebdb69367f..844915cb61 100644 --- a/bin/vinyltest/tests/v00038.vtc +++ b/bin/vinyltest/tests/v00038.vtc @@ -145,7 +145,7 @@ vinyl v1 -cliexpect "(?s)Cannot stat:.+That was just a warning" \ # VCC also warns but doesn't fail for EACCES. Tested in c00086.vtc. -# The following test verifies that Varnish continues connecting to a +# The following test verifies that Vinyl continues connecting to a # socket file, even if the listener at that location changes. server s1 -listen "${tmpdir}/server.sock" { diff --git a/bin/vinyltest/tests/v00064.vtc b/bin/vinyltest/tests/v00064.vtc index d6c3579912..c958ede481 100644 --- a/bin/vinyltest/tests/v00064.vtc +++ b/bin/vinyltest/tests/v00064.vtc @@ -59,7 +59,7 @@ vinyl v1 -expect SM?.s0.g_bytes > 1048000 vinyl v1 -expect SM?.s0.g_space < 50 client c1 { - # Check that Varnish is still alive + # Check that Vinyl is still alive txreq -url "/malloc" -hdr "If-Modified-Since: Fri, 03 Apr 2020 12:00:01 GMT" rxresp expect resp.status == 200 diff --git a/bin/vinyltop/flint.lnt b/bin/vinyltop/flint.lnt index 41dadcc9f7..e93e19baf2 100644 --- a/bin/vinyltop/flint.lnt +++ b/bin/vinyltop/flint.lnt @@ -2,7 +2,7 @@ // SPDX-License-Identifier: BSD-2-Clause // See LICENSE file for full text of license --efile(451, "varnishtop_options.h") +-efile(451, "vinyltop_options.h") -e712 // 14 Info 712 Loss of precision (___) (___ to ___) -e747 // 16 Info 747 Significant prototype coercion (___) ___ to ___ @@ -16,7 +16,7 @@ -sem(t_key_VRBT_INSERT, custodial(2)) /////////////////////////////////////////////////////////////////////// -// Varnishstat specific +// Vinylstat specific /// -e850 // for loop index variable '___' whose type category is '___' is modified in body of the for loop that began at '___' diff --git a/bin/vinyltop/vinyltop.c b/bin/vinyltop/vinyltop.c index 82f7329ace..5dd9f12b30 100644 --- a/bin/vinyltop/vinyltop.c +++ b/bin/vinyltop/vinyltop.c @@ -30,7 +30,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * Log tailer for Varnish + * Log tailer for Vinyl */ #include "config.h" diff --git a/contrib/vinylstatdiff b/contrib/vinylstatdiff index 8ff28d86d0..87902453d0 100755 --- a/contrib/vinylstatdiff +++ b/contrib/vinylstatdiff @@ -43,8 +43,8 @@ usage() { Usage: $SCRIPT $SCRIPT -h - Show the differences between two sets of varnish metrics extracted - with 'varnishstat -1'. + Show the differences between two sets of vinyl metrics extracted + with 'vinylstat -1'. Available options: -h : show this help and exit @@ -83,7 +83,7 @@ join_prepare() { # NB: the metrics need to be sorted to later be joined, and since # the metrics descriptions contain spaces, using a delimiter other # than space solves the problem. Hopefully @ never shows up in the - # varnishstat -1 output. + # vinylstat -1 output. sort -k 1b,1 "$1" | sed 's: *:@: ; s::@: ; s::@:' } diff --git a/etc/Makefile.am b/etc/Makefile.am index 76c83fc2ed..85d35a3a30 100644 --- a/etc/Makefile.am +++ b/etc/Makefile.am @@ -6,7 +6,7 @@ dist_doc_DATA = builtin.vcl \ example.vcl builtin.vcl: $(top_srcdir)/bin/vinyld/builtin.vcl - ( printf "This is the VCL configuration Varnish will automatically append to your VCL\nfile during compilation/loading. See the vcl(7) man page for details on syntax\nand semantics.\n\ + ( printf "This is the VCL configuration which Vinyl Cache will automatically append to your VCL\nfile during compilation/loading. See the vcl(7) man page for details on syntax\nand semantics.\n\ New users is recommended to use the example.vcl file as a starting point.\n\n";\ sed -n '/vcl_recv/,$$p' $(top_srcdir)/bin/vinyld/builtin.vcl ) | \ sed 's/^\(.*\)$$/# \1/' > builtin.vcl diff --git a/etc/devicedetect.vcl b/etc/devicedetect.vcl index e1c0e87f3e..4317bb9823 100644 --- a/etc/devicedetect.vcl +++ b/etc/devicedetect.vcl @@ -25,7 +25,7 @@ # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # -# detectdevice.vcl - regex based device detection for Varnish +# detectdevice.vcl - regex based device detection for Vinyl Cache # https://code.vinyl-cache.org/vinyl-cache/vinyl-devicedetect/ # # Original author: Lasse Karstensen diff --git a/include/compat/daemon.h b/include/compat/daemon.h index 6f335e9923..4467bb7d9f 100644 --- a/include/compat/daemon.h +++ b/include/compat/daemon.h @@ -34,9 +34,9 @@ #define COMPAT_DAEMON_H_INCLUDED #ifndef HAVE_DAEMON -int varnish_daemon(int nochdir, int noclose); +int vinyl_daemon(int nochdir, int noclose); #else -#define varnish_daemon(a,b) daemon(a,b) +#define vinyl_daemon(a,b) daemon(a,b) #endif #endif diff --git a/include/tbl/debug_bits.h b/include/tbl/debug_bits.h index 2c6a980c46..8bd10d61ff 100644 --- a/include/tbl/debug_bits.h +++ b/include/tbl/debug_bits.h @@ -42,7 +42,7 @@ DEBUG_BIT(VCLREL, vclrel, "Rapid VCL release") DEBUG_BIT(LURKER, lurker, "VSL Ban lurker") DEBUG_BIT(ESI_CHOP, esi_chop, "Chop ESI fetch to bits") DEBUG_BIT(FLUSH_HEAD, flush_head, "Flush after http1 head") // XXX -> filter -DEBUG_BIT(VTC_MODE, vtc_mode, "Varnishtest Mode") +DEBUG_BIT(VTC_MODE, vtc_mode, "Vinyltest Mode") DEBUG_BIT(WITNESS, witness, "Emit WITNESS lock records") DEBUG_BIT(VSM_KEEP, vsm_keep, "Keep the VSM file on restart") DEBUG_BIT(SLOW_ACCEPTOR, slow_acceptor, "Slow down Acceptor") diff --git a/include/tbl/params.h b/include/tbl/params.h index f293795888..9745f147f4 100644 --- a/include/tbl/params.h +++ b/include/tbl/params.h @@ -1859,7 +1859,7 @@ PARAM_STRING( /* flags */ BUILD_OPTIONS, /* dyn_min_reason */ NULL, /* dyn_max_reason */ NULL, - /* dyn_def_reason */ "${sysconfdir}/varnish:${datadir}/varnish/vcl" + /* dyn_def_reason */ "${sysconfdir}/vinyl-cache:${datadir}/vinyl-cache/vcl" ) PARAM_STRING( @@ -1873,7 +1873,7 @@ PARAM_STRING( /* flags */ BUILD_OPTIONS, /* dyn_min_reason */ NULL, /* dyn_max_reason */ NULL, - /* dyn_def_reason */ "${libdir}/varnish/vmods" + /* dyn_def_reason */ "${libdir}/vinyl-cache/vmods" ) /*-------------------------------------------------------------------- diff --git a/include/tbl/vsc_levels.h b/include/tbl/vsc_levels.h index c043bc5b82..358885cab6 100644 --- a/include/tbl/vsc_levels.h +++ b/include/tbl/vsc_levels.h @@ -46,7 +46,7 @@ VSC_LEVEL_F(diag, "DIAG", "Diagnostic counters", ) VSC_LEVEL_F(debug, "DEBUG", "Debug counters", - "Counters giving Varnish internals debug information" + "Counters giving Vinyl internals debug information" ) #undef VSC_LEVEL_F diff --git a/include/vapi/vsm.h b/include/vapi/vsm.h index 6339e24165..9f3be5ff5f 100644 --- a/include/vapi/vsm.h +++ b/include/vapi/vsm.h @@ -86,7 +86,7 @@ void VSM_ResetError(struct vsm *vd); * Reset recorded error message. */ -#define VSM_n_USAGE "[-n varnish_name]" +#define VSM_n_USAGE "[-n vinyl_name]" #define VSM_t_USAGE "[-t ]" int VSM_Arg(struct vsm *, char flag, const char *arg); diff --git a/include/vcli.h b/include/vcli.h index 373245ac16..a9880b9062 100644 --- a/include/vcli.h +++ b/include/vcli.h @@ -28,7 +28,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * Public definition of the CLI protocol, part of the published Varnish-API. + * Public definition of the CLI protocol, part of the published Vinyl-API. * * The overall structure of the protocol is a command-line like * "command+arguments" request and a IETF style "number + string" response. diff --git a/include/vcli_serve.h b/include/vcli_serve.h index 4e9be7343e..be13e9403b 100644 --- a/include/vcli_serve.h +++ b/include/vcli_serve.h @@ -28,7 +28,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * Varnish process internal CLI stuff. + * Vinyl process internal CLI stuff. * * XXX: at a latter date we may want to move some to cli.h/libvinylapi */ diff --git a/include/vre.h b/include/vre.h index fc58c234b1..fabeaa33eb 100644 --- a/include/vre.h +++ b/include/vre.h @@ -30,7 +30,7 @@ * Regular expression support * * We wrap PCRE2 in VRE to make to make it feasible to use something else - * without hunting down stuff through out the Varnish source code. + * without hunting down stuff through out the Vinyl source code. * */ diff --git a/include/vte.h b/include/vte.h index 28e26871e4..830b9f6d1e 100644 --- a/include/vte.h +++ b/include/vte.h @@ -26,7 +26,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * Varnish Turbo Encabulator + * Vinyl Turbo Encabulator * * Align and print fields in a line-based output. Fields are delimited * with a horizontal tab HT and lines starting with a space SP are kept diff --git a/lib/libvcc/vcc_compile.c b/lib/libvcc/vcc_compile.c index 368a6a34d6..8feee69621 100644 --- a/lib/libvcc/vcc_compile.c +++ b/lib/libvcc/vcc_compile.c @@ -40,7 +40,7 @@ * > sub request_policy { * > ----##############-- * >Read more about this type of error: - * >http://varnish/doc/error.html#Unreferenced%20function + * >http://vinyl/doc/error.html#Unreferenced%20function * > * > * > Unknown variable 'obj.bandwidth' @@ -48,7 +48,7 @@ * > if (obj.bandwidth < 1 kb/h) { * > ------------#############------------ * >Read more about this type of error: - * >http://varnish/doc/error.html#Unknown%20variable + * >http://vinyl/doc/error.html#Unknown%20variable * */ diff --git a/lib/libvcc/vcc_token.c b/lib/libvcc/vcc_token.c index 96ece50e36..7b8d4830e4 100644 --- a/lib/libvcc/vcc_token.c +++ b/lib/libvcc/vcc_token.c @@ -321,7 +321,7 @@ vcc_IdIs(const struct token *t, const char *p) } /*-------------------------------------------------------------------- - * Check that we have a Varnish identifier + * Check that we have a Vinyl identifier */ void diff --git a/lib/libvcc/vmodtool.py b/lib/libvcc/vmodtool.py index 349278f89f..91a6c7747b 100755 --- a/lib/libvcc/vmodtool.py +++ b/lib/libvcc/vmodtool.py @@ -1203,7 +1203,7 @@ def json(self, fo, fnx): fo.write('\t\"\\n\\x03\"\n};\n') fo.write('#undef STRINGIFY\n') - # parts from varnish-cache include/generate.py + # parts from vinyl-cache include/generate.py def version(self): srcdir = os.path.dirname(self.inputfile) @@ -1223,7 +1223,7 @@ def version(self): break return pkgstr - # parts from varnish-cache include/generate.py + # parts from vinyl-cache include/generate.py def vcs(self): srcdir = os.path.normpath(os.path.dirname(self.inputfile)) diff --git a/lib/libvinyl/vnum.c b/lib/libvinyl/vnum.c index b12e6bc01e..253e8fd256 100644 --- a/lib/libvinyl/vnum.c +++ b/lib/libvinyl/vnum.c @@ -189,9 +189,9 @@ SF_Parse_Decimal(const char **ipp, int strict, const char **errtxt) } /********************************************************************** - * Parse a "Varnish number". + * Parse a "Vinyl number". * - * Varnish numbers are the union of RFC8941 sf-integer and sf-decimal. + * Vinyl numbers are the union of RFC8941 sf-integer and sf-decimal. * If `errno` is non-zero the conversion failed and NAN is returned. */ diff --git a/lib/libvinyl/vsa.c b/lib/libvinyl/vsa.c index 58477a0028..7ea79685a8 100644 --- a/lib/libvinyl/vsa.c +++ b/lib/libvinyl/vsa.c @@ -155,7 +155,7 @@ * false negatives which confuse people ? * * I have decided to try to contain this crap in this single - * source-file, with only minimum leakage into the rest of Varnish, + * source-file, with only minimum leakage into the rest of Vinyl, * which will only know of pointers to "struct suckaddr", the naming * of which is my of the historical narrative above. * diff --git a/lib/libvinylapi/daemon.c b/lib/libvinylapi/daemon.c index 3ff7a9a9a2..43f119bd92 100644 --- a/lib/libvinylapi/daemon.c +++ b/lib/libvinylapi/daemon.c @@ -62,7 +62,7 @@ vfil_null_fd(int target) } int -varnish_daemon(int nochdir, int noclose) +vinyl_daemon(int nochdir, int noclose) { struct sigaction osa, sa; pid_t newgrp; diff --git a/lib/libvinylapi/vut.c b/lib/libvinylapi/vut.c index 42839da0c1..930b74df65 100644 --- a/lib/libvinylapi/vut.c +++ b/lib/libvinylapi/vut.c @@ -75,7 +75,7 @@ vut_daemon(struct VUT *vut) if (daemonized) VUT_Error(vut, 1, "Already running as a daemon"); daemonized = 1; - return (varnish_daemon(0, 0)); + return (vinyl_daemon(0, 0)); } static void @@ -187,7 +187,7 @@ VUT_Arg(struct VUT *vut, int opt, const char *arg) VUT_Error(vut, 1, "-k: Invalid number '%s'", arg); return (1); case 'n': - /* Varnish instance name */ + /* Vinyl instance name */ AN(arg); REPLACE(vut->n_arg, arg); return (1); diff --git a/lib/libvsc/vsctool.py b/lib/libvsc/vsctool.py index e46a3203b2..a05ce2b057 100755 --- a/lib/libvsc/vsctool.py +++ b/lib/libvsc/vsctool.py @@ -359,7 +359,7 @@ def getdoc(self): Note that these docs end with the first '\n.. ' sequence in the .vsc file, so that we can put a longer and more complex description into the .RST docs than the "long" - explanation varnishstat(1) and similar programs provide. + explanation vinylstat(1) and similar programs provide. ''' while self.ldoc and self.ldoc[0].strip() == "": self.ldoc.pop(0) diff --git a/tools/audit_vfl.sh b/tools/audit_vfl.sh index 4be60a9714..d72fcfd742 100644 --- a/tools/audit_vfl.sh +++ b/tools/audit_vfl.sh @@ -6,6 +6,6 @@ sed ' s/VFL_Open/flopen/ -' lib/libvarnish/vfl.c | +' lib/libvinyl/vfl.c | diff -u /usr/src/lib/libutil/flopen.c - diff --git a/tools/audit_vpf.sh b/tools/audit_vpf.sh index 2115e6c718..c62f0b2891 100644 --- a/tools/audit_vpf.sh +++ b/tools/audit_vpf.sh @@ -13,6 +13,6 @@ s/pidfile_Close/pidfile_close/g s/pidfile_Remove/pidfile_remove/g s/pidfile_Open/pidfile_open/g s/ (void)/ /g -' lib/libvarnish/vpf.c | +' lib/libvinyl/vpf.c | diff -ub /usr/src/lib/libutil/pidfile.c - diff --git a/tools/audit_vsha256.sh b/tools/audit_vsha256.sh index a81c8c0950..f7434fbb15 100644 --- a/tools/audit_vsha256.sh +++ b/tools/audit_vsha256.sh @@ -6,6 +6,6 @@ sed ' s/vbe32/be32/g -' lib/libvarnish/vsha256.c | +' lib/libvinyl/vsha256.c | diff -ub /usr/src/sys/crypto/sha2/sha256c.c - diff --git a/tools/coccinelle/archive/wrk_vpi.cocci b/tools/coccinelle/archive/wrk_vpi.cocci index bea1e285bd..b0df01a90b 100644 --- a/tools/coccinelle/archive/wrk_vpi.cocci +++ b/tools/coccinelle/archive/wrk_vpi.cocci @@ -3,7 +3,7 @@ * * Retained for reference only */ -using "varnish.iso" +using "vinyl.iso" @@ idexpression struct worker *wrk; diff --git a/tools/coccinelle/varnish.iso b/tools/coccinelle/varnish.iso index c47b97f69d..42b555571c 100644 --- a/tools/coccinelle/varnish.iso +++ b/tools/coccinelle/varnish.iso @@ -1,11 +1,11 @@ /* - * This file contains isomorphisms specific to the Varnish code base and - * out of tree Varnish projects such as VUTs for VMODs. + * This file contains isomorphisms specific to the Vinyl code base and + * out of tree Vinyl projects such as VUTs for VMODs. * * It can be used directly by semantic patches from the same directory * with the following syntax: * - * @using "varnish.iso"@ + * @using "vinyl.iso"@ * * @@ * diff --git a/tools/coccinelle/vcocci.sh b/tools/coccinelle/vcocci.sh index c6235496ec..36c0a37c30 100755 --- a/tools/coccinelle/vcocci.sh +++ b/tools/coccinelle/vcocci.sh @@ -50,10 +50,10 @@ usage() { apply Apply a patch to the source tree parse Parse and expand a patch - mkiso Generate a varnish.iso file + mkiso Generate a vinyl.iso file help Show this help and exit - This script operates directly on the Varnish Cache git repository. + This script operates directly on the Vinyl Cache git repository. EOF exit $ERR } diff --git a/tools/coccinelle/vcountof.cocci b/tools/coccinelle/vcountof.cocci index 277c279082..8b36e53b70 100644 --- a/tools/coccinelle/vcountof.cocci +++ b/tools/coccinelle/vcountof.cocci @@ -7,7 +7,7 @@ // // copied and modified from https://coccinelle.gitlabpages.inria.fr/website/rules/array.cocci -using "varnish.iso" +using "vinyl.iso" @@ type T; diff --git a/tools/coccinelle/vminmax.cocci b/tools/coccinelle/vminmax.cocci index b3ebe292c6..0a2ec2fa9c 100644 --- a/tools/coccinelle/vminmax.cocci +++ b/tools/coccinelle/vminmax.cocci @@ -3,7 +3,7 @@ * * Note: Has false positives on pointer types, tolerated for clarity */ -using "varnish.iso" +using "vinyl.iso" @@ type T; T e1, e2; @@ diff --git a/tools/coccinelle/vsl_setup_retire.cocci b/tools/coccinelle/vsl_setup_retire.cocci index 034abaf26b..64c21424a0 100644 --- a/tools/coccinelle/vsl_setup_retire.cocci +++ b/tools/coccinelle/vsl_setup_retire.cocci @@ -5,7 +5,7 @@ * * Retained for reference and use by VMODs only */ -using "varnish.iso" +using "vinyl.iso" @@ expression vsl; diff --git a/tools/coverity-run b/tools/coverity-run index 0e2b2c6506..d5d72202ff 100755 --- a/tools/coverity-run +++ b/tools/coverity-run @@ -1,6 +1,6 @@ #!/bin/sh # -# Build Varnish under Coverity, and upload the output to Coverity Scan. +# Build Vinyl under Coverity, and upload the output to Coverity Scan. # # Requires the Coverity scanner in $PATH and the upload token set in $COVTOKEN. # @@ -49,6 +49,6 @@ curl --form token=$COVTOKEN \ --form "file=@myproject.tgz" \ --form version="$GITREF" \ --form description="description=${GITBRANCH}_branch" \ - 'https://scan.coverity.com/builds?project=varnish' + 'https://scan.coverity.com/builds?project=vinyl' rm myproject.tgz diff --git a/tools/lsan.suppr b/tools/lsan.suppr index bc3a32ebd0..755f386189 100644 --- a/tools/lsan.suppr +++ b/tools/lsan.suppr @@ -1,4 +1,4 @@ -# varnishtest +# vinyltest leak:parse_string # av leak:STV_Config diff --git a/tools/tsan.suppr b/tools/tsan.suppr index ff9fac8227..a0f027563a 100644 --- a/tools/tsan.suppr +++ b/tools/tsan.suppr @@ -1,3 +1,3 @@ -# varnishtest +# vinyltest race:cmd_barrier race:vtc_log diff --git a/tools/vtc-bisect.sh b/tools/vtc-bisect.sh index b5e2007877..0348b06997 100755 --- a/tools/vtc-bisect.sh +++ b/tools/vtc-bisect.sh @@ -89,9 +89,9 @@ run() { if [ -n "$INVERSE" ] then - ! bin/varnishtest/varnishtest -i "$VTC_FILE" + ! bin/vinyltest/vinyltest -i "$VTC_FILE" else - bin/varnishtest/varnishtest -i "$VTC_FILE" + bin/vinyltest/vinyltest -i "$VTC_FILE" fi exit $? } diff --git a/vinyl-legacy.m4 b/vinyl-legacy.m4 index 3004f0b4f4..73a3af63e6 100644 --- a/vinyl-legacy.m4 +++ b/vinyl-legacy.m4 @@ -1,4 +1,4 @@ -# varnish-legacy.m4 - Macros to locate Varnish header files. -*- Autoconf -*- +# vinyl-legacy.m4 - Macros to locate Vinyl header files. -*- Autoconf -*- # serial 4 (varnish-4.0) # Copyright (c) 2013-2016 Varnish Software AS diff --git a/vmod/vmod_math_gen.py b/vmod/vmod_math_gen.py index 72ba4fef26..51251ff12f 100755 --- a/vmod/vmod_math_gen.py +++ b/vmod/vmod_math_gen.py @@ -257,7 +257,7 @@ def gen_class(spec, vcc_fh, c_fh): vcc_top = """ #- -# This document is licensed under the same conditions as Varnish-Cache itself. +# This document is licensed under the same conditions as Vinyl Cache itself. # See LICENSE for details. # # SPDX-License-Identifier: BSD-2-Clause diff --git a/vmod/vmod_vtc.c b/vmod/vmod_vtc.c index c42b70e95f..9861f52dfc 100644 --- a/vmod/vmod_vtc.c +++ b/vmod/vmod_vtc.c @@ -454,7 +454,7 @@ vsl_line(VRT_CTX, char *str) char *e, *save; if (*str == '*') { - // varnishtest + // vinyltest str = strstr(str, "vsl|"); if (str == NULL) return; diff --git a/vsc.am b/vsc.am index b9f269c4d0..5f80ad25e3 100644 --- a/vsc.am +++ b/vsc.am @@ -1,6 +1,6 @@ ## Generic rule to generate C code from VSC files. VSC files must be listed ## in the $(VSC_SRC) variable. The $(VSCTOOL) variable must point to the -## location of vsctool.py, normally set up by varnish.m4 at configure time. +## location of vsctool.py, normally set up by vinyl.m4 at configure time. ## The resulting $(VSC_GEN) variable must be added to $(BUILT_SOURCES). The ## $(VSC_RST) variable references RST file names for manual pages includes. From c0530594408905c2854336826e0a58ef012cad9f Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 16:22:52 +0100 Subject: [PATCH 137/196] NO --- doc/sphinx/conf.py.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/sphinx/conf.py.in b/doc/sphinx/conf.py.in index 8b56f64c9c..972719de2f 100644 --- a/doc/sphinx/conf.py.in +++ b/doc/sphinx/conf.py.in @@ -47,8 +47,8 @@ master_doc = 'index' # General information about the project. project = u'Vinyl Cache Project' -copyright = u'2016-2026, The Varnish Cache and Vinyl Cache Contributors. Vinyl Cache Logo & Mascot: CC-BY 4.0 Rhubarbe.design' -author = u'The Varnish Cache and Vinyl Cache Contributors' +copyright = u'2016-2026, The Vinyl Cache Cache and Vinyl Cache Contributors. Vinyl Cache Logo & Mascot: CC-BY 4.0 Rhubarbe.design' +author = u'The Vinyl Cache Cache and Vinyl Cache Contributors' # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the @@ -225,7 +225,7 @@ latex_elements = { # author, documentclass [howto, manual, or own class]). latex_documents = [ ('index', 'VinylCache.tex', u'Vinyl Cache Administrator documentation', - u'The Varnish Cache and Vinyl Cache Contributors', 'manual'), + u'The Vinyl Cache Cache and Vinyl Cache Contributors', 'manual'), ] # The name of an image file (relative to this directory) to place at the top of From 7e7fb9092e2b6618869dc2ae133aae1cdc6e1221 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Mar 2026 16:31:06 +0100 Subject: [PATCH 138/196] Revert "NO" Sorry, this was a commit to be discarded locally This reverts commit c0530594408905c2854336826e0a58ef012cad9f. --- doc/sphinx/conf.py.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/sphinx/conf.py.in b/doc/sphinx/conf.py.in index 972719de2f..8b56f64c9c 100644 --- a/doc/sphinx/conf.py.in +++ b/doc/sphinx/conf.py.in @@ -47,8 +47,8 @@ master_doc = 'index' # General information about the project. project = u'Vinyl Cache Project' -copyright = u'2016-2026, The Vinyl Cache Cache and Vinyl Cache Contributors. Vinyl Cache Logo & Mascot: CC-BY 4.0 Rhubarbe.design' -author = u'The Vinyl Cache Cache and Vinyl Cache Contributors' +copyright = u'2016-2026, The Varnish Cache and Vinyl Cache Contributors. Vinyl Cache Logo & Mascot: CC-BY 4.0 Rhubarbe.design' +author = u'The Varnish Cache and Vinyl Cache Contributors' # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the @@ -225,7 +225,7 @@ latex_elements = { # author, documentclass [howto, manual, or own class]). latex_documents = [ ('index', 'VinylCache.tex', u'Vinyl Cache Administrator documentation', - u'The Vinyl Cache Cache and Vinyl Cache Contributors', 'manual'), + u'The Varnish Cache and Vinyl Cache Contributors', 'manual'), ] # The name of an image file (relative to this directory) to place at the top of From a91117dac72e05d38646d9b07ca18d03c8ceee9c Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Mar 2026 08:45:12 +0100 Subject: [PATCH 139/196] Add /vinyl-cache-trunk to .gitignore --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 5fab7ead30..d8cf3355fa 100644 --- a/.gitignore +++ b/.gitignore @@ -148,6 +148,7 @@ cscope.*out # Source artifact /vinyl-cache-trunk.tar.gz +/vinyl-cache-trunk # Witness droppings witness.dot From f1ee6c0915fd24c942bc71981e34ce9be65cb17f Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Mar 2026 08:49:58 +0100 Subject: [PATCH 140/196] Partly vinylize and update who.rst this would really need a more complete overhaul. Many people relevant in the project are not mentioned at all. --- doc/sphinx/dev-guide/who.rst | 41 ++++++++++++++++++------------------ 1 file changed, 20 insertions(+), 21 deletions(-) diff --git a/doc/sphinx/dev-guide/who.rst b/doc/sphinx/dev-guide/who.rst index 931841fa84..5dc05ea412 100644 --- a/doc/sphinx/dev-guide/who.rst +++ b/doc/sphinx/dev-guide/who.rst @@ -41,18 +41,18 @@ He does have 30+ years of experience in systems programming, and that seems useful too. PHK's `random outbursts `_ has their own -section in the Varnish documentation. +section in the Vinyl Cache documentation. Per Buer ~~~~~~~~ Per also worked at Redpill-Linpro, and at some point when the impedance mismatch between Linpros "normal way of doing things" and -the potential of Varnish became to steep, he convinced the company +the potential of Varnish Cache became to steep, he convinced the company to spin off `Varnish Software `_ with himself at the helm. -Do a git blame on the Varnish documentation and you will be surprised +Do a git blame on the Varnish Cache documentation and you will be surprised to see how much he cares about it. Very few people notice this. Ingvar Hagelund @@ -60,9 +60,9 @@ Ingvar Hagelund Ingvar works as Team Leader (read very skilled sysadmin) at Redpill-Linpro, but his passion is reading books and blogging about it, as well as RPM -packaging. So every Fedora and EPEL (read RedHat and CentOS) Varnish user +packaging. So every Fedora and EPEL (read RedHat and CentOS) Varnish Cache user out there owe him a thanks or two. Once in a while, he also trawls the -internet checking for the rate of Varnish adoption among top web sites. +internet checking for the rate of Varnish Cache adoption among top web sites. Stig Sandbeck Mathisen ~~~~~~~~~~~~~~~~~~~~~~ @@ -75,27 +75,27 @@ he maintains VCL-mode for emacs and is generally a nice and helpful guy. Tollef Fog Heen ~~~~~~~~~~~~~~~ -Tollef was product owner and responsible for Varnish while working +Tollef was product owner and responsible for Varnish Cache while working for Redpill-Linpro. later tech lead at Varnish Software and held -the Varnish release manager helmet for a few years. His experience with +the Varnish Cache release manager helmet for a few years. His experience with open source (Debian, Ubuntu and many others) brought sanity to the project in ways that are hard to measure or describe. Kristian Lyngstøl ~~~~~~~~~~~~~~~~~ -Kristian was the first Varnish SuperUser, and he quite literally -wrote the book, while giving Varnish courses for Redpill-Linpro, +Kristian was the first Varnish Cache SuperUser, and he quite literally +wrote the book, while giving Varnish Cache courses for Redpill-Linpro, and he pushed boundaries where no boundaries had been pushed before which caused a lot of improvements and "aha!" moments in Varnish. Artur Bergman ~~~~~~~~~~~~~ -Artur ran Wikias webservers and CDN when he discovered Varnish and +Artur ran Wikias webservers and CDN when he discovered Varnish Cache and eagerly adopted it, causing many bugreports, suggestions, patches and improvements. At some point, he pivoted Wikias CDN into the -Varnish based startup-CDN named `Fastly `_ +Varnish Cache based startup-CDN named `Fastly `_ Kacper Wysocki ~~~~~~~~~~~~~~ @@ -103,7 +103,7 @@ Kacper Wysocki Kacper was probably the first VCL long program writer. Combine this with an interest in security and a job at Redpill-Linpro and he turned quickly into the author of security.vcl and, later, the Varnish Security -Firewall. He does not have any commits in Varnish and still has managed +Firewall. He does not have any commits in Varnish Cache and still has managed to drive quite a few changes into the project. Similarly, he has no idea or has even thought about asking for it, and still is being added here He maintains the VCL grammar in BNF notation, which is an unexploited @@ -115,14 +115,14 @@ Nils Goroll aka 'slink' is the founder of `UPLEX `_, a five-head tech / consultancy company with negative to zero marketing (applied for entry into the "Earth's worst company homepage" competition). He -fell in love with Varnish when he migrated Germany's Verdens Gang +fell in love with Varnish Cache when he migrated Germany's Verdens Gang counterpart over a weekend in March 2009 and, since then, has experienced countless moments of pure joy and happiness when, after struggling for hours, he finally understood another piece of -beautiful, ingenious Varnish code. +beautiful, ingenious Vinyl Cache code. Nils' primary focus are his clients and their projects. He tries to -make those improvements to Varnish which matter to them. +make those improvements to Vinyl Cache which matter to them. Martin Blix Grydeland ~~~~~~~~~~~~~~~~~~~~~ @@ -131,23 +131,22 @@ Martin was the first full-time member of the C-team at Varnish Software. He is the main responsible for the amazing revamp of the logging facilities and utilities in the 4.0 cycle and later the storage rework. Besides that he fixes lots of bugs, knows varnishtest better -than most, writes vmods and is the Vinyl Cache Plus architect. +than most, writes vmods and is the Varnish Cache Plus architect. Lasse Karstensen ~~~~~~~~~~~~~~~~ -Lasse is the current release manager and stable version maintainer of -Vinyl Cache. When not doing that, he maintains build infrastructure -and runs the Varnish Software C developer team in Oslo. +Lasse was the release manager and stable version maintainer of +Varnish Cache for years. Geoff Simmons ~~~~~~~~~~~~~ Geoff started working at UPLEX in 2010 and soon learned to love -Varnish as much as slink does. Since then he's been contributing code +Varnish Cache as much as slink does. Since then he's been contributing code to the project, writing up various VMODs (mostly about regular expressions, blobs, backends and directors), developing standalone applications for logging that use Martin's VSL API, and adding custom -patches to Varnish for various customer needs. He spends most of his +patches to Varnish Cache for various customer needs. He spends most of his days in customer projects as "the Varnish guy" on the operations teams. From c503fbf952068b0a12b95172b7c42305ee2c1bed Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Mar 2026 08:47:11 +0100 Subject: [PATCH 141/196] Vinylize most of the docs the guiding principle here was: - if it still applies, change to Vinyl Cache - if historic, keep Varnish Cache - be careful with phk docs in particular, and prefer old version when in doubt Methodology: Create baseline: git reset --hard ; for f in $(git grep -lP '([vV])arnish(?!(-softwar| Software))') ; do mv $f $f.o && perl -ne <$f.o >$f 's#([vV])arnish(?!(-| [sS]oftware))#\1inyl Cache\2#gm; print $_;' && rm $f.o ; done ; git diff Then either - commit change as is (to be later squashed into this commit) - undo usind git checkout origin/main -- $file - or manually edit and commit --- doc/sphinx/dev-guide/policy_vmods.rst | 10 +-- doc/sphinx/installation/install.rst | 2 +- doc/sphinx/installation/install_freebsd.rst | 8 ++- doc/sphinx/installation/install_source.rst | 44 ++++++------ doc/sphinx/installation/platformnotes.rst | 32 ++++----- doc/sphinx/installation/prerequisites.rst | 4 +- doc/sphinx/phk/apispaces.rst | 12 ++-- doc/sphinx/phk/autocrap.rst | 4 +- doc/sphinx/phk/barriers.rst | 24 +++---- doc/sphinx/phk/brinch-hansens-arrows.rst | 10 +-- doc/sphinx/phk/gzip.rst | 26 +++---- doc/sphinx/phk/ip_address.rst | 10 +-- doc/sphinx/phk/ipv6suckage.rst | 2 +- doc/sphinx/phk/platforms.rst | 18 ++--- doc/sphinx/phk/quic.rst | 18 ++--- doc/sphinx/phk/sphinx.rst | 4 +- doc/sphinx/phk/thetoolsweworkwith.rst | 4 +- doc/sphinx/reference/cli_protocol.rst | 6 +- doc/sphinx/reference/vcl_step.rst | 6 +- doc/sphinx/reference/vext.rst | 8 +-- doc/sphinx/users-guide/compression.rst | 20 +++--- doc/sphinx/users-guide/devicedetection.rst | 10 +-- doc/sphinx/users-guide/esi.rst | 26 +++---- doc/sphinx/users-guide/index.rst | 24 +++---- doc/sphinx/users-guide/intro.rst | 25 ++++--- doc/sphinx/users-guide/operation-logging.rst | 18 ++--- .../users-guide/operation-statistics.rst | 8 +-- doc/sphinx/users-guide/params.rst | 2 +- doc/sphinx/users-guide/performance.rst | 14 ++-- doc/sphinx/users-guide/purging.rst | 38 +++++----- doc/sphinx/users-guide/report.rst | 2 +- doc/sphinx/users-guide/run_cli.rst | 8 +-- doc/sphinx/users-guide/run_security.rst | 28 ++++---- doc/sphinx/users-guide/running.rst | 10 +-- doc/sphinx/users-guide/storage-backends.rst | 36 +++++----- doc/sphinx/users-guide/troubleshooting.rst | 72 +++++++++---------- doc/sphinx/users-guide/vcl-backends.rst | 48 ++++++------- doc/sphinx/users-guide/vcl-built-in-code.rst | 6 +- .../users-guide/vcl-example-websockets.rst | 2 +- doc/sphinx/users-guide/vcl-grace.rst | 28 ++++---- doc/sphinx/users-guide/vcl-hashing.rst | 18 ++--- doc/sphinx/users-guide/vcl-inline-c.rst | 8 +-- doc/sphinx/users-guide/vcl-separate.rst | 28 ++++---- doc/sphinx/users-guide/vcl-syntax.rst | 8 +-- doc/sphinx/users-guide/vcl-variables.rst | 4 +- doc/sphinx/users-guide/vcl.rst | 20 +++--- .../req-hash_ignore_vary.rst | 2 +- .../vcl-design-patterns/resp-status.rst | 2 +- doc/sphinx/vtc-syntax.py | 2 +- doc/sphinx/whats-new/index.rst | 10 ++- 50 files changed, 389 insertions(+), 390 deletions(-) diff --git a/doc/sphinx/dev-guide/policy_vmods.rst b/doc/sphinx/dev-guide/policy_vmods.rst index ee5575fc19..4a33e6129a 100644 --- a/doc/sphinx/dev-guide/policy_vmods.rst +++ b/doc/sphinx/dev-guide/policy_vmods.rst @@ -5,11 +5,11 @@ .. _policy-vmods: -Bundling VMODs with the Varnish distribution --------------------------------------------- +Bundling VMODs with the Vinyl Cache distribution +------------------------------------------------ -Decisions about whether to add a new Varnish module (VMOD) to those -bundled with Varnish are guided by these criteria. +Decisions about whether to add a new Vinyl Cache module (VMOD) to those +bundled with Vinyl Cache are guided by these criteria. * The VMOD is known to be in widespread use and in high demand for common use cases. @@ -25,7 +25,7 @@ bundled with Varnish are guided by these criteria. * We don't want to add new burdens of dependency and compatibility to the project. - * We don't want to force Varnish deployments to install more than + * We don't want to force Vinyl Cache deployments to install more than admins explicitly choose to install. * The VMOD code follows project conventions (passes make distcheck, diff --git a/doc/sphinx/installation/install.rst b/doc/sphinx/installation/install.rst index 3ee4e5f2af..e94a0f36f3 100644 --- a/doc/sphinx/installation/install.rst +++ b/doc/sphinx/installation/install.rst @@ -31,7 +31,7 @@ Compiling Vinyl Cache from source ================================= If there are no binary packages available for your system, or if you -want to compile Varnish from source for other reasons: +want to compile Vinyl Cache from source for other reasons: .. toctree:: :maxdepth: 2 diff --git a/doc/sphinx/installation/install_freebsd.rst b/doc/sphinx/installation/install_freebsd.rst index 531cf2471f..87e5953cc3 100644 --- a/doc/sphinx/installation/install_freebsd.rst +++ b/doc/sphinx/installation/install_freebsd.rst @@ -8,10 +8,12 @@ Installing on FreeBSD ===================== +.. XXX needs to be updated for Vinyl + From package ------------ -FreeBSD offers two versions of Varnish pre-packaged:: +FreeBSD offers two versions of Varnish Cache pre-packaged:: pkg install varnish6 @@ -23,8 +25,8 @@ From ports ---------- The FreeBSD packages are built out of the "ports" tree, and you can -install varnish directly from ports if you prefer, for instance to -get a newer version of Varnish than the current set of prebuilt +install Varnish Cache directly from ports if you prefer, for instance to +get a newer version of Varnish Cache than the current set of prebuilt packages provide:: cd /usr/ports/www/varnish6 diff --git a/doc/sphinx/installation/install_source.rst b/doc/sphinx/installation/install_source.rst index f825b622b1..cafd8fe13a 100644 --- a/doc/sphinx/installation/install_source.rst +++ b/doc/sphinx/installation/install_source.rst @@ -5,11 +5,11 @@ .. _install-src: -Compiling Varnish from source -============================= +Compiling Vinyl Cache from source +================================= If there are no binary packages available for your system, or if you -want to compile Varnish from source for other reasons, follow these +want to compile Vinyl Cache from source for other reasons, follow these steps: Getting hold of the source @@ -18,7 +18,7 @@ Getting hold of the source Download the appropriate release tarball, which you can find on https://vinyl-cache.org/releases/ . -Alternatively, if you want to hack on Varnish, you should clone our +Alternatively, if you want to hack on Vinyl Cache, you should clone our git repository by doing. ``git clone --recursive https://code.vinyl-cache.org/vinyl-cache/vinyl-cache`` @@ -32,7 +32,7 @@ tell git to replace the url: Build dependencies on FreeBSD ----------------------------- -To get the dependencies required to build varnish from source +To get the dependencies required to build vinyl Cache from source you can either:: pkg install git automake pkgconf py39-sphinx py39-docutils pcre2 libtool @@ -43,21 +43,17 @@ And optionally, to be able to run all the testcases:: pkg install haproxy nghttp2 vttest -Or if you want the built from sources:: - - cd /usr/ports/www/varnish6 - make depends clean - +.. XXX ports is mentioned in install_freebsd.rst .. XXX furo for sphinx -Then continue `Compiling Varnish`_ +Then continue `Compiling Vinyl Cache`_ Build dependencies on Debian / Ubuntu -------------------------------------- .. grep-dctrl -n -sBuild-Depends -r ^ ../../../../varnish-cache-debian/control | tr -d '\n' | awk -F,\ '{ for (i = 0; ++i <= NF;) { sub (/ .*/, "", $i); print "* `" $i "`"; }}' | egrep -v '(debhelper)' -In order to build Varnish from source you need a number of packages +In order to build Vinyl Cache from source you need a number of packages installed. On a Debian or Ubuntu system, use this command to install them (replace ``sudo apt-get install`` if needed):: @@ -91,12 +87,12 @@ Optionally, to build the HTML documentation:: sudo apt-get install pip furo -Then continue `Compiling Varnish`_ +Then continue `Compiling Vinyl Cache`_ Build dependencies on Red Hat / CentOS -------------------------------------- -.. gawk '/^BuildRequires/ {print "* `" $2 "`"}' ../../../redhat/varnish.spec | sort | uniq | egrep -v '(systemd)' +.. gawk '/^BuildRequires/ {print "* `" $2 "`"}' ../../../redhat/vinyl Cache.spec | sort | uniq | egrep -v '(systemd)' in the following shell commands, replace ``sudo yum install`` if needed. @@ -160,12 +156,12 @@ Optionally, to pull from a repository:: .. XXX autoconf-archive ? is this any helpful on the notoriously outdated Redhats? -Then continue `Compiling Varnish`_ +Then continue `Compiling Vinyl Cache`_ Build dependencies on macOS --------------------------- -To compile varnish on macOS, these steps should install the required +To compile vinyl Cache on macOS, these steps should install the required dependencies: * Install xcode: `xcode-select --install` @@ -188,7 +184,7 @@ dependencies: It'll be a good idea to persist these changes so you can rebuild the source later. -Then continue `Compiling Varnish`_ +Then continue `Compiling Vinyl Cache`_ Build dependencies on Alpine Linux ---------------------------------- @@ -228,7 +224,7 @@ Optionally, to pull from a repository:: .. XXX furo for sphinx -Then continue `Compiling Varnish`_, using the ``--with-unwind`` +Then continue `Compiling Vinyl Cache`_, using the ``--with-unwind`` ``configure`` option. .. _Alpine Community Repository: https://wiki.alpinelinux.org/wiki/Enable_Community_Repository @@ -260,7 +256,7 @@ Building on Solaris and other Solaris-ish OSes Building with gcc should be straight forward, as long as the above requirements are installed. -By convention, consider installing Varnish under `/opt/local` using:: +By convention, consider installing Vinyl Cache under `/opt/local` using:: ./configure \ --prefix=/opt/local \ @@ -291,19 +287,19 @@ If you see this error from GNU ``cp``:: put ``/usr/bin`` first in ``PATH``. -Compiling Varnish ------------------ +Compiling Vinyl Cache +--------------------- The configuration will need the dependencies above satisfied. Once that is taken care of:: - cd varnish-cache + cd vinyl-cache sh autogen.sh sh configure make The `configure` script takes some arguments, but more likely than not you can -forget about that for now, almost everything in Varnish can be tweaked with run +forget about that for now, almost everything in Vinyl Cache can be tweaked with run time parameters. Before you install, you may want to run the test suite, make a cup of @@ -322,6 +318,6 @@ Installing And finally, the true test of a brave heart: ``sudo make install`` -Varnish will now be installed in ``/usr/local``. The ``vinyld`` binary is in +Vinyl Cache will now be installed in ``/usr/local``. The ``vinyld`` binary is in `/usr/local/sbin/vinyld`. To make sure that the necessary links and caches of the most recent shared libraries are found, run ``sudo ldconfig``. diff --git a/doc/sphinx/installation/platformnotes.rst b/doc/sphinx/installation/platformnotes.rst index deb688e267..0495ed2962 100644 --- a/doc/sphinx/installation/platformnotes.rst +++ b/doc/sphinx/installation/platformnotes.rst @@ -8,15 +8,15 @@ Platform specific notes ------------------------ On some platforms it is necessary to adjust the operating system before running -Varnish on it. The systems and steps known to us are described in this section. +Vinyl Cache on it. The systems and steps known to us are described in this section. On Linux, use tmpfs for the workdir ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Varnish uses mapped files for shared memory, for which performance depends on +Vinyl Cache uses mapped files for shared memory, for which performance depends on writes not blocking. On Linux, however, write throttling implemented by some file systems (which is generally useful in other scenarios) can interact badly -with the way Varnish works and cause lockups or performance impacts. To avoid +with the way Vinyl Cache works and cause lockups or performance impacts. To avoid such problems, it is recommended to use a ``tmpfs`` "virtual memory file system" as the *workdir*. @@ -42,18 +42,18 @@ know what you are doing. workdir can not be mounted ``noexec`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Varnish compiles VCL to a shared object and needs to load it at runtime. So the +Vinyl Cache compiles VCL to a shared object and needs to load it at runtime. So the *workdir* can not reside on a file system mounted with ``noexec``. Lift locked memory limits ~~~~~~~~~~~~~~~~~~~~~~~~~ -For the same reason as explained above, varnish tries to lock shared memory in +For the same reason as explained above, Vinyl Cache tries to lock shared memory in RAM. Therefore, the locked memory limit should ideally be set to unlimited or sufficiently high to accommodate all mapped files. The specific minimum required value is dynamic, depending among other factors on the number of VCLs loaded and backends configured. As a rule of thumb, it should be a generous multiple of the -size of *workdir* when varnish is running. +size of *workdir* when Vinyl Cache is running. See :ref:`ref-vsm` for details. @@ -63,13 +63,13 @@ Transparent Hugepage on Linux ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On certain Linux distributions Transparent Hugepage (THP) kernel support is -enabled by default. This is known to cause instabilities of Varnish. +enabled by default. This is known to cause instabilities of Vinyl Cache. -By default, Varnish tries to disable the THP feature, but does not fail if it +By default, Vinyl Cache tries to disable the THP feature, but does not fail if it can't. The ``linux`` :ref:`ref-vinyld-opt_j` offers to optionally enable, disable or ignore THP. -Alternatively, THP can be disabled system-wide. If Varnish is the only +Alternatively, THP can be disabled system-wide. If Vinyl Cache is the only significant service running on this system, this can be done during runtime with:: @@ -82,24 +82,24 @@ OpenVZ ~~~~~~ It is possible, but not recommended for high performance, to run -Varnish on virtualised hardware. Reduced disk and network -performance +Vinyl Cache on virtualised hardware. Reduced disk and network -performance will reduce the performance a bit so make sure your system has good IO performance. If you are running on 64bit OpenVZ (or Parallels VPS), you must reduce -the maximum stack size before starting Varnish. +the maximum stack size before starting Vinyl Cache. -The default allocates too much memory per thread, which will make Varnish fail +The default allocates too much memory per thread, which will make Vinyl Cache fail as soon as the number of threads (traffic) increases. Reduce the maximum stack size by adding ``ulimit -s 256`` before starting -Varnish in the init script. +Vinyl Cache in the init script. TCP keep-alive configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -On some Solaris, FreeBSD and OS X systems, Varnish is not able to set the TCP -keep-alive values per socket, and therefore the *tcp_keepalive_* Varnish runtime +On some Solaris, FreeBSD and OS X systems, Vinyl Cache is not able to set the TCP +keep-alive values per socket, and therefore the *tcp_keepalive_* Vinyl Cache runtime parameters are not available. On these platforms it can be beneficial to tune the system wide values for these in order to more reliably detect remote close for sessions spending long time on waitinglists. This will help free up @@ -118,7 +118,7 @@ to: - `tcp_keepalive_probes` = 5 - `tcp_keepalive_intvl` = 5 seconds -Note that Varnish will only apply these run-time parameters so long as +Note that Vinyl Cache will only apply these run-time parameters so long as they are less than the system default value. .. XXX:Maybe a sample-command of using/setting/changing these values? benc diff --git a/doc/sphinx/installation/prerequisites.rst b/doc/sphinx/installation/prerequisites.rst index ed3e4768b6..138aa59342 100644 --- a/doc/sphinx/installation/prerequisites.rst +++ b/doc/sphinx/installation/prerequisites.rst @@ -6,7 +6,7 @@ Prerequisites ============= -In order for you to install Varnish you must have the following: +In order for you to install Vinyl Cache you must have the following: * A recent, preferably server grade, computer. * A fairly modern and 64 bit version of either @@ -16,7 +16,7 @@ In order for you to install Varnish you must have the following: * Root access. -Varnish can be installed on other UNIX systems as well, but it is not extensively or systematically tested by us on other systems than the above. Varnish is, from time to +Vinyl Cache can be installed on other UNIX systems as well, but it is not extensively or systematically tested by us on other systems than the above. Vinyl Cache is, from time to time, said to work on: * 32 bit versions of the before-mentioned systems, diff --git a/doc/sphinx/phk/apispaces.rst b/doc/sphinx/phk/apispaces.rst index 63c8c39acb..bf102d6c69 100644 --- a/doc/sphinx/phk/apispaces.rst +++ b/doc/sphinx/phk/apispaces.rst @@ -26,7 +26,7 @@ One of the big attractions of Object Oriented programming is that it solves exactly that problem: Nobody is confused about ``car->push()`` and ``stack->push()``. -But Varnish is written in C which has a flat namespace and we must +But Vinyl Cache is written in C which has a flat namespace and we must live with it. From the very start, we defined cadastral boundaries in the flat @@ -86,14 +86,14 @@ detail below. A VMOD which restricts itself to the ``VRT`` API/ABI gets maximum stability and will, we hope, work without recompilation across -many major and minor releases of Varnish. +many major and minor releases of Vinyl Cache. A VMOD which uses the ``PACKAGE`` API, will likely keep working -across minor releases of varnish releases, but will usually -need to be recompiled for new major releases of varnish. +across minor releases of vinyl Cache releases, but will usually +need to be recompiled for new major releases of vinyl Cache. A VMOD which uses the ``SOURCE`` API is compiled against one -specific version of Varnish, and will not work with another +specific version of Vinyl Cache, and will not work with another version until recompiled. The VMOD VRT API/ABI @@ -155,7 +155,7 @@ The VMOD SOURCE API/ABI This API space provides access to private parts of vinyld and its use is highly discouraged, unless you absolutely have to, -You can #include any file from the varnish source tree and use +You can #include any file from the vinyl Cache source tree and use anything you find in them - but don't come crying to us if it all ends in tears: No refunds at this window. diff --git a/doc/sphinx/phk/autocrap.rst b/doc/sphinx/phk/autocrap.rst index baaa3c7a3b..1faba0bcd6 100644 --- a/doc/sphinx/phk/autocrap.rst +++ b/doc/sphinx/phk/autocrap.rst @@ -61,13 +61,13 @@ and the autocrap tools have become part of the portability problem, rather than part of the solution. Amongst the silly activities of the autocrap generated configure script -in Varnish are: +in Vinyl Cache are: * Looks for ANSI-C header files (show me a system later than 1995 without them ?) * Existence and support for POSIX mandated symlinks, (which - are not used by Varnish btw.) + are not used by Vinyl Cache btw.) * Tests, 19 different ways, that the compiler is not a relic from SYS III days. (Find me just one SYS III running computer with diff --git a/doc/sphinx/phk/barriers.rst b/doc/sphinx/phk/barriers.rst index 6ed051c96d..763ebb38d8 100644 --- a/doc/sphinx/phk/barriers.rst +++ b/doc/sphinx/phk/barriers.rst @@ -5,15 +5,15 @@ .. _phk_barriers: -============================ -Security barriers in Varnish -============================ +================================ +Security barriers in Vinyl Cache +================================ -Security is a very important design driver in Varnish, more likely than not, +Security is a very important design driver in Vinyl Cache, more likely than not, if you find yourself thinking "Why did he do _that_ ? the answer has to do with security. -The Varnish security model is based on some very crude but easy to understand +The Vinyl Cache security model is based on some very crude but easy to understand barriers between the various components: .. code-block:: text @@ -55,7 +55,7 @@ barriers between the various components: The really Important Barrier ============================ -The central actor in Varnish is the Manager process, "MGT", which is the +The central actor in Vinyl Cache is the Manager process, "MGT", which is the process the administrator "(ADMIN)" starts to get web-cache service. Having been there myself, I do not subscribe to the "I feel cool and important @@ -67,7 +67,7 @@ The task of the Manager process is therefore not cache web content, but to make sure there always is a process which does that, the Child "CLD" process. -That is the major barrier in Varnish: All management happens in +That is the major barrier in Vinyl Cache: All management happens in one process all actual movement of traffic happens in another, and the Manager process does not trust the Child process at all. @@ -75,7 +75,7 @@ The Child process is in a totally unprotected domain: Any computer on the InterNet "(ANON)" can connect to the Child process and ask for some web-object. -If John D. Criminal manages to exploit a security hole in Varnish, it is +If John D. Criminal manages to exploit a security hole in Vinyl Cache, it is the Child process he subverts. If he carries out a DoS attack, it is the Child process he tries to fell. @@ -91,14 +91,14 @@ these are well defended by the Manager process. The Admin/Oper Barrier ====================== -If you look at the top left corner of the diagram, you will see that Varnish +If you look at the top left corner of the diagram, you will see that Vinyl Cache operates with separate Administrator "(ADMIN)" and Operator "(OPER)" roles. The Administrator does things, changes stuff etc. The Operator keeps an eye on things to make sure they are as they should be. These days Operators are often scripts and data collection tools, and -there is no reason to assume they are bugfree, so Varnish does not +there is no reason to assume they are bugfree, so Vinyl Cache does not trust the Operator role, that is a pure one-way relationship. (Trick: If the Child process us run under user "nobody", you can @@ -110,7 +110,7 @@ restart it again with the same parameters and settings.) The Administrator has the final say, and of course, the administrator can decide under which circumstances that authority will be shared. -Needless to say, if the system on which Varnish runs is not properly +Needless to say, if the system on which Vinyl Cache runs is not properly secured, the Administrator's monopoly of control will be compromised. All the other barriers @@ -125,7 +125,7 @@ For instance the VCC compiler runs in a separate child process, to make sure that a memory leak or other flaw in the compiler does not accumulate trouble for the Manager process. -Hope this explanation helps understand why Varnish is not just a single +Hope this explanation helps understand why Vinyl Cache is not just a single process like all other server programs. Poul-Henning, 2010-06-28 diff --git a/doc/sphinx/phk/brinch-hansens-arrows.rst b/doc/sphinx/phk/brinch-hansens-arrows.rst index 8a79458d19..73099f9f8a 100644 --- a/doc/sphinx/phk/brinch-hansens-arrows.rst +++ b/doc/sphinx/phk/brinch-hansens-arrows.rst @@ -40,21 +40,21 @@ to come natural to me to think about locking order, but not everybody feels that way about them, and WITNESS have caught a lot of "Ohh, didn't think about *that*" situations over the years. -It is no accident that Varnish has a very simple locking structure, -but as we add more and more flexibility and extensibility to Varnish +It is no accident that Vinyl Cache has a very simple locking structure, +but as we add more and more flexibility and extensibility to Vinyl Cache it grows a little here and there, and I managed to introduce a lock-order reversal the other day - my first in about five years I think. Since I'm obviously getting old and slipping up here, I though it -was about time I carried out the Brinch-Hansen check on Varnish. +was about time I carried out the Brinch-Hansen check on Vinyl Cache. -I briefly pondered porting WITNESS into Varnish, but it's 3k lines +I briefly pondered porting WITNESS into Vinyl Cache, but it's 3k lines and we have extremely good code coverage in our regression tests so I decided to KISS and do it as post-processing. I have added default-off debug code to emit VSL "Witness" records, -taught varnishtest how to enable that code, and added a small python +taught vinyl Cachetest how to enable that code, and added a small python script to process the records into a nice plot: .. image:: brinch_hansens_arrows_1.svg diff --git a/doc/sphinx/phk/gzip.rst b/doc/sphinx/phk/gzip.rst index e8d997cf01..7959ee04dc 100644 --- a/doc/sphinx/phk/gzip.rst +++ b/doc/sphinx/phk/gzip.rst @@ -5,16 +5,16 @@ .. _phk_gzip: -======================================= -How GZIP, and GZIP+ESI works in Varnish -======================================= +=========================================== +How GZIP, and GZIP+ESI works in Vinyl Cache +=========================================== First of all, everything you read about GZIP here, is controlled by the parameter: http_gzip_support -Which defaults to "on" if you do not want Varnish to try to be smart +Which defaults to "on" if you do not want Vinyl Cache to try to be smart about compression, set it to "off" instead. What does http_gzip_support do @@ -39,12 +39,12 @@ header removed. This ensures conformity with respect to creating Vary: strings during object creation. During lookup, we ignore any "Accept-encoding" in objects Vary: strings, -to avoid having a gzip and gunzip'ed version of the object, varnish +to avoid having a gzip and gunzip'ed version of the object, vinyl Cache can gunzip on demand. (We implement this bit of magic at lookup time, so that any objects stored in persistent storage can be used with or without gzip support enabled.) -Varnish will not do any other types of compressions than gzip, in particular +Vinyl Cache will not do any other types of compressions than gzip, in particular we will not do deflate, as there are browser bugs in that case. Before vcl_miss{} is called, the backend requests Accept-Encoding is @@ -56,7 +56,7 @@ Even if this particular client does not support To always entice the backend into sending us gzipped content. -Varnish will not gzip any content on its own (but see below), we trust +Vinyl Cache will not gzip any content on its own (but see below), we trust the backend to know what content can be sensibly gzipped (html) and what cannot (jpeg) @@ -74,7 +74,7 @@ In vcl_pass{} the client's Accept-Encoding header is copied to the backend request unchanged. Even if the client does not support gzip, you can force the A-E header to "gzip" on bereq.http in vcl_backend_fetch{} to save bandwidth between -the backend and varnish. Varnish will gunzip the object before delivering +the backend and vinyl Cache. Vinyl Cache will gunzip the object before delivering to the client. In vcl_miss{} you can remove the "Accept-Encoding: gzip" header, if you @@ -85,12 +85,12 @@ gzip-ness of objects during fetch: set beresp.do_gunzip = true; -Will make varnish gunzip an already gzipped object from the backend during +Will make vinyl Cache gunzip an already gzipped object from the backend during fetch. (I have no idea why/when you would use this...) set beresp.do_gzip = true; -Will make varnish gzip the object during fetch from the backend, provided +Will make vinyl Cache gzip the object during fetch from the backend, provided the backend didn't send us a gzipped object. Remember that a lot of content types cannot sensibly be gzipped, most @@ -125,7 +125,7 @@ Things can get really hairy here, so let me explain it in stages. Assume we have a ungzipped object we want to ESI process. The ESI parser will run through the object looking for the various -magic strings and produce a byte-stream we call the "VEC" for Varnish +magic strings and produce a byte-stream we call the "VEC" for Vinyl Cache ESI Codes. The VEC contains instructions like "skip 234 bytes", "deliver 12919 bytes", @@ -168,8 +168,8 @@ compression efficiency, you should:: } } -So that the backend sends these objects uncompressed to varnish. +So that the backend sends these objects uncompressed to vinyl Cache. You should also attempt to make sure that all objects which are esi:included are gzipped, either by making the backend do it or -by making varnish do it. +by making vinyl Cache do it. diff --git a/doc/sphinx/phk/ip_address.rst b/doc/sphinx/phk/ip_address.rst index 06c117c4fb..ecced94e17 100644 --- a/doc/sphinx/phk/ip_address.rst +++ b/doc/sphinx/phk/ip_address.rst @@ -63,7 +63,7 @@ I believe there were also some lilliputian dispute about the fact that `192.168.61` would return `192.168.0.61` to stay backwards compatible, whereas `192.168.61/23` would return `192.168.61.0 + 255.255.254.0`. -Because of this, Varnish uses `getaddrinfo(3)` everywhere but one single +Because of this, Vinyl Cache uses `getaddrinfo(3)` everywhere but one single place: Parsing of ACL specifications in VCL. First we have to use our own parser to check if it is a CIDR entry and if not we ask `getaddrinfo(3)`. @@ -73,10 +73,10 @@ The reason for this rant, is that somebody noticed that `ping That has just become CVE-2021-29418 and CVE-2021-28918 and will probably become a dozen more, once the CVE-trophy-hunters go to town. -All IP number strings enter Varnish from trusted points, either +All IP number strings enter Vinyl Cache from trusted points, either as command line arguments (`-a`, `-b`, `-M` etc.), in the VCL source (`backend`, `acl` etc.) or as PROXYv1 header -strings from the TLS-stripper in front of Varnish. +strings from the TLS-stripper in front of Vinyl Cache. Of course, VCL allows you to do pretty much anything, including:: @@ -89,12 +89,12 @@ of trusting IP#'s from strangers and b) Think about this "critical netmask problem". Otherwise, I do not expect this new "critical netmask problem" to -result in any source code changes in Varnish. +result in any source code changes in Vinyl Cache. If and when the various UNIX-oid operating systems, and the smoking remains of the "serious UNIX industry", (IEEE ? The Austin Group ? The Open Group ? Whatever they are called these days) get their -act together, and renovate the `getaddrinfo(3)` API, Varnish will +act together, and renovate the `getaddrinfo(3)` API, Vinyl Cache will automatically pick that up and use it. Should they, in a flash of enlightenment, also make `getaddrinfo(3)` diff --git a/doc/sphinx/phk/ipv6suckage.rst b/doc/sphinx/phk/ipv6suckage.rst index d4dd18bf11..1b9eceab7d 100644 --- a/doc/sphinx/phk/ipv6suckage.rst +++ b/doc/sphinx/phk/ipv6suckage.rst @@ -73,7 +73,7 @@ or: Careless standardization costs code, have I mentioned this before ? -Varnish reports socket addresses as two fields: IP space PORT, +Vinyl Cache reports socket addresses as two fields: IP space PORT, now you know why. Until next time, diff --git a/doc/sphinx/phk/platforms.rst b/doc/sphinx/phk/platforms.rst index d32ffe8003..4c0385173e 100644 --- a/doc/sphinx/phk/platforms.rst +++ b/doc/sphinx/phk/platforms.rst @@ -23,11 +23,11 @@ For instance, did you know that: is legal in a ISO-C compliant environment ? -Varnish `runs on a Nokia N900 `_ +Varnish Cache once ran on a Nokia N900, but I am not going to go out of my way to make sure that is always the case. -To make sense for Varnish, a platform has to be able to deliver, +To make sense for Vinyl Cache, a platform has to be able to deliver, both in terms of performance, but also in terms of the APIs we use to get that performance. @@ -35,13 +35,13 @@ In the FreeBSD project where I grew up, we ended up instituting platform-tiers, in an effort to document which platforms we cared about and which we did love quite as much. -If we did the same for Varnish, the result would look something like: +If we did the same for Vinyl Cache, the result would look something like: A - Platforms we care about --------------------------- We care about these platforms because our users use them and -because they deliver a lot of bang for the buck with Varnish. +because they deliver a lot of bang for the buck with Vinyl Cache. These platforms are in our "tinderbox" tests, we use them ourselves and they pass all regression tests all the time. @@ -51,9 +51,9 @@ Platform specific bug reports gets acted on. *Linux* -Obviously you can forget about running Varnish on your +Obviously you can forget about running Vinyl Cache on your `WRT54G `_ -but if you have a real computer, you can expect Varnish to work +but if you have a real computer, you can expect Vinyl Cache to work "ok or better" on any distro that has a package available. B - Platforms we try not to break @@ -83,7 +83,7 @@ C - Platforms we tolerate ------------------------- We tolerate any other platform, as long as the burden of doing -so is proportional to the benefit to the Varnish community. +so is proportional to the benefit to the Vinyl Cache community. Do not file bug reports specific to these platforms without attaching a patch that solves the problem, we will just close it. @@ -94,7 +94,7 @@ I'm afraid I have to put OpenBSD here for now, it is seriously behind on socket APIs and working around those issues is just not worth the effort. -If people send us a small non-intrusive patches that makes Varnish +If people send us a small non-intrusive patches that makes Vinyl Cache run on these platforms, we'll take it. If they send us patches that reorganizes everything, hurts code @@ -104,7 +104,7 @@ they get told that thanks, but no thanks. Is that it ? Abandon all hope etc. ? ------------------------------------- -These tiers are not static, if for some reason Varnish suddenly +These tiers are not static, if for some reason Vinyl Cache suddenly becomes a mandatory accessory to some technically sensible platform, (zOS anyone ?) that platform will get upgraded. If the pessimists are right about Oracles intentions, Solaris may get demoted. diff --git a/doc/sphinx/phk/quic.rst b/doc/sphinx/phk/quic.rst index 464257030e..9771d43aac 100644 --- a/doc/sphinx/phk/quic.rst +++ b/doc/sphinx/phk/quic.rst @@ -108,8 +108,8 @@ can point at the "job creation" their data-centers provide. The rest of us will have to wait and see where that leaves us. -QUIC and Varnish ----------------- +QUIC and Vinyl Cache +-------------------- I can say with certainty that writing a QUIC implementation from scratch, including TLS 1.3 is out of the question, that @@ -121,9 +121,9 @@ That leaves basically three options: 2) Pick up a QUIC library and the TLS library it uses. -3) Stick with "That belongs in a separate process in front of Varnish." +3) Stick with "That belongs in a separate process in front of Vinyl Cache." -The precondition for linking an TLS library to Varnishd, is that +The precondition for linking an TLS library to Vinyl Cache, is that the private keys/certificates are still isolated in a different address space, these days known as "KeyLess TLS". @@ -133,7 +133,7 @@ QUIC implementations do it, at least not yet. The actual selection of QUIC implementations we could adopt is very short, and since I am not very inclined to make Go or Rust a -dependency for Varnish, it rapidly becomes even shorter. +dependency for Vinyl Cache, it rapidly becomes even shorter. Presently, The H2O projects `quicly `_ would probably be the most obvious candidate for us, but even that @@ -151,7 +151,7 @@ boxes using a richer PROXY protocol or maybe a "naked" QUIC, to maintain functionality. One argument for staying out of the fray is that our "No TLS in -Varnish" policy looks like it was the right decision. +Vinyl Cache" policy looks like it was the right decision. While it is inconvenient for small sites to have to run two processes, as soon as sites grow, the feedback changes to @@ -159,11 +159,11 @@ appreciation for the decoupling for TLS from policy/caching, and once sites get even bigger, or more GDPR exposed, the ability to use diverse TLS offloaders is seen as a big benefit. -Finally, there is the little detail of testing: Varnishtest, -which has its own `VTest project `_ +Finally, there is the little detail of testing: vinylcache, +which has its own `VTest project `_ now, will need to learn about HTTP3, QUIC and possibly TLS also. -And of course, when we ask the Varnish users, they say *"Ohhh... +And of course, when we ask the Vinyl Cache users, they say *"Ohhh... they all sound delicious, can we have the buffet ?"* :-) *phk* diff --git a/doc/sphinx/phk/sphinx.rst b/doc/sphinx/phk/sphinx.rst index 68e6b19de9..d87fbcab7a 100644 --- a/doc/sphinx/phk/sphinx.rst +++ b/doc/sphinx/phk/sphinx.rst @@ -10,7 +10,7 @@ Why Sphinx_ and reStructuredText_ ? =================================== The first school of thought on documentation, is the one we subscribe -to in Varnish right now: "Documentation schmocumentation..." It does +to in Vinyl Cache right now: "Documentation schmocumentation..." It does not work for anybody. The second school is the "Write a {La}TeX document" school, where @@ -62,7 +62,7 @@ In other words: we are talking about the ReStructuredText_ of the Python project, as wrapped by the Sphinx_ project. Unless there is something I have totally failed to spot, that is -going to be the new documentation platform in Varnish. +going to be the new documentation platform in Vinyl Cache. Take a peek at the Python docs, and try pressing the "show source" link at the bottom of the left menu: diff --git a/doc/sphinx/phk/thetoolsweworkwith.rst b/doc/sphinx/phk/thetoolsweworkwith.rst index c8b9cc7823..07434c36b1 100644 --- a/doc/sphinx/phk/thetoolsweworkwith.rst +++ b/doc/sphinx/phk/thetoolsweworkwith.rst @@ -22,7 +22,7 @@ is the tools that makes the difference between using concrete as a filler material between stones, and as gravity-defying curved but perfectly safe load-bearing wall. -My tool for writing Varnish is the C-language which in many ways +My tool for writing Vinyl Cache is the C-language which in many ways is unique amongst all of the computer programming languages for having no ambitions. @@ -111,7 +111,7 @@ holding this mutex locked" facility. I will posit that you cannot successfully develop real-world threaded programs and APIs without that, or without wasting a lot of time debugging silly mistakes. -If you look in the Varnish source code, which uses pthreads, you +If you look in the Vinyl Cache source code, which uses pthreads, you will see that I have wrapped pthread mutexes in my own little data structure, to be able to do those asserts, and to get some usable statistics on lock-contention. diff --git a/doc/sphinx/reference/cli_protocol.rst b/doc/sphinx/reference/cli_protocol.rst index 89c1aae6f8..e91b2cad58 100644 --- a/doc/sphinx/reference/cli_protocol.rst +++ b/doc/sphinx/reference/cli_protocol.rst @@ -11,7 +11,7 @@ VCLI protocol - Scripting the CLI interface =========================================== -The Varnish CLI has a few bells&whistles when used as an API. +The Vinyl Cache CLI has a few bells&whistles when used as an API. First: `vcli.h` contains magic numbers. @@ -29,7 +29,7 @@ of bytes in the "body" of the response:: This makes parsing the response unambiguous, even in cases like this where the response does not end with a NL. -The varnishapi library contains functions to implement the basics of +The vinylapi library contains functions to implement the basics of the CLI protocol, for more, see the `vcli.h` include file. .. _ref_remote_cli: @@ -159,7 +159,7 @@ In the above example, the secret file contains ``foo\n`` and thus: critter phk> openssl dgst -sha256 < tmpfile 455ce847f0073c7ab3b1465f74507b75d3dc064c1e7de3b71e00de9092fdc89a -The sourcefile `lib/libvarnish/cli_auth.c` contains a useful function +The sourcefile ``lib/libvinyl/vcli_proto.c`` contains a useful function which calculates the response, given an open filedescriptor to the secret file, and the challenge string. diff --git a/doc/sphinx/reference/vcl_step.rst b/doc/sphinx/reference/vcl_step.rst index 40d79eb7bc..70be3cbaa4 100644 --- a/doc/sphinx/reference/vcl_step.rst +++ b/doc/sphinx/reference/vcl_step.rst @@ -67,7 +67,7 @@ vcl_pipe Called upon entering pipe mode. In this mode, the request is passed on to the backend, and any further data from both the client and backend is passed on unaltered until either end closes the -connection. Basically, Varnish will degrade into a simple TCP proxy, +connection. Basically, Vinyl Cache will degrade into a simple TCP proxy, shuffling bytes back and forth. For a connection in pipe mode, no other VCL subroutine will ever get called after `vcl_pipe`. @@ -116,7 +116,7 @@ vcl_hash ~~~~~~~~ Called after `vcl_recv` to create a hash value for the request. This is -used as a key to look up the object in Varnish. +used as a key to look up the object in Vinyl Cache. The `vcl_hash` subroutine may terminate with calling ``return()`` with one of the following keywords: @@ -303,7 +303,7 @@ The `vcl_backend_fetch` subroutine may terminate with calling .. could add return(retry) if there was a(nother) use case, see also https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4342 -Before calling `vcl_backend_fetch`, Varnish core prepares the `bereq` +Before calling `vcl_backend_fetch`, Vinyl Cache core prepares the `bereq` backend request as follows: * Unless the request is a `pass`, diff --git a/doc/sphinx/reference/vext.rst b/doc/sphinx/reference/vext.rst index 1b324b45e4..058c714b38 100644 --- a/doc/sphinx/reference/vext.rst +++ b/doc/sphinx/reference/vext.rst @@ -5,11 +5,11 @@ .. _ref-vext: -%%%%%%%%%%%%%%%%%%%%%%%%% -VEXT - Varnish Extensions -%%%%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +VEXT - Vinyl Cache Extensions +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -A Varnish Extension is a shared library, loaded into the worker +A Vinyl Cache Extension is a shared library, loaded into the worker process during startup, before privileges are dropped for good. This allows a VEXT to do pretty much anything it wants to do in the worker process. diff --git a/doc/sphinx/users-guide/compression.rst b/doc/sphinx/users-guide/compression.rst index bdf80aff5e..fc60bd6537 100644 --- a/doc/sphinx/users-guide/compression.rst +++ b/doc/sphinx/users-guide/compression.rst @@ -14,7 +14,7 @@ encoding. *Before* 3.0, Varnish would never compress objects. In Varnish 4.0 compression defaults to "on", meaning that it tries to be smart and do the sensible thing. -If you don't want Varnish tampering with the encoding you can disable +If you don't want Vinyl Cache tampering with the encoding you can disable compression all together by setting the parameter `http_gzip_support` to false. Please see man :ref:`vinyld(1)` for details. @@ -25,12 +25,12 @@ The default behaviour is active when the `http_gzip_support` parameter is set to "on" and neither `beresp.do_gzip` nor `beresp.do_gunzip` are used in VCL. -Unless returning from `vcl_recv` with `pipe` or `pass`, Varnish +Unless returning from `vcl_recv` with `pipe` or `pass`, Vinyl Cache modifies `req.http.Accept-Encoding`: if the client supports gzip `req.http.Accept-Encoding` is set to "gzip", otherwise the header is removed. -Unless the request is a `pass`, Varnish sets `bereq.http.Accept-Encoding` +Unless the request is a `pass`, Vinyl Cache sets `bereq.http.Accept-Encoding` to "gzip" before `vcl_backend_fetch` runs, so the header can be changed in VCL. @@ -49,7 +49,7 @@ For Vary Lookups, `Accept-Encoding` is ignored. Compressing content if backends don't ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -You can tell Varnish to compress content before storing it in cache in +You can tell Vinyl Cache to compress content before storing it in cache in `vcl_backend_response` by setting `beresp.do_gzip` to "true", like this:: sub vcl_backend_response { @@ -58,7 +58,7 @@ You can tell Varnish to compress content before storing it in cache in } } -With `beresp.do_gzip` set to "true", Varnish will make the following +With `beresp.do_gzip` set to "true", Vinyl Cache will make the following changes to the headers of the resulting object before inserting it in the cache: @@ -66,8 +66,8 @@ the cache: * add "Accept-Encoding" to `obj.http.Vary`, unless already present * weaken any `Etag` (by prepending "W/") -Generally, Varnish doesn't use much CPU so it might make more sense to -have Varnish spend CPU cycles compressing content than doing it in your +Generally, Vinyl Cache doesn't use much CPU so it might make more sense to +have Vinyl Cache spend CPU cycles compressing content than doing it in your web- or application servers, which are more likely to be CPU-bound. Please make sure that you don't try to compress content that is @@ -82,7 +82,7 @@ around badly configured backends uselessly compressing already compressed content like JPG images (but fixing the misbehaving backend is always the better option). -With `beresp.do_gunzip` set to "true", Varnish will make the following +With `beresp.do_gunzip` set to "true", Vinyl Cache will make the following changes to the headers of the resulting object before inserting it in the cache: @@ -95,14 +95,14 @@ GZIP and ESI ~~~~~~~~~~~~ If you are using Edge Side Includes (ESI) you'll be happy to note that -ESI and GZIP work together really well. Varnish will magically decompress +ESI and GZIP work together really well. Vinyl Cache will magically decompress the content to do the ESI-processing, then recompress it for efficient storage and delivery. Turning off gzip support ~~~~~~~~~~~~~~~~~~~~~~~~ -When the `http_gzip_support` parameter is set to "off", Varnish does +When the `http_gzip_support` parameter is set to "off", Vinyl Cache does not do any of the header alterations documented above, handles `Vary: Accept-Encoding` like it would for any other `Vary` value and ignores `beresp.do_gzip` and `beresp.do_gunzip`. diff --git a/doc/sphinx/users-guide/devicedetection.rst b/doc/sphinx/users-guide/devicedetection.rst index e3fdc0e110..492059a00b 100644 --- a/doc/sphinx/users-guide/devicedetection.rst +++ b/doc/sphinx/users-guide/devicedetection.rst @@ -47,7 +47,7 @@ it). includes for example setting a header, changing a header or even changing the backend request URL. 3. Modify any response from the backend to add missing 'Vary' headers, so -Varnish' internal handling of this kicks in. +Vinyl Cache' internal handling of this kicks in. 4. Modify output sent to the client so any caches outside our control don't serve the wrong content. @@ -58,11 +58,11 @@ device class. Example 1: Send HTTP header to backend '''''''''''''''''''''''''''''''''''''' -The basic case is that Varnish adds the 'X-UA-Device' HTTP header on the backend +The basic case is that Vinyl Cache adds the 'X-UA-Device' HTTP header on the backend requests, and the backend mentions in the response 'Vary' header that the content is dependent on this header. -Everything works out of the box from Varnish' perspective. +Everything works out of the box from Vinyl Cache' perspective. .. 071-example1-start @@ -71,10 +71,10 @@ VCL:: sub vcl_recv { # call some detection engine that set req.http.X-UA-Device } - # req.http.X-UA-Device is copied by Varnish into bereq.http.X-UA-Device + # req.http.X-UA-Device is copied by Vinyl Cache into bereq.http.X-UA-Device # so, this is a bit counterintuitive. The backend creates content based on - # the normalized User-Agent, but we use Vary on X-UA-Device so Varnish will + # the normalized User-Agent, but we use Vary on X-UA-Device so Vinyl Cache will # use the same cached object for all U-As that map to the same X-UA-Device. # # If the backend does not mention in Vary that it has crafted special diff --git a/doc/sphinx/users-guide/esi.rst b/doc/sphinx/users-guide/esi.rst index 25be4e18af..0d608d3d7b 100644 --- a/doc/sphinx/users-guide/esi.rst +++ b/doc/sphinx/users-guide/esi.rst @@ -8,7 +8,7 @@ Content composition with Edge Side Includes ------------------------------------------- -Varnish can create web pages by assembling different pages, called `fragments`, +Vinyl Cache can create web pages by assembling different pages, called `fragments`, together into one page. These `fragments` can have individual cache policies. If you have a web site with a list showing the five most popular articles on your site, this list can probably be cached as a `fragment` and included @@ -19,7 +19,7 @@ in all the other pages. Used properly this strategy can dramatically increase your hit rate and reduce the load on your servers. -In Varnish we've only implemented a small subset of ESI, because most of +In Vinyl Cache we've only implemented a small subset of ESI, because most of the rest of the ESI specifications facilities are easier and better done with VCL:: @@ -29,7 +29,7 @@ with VCL:: Content substitution based on variables and cookies is not implemented. -Varnish will not process ESI instructions in HTML comments. +Vinyl Cache will not process ESI instructions in HTML comments. Example: esi:include ~~~~~~~~~~~~~~~~~~~~ @@ -109,13 +109,13 @@ the ESI fragment with an ``onerror`` attribute:: -This attribute is ignored by default. In fact, Varnish will treat +This attribute is ignored by default. In fact, Vinyl Cache will treat failures to deliver ESI fragments as if there was the attribute ``onerror="continue"``. In the absence of this attribute with this -specific value, Varnish should normally abort the delivery of the +specific value, Vinyl Cache should normally abort the delivery of the parent request. -We say "abort" rather than "fail", because by the time Varnish +We say "abort" rather than "fail", because by the time Vinyl Cache starts inserting the fragments, the HTTP response header has long since been sent, and it is no longer possible to change the parent requests's ``resp.status`` to a 5xx, so the only way to signal that @@ -142,8 +142,8 @@ parameter in order to prevent infinite recursion. Doing ESI on JSON and other non-XML'ish content ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Varnish will peek at the first byte of an object and if it is not -a "<" Varnish assumes you didn't really mean to ESI process it. +Vinyl Cache will peek at the first byte of an object and if it is not +a "<" Vinyl Cache assumes you didn't really mean to ESI process it. You can disable this check by:: param.set feature +esi_disable_xml_check @@ -169,15 +169,15 @@ ESI includes with HTTPS protocol ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If ESI:include tags specify HTTPS protocol, it will be ignored -by default, because Varnish has no way to fetch it with encryption. -If you want Varnish to fetch them like it does anything else, set:: +by default, because Vinyl Cache has no way to fetch it with encryption. +If you want Vinyl Cache to fetch them like it does anything else, set:: param.set feature +esi_ignore_https ESI on partial responses (206) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Varnish supports range requests, but in general partial responses +Vinyl Cache supports range requests, but in general partial responses make no sense in an ESI context. If you really know what you are doing, change the 206 to a 200:: @@ -200,12 +200,12 @@ in the one it switched to. ESI and gzip compression ~~~~~~~~~~~~~~~~~~~~~~~~ -Varnish's ESI implementation handles gzip compression automatically, +Vinyl Cache's ESI implementation handles gzip compression automatically, no matter how it is mixed: The parent request can be compressed or uncompressed and the fragments can be compressed or uncompressed, it all works out. -Varnish does this compressing all parts of ESI responses +Vinyl Cache does this compressing all parts of ESI responses separately, and stitching them together on the fly during delivery, which has a negative impact on compression ratio. diff --git a/doc/sphinx/users-guide/index.rst b/doc/sphinx/users-guide/index.rst index c399a5dd31..6b54b749bf 100644 --- a/doc/sphinx/users-guide/index.rst +++ b/doc/sphinx/users-guide/index.rst @@ -5,36 +5,36 @@ .. _users-guide-index: -The Varnish Users Guide -======================= +The Vinyl Cache Users Guide +=========================== -The Varnish documentation consists of three main documents: +The Vinyl Cache documentation consists of three main documents: -* :ref:`tutorial-index` explains the basics and gets you started with Varnish. +* :ref:`tutorial-index` explains the basics and gets you started with Vinyl Cache. -* :ref:`users-guide-index` (this document), explains how Varnish works +* :ref:`users-guide-index` (this document), explains how Vinyl Cache works and how you can use it to improve your website. * :ref:`reference-index` contains hard facts and is useful for looking up specific questions. After :ref:`users_intro`, this Users Guide is organized in sections -following the major interfaces to Varnish as a service: +following the major interfaces to Vinyl Cache as a service: -:ref:`users_running` is about getting Varnish configured, with +:ref:`users_running` is about getting Vinyl Cache configured, with respect to storage, sockets, security and how you can control and -communicate with Varnish once it is running. +communicate with Vinyl Cache once it is running. -:ref:`users_vcl` is about getting Varnish to handle the +:ref:`users_vcl` is about getting Vinyl Cache to handle the HTTP requests the way you want, what to cache, how to cache it, modifying HTTP headers etc. etc. -:ref:`users_report` explains how you can monitor what Varnish does, +:ref:`users_report` explains how you can monitor what Vinyl Cache does, from a transactional level to aggregating statistics. -:ref:`users_performance` is about tuning your website with Varnish. +:ref:`users_performance` is about tuning your website with Vinyl Cache. -:ref:`users_trouble` is for locating and fixing common issues with Varnish. +:ref:`users_trouble` is for locating and fixing common issues with Vinyl Cache. .. toctree:: :maxdepth: 2 diff --git a/doc/sphinx/users-guide/intro.rst b/doc/sphinx/users-guide/intro.rst index f73fb22751..6b542f0ae7 100644 --- a/doc/sphinx/users-guide/intro.rst +++ b/doc/sphinx/users-guide/intro.rst @@ -5,15 +5,14 @@ .. _users_intro: -The Big Varnish Picture -======================= +The Big Vinyl Cache Picture +=========================== In this section we will cover answers to the questions: -- What is in this package called "Varnish"? - what are all the different bits and pieces named? - Will you need a hex-wrench for assembly? -The two main parts of Varnish are the two processes in the `vinyld` +The two main parts of Vinyl Cache are the two processes in the `vinyld` program. The first process is called "the manager", and its job is to talk to you, the administrator, and make the things you ask for happen. @@ -34,21 +33,21 @@ permissions, as a defensive measure. The manager process is interactive, it offers a CLI -- Command Line Interface, which can be used manually, from scripts or programs. The -CLI offers almost full control of what Varnish actually does to your +CLI offers almost full control of what Vinyl Cache actually does to your HTTP traffic, and we have gone to great lengths to ensure that you -should not need to restart the Varnish processes, unless you need to +should not need to restart the Vinyl Cache processes, unless you need to change something very fundamental. The CLI can be safely accessed remotely, using a simple and flexible PSK -- Pre Shared Key, access control scheme, so it is easy to -integrate Varnish into your operations and management infrastructure +integrate Vinyl Cache into your operations and management infrastructure or tie it to your CMS. All this is covered in :ref:`users_running`. Things like, how the child process should deal with the HTTP requests, what to cache, which headers to remove etc, is all specified using a small -programming language called VCL -- Varnish Configuration Language. +programming language called VCL -- Vinyl Cache Configuration Language. The manager process will compile the VCL program and check it for errors, @@ -75,12 +74,12 @@ instantly, without restarting the child process and without missing a single HTTP request. VCL code can be extended using external modules, called VMODs or -even by inline C-code if you are brave, so in terms of what Varnish +even by inline C-code if you are brave, so in terms of what Vinyl Cache can do for your HTTP traffic, there really is no limit. :ref:`users_vcl` describes VCL and what it can do in great detail. -Varnish uses a segment of shared memory to report and log its activities and +Vinyl Cache uses a segment of shared memory to report and log its activities and status. For each HTTP request, a number of very detailed records will be appended to the log memory segment. Other processes can subscribe to log-records, filter them, and format them, for @@ -91,13 +90,13 @@ this allows real-time, down to microsecond resolution monitoring of cache hit-rate, resource usage and specific performance indicating metrics. -Varnish comes with a number of tools which reports from shared +Vinyl Cache comes with a number of tools which reports from shared memory, `vinyllog`, `vinylstats`, `vinylncsa` etc, and with an API library so you can write your own tools, should you need that. :ref:`users_report` explains how all that work. -Presumably the reason for your interest in Varnish, is that you +Presumably the reason for your interest in Vinyl Cache, is that you want your website to work better. There are many aspects of performance tuning a website, from relatively simple policy decisions about what to cache, to designing a geographically diverse multilevel @@ -106,7 +105,7 @@ CDNs using ESI and automatic failover. .. XXX:CDNs or CDN? benc :ref:`users_performance` will take you through the possibilities -and facilities Varnish offers. +and facilities Vinyl Cache offers. Finally, Murphys Law must be referenced here: Things will go wrong, and more likely than not, they will do so at zero-zero-dark O'clock. Most diff --git a/doc/sphinx/users-guide/operation-logging.rst b/doc/sphinx/users-guide/operation-logging.rst index 300620922b..58531e151b 100644 --- a/doc/sphinx/users-guide/operation-logging.rst +++ b/doc/sphinx/users-guide/operation-logging.rst @@ -5,12 +5,12 @@ .. _users-guide-logging: -Logging in Varnish ------------------- +Logging in Vinyl Cache +---------------------- -One of the really nice features in Varnish is the way logging -works. Instead of logging to a normal log file Varnish logs to a shared -memory segment, called the VSL - the Varnish Shared Log. When the end +One of the really nice features in Vinyl Cache is the way logging +works. Instead of logging to a normal log file Vinyl Cache logs to a shared +memory segment, called the VSL - the Vinyl Shared Log. When the end of the segment is reached we start over, overwriting old data. This is much, much faster than logging to a file and it doesn't @@ -20,12 +20,12 @@ when you need it. The flip side is that if you forget to have a program actually write the logs to disk they will be overwritten. -`vinyllog` is one of the programs you can use to look at what Varnish +`vinyllog` is one of the programs you can use to look at what Vinyl Cache is logging. `vinyllog` gives you the raw logs, everything that is written to the logs. There are other clients that can access the logs as well, we'll show you these later. -In the terminal window you started Varnish now type ``vinyllog -g raw`` +In the terminal window you started Vinyl Cache now type ``vinyllog -g raw`` and press enter. You'll see lines like these scrolling slowly by.:: @@ -33,7 +33,7 @@ You'll see lines like these scrolling slowly by.:: 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1273698726 1.0 -These is the Varnish master process checking up on the caching process +These is the Vinyl Cache master process checking up on the caching process to see that everything is OK. Now go to the browser and reload the page displaying your web app. @@ -65,7 +65,7 @@ Now, you can filter quite a bit with `vinyllog`. The basic options we think you want to know are: '-b' - Only show log lines from traffic going between Varnish and the backend + Only show log lines from traffic going between Vinyl Cache and the backend servers. This will be useful when we want to optimize cache hit rates. '-c' diff --git a/doc/sphinx/users-guide/operation-statistics.rst b/doc/sphinx/users-guide/operation-statistics.rst index d67543d408..42ff764e5e 100644 --- a/doc/sphinx/users-guide/operation-statistics.rst +++ b/doc/sphinx/users-guide/operation-statistics.rst @@ -9,7 +9,7 @@ Statistics ---------- -Varnish comes with a couple of nifty and very useful statistics generating tools that generates statistics in real time by constantly updating and presenting a specific dataset by aggregating and analyzing logdata from the shared memory logs. +Vinyl Cache comes with a couple of nifty and very useful statistics generating tools that generates statistics in real time by constantly updating and presenting a specific dataset by aggregating and analyzing logdata from the shared memory logs. .. XXX:Heavy rewrite above. benc @@ -41,12 +41,12 @@ pipe character ("|"), and misses are marked with a hash character ("#"). vinylstat ~~~~~~~~~ -Varnish has lots of counters. We count misses, hits, information about +Vinyl Cache has lots of counters. We count misses, hits, information about the storage, threads created, deleted objects. Just about everything. :ref:`vinylstat(1)` will dump these counters. This is useful when -tuning Varnish. +tuning Vinyl Cache. There are programs that can poll :ref:`vinylstat(1)` regularly and make nice graphs of these counters. One such program is Munin. Munin can be found at http://munin-monitoring.org/ . There is a plugin for -munin in the Varnish source code. +munin in the Vinyl Cache source code. diff --git a/doc/sphinx/users-guide/params.rst b/doc/sphinx/users-guide/params.rst index 6f9a13291e..0cb29ebde3 100644 --- a/doc/sphinx/users-guide/params.rst +++ b/doc/sphinx/users-guide/params.rst @@ -14,7 +14,7 @@ arguments to ``vinyld`` or at runtime through ``vinyladm`` using the ``param.set`` CLI command. We don't recommend that you tweak parameters unless you're sure of what -you're doing. We've worked hard to make the defaults sane and Varnish +you're doing. We've worked hard to make the defaults sane and Vinyl Cache should be able to handle most workloads with the default settings. For a complete listing of all parameters and their specifics see diff --git a/doc/sphinx/users-guide/performance.rst b/doc/sphinx/users-guide/performance.rst index 1b5ed440ad..bcab15712b 100644 --- a/doc/sphinx/users-guide/performance.rst +++ b/doc/sphinx/users-guide/performance.rst @@ -5,21 +5,21 @@ .. _users_performance: -Varnish and Website Performance -=============================== +Vinyl Cache and Website Performance +=================================== -This section focuses on how to tune the performance of your Varnish server, -and how to tune the performance of your website using Varnish. +This section focuses on how to tune the performance of your Vinyl Cache server, +and how to tune the performance of your website using Vinyl Cache. The section is split in three subsections. The first subsection deals with the -various tools and functions of Varnish that you should be aware of. The next +various tools and functions of Vinyl Cache that you should be aware of. The next subsection focuses on the how to purge content out of your cache. Purging of content is essential in a performance context because it allows you to extend the *time-to-live* (TTL) of your cached objects. Having a long TTL allows -Varnish to keep the content in cache longer, meaning Varnish will make fewer +Vinyl Cache to keep the content in cache longer, meaning Vinyl Cache will make fewer requests to your relatively slower backend. -The final subsection deals with compression of web content. Varnish can +The final subsection deals with compression of web content. Vinyl Cache can gzip content when fetching it from the backend and then deliver it compressed. This will reduce the time it takes to download the content thereby increasing the performance of your website. diff --git a/doc/sphinx/users-guide/purging.rst b/doc/sphinx/users-guide/purging.rst index 4820611a4c..fe9d287cf6 100644 --- a/doc/sphinx/users-guide/purging.rst +++ b/doc/sphinx/users-guide/purging.rst @@ -14,7 +14,7 @@ increase the time-to-live (ttl) of your objects. But, as you're aware of, in this twitterific day of age, serving content that is outdated is bad for business. -The solution is to notify Varnish when there is fresh content +The solution is to notify Vinyl Cache when there is fresh content available. This can be done through three mechanisms. HTTP purging, banning and forced cache misses. First, lets look at HTTP purging. @@ -29,7 +29,7 @@ through HTTP with the method `PURGE`. An HTTP purge is similar to an HTTP GET request, except that the *method* is `PURGE`. Actually you can call the method whatever you'd like, but most people refer to this as purging. Squid, for example, -supports the same mechanism. In order to support purging in Varnish +supports the same mechanism. In order to support purging in Vinyl Cache you need the following VCL in place:: acl purge { @@ -50,18 +50,18 @@ you need the following VCL in place:: As you can see we have used a new action - return(purge). This ends execution of vcl_recv and jumps to vcl_hash. This is just like we -handle a regular request. When vcl_hash calls return(lookup) Varnish +handle a regular request. When vcl_hash calls return(lookup) Vinyl Cache will purge the object and then call vcl_purge. Here you have the -option of adding any particular actions you want Varnish to take once +option of adding any particular actions you want Vinyl Cache to take once it has purge the object. So for example.com to invalidate their front page they would call out -to Varnish like this:: +to Vinyl Cache like this:: PURGE / HTTP/1.0 Host: example.com -And Varnish would then discard the front page. This will remove all +And Vinyl Cache would then discard the front page. This will remove all variants as defined by Vary. Bans @@ -74,7 +74,7 @@ content based on any metadata we have. A ban will only work on objects already in the cache, it does not prevent new content from entering the cache or being served. -Support for bans is built into Varnish and available in the CLI +Support for bans is built into Vinyl Cache and available in the CLI interface. To ban every png object belonging on example.com, issue the following command from the shell:: @@ -83,7 +83,7 @@ the following command from the shell:: See :ref:`std.ban()` for details on the syntax of ban expressions. In particular, note that in the example given above, the quotes are required for execution from the shell and escaping the backslash in -the regular expression is required by the Varnish cli interface. +the regular expression is required by the Vinyl Cache cli interface. Bans are checked when we hit an object in the cache, but before we deliver it. *An object is only checked against newer bans*. @@ -92,18 +92,14 @@ During lookup, object variants that may not satisfy the current request are also tested against the ban list, which means that a ban may also hit a non matching variant. -However, the parameter `ban_any_variant` can be used to limit the number -of possibly non matching variants that are checked against the ban list during +However, the parameter `ban_any_variant` can be used to limit the number of +possibly non matching variants that are checked against the ban list during lookup for a particular request. This means that at most `ban_any_variant` variants will be evaluated, and possibly evicted, before looking for matching -variants. A value of 0 means that every request would only evaluate bans -against matching variants. In contrast, a value that is too high may cause a -request to evaluate all variants against all active bans, which can add -significant delays for configurations having a large number of variants -and/or bans. - -In the next major release of varnish (8.0), the default value of -`ban_any_variant` will be set to 0. +variants. The default value of 0 means that every request would only evaluate +bans against matching variants. Any other value may cause a request to evaluate +all variants against all active bans. Very high values can add significant +delays for configurations having a large number of variants and/or bans. Bans that only match against `obj.*` are also processed by a background worker threads called the `ban lurker`. The `ban lurker` will walk the @@ -119,7 +115,7 @@ without evaluation. If you have a lot of objects with long TTL, that are seldom accessed, you might accumulate a lot of bans. This might impact CPU usage and thereby performance. -You can also add bans to Varnish via HTTP. Doing so requires a bit of VCL:: +You can also add bans to Vinyl Cache via HTTP. Doing so requires a bit of VCL:: import std; @@ -139,7 +135,7 @@ You can also add bans to Varnish via HTTP. Doing so requires a bit of VCL:: } } -This VCL stanza enables Varnish to handle a `HTTP BAN` method, adding a +This VCL stanza enables Vinyl Cache to handle a `HTTP BAN` method, adding a ban on the URL, including the host part. The `ban lurker` can help you keep the ban list at a manageable size, so @@ -195,7 +191,7 @@ Forcing a cache miss The final way to invalidate an object is a method that allows you to refresh an object by forcing a `hash miss` for a single request. If you set -'req.hash_always_miss' to true, Varnish will miss the current object in the +'req.hash_always_miss' to true, Vinyl Cache will miss the current object in the cache, thus forcing a fetch from the backend. This can in turn add the freshly fetched object to the cache, thus overriding the current one. The old object will stay in the cache until ttl expires or it is evicted by diff --git a/doc/sphinx/users-guide/report.rst b/doc/sphinx/users-guide/report.rst index 37239e2e61..436c7f0018 100644 --- a/doc/sphinx/users-guide/report.rst +++ b/doc/sphinx/users-guide/report.rst @@ -8,7 +8,7 @@ Reporting and statistics ======================== -This section covers how to find out what Varnish is doing, from +This section covers how to find out what Vinyl Cache is doing, from the detailed per HTTP request blow-by-blow logrecords to the global summary statistics counters. diff --git a/doc/sphinx/users-guide/run_cli.rst b/doc/sphinx/users-guide/run_cli.rst index afb83286eb..e7eb0a8f72 100644 --- a/doc/sphinx/users-guide/run_cli.rst +++ b/doc/sphinx/users-guide/run_cli.rst @@ -5,8 +5,8 @@ .. _run_cli: -CLI - bossing Varnish around -============================ +CLI - bossing Vinyl Cache around +================================ Once ``vinyld`` is started, you can control it using the ``vinyladm`` program and the command line interface:: @@ -112,14 +112,14 @@ it loaded, so it can be activated with :: Ban cache content ^^^^^^^^^^^^^^^^^ -Varnish offers "purges" to remove things from cache, but that +Vinyl Cache offers "purges" to remove things from cache, but that requires you to know exactly what they are. Sometimes it is useful to be able to throw things out of cache without having an exact list of what to throw out. Imagine for instance that the company logo changed and now you need -Varnish to stop serving the old logo out of the cache: +Vinyl Cache to stop serving the old logo out of the cache: .. code-block:: text diff --git a/doc/sphinx/users-guide/run_security.rst b/doc/sphinx/users-guide/run_security.rst index 8fbf6d2d47..90662ceafc 100644 --- a/doc/sphinx/users-guide/run_security.rst +++ b/doc/sphinx/users-guide/run_security.rst @@ -8,17 +8,17 @@ Security first ============== -If you are the only person involved in running Varnish, or if all +If you are the only person involved in running Vinyl Cache, or if all the people involved are trusted to the same degree, you can skip -this chapter. We have protected Varnish as well as we can from +this chapter. We have protected Vinyl Cache as well as we can from anything which can come in through an HTTP socket. If parts of your web infrastructure are outsourced or otherwise partitioned along administrative lines, you need to think about security. -Varnish provides four levels of authority, roughly related to -how and where control comes into Varnish: +Vinyl Cache provides four levels of authority, roughly related to +how and where control comes into Vinyl Cache: * The command line arguments, @@ -32,7 +32,7 @@ Command line arguments ---------------------- The top level security decisions is decided and defined when starting -Varnish in the form of command line arguments, we use this strategy +Vinyl Cache in the form of command line arguments, we use this strategy in order to make them invulnerable to subsequent manipulation. The important decisions to make are: @@ -86,7 +86,7 @@ around :ref:`vinyladm(1)` to allow specific CLI commands. It is also possible to configure :ref:`vinyld(1)` for "reverse mode", using the ``-M`` argument. In that case :ref:`vinyld(1)` will attempt to open a TCP connection to the specified address, and -initiate a CLI connection to your central Varnish management facility. +initiate a CLI connection to your central Vinyl Cache management facility. .. XXX:Maybe a sample command here with a brief explanation? benc @@ -123,7 +123,7 @@ it possible for (only!) these users to read it. A good way to create the secret file is:: - dd if=/dev/random of=/etc/varnish_secret count=1 + dd if=/dev/random of=/etc/vinyl_secret count=1 When you start :ref:`vinyld(1)`, you specify the filename with '-S', and it goes without saying that the :ref:`vinyld(1)` master process @@ -157,7 +157,7 @@ HTTP service, but a few can do more damage than others: :ref:`ref_param_vcc_feature` The ``allow_inline_c`` flag would allow any C code from VCL to be - executed by Varnish. + executed by Vinyl Cache. Furthermore you may want to look at and lock down: @@ -170,15 +170,15 @@ Furthermore you may want to look at and lock down: :ref:`ref_param_vmod_path` The directory (or colon separated list of directories) where - Varnish will look for modules. This could potentially be - used to load rogue modules into Varnish. + Vinyl Cache will look for modules. This could potentially be + used to load rogue modules into Vinyl Cache. The CLI interface ----------------- -The CLI interface in Varnish is very powerful, if you have +The CLI interface in Vinyl Cache is very powerful, if you have access to the CLI interface, you can do almost anything to -the Varnish process. +the Vinyl Cache process. As described above, some of the damage can be limited by restricting certain parameters, but that will only protect the local filesystem, @@ -208,7 +208,7 @@ be superuser to lower the privilege of a child process... .. XXX the above is not correct for the solaris jail -Inline-C is disabled by default since Varnish version 4, so unless +Inline-C is disabled by default since Varnish Cache version 4, so unless you enable it, you don't have to worry about it. The parameters mentioned above can restrict the loading of VMODs to only @@ -221,7 +221,7 @@ from VCL code. HTTP requests ------------- -We have gone to great lengths to make Varnish resistant to anything +We have gone to great lengths to make Vinyl Cache resistant to anything coming in through the socket where HTTP requests are received, and you should, generally speaking, not need to protect it any further. diff --git a/doc/sphinx/users-guide/running.rst b/doc/sphinx/users-guide/running.rst index 3d346a2ddf..8d37147c16 100644 --- a/doc/sphinx/users-guide/running.rst +++ b/doc/sphinx/users-guide/running.rst @@ -5,13 +5,13 @@ .. _users_running: -Starting and running Varnish -============================ +Starting and running Vinyl Cache +================================ -This section covers starting, running, and stopping Varnish, +This section covers starting, running, and stopping Vinyl Cache, command line flags and options, and communicating with the running -Varnish processes, configuring storage and sockets and, and about -securing and protecting Varnish against attacks. +Vinyl Cache processes, configuring storage and sockets and, and about +securing and protecting Vinyl Cache against attacks. .. toctree:: :maxdepth: 2 diff --git a/doc/sphinx/users-guide/storage-backends.rst b/doc/sphinx/users-guide/storage-backends.rst index 77cc55b398..b94089b656 100644 --- a/doc/sphinx/users-guide/storage-backends.rst +++ b/doc/sphinx/users-guide/storage-backends.rst @@ -12,10 +12,10 @@ Storage backends Intro ~~~~~ -Varnish has pluggable storage backends. It can store data in various +Vinyl Cache has pluggable storage backends. It can store data in various backends which can have different performance characteristics. The default configuration is to use the malloc backend with a limited size. For a -serious Varnish deployment you probably would want to adjust the storage +serious Vinyl Cache deployment you probably would want to adjust the storage settings. All built-in storage backends cache full objects only, so, for example, to @@ -32,7 +32,7 @@ Besides the built-in storage backends, separately distributed extensions exist, Storage Selection ~~~~~~~~~~~~~~~~~ -By default, Varnish will store short-lived and passed objects in a storage +By default, Vinyl Cache will store short-lived and passed objects in a storage called `Transient`, described below. For other objects, it will rotate between all the non-transient storages, @@ -103,11 +103,11 @@ implementations. In particular, `libumem`_ is included in the family of OpenSolaris descendent operating systems where jemalloc(3) is not commonly available. -If `libumem`_ is not used otherwise, Varnish will only use it for +If `libumem`_ is not used otherwise, Vinyl Cache will only use it for storage allocations and keep the default libc allocator for all other -Varnish memory allocation purposes. +Vinyl Cache memory allocation purposes. -If `libumem`_ is already loaded when Varnish initializes, this message +If `libumem`_ is already loaded when Vinyl Cache initializes, this message is output:: notice: libumem was already found to be loaded @@ -122,15 +122,15 @@ reasons for this to be the case are: ``LD_PRELOAD_32=/usr/lib/libumem.so.1`` or ``LD_PRELOAD=/usr/lib/libumem.so.1`` is set -Varnish will also output this message to recommend settings for using +Vinyl Cache will also output this message to recommend settings for using `libumem`_ for all allocations:: it is recommended to set UMEM_OPTIONS=perthread_cache=0,backend=mmap - before starting varnish + before starting vinyl Cache This recommendation should be followed to achieve an optimal -`libumem`_ configuration for Varnish. Setting this environment -variable before starting Varnish is required because `libumem`_ cannot +`libumem`_ configuration for Vinyl Cache. Setting this environment +variable before starting Vinyl Cache is required because `libumem`_ cannot be reconfigured once loaded. .. _libumem: http://dtrace.org/blogs/ahl/2004/07/13/number-11-of-20-libumem/ @@ -145,7 +145,7 @@ unlinked file on disk with `mmap`, relying on the kernel to handle paging as parts of the file are being accessed. This implies that sufficient *virtual* memory needs to be available to -accomodate the file size in addition to any memory Varnish requires +accomodate the file size in addition to any memory Vinyl Cache requires anyway. Traditionally, the virtual memory limit is configured with ``ulimit -v``, but modern operating systems have other abstractions for this limit like control groups (Linux) or resource controls @@ -210,12 +210,12 @@ syntax: deprecated_persistent,path,size {experimental} *Before using, read* :ref:`phk_persistent`\ *!* -Persistent storage. Varnish will store objects in a file in a manner +Persistent storage. Vinyl Cache will store objects in a file in a manner that will secure the survival of *most* of the objects in the event of -a planned or unplanned shutdown of Varnish. +a planned or unplanned shutdown of Vinyl Cache. The 'path' parameter specifies the path to the backing file. If -the file doesn't exist Varnish will create it. +the file doesn't exist Vinyl Cache will create it. The 'size' parameter specifies the size of the backing file. The size is expressed in bytes, unless followed by one of the @@ -229,9 +229,9 @@ following suffixes: T, t The size is expressed in tebibytes. -Varnish will split the file into logical *silos* and write to the +Vinyl Cache will split the file into logical *silos* and write to the silos in the manner of a circular buffer. Only one silo will be kept -open at any given point in time. Full silos are *sealed*. When Varnish +open at any given point in time. Full silos are *sealed*. When Vinyl Cache starts after a shutdown it will discard the content of any silo that isn't sealed. @@ -246,12 +246,12 @@ Transient Storage If you name any of your storage backend "Transient" it will be used for transient (short lived) objects. This includes the temporary -objects created when returning a synthetic object. By default Varnish +objects created when returning a synthetic object. By default Vinyl Cache would use an unlimited malloc backend for this. .. XXX: Is this another parameter? In that case handled in the same manner as above? benc -Varnish will consider an object short lived if the TTL is below the +Vinyl Cache will consider an object short lived if the TTL is below the parameter 'shortlived'. diff --git a/doc/sphinx/users-guide/troubleshooting.rst b/doc/sphinx/users-guide/troubleshooting.rst index 416c2d4d91..5cd8d34b2d 100644 --- a/doc/sphinx/users-guide/troubleshooting.rst +++ b/doc/sphinx/users-guide/troubleshooting.rst @@ -5,33 +5,33 @@ .. _users_trouble: -Troubleshooting Varnish -======================= +Troubleshooting Vinyl Cache +=========================== -Sometimes Varnish misbehaves or rather behaves the way you told it to +Sometimes Vinyl Cache misbehaves or rather behaves the way you told it to behave but not necessarily the way you want it to behave. In order for you to understand whats going on there are a couple of places you can check. :ref:`vinyllog(1)`, ``/var/log/syslog``, -``/var/log/messages`` are all good places where Varnish might leave +``/var/log/messages`` are all good places where Vinyl Cache might leave clues of whats going on. This section will guide you through basic -troubleshooting in Varnish. +troubleshooting in Vinyl Cache. -When Varnish won't start ------------------------- +When Vinyl Cache won't start +---------------------------- -Sometimes Varnish wont start. There is a plethora of possible reasons why -Varnish wont start on your machine. We've seen everything from wrong +Sometimes Vinyl Cache wont start. There is a plethora of possible reasons why +Vinyl Cache wont start on your machine. We've seen everything from wrong permissions on ``/dev/null`` to other processes blocking the ports. -Starting Varnish in debug mode to see what is going on. +Starting Vinyl Cache in debug mode to see what is going on. -Try to start Varnish with the same arguments as otherwise, but ``-d`` +Try to start Vinyl Cache with the same arguments as otherwise, but ``-d`` added. This will give you some more information on what is going -on. Let us see how Varnish will react when something else is listening +on. Let us see how Vinyl Cache will react when something else is listening on its port.:: - # vinyld -n foo -f /usr/local/etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000 -a 0.0.0.0:8080 -d + # vinyld -n foo -f /usr/local/etc/vinyl-cache/default.vcl -s malloc,1G -T 127.0.0.1:2000 -a 0.0.0.0:8080 -d storage_malloc: max size 1024 MB. Using old SHMFILE Platform: Linux,2.6.32-21-generic,i686,-smalloc,-hcritbit @@ -43,7 +43,7 @@ on its port.:: Type 'quit' to close CLI session. Type 'start' to launch worker process. -Now Varnish is running but only the master process is running, in debug +Now Vinyl Cache is running but only the master process is running, in debug mode the cache does not start. Now you're on the console. You can instruct the master process to start the cache by issuing "start".:: @@ -53,16 +53,16 @@ instruct the master process to start the cache by issuing "start".:: Could not open sockets And here we have our problem. Something else is bound to the HTTP port -of Varnish. If this doesn't help try ``strace`` or ``truss`` or come find us +of Vinyl Cache. If this doesn't help try ``strace`` or ``truss`` or come find us on IRC. -Varnish is crashing - panics ----------------------------- +Vinyl Cache is crashing - panics +-------------------------------- -When Varnish goes bust the child processes crashes. Most of the +When Vinyl Cache goes bust the child processes crashes. Most of the crashes are caught by one of the many consistency checks we have -included in the Varnish source code. When Varnish hits one of these +included in the Vinyl Cache source code. When Vinyl Cache hits one of these the caching process will crash itself in a controlled manner, leaving a nice stack trace with the mother process. @@ -86,8 +86,8 @@ The crash might be due to misconfiguration or a bug. If you suspect it is a bug you can use the output in a bug report, see the "Trouble Tickets" section in the Introduction chapter above. -Varnish is crashing - stack overflows -------------------------------------- +Vinyl Cache is crashing - stack overflows +----------------------------------------- Bugs put aside, the most likely cause of crashes are stack overflows, which is why we have added a heuristic to add a note when a crash @@ -99,23 +99,23 @@ contains something like this:: as a first measure, please follow this advise and check if crashes still occur when you add 128k to whatever the value of the -``thread_pool_stack`` parameter and restart varnish. +``thread_pool_stack`` parameter and restart vinyl Cache. -If varnish stops crashing with a larger ``thread_pool_stack`` +If vinyl Cache stops crashing with a larger ``thread_pool_stack`` parameter, it's not a bug (at least most likely). -Varnish is crashing - segfaults -------------------------------- +Vinyl Cache is crashing - segmentation faults +--------------------------------------------- -Sometimes a bug escapes the consistency checks and Varnish gets hit +Sometimes a bug escapes the consistency checks and Vinyl Cache gets hit with a segmentation error. When this happens with the child process it is logged, the core is dumped and the child process starts up again. -A core dumped is usually due to a bug in Varnish. However, in order to +A core dumped is usually due to a bug in Vinyl Cache. However, in order to debug a segfault the developers need you to provide a fair bit of data. - * Make sure you have Varnish installed with debugging symbols. + * Make sure you have Vinyl Cache installed with debugging symbols. * Check where your operating system writes core files and ensure that you actually get them. For example on linux, learn about ``/proc/sys/kernel/core_pattern`` from the `core(5)` manpage. @@ -124,19 +124,19 @@ data. ulimit -c unlimited - but if varnish is started from an init-script, that would need to + but if vinyl Cache is started from an init-script, that would need to be adjusted or in the case of systemd, ``LimitCORE=infinity`` set in the service's ``[Service]]`` section of the unit file. -Once you have the core, ``cd`` into varnish's working directory (as +Once you have the core, ``cd`` into vinyl Cache's working directory (as given by the ``-n`` parameter (see :ref:`vinyld(1)` for defaults), open the core with ``gdb`` and issue the command ``bt`` to get a stack trace of the thread that caused the segfault. -A basic debug session for varnish installed under ``/usr/local`` could look +A basic debug session for vinyl Cache installed under ``/usr/local`` could look like this:: - $ cd /usr/local/var/varnish/`uname -n`/ + $ cd /usr/local/var/vinyl Cache/`uname -n`/ $ gdb /usr/local/sbin/vinyld core GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. @@ -176,8 +176,8 @@ like this:: -Varnish gives me Guru meditation --------------------------------- +Vinyl Cache gives me Guru meditation +------------------------------------ First find the relevant log entries in :ref:`vinyllog(1)`. That will probably give you a clue. Since :ref:`vinyllog(1)` logs a lot of @@ -198,7 +198,7 @@ for elaborations on further filtering capabilities and explanation of the various options. -Varnish doesn't cache ---------------------- +Vinyl Cache doesn't cache +------------------------- See :ref:`users-guide-increasing_your_hitrate`. diff --git a/doc/sphinx/users-guide/vcl-backends.rst b/doc/sphinx/users-guide/vcl-backends.rst index 423a688e54..6f519ca8bb 100644 --- a/doc/sphinx/users-guide/vcl-backends.rst +++ b/doc/sphinx/users-guide/vcl-backends.rst @@ -8,10 +8,10 @@ Backend servers --------------- -Varnish has a concept of "backend" or "origin" servers. A backend -server is the server providing the content Varnish will accelerate. +Vinyl Cache has a concept of "backend" or "origin" servers. A backend +server is the server providing the content Vinyl Cache will accelerate. -Our first task is to tell Varnish where it can find its backends. Start +Our first task is to tell Vinyl Cache where it can find its backends. Start your favorite text editor and open the relevant VCL file. Somewhere in the top there will be a section that looks a bit like this.:: @@ -28,11 +28,11 @@ We remove the comment markings in this code block making it look like.:: .port = "8080"; } -Now, this piece of configuration defines a backend in Varnish called -*default*. When Varnish needs to get content from this backend it will +Now, this piece of configuration defines a backend in Vinyl Cache called +*default*. When Vinyl Cache needs to get content from this backend it will connect to port 8080 on localhost (127.0.0.1). -Varnish can have several backends defined you can even join +Vinyl Cache can have several backends defined you can even join several backends together into clusters of backends for load balancing purposes. @@ -75,8 +75,8 @@ Backends can also be declared as ``none`` with the following syntax::: Multiple backends ----------------- -At some point you might need Varnish to cache content from several -servers. You might want Varnish to map all the URL into one single +At some point you might need Vinyl Cache to cache content from several +servers. You might want Vinyl Cache to map all the URL into one single host or not. There are lot of options. Lets say we need to introduce a Java application into out PHP web @@ -98,7 +98,7 @@ We add a new backend.:: .port = "8000"; } -Now we need tell Varnish where to send the difference URL. Lets look at `vcl_recv`.:: +Now we need tell Vinyl Cache where to send the difference URL. Lets look at `vcl_recv`.:: sub vcl_recv { if (req.url ~ "^/java/") { @@ -114,15 +114,15 @@ really arbitrary data. You want to send mobile devices to a different backend? No problem. ``if (req.http.User-agent ~ /mobile/) ..`` should do the trick. -Without an explicit backend selection, Varnish will continue using +Without an explicit backend selection, Vinyl Cache will continue using the `default` backend. If there is no backend named `default`, the first backend found in the vcl will be used as the default backend. -Backends and virtual hosts in Varnish -------------------------------------- +Backends and virtual hosts in Vinyl Cache +----------------------------------------- -Varnish fully supports virtual hosts. They might however work in a somewhat +Vinyl Cache fully supports virtual hosts. They might however work in a somewhat counter-intuitive fashion since they are never declared explicitly. You set up the routing of incoming HTTP requests in `vcl_recv`. If you want this routing to be done on the basis of virtual @@ -157,7 +157,7 @@ Connecting Through a Proxy .. _haproxy: http://www.haproxy.org/ .. _SNI: https://en.wikipedia.org/wiki/Server_Name_Indication -As of this release, Varnish can connect to an actual *destination* +As of this release, Vinyl Cache can connect to an actual *destination* through a *proxy* using the `PROXY2`_ protocol. Other protocols may be added. @@ -185,7 +185,7 @@ higher, this snippet can be used as a basis for configuring an # ... # A higher number of servers improves TLS session caching -Varnish running on the same server/namespace can then use the +Vinyl Cache running on the same server/namespace can then use the *onloader* with the ``.via`` feature (see :ref:`backend_definition_via`):: backend sslon { @@ -213,7 +213,7 @@ groups are called directors. This will give you increased performance and resilience. You can define several backends and group them together in a -director. This requires you to load a VMOD, a Varnish module, and then to +director. This requires you to load a VMOD, a Vinyl Cache module, and then to call certain actions in `vcl_init`.:: @@ -243,7 +243,7 @@ also a *random* director which distributes requests in a, you guessed it, random fashion. If that is not enough, you can also write your own director (see :ref:`ref-writing-a-director`). -But what if one of your servers goes down? Can Varnish direct all the +But what if one of your servers goes down? Can Vinyl Cache direct all the requests to the healthy server? Sure it can. This is where the Health Checks come into play. @@ -277,7 +277,7 @@ us define the backends:: } } -What is new here is the ``probe``. In this example Varnish will check the +What is new here is the ``probe``. In this example Vinyl Cache will check the health of each backend every 5 seconds, timing out after 1 second. Each poll will send a GET request to /. If 3 out of the last 5 polls succeeded the backend is considered healthy, otherwise it will be marked as sick. @@ -296,15 +296,15 @@ Now we define the 'director':: } You use this `vdir` director as a backend_hint for requests, just like -you would with a simple backend. Varnish will not send traffic to hosts +you would with a simple backend. Vinyl Cache will not send traffic to hosts that are marked as unhealthy. -Varnish can also serve stale content if all the backends are down. See +Vinyl Cache can also serve stale content if all the backends are down. See :ref:`users-guide-handling_misbehaving_servers` for more information on how to enable this. -Please note that Varnish will keep health probes running for all loaded -VCLs. Varnish will coalesce probes that seem identical - so be careful +Please note that Vinyl Cache will keep health probes running for all loaded +VCLs. Vinyl Cache will coalesce probes that seem identical - so be careful not to change the probe config if you do a lot of VCL loading. Unloading the VCL will discard the probes. For more information on how to do this please see ref:`reference-vcl-director`. @@ -370,7 +370,7 @@ connections over possibly multiple hops and long network paths. However relevant the overhead, it certainly always exists. So because re-using existing connections can generally be considered -to reduce overhead and latencies, Varnish pools backend connections by +to reduce overhead and latencies, Vinyl Cache pools backend connections by default: Whenever a backend task is finished, the used connection is not closed but rather added to a pool for later reuse. To avoid a connection from being reused, the ``Connection: close`` http header @@ -385,5 +385,5 @@ address information, irrespective of which VCLs they are defined in, their connections are taken from a common pool. If not actively closed by the backend, pooled connections are kept -open by Varnish until the :ref:`ref_param_backend_idle_timeout` +open by Vinyl Cache until the :ref:`ref_param_backend_idle_timeout` expires. diff --git a/doc/sphinx/users-guide/vcl-built-in-code.rst b/doc/sphinx/users-guide/vcl-built-in-code.rst index e9cdcf5979..91eaad2af5 100644 --- a/doc/sphinx/users-guide/vcl-built-in-code.rst +++ b/doc/sphinx/users-guide/vcl-built-in-code.rst @@ -24,7 +24,7 @@ This is how it is guaranteed that all :ref:`reference-states` have at least one ``return ()``. It is generally recommended not to invariably return from loaded code to -let Varnish execute the built-in code, because the built-in code provides +let Vinyl Cache execute the built-in code, because the built-in code provides essentially a sensible default behavior for an HTTP cache. Built-in subroutines split @@ -56,7 +56,7 @@ a response as uncacheable, but only if the built-in ``vcl_backend_response`` is not circumvented by a ``return ()``. However, in a multi-tier architecture where a backend might be another -Varnish server, you might want to cache stale responses to allow the +Vinyl Cache server, you might want to cache stale responses to allow the delivery of graced objects and enable revalidation on the next fetch. This can be done with the following snippet:: @@ -189,7 +189,7 @@ case the loaded VCL code will be executed before the built-in code. Re-enabling pipe mode ~~~~~~~~~~~~~~~~~~~~~ -As of Varnish 8.0, Varnish no longer pipes unknown HTTP methods by default. +Since Varnish Cache 8.0, Vinyl Cache no longer pipes unknown HTTP methods by default. Instead, it returns a 501 synthetic error. If you want to re-enable pipe mode for a specific method, you can do so by adding the following to your VCL: diff --git a/doc/sphinx/users-guide/vcl-example-websockets.rst b/doc/sphinx/users-guide/vcl-example-websockets.rst index 05fa54337a..cae8b08f6f 100644 --- a/doc/sphinx/users-guide/vcl-example-websockets.rst +++ b/doc/sphinx/users-guide/vcl-example-websockets.rst @@ -10,7 +10,7 @@ Adding WebSockets support WebSockets is a technology for creating a bidirectional stream-based channel over HTTP. -To run WebSockets through Varnish you need to pipe the request and copy +To run WebSockets through Vinyl Cache you need to pipe the request and copy the Upgrade and Connection headers as follows:: sub vcl_recv { diff --git a/doc/sphinx/users-guide/vcl-grace.rst b/doc/sphinx/users-guide/vcl-grace.rst index 3d0dafa3aa..beb975ab7e 100644 --- a/doc/sphinx/users-guide/vcl-grace.rst +++ b/doc/sphinx/users-guide/vcl-grace.rst @@ -8,21 +8,21 @@ Grace mode and keep ------------------- -Sometimes you want Varnish to serve content that is somewhat stale +Sometimes you want Vinyl Cache to serve content that is somewhat stale instead of waiting for a fresh object from the backend. For example, if you run a news site, serving a main page that is a few seconds old is not a problem if this gives your site faster load times. -In Varnish this is achieved by using `grace mode`. A related idea +In Vinyl Cache this is achieved by using `grace mode`. A related idea is `keep`, which is also explained here. Grace mode ~~~~~~~~~~ -When several clients are requesting the same page Varnish will send +When several clients are requesting the same page Vinyl Cache will send one request to the backend and place the others on hold while fetching one copy from the backend. In some products this is called request -coalescing and Varnish does this automatically. +coalescing and Vinyl Cache does this automatically. If you are serving thousands of hits per second the queue of waiting requests can get huge. There are two potential problems - one is a @@ -30,15 +30,15 @@ thundering herd problem - suddenly releasing a thousand threads to serve content might send the load sky high. Secondly - nobody likes to wait. -Setting an object's `grace` to a positive value tells Varnish that it +Setting an object's `grace` to a positive value tells Vinyl Cache that it should serve the object to clients for some time after the TTL has -expired, while Varnish fetches a new version of the object. The default +expired, while Vinyl Cache fetches a new version of the object. The default value is controlled by the runtime parameter ``default_grace``. Keep ~~~~ -Setting an object's `keep` tells Varnish that it should keep an object +Setting an object's `keep` tells Vinyl Cache that it should keep an object in the cache for some additional time. The reasons to set `keep` is to use the object to construct a conditional GET backend request (with If-Modified-Since: and/or Ìf-None-Match: headers), allowing the @@ -52,7 +52,7 @@ expired. Setting grace and keep ~~~~~~~~~~~~~~~~~~~~~~ -We can use VCL to make Varnish keep all objects for 10 minutes beyond +We can use VCL to make Vinyl Cache keep all objects for 10 minutes beyond their TTL with a grace period of 2 minutes:: sub vcl_backend_response { @@ -66,18 +66,18 @@ The effect of grace and keep For most users setting the default grace and/or a suitable grace for each object is enough. The default VCL will do the right thing and behave as described above. However, if you want to customize how -Varnish behaves, then you should know some of the details on how this +Vinyl Cache behaves, then you should know some of the details on how this works. When ``sub vcl_recv`` ends with ``return (hash)`` (which is the -default behavior), Varnish will look for a matching object in its -cache. Then, if it only found an object whose TTL has run out, Varnish +default behavior), Vinyl Cache will look for a matching object in its +cache. Then, if it only found an object whose TTL has run out, Vinyl Cache will consider the following: * Is there already an ongoing backend request for the object? * Is the object within the `grace period`? -Then, Varnish reacts using the following rules: +Then, Vinyl Cache reacts using the following rules: * If the `grace period` has run out and there is no ongoing backend request, then ``sub vcl_miss`` is called immediately, and the object @@ -112,7 +112,7 @@ initiated. Misbehaving servers ~~~~~~~~~~~~~~~~~~~ -A key feature of Varnish is its ability to shield you from misbehaving +A key feature of Vinyl Cache is its ability to shield you from misbehaving web- and application servers. If you have enabled :ref:`users-guide-advanced_backend_servers-health` @@ -148,7 +148,7 @@ returns an ``5xx`` error:: Summary ~~~~~~~ -Grace mode allows Varnish to deliver slightly stale content to clients +Grace mode allows Vinyl Cache to deliver slightly stale content to clients while getting a fresh version from the backend. The result is faster load times at lower cost. diff --git a/doc/sphinx/users-guide/vcl-hashing.rst b/doc/sphinx/users-guide/vcl-hashing.rst index 1f50a5e631..5623cc2fc1 100644 --- a/doc/sphinx/users-guide/vcl-hashing.rst +++ b/doc/sphinx/users-guide/vcl-hashing.rst @@ -6,7 +6,7 @@ Hashing ------- -Internally, when Varnish stores content in the cache indexed by a hash +Internally, when Vinyl Cache stores content in the cache indexed by a hash key used to find the object again. In the default setup this key is calculated based on `URL`, the `Host:` header, or if there is none, the IP address of the server:: @@ -22,12 +22,14 @@ if there is none, the IP address of the server:: } As you can see it first hashes `req.url` and then `req.http.host` if -it exists. It is worth pointing out that Varnish doesn't lowercase the -hostname or the URL before hashing it so in theory having "Varnish.org/" -and "varnish.org/" would result in different cache entries. Browsers -however, tend to lowercase hostnames. - -You can change what goes into the hash. This way you can make Varnish +it exists. It is worth pointing out that Vinyl Cache core code doesn't lowercase the +hostname or the URL before hashing it so in theory https://vinyl-cache.org/ and +https://Vinyl-Cache.org/ would use different cache entries. However, ``sub +vcl_req_host`` from ``builtin.vcl`` takes care of converting the host name to +lowercase if the built-in VCL is in effect. The path component of the URL should +not be lowercased unless when the application does not use mixed case. + +You can change what goes into the hash. This way you can make Vinyl Cache serve up different content to different clients based on arbitrary criteria. @@ -55,6 +57,6 @@ If `vcl_hash` did return, ie:: return(lookup); } -then *only* the country-code would matter, and Varnish would return +then *only* the country-code would matter, and Vinyl Cache would return seemingly random objects, ignoring the URL, (but they would always have the correct `X-Country-Code`). diff --git a/doc/sphinx/users-guide/vcl-inline-c.rst b/doc/sphinx/users-guide/vcl-inline-c.rst index f30774cdaf..1194baf6a4 100644 --- a/doc/sphinx/users-guide/vcl-inline-c.rst +++ b/doc/sphinx/users-guide/vcl-inline-c.rst @@ -6,13 +6,13 @@ -Using inline C to extend Varnish ---------------------------------- +Using inline C to extend Vinyl Cache +------------------------------------ (Here there be dragons. Big and mean ones.) -You can use *inline C* to extend Varnish. Please note that you can -seriously mess up Varnish this way. The C code runs within the Varnish +You can use *inline C* to extend Vinyl Cache. Please note that you can +seriously mess up Vinyl Cache this way. The C code runs within the Vinyl Cache Cache process so if your code generates a segfault the cache will crash. One of the first uses of inline C was logging to `syslog`.:: diff --git a/doc/sphinx/users-guide/vcl-separate.rst b/doc/sphinx/users-guide/vcl-separate.rst index 0c540228b0..ce72066532 100644 --- a/doc/sphinx/users-guide/vcl-separate.rst +++ b/doc/sphinx/users-guide/vcl-separate.rst @@ -8,26 +8,26 @@ Separate VCL files ================== -Having multiple different vhosts in the same Varnish is a very -typical use-case, and from Varnish 5.0 it is possible to have +Having multiple different vhosts in the same Vinyl Cache is a very +typical use-case, and from Varnish Cache 5.0 it is possible to have a separate VCL files for separate vhosts or any other distinct subset of requests. -Assume that we want to handle ``varnish.org`` with one VCL file +Assume that we want to handle ``code.vinyl-cache.org`` with one VCL file and ``vinyl-cache.org`` with another VCL file. First load the two VCL files:: - vcl.load vo_1 /somewhere/vo.vcl - vcl.load vc_1 /somewhere/vc.vcl + vcl.load code_1 /somewhere/code.vcl + vcl.load vinyl_1 /somewhere/vinyl.vcl These are 100% normal VCL files, as they would look if you ran -only that single domain on your Varnish instance. +only that single domain on your Vinyl Cache instance. Next we need to point VCL labels to them:: - vcl.label l_vo vo_1 - vcl.label l_vc vc_1 + vcl.label l_code code_1 + vcl.label l_vinyl vinyl_1 Next we write the top-level VCL program, which branches out to the other two, depending on the Host: header in the @@ -40,13 +40,13 @@ request:: sub vcl_recv { # Normalize host header - set req.http.host = std.tolower(req.http.host); + call vcl_req_host; - if (req.http.host ~ "\.?varnish\.org$") { - return (vcl(l_vo)); + if (req.http.host == "code.vinyl-cache.org") { + return (vcl(l_code)); } if (req.http.host ~ "\.?vinyl-cache\.org$") { - return (vcl(l_vc)); + return (vcl(l_vinyl)); } return (synth(302, "http://vinyl-cache.org")); } @@ -68,8 +68,8 @@ active VCL:: If you want to update one of the separated VCLs, you load the new one and change the label to point to it:: - vcl.load vo_2 /somewhere/vo.vcl - vcl.label l_vo vo_2 + vcl.load code_2 /somewhere/code.vcl + vcl.label l_code code_2 If you want to change the top level VCL, do as you always did:: diff --git a/doc/sphinx/users-guide/vcl-syntax.rst b/doc/sphinx/users-guide/vcl-syntax.rst index 3d9d819ec3..c2c4a3782f 100644 --- a/doc/sphinx/users-guide/vcl-syntax.rst +++ b/doc/sphinx/users-guide/vcl-syntax.rst @@ -47,7 +47,7 @@ which can later be used to match client addresses:: ! "192.0.2.23"; // except for the dialin router } -If an ACL entry specifies a host name which Varnish is unable to +If an ACL entry specifies a host name which Vinyl Cache is unable to resolve, it will match any address it is compared to. Consequently, if it is preceded by a negation mark, it will reject any address it is compared to, which may not be what you intended. If the entry is @@ -59,7 +59,7 @@ To match an IP address against an ACL, simply use the match operator:: return (pipe); } -In Varnish versions before 7.0, ACLs would always emit a `VCL_acl` +In Varnish Cache versions before 7.0, ACLs would always emit a `VCL_acl` record in the VSL log, from 7.0 and forward, this must be explicitly enabled by specifying the `+log` flag:: @@ -97,8 +97,8 @@ down for, uhm, examples. 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 +Vinyl Cache has quite a few built-in subroutines that are called for each +transaction as it flows through Vinyl Cache. These built-in subroutines are all named ``vcl_*`` and are explained in :ref:`vcl_steps`. Processing in built-in subroutines ends with ``return ()`` diff --git a/doc/sphinx/users-guide/vcl-variables.rst b/doc/sphinx/users-guide/vcl-variables.rst index 8db0041b9b..5ba01bb06f 100644 --- a/doc/sphinx/users-guide/vcl-variables.rst +++ b/doc/sphinx/users-guide/vcl-variables.rst @@ -14,12 +14,12 @@ objects can be accessed and manipulated using VCL. *req* - The request object. When Varnish has received the request the `req` object is + The request object. When Vinyl Cache has received the request the `req` object is created and populated. Most of the work you do in `vcl_recv` you do on or with the `req` object. *bereq* - The backend request object. Varnish constructs this before sending it to the + The backend request object. Vinyl Cache constructs this before sending it to the backend. It is based on the `req` object. .. XXX:in what way? benc diff --git a/doc/sphinx/users-guide/vcl.rst b/doc/sphinx/users-guide/vcl.rst index d614788cd0..0638dfb9c2 100644 --- a/doc/sphinx/users-guide/vcl.rst +++ b/doc/sphinx/users-guide/vcl.rst @@ -6,24 +6,24 @@ .. _users_vcl: -VCL - Varnish Configuration Language ------------------------------------- +VCL - Vinyl Configuration Language +---------------------------------- -This section covers how to tell Varnish how to handle -your HTTP traffic, using the Varnish Configuration Language (VCL). +This section covers how to tell Vinyl Cache how to handle +your HTTP traffic, using the Vinyl Configuration Language (VCL). -Varnish has a great configuration system. Most other systems use +Vinyl Cache has a great configuration system. Most other systems use configuration directives, where you basically turn on and off lots of switches. We have instead chosen to use a domain specific language called VCL for this. -Every inbound request flows through Varnish and you can influence how +Every inbound request flows through Vinyl Cache and you can influence how the request is being handled by altering the VCL code. You can direct certain requests to particular backends, you can alter the requests and -the responses or have Varnish take various actions depending on +the responses or have Vinyl Cache take various actions depending on arbitrary properties of the request or the response. This makes -Varnish an extremely powerful HTTP processor, not just for caching. +Vinyl Cache an extremely powerful HTTP processor, not just for caching. -Varnish translates VCL into binary code which is then executed when +Vinyl Cache translates VCL into binary code which is then executed when requests arrive. The performance impact of VCL is negligible. The VCL files are organized into subroutines. The different subroutines @@ -31,7 +31,7 @@ are executed at different times. One is executed when we get the request, another when files are fetched from the backend server. If you don't call an action in your subroutine and it reaches the end -Varnish will execute some built-in VCL code. You will see this VCL +Vinyl Cache will execute some built-in VCL code. You will see this VCL code commented out in the file `builtin.vcl` that ships with Vinyl Cache. .. _users-guide-vcl_fetch_actions: diff --git a/doc/sphinx/vcl-design-patterns/req-hash_ignore_vary.rst b/doc/sphinx/vcl-design-patterns/req-hash_ignore_vary.rst index b5b620c961..64257f35bf 100644 --- a/doc/sphinx/vcl-design-patterns/req-hash_ignore_vary.rst +++ b/doc/sphinx/vcl-design-patterns/req-hash_ignore_vary.rst @@ -6,7 +6,7 @@ Ignoring the Vary header for bots ================================= -Varnish supports HTTP variants out of the box, but the *Vary* header is +Vinyl Cache supports HTTP variants out of the box, but the *Vary* header is somewhat limited since it operates on complete header values. If you want for example to conduct an A/B testing campaign or perform blue/green deployment you can make clients "remember" their path with a first-party cookie. diff --git a/doc/sphinx/vcl-design-patterns/resp-status.rst b/doc/sphinx/vcl-design-patterns/resp-status.rst index 29feeb59bc..9a2258b714 100644 --- a/doc/sphinx/vcl-design-patterns/resp-status.rst +++ b/doc/sphinx/vcl-design-patterns/resp-status.rst @@ -6,7 +6,7 @@ Using extra digits in resp.status ================================= -In Varnish the ``.status`` variables can hold more than three +In Vinyl Cache the ``.status`` variables can hold more than three digits, which is useful to send information to ``vcl_synth{}`` about which error message to produce:: diff --git a/doc/sphinx/vtc-syntax.py b/doc/sphinx/vtc-syntax.py index acf6f356cb..81a5014318 100644 --- a/doc/sphinx/vtc-syntax.py +++ b/doc/sphinx/vtc-syntax.py @@ -28,7 +28,7 @@ # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # -# Process various varnishtest C files and output reStructuredText to be +# Process various vinyltest C files and output reStructuredText to be # included in vtc(7). import sys diff --git a/doc/sphinx/whats-new/index.rst b/doc/sphinx/whats-new/index.rst index 49a651085a..c946ebb2fa 100644 --- a/doc/sphinx/whats-new/index.rst +++ b/doc/sphinx/whats-new/index.rst @@ -10,11 +10,15 @@ What's new / Upgrading %%%%%%%%%%%%%%%%%%%%%% This section describes the changes and improvements between different -versions of Varnish, and what upgrading between the different versions +versions of Vinyl Cache, and what upgrading between the different versions entail. -Vinyl 9.0 ---------- +Releases up to and including 8.0 were called Varnish. From 9.0 on, this project +is called Vinyl Cache and releases called Varnish are continued by Varnish +Software as a fork. + +Vinyl Cache 9.0 +--------------- **Note: These are working documents for a future release, with running updates for changes in the development branch. For changes in the From bc9e632b1a3e48234e4084864c967f204b173e65 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Mar 2026 11:06:10 +0100 Subject: [PATCH 142/196] Try to stabilize vtc --- bin/vinyltest/tests/r02946.vtc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/vinyltest/tests/r02946.vtc b/bin/vinyltest/tests/r02946.vtc index a1d348bb23..bde3c4cd9b 100644 --- a/bin/vinyltest/tests/r02946.vtc +++ b/bin/vinyltest/tests/r02946.vtc @@ -42,7 +42,7 @@ client c1 { expect resp.http.age > 1 } -run -delay 1 +delay 2 vinyl v1 -expect s_fetch > s_bgfetch vinyl v1 -expect n_objectcore == 1 From 923da5d12213224bbe70495cbf71f4c1002969a4 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Mar 2026 12:29:30 +0100 Subject: [PATCH 143/196] Sync package availability with reality --- doc/sphinx/installation/install_debian.rst | 42 +++-------------- doc/sphinx/installation/install_redhat.rst | 54 +++------------------- 2 files changed, 14 insertions(+), 82 deletions(-) diff --git a/doc/sphinx/installation/install_debian.rst b/doc/sphinx/installation/install_debian.rst index f5c5688b3c..66c1f59cd7 100644 --- a/doc/sphinx/installation/install_debian.rst +++ b/doc/sphinx/installation/install_debian.rst @@ -1,5 +1,5 @@ .. - Copyright (c) 2019 Varnish Software AS + Copyright 2026 The Vinyl Cache Project SPDX-License-Identifier: BSD-2-Clause See LICENSE file for full text of license @@ -8,38 +8,10 @@ Installing on Debian/Ubuntu =========================== -From package ------------- +.. _RSS: https://vinyl-cache.org/atom.xml +.. _Mastodon: https://fosstodon.org/@vinyl_cache +.. _vinyl-accounce: https://vinyl-cache.org/lists/mailman/listinfo/vinyl-announce -Type:: - - sudo apt-get install vinyl - - -Official packages of 6 ----------------------- - -Starting from Vinyl Cache 5.0, we've simplified our packaging down to two: -the main package and a development package. - -The official Vinyl Cache repository is now hosted at Packagecloud.io. -Note that while Packagecloud.io provides Bash Script installs, we recommend -using the manual installation procedures. - -Instructions for installing the official repository which contains the newest -Vinyl Cache 6 release are available at: - -* https://packagecloud.io/varnishcache/varnish60lts/install#manual-deb - -With the release of 6.0.2, users have to switch to switch repositories to get -the latest version. -Read more about this on `Release 6.0.2 `_. - - -Official packages of 4.1 ------------------------- - -To use Vinyl Cache 4.1 packages from the official varnish-cache.org repos, -follow the instructions available at: - -* https://packagecloud.io/varnishcache/varnish41/install#manual-deb +As of Vinyl Cache 9.0, we do not yet provide Debian packages again. Please +follow the homepage updates via `RSS`_, follow via `Mastodon`_ or subscribe to +`vinyl-announce`_ to get informed when we have packages ready. diff --git a/doc/sphinx/installation/install_redhat.rst b/doc/sphinx/installation/install_redhat.rst index 1a374a47eb..1bf74b9dd8 100644 --- a/doc/sphinx/installation/install_redhat.rst +++ b/doc/sphinx/installation/install_redhat.rst @@ -1,5 +1,5 @@ .. - Copyright (c) 2019-2020 Varnish Software AS + Copyright 2026 The Vinyl Cache Project SPDX-License-Identifier: BSD-2-Clause See LICENSE file for full text of license @@ -8,51 +8,11 @@ Installing on RedHat or CentOS ============================== -Varnish is included in the `EPEL -`_ repository, however due to -incompatible syntax changes in newer versions of Varnish, only older -versions are available. +.. _RSS: https://vinyl-cache.org/atom.xml +.. _Mastodon: https://fosstodon.org/@vinyl_cache +.. _vinyl-accounce: https://vinyl-cache.org/lists/mailman/listinfo/vinyl-announce -We therefore recommend that you install the latest version directly from our repository, as described above. +As of Vinyl Cache 9.0, we do not yet provide RedHat / Alma / Fedora packages again. Please +follow the homepage updates via `RSS`_, follow via `Mastodon`_ or subscribe to +`vinyl-announce`_ to get informed when we have packages ready. -Vinyl Cache is packaged in RPMs for easy installation and upgrade on Red Hat -systems. The Vinyl Cache project maintains official packages for the current -Enterprise Linux versions. Vinyl Cache 6.x series are supported on el7 and el8. - -We try to keep the latest version available as prebuilt RPMs (el7 and el8) -on `packagecloud.io/varnishcache `_. - -Starting with el8 a DNF module will inhibit Varnish packages, and the solution -is to disable the module before installing:: - - dnf module disable varnish - -Official packages of 6 ----------------------- - -Starting from Vinyl Cache 5.0, we've simplified our packaging down to two: -the main package and a development package. - -The official Vinyl Cache repository is now hosted at Packagecloud.io. -Note that while Packagecloud.io provides Bash Script installs, we recommend -using the manual installation procedures. - -Instructions for installing the official repository which contains the newest -Vinyl Cache 6 release are available at: - -* https://packagecloud.io/varnishcache/varnish60lts/install#manual-rpm - -With the release of 6.0.2, users have to switch to switch repositories to get -the latest version. -Read more about this on `Release 6.0.2 `_. - -External packaging ------------------- - -Vinyl Cache is also distributed in third party package repositories. - -.. _`Fedora EPEL`: https://fedoraproject.org/wiki/EPEL - -* `Fedora EPEL`_ does community packaging of Vinyl Cache. - -* RedHat has packaged versions of Vinyl Cache available since Software Collections 2.1. Announcement on . From 7bc23ba2d6a07f12dcb283724e28aaa87cef7c15 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Mar 2026 15:35:08 +0100 Subject: [PATCH 144/196] fix typo - sorry --- doc/sphinx/installation/install_debian.rst | 2 +- doc/sphinx/installation/install_redhat.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/sphinx/installation/install_debian.rst b/doc/sphinx/installation/install_debian.rst index 66c1f59cd7..d053afb025 100644 --- a/doc/sphinx/installation/install_debian.rst +++ b/doc/sphinx/installation/install_debian.rst @@ -10,7 +10,7 @@ Installing on Debian/Ubuntu .. _RSS: https://vinyl-cache.org/atom.xml .. _Mastodon: https://fosstodon.org/@vinyl_cache -.. _vinyl-accounce: https://vinyl-cache.org/lists/mailman/listinfo/vinyl-announce +.. _vinyl-announce: https://vinyl-cache.org/lists/mailman/listinfo/vinyl-announce As of Vinyl Cache 9.0, we do not yet provide Debian packages again. Please follow the homepage updates via `RSS`_, follow via `Mastodon`_ or subscribe to diff --git a/doc/sphinx/installation/install_redhat.rst b/doc/sphinx/installation/install_redhat.rst index 1bf74b9dd8..2802a420fe 100644 --- a/doc/sphinx/installation/install_redhat.rst +++ b/doc/sphinx/installation/install_redhat.rst @@ -10,7 +10,7 @@ Installing on RedHat or CentOS .. _RSS: https://vinyl-cache.org/atom.xml .. _Mastodon: https://fosstodon.org/@vinyl_cache -.. _vinyl-accounce: https://vinyl-cache.org/lists/mailman/listinfo/vinyl-announce +.. _vinyl-announce: https://vinyl-cache.org/lists/mailman/listinfo/vinyl-announce As of Vinyl Cache 9.0, we do not yet provide RedHat / Alma / Fedora packages again. Please follow the homepage updates via `RSS`_, follow via `Mastodon`_ or subscribe to From d57c98264423bfeb0ad606c25ba4db98caeea282 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Mar 2026 16:01:48 +0100 Subject: [PATCH 145/196] Update CSS see https://code.vinyl-cache.org/vinyl-cache/homepage/commit/ffbabb4a4b8e3b58d1cd562653cd43c6286fc25d --- doc/sphinx/_static/custom.css | 102 +++++++++++++++++++++++++++++++--- 1 file changed, 95 insertions(+), 7 deletions(-) diff --git a/doc/sphinx/_static/custom.css b/doc/sphinx/_static/custom.css index 3bc0f423e5..dcf63bf572 100644 --- a/doc/sphinx/_static/custom.css +++ b/doc/sphinx/_static/custom.css @@ -70,9 +70,15 @@ body { --toc-font-size: 0.6rem; } +h1, h2 { + text-wrap: balance; +} + h1 { font-size: 3.5em; margin-bottom: 1.5rem; + line-height: 1em; + margin-top: 2.35rem; } h2 { @@ -104,11 +110,11 @@ h6 { --color-vinyl-brand: #660066; --color-vinyl-white: #ffffff; --color-vinyl-red: #ff9f8c; - --color-vinyl-red-lighter: #ff9f8c; - --color-vinyl-red-lightest: #ffcfc5; + --color-vinyl-red-lighter: #ffcfc5; + --color-vinyl-red-lightest: #ffe7e2; --color-vinyl-yellow: #ffee99; --color-vinyl-yellow-lighter: #fff6cc; - --color-vinyl-yellow-lightest: #ffe7e2; + --color-vinyl-yellow-lightest: #fffbe5; --color-vinyl-blue: #a6ffe1; --color-vinyl-blue-lighter: #d2fff0; --color-vinyl-blue-lightest: #e9fff7; @@ -220,6 +226,10 @@ h3, h4, h5, h6 { margin: 0; } +li::marker { + color: var(--color-theme-main); +} + /* Spacing */ body { @@ -237,6 +247,8 @@ body { /* Elements */ +/* Homepage introduction block */ + .intro-card { background-color: light-dark( var(--color-theme-main-10), @@ -273,22 +285,98 @@ body { background-color: var(--color-theme-main-80); } +/* Timestamps for news items */ + time:has(+h3), -h3 + time { +h3 + time, +.rubric.date { font-family: var(--font-stack--monospace); color: var(--color-theme-main); font-size: .8rem; } -time + h3 { +time + h3, +.rubric.date + h3 { margin-top: 0; } +/* Admonitions */ + +.admonition { + --color-admonition: var(--color-theme-main); + --color-admonition-background: rgb(from var(--color-admonition) r g b / 15%); + --color-admonition-heading: light-dark(var(--color-theme-main), var(--color-admonition)); + border-radius: 0; + box-shadow: none; + border-left: .75rem solid var(--color-admonition) !important; + background: var(--color-admonition-background); + padding: .75rem .75rem; +} + +.admonition .admonition-title { + --admonition-title-font-size: .9rem; + background: transparent !important; + color: var(--color-admonition-heading) !important; + font-family: var(--font-stack--monospace); + text-transform: uppercase; + padding-block: 0 !important; +} + +.admonition .admonition-title::before { + background-color: var(--color-admonition-heading) !important; + top: .1em; +} + +.admonition.attention, +.admonition.danger, +.admonition.error { + --color-admonition: var(--color-vinyl-red); +} + +.admonition.important, +.admonition.caution, +.admonition.warning { + --color-admonition: var(--color-vinyl-yellow); +} + +.admonition.tip, +.admonition.note, +.admonition.hint { + --color-admonition: var(--color-vinyl-blue); +} + +/* Code blocks */ + +.highlight { + background: light-dark(rgb(from var(--color-vinyl-yellow) r g b / 50%), var(--color-theme-main-variant-20)) !important; +} + +/* Tables */ + +table.docutils { + box-shadow: none; + border: 2px solid var(--color-table-border); +} + +/* Sponsors sidebar */ + +.sidebar-tree + div { + margin-top: calc(2 * var(--sidebar-tree-space-above)); + padding-inline: var(--sidebar-item-spacing-horizontal); + font-family: var(--font-stack--headings); + font-size: .8em; +} + +.sidebar-tree + div img { + margin-bottom: 1.5em; +} + +/* Layout */ + section { margin-bottom: 1.5rem; } .bottom-of-page * { display: inline; -} - +} \ No newline at end of file From 6b0ce5cbfb8119c818e22173c9dc7705ed6ff1a8 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Mar 2026 18:43:22 +0100 Subject: [PATCH 146/196] Reference the rst writing guide on the website --- doc/README.WRITING_RST.rst | 106 ++----------------------------------- 1 file changed, 3 insertions(+), 103 deletions(-) diff --git a/doc/README.WRITING_RST.rst b/doc/README.WRITING_RST.rst index f65ca25909..0e8b925215 100644 --- a/doc/README.WRITING_RST.rst +++ b/doc/README.WRITING_RST.rst @@ -1,107 +1,7 @@ -.. - Copyright 2015,2016,2019,2024 UPLEX - Nils Goroll Systemoptimierung - SPDX-License-Identifier: BSD-2-Clause - See LICENSE file for full text of license - THINGS TO CONSIDER WHEN WRITING VINYL CACHE RST DOCUMENTATION ============================================================= -Inline Markup -------------- - -Please try to be consistent with inline markup and fix places which do -not follow the style: - -* VCL language and other literals as ``literal`` - -* placeholders and emphasis as *emphasis* - -* no `interpreted text` except where it actually *is* that - -.. _Reference: http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#character-level-inline-markup - - * exception: Links to manpages outside vinyl as `man(section)` - -* use code blocks for:: - - Examples and - - other code - -References are tricky ---------------------- - -To build html documentation, we want to create cross-document -cross-references using:: - - :ref:`reference name` - -Trouble is that ``rst2man`` and ``rst2pdf`` working on individual -files cannot parse `ref` roles to anything outside the current rst -file, so we need to differentiate link targets depending on the kind -of documentation: - -* set link targets on the top of documents ending up in man-pages - following the manpage naming scheme, e.g.:: - - .. _vinyld(1): - -* set link targets for important paragraphs following the scheme - ref-`doc`-`section`, for instance:: - - .. _ref-vinyld-opt_T: - - These can be referenced from other documents making up the html - documentation, but not from stand-alone documents (like man-pages). - -* in all documents which are used to create man-pages, add the - following definition at the top:: - - .. role:: ref(emphasis) - - This will allow the use of `ref` in a compatible manner, IF - references follow the man-page naming scheme - -* to be compatible both with ``sphinx`` and ``rst2man``, use `implicit - link targets`_ in stand-alone documents, like this one creating - `References are tricky`_:: - - `References are tricky`_ - -.. _implicit link targets: http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#implicit-hyperlink-targets - -Document Structure ------------------- - -While RST supports a great deal of flexibility for adornments of -titles and section headers, we should adhere to a consistent style to -avoid breaking the document structure unintentionally. - -Within the Vinyl-Cache project, we should use these characters: - -* Over and underline ``=`` for document titles - -* Over and underline ``-`` for document subtitles - -* Underline ``=`` for sections - -* Underline ``-`` for subsection - -* Underline ``~`` for subsubsections - -This is in line with the example in -https://docutils.sourceforge.io/docs/user/rst/quickstart.html#sections - -HISTORY -======= - -This README was initially started by Nils Goroll. - -COPYRIGHT -========= - -This document is licensed under the same licence as Vinyl Cache -itself. See LICENCE for details. +Please read https://vinyl-cache.org/developer/writing_docs.html -* Copyright 2015,2016,2019,2024 UPLEX - Nils Goroll - Systemoptimierung +Note that the *Additional Considerations for the Website* do **not** apply for +the documentation herein. From afd27bf3e578d4303b4b9dafd6000ac4236db902 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sat, 14 Mar 2026 13:50:30 +0100 Subject: [PATCH 147/196] Link trac tickets to code.vinyl Yesterday, I imported a text only version of the scraped trac html into forgejo, see https://code.vinyl-cache.org/vinyl-cache/code.vinyl-cache.org/wiki/worklog%3A-20260313-imported-old-trac-tickets --- doc/changes.rst | 468 ++++++++++++++++++++++++------------------------ 1 file changed, 234 insertions(+), 234 deletions(-) diff --git a/doc/changes.rst b/doc/changes.rst index 07a9242eac..9aea3c0c65 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -4334,9 +4334,9 @@ Bugs fixed * 1863_ - Don't reset the oc->ban pointer from BAN_CheckObject * 1864_ - Avoid panic if the lurker is working on a ban to be checked. -.. _1860: https://www.varnish-cache.org/trac/ticket/1860 -.. _1863: https://www.varnish-cache.org/trac/ticket/1863 -.. _1864: https://www.varnish-cache.org/trac/ticket/1864 +.. _1860: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1860 +.. _1863: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1863 +.. _1864: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1864 ====================================== @@ -4356,7 +4356,7 @@ Bugs fixed * 1858_ - Hit-for-pass objects are not IMS candidates -.. _1858: https://www.varnish-cache.org/trac/ticket/1858 +.. _1858: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1858 ====================================== Varnish Cache 4.1.2-beta1 (2016-02-17) @@ -4388,15 +4388,15 @@ Bugs fixed * 1852_ - Add a missing VDP flush operation after ESI:includes. * 1857_ - Fix timeout calculation for session herding. -.. _1739: https://www.varnish-cache.org/trac/ticket/1739 -.. _1837: https://www.varnish-cache.org/trac/ticket/1837 -.. _1841: https://www.varnish-cache.org/trac/ticket/1841 -.. _1843: https://www.varnish-cache.org/trac/ticket/1843 -.. _1844: https://www.varnish-cache.org/trac/ticket/1844 -.. _1851: https://www.varnish-cache.org/trac/ticket/1851 -.. _1852: https://www.varnish-cache.org/trac/ticket/1852 -.. _1857: https://www.varnish-cache.org/trac/ticket/1857 -.. _1847: https://www.varnish-cache.org/trac/ticket/1847 +.. _1739: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1739 +.. _1837: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1837 +.. _1841: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1841 +.. _1843: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1843 +.. _1844: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1844 +.. _1851: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1851 +.. _1852: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1852 +.. _1857: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1857 +.. _1847: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1847 ================================ @@ -4421,10 +4421,10 @@ Bugs fixed * 1842_ - Handle missing waiting list gracefully. * 1845_ - Handle whitespace after floats in test fields -.. _1802: https://www.varnish-cache.org/trac/ticket/1802 -.. _1825: https://www.varnish-cache.org/trac/ticket/1825 -.. _1842: https://www.varnish-cache.org/trac/ticket/1842 -.. _1845: https://www.varnish-cache.org/trac/ticket/1845 +.. _1802: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1802 +.. _1825: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1825 +.. _1842: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1842 +.. _1845: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1845 ====================================== @@ -4463,21 +4463,21 @@ Bugs fixed - 1804_ - Log proxy related messages on the session, not on the request. - 1801_ - Relax IP constant parsing -.. _1796: https://www.varnish-cache.org/trac/ticket/1796 -.. _1794: https://www.varnish-cache.org/trac/ticket/1794 -.. _1763: https://www.varnish-cache.org/trac/ticket/1763 -.. _1788: https://www.varnish-cache.org/trac/ticket/1788 -.. _1798: https://www.varnish-cache.org/trac/ticket/1798 -.. _1816: https://www.varnish-cache.org/trac/ticket/1816 -.. _1818: https://www.varnish-cache.org/trac/ticket/1818 -.. _1821: https://www.varnish-cache.org/trac/ticket/1821 -.. _1823: https://www.varnish-cache.org/trac/ticket/1823 -.. _1826: https://www.varnish-cache.org/trac/ticket/1826 -.. _1813: https://www.varnish-cache.org/trac/ticket/1813 -.. _1810: https://www.varnish-cache.org/trac/ticket/1810 -.. _1807: https://www.varnish-cache.org/trac/ticket/1807 -.. _1804: https://www.varnish-cache.org/trac/ticket/1804 -.. _1801: https://www.varnish-cache.org/trac/ticket/1801 +.. _1796: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1796 +.. _1794: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1794 +.. _1763: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1763 +.. _1788: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1788 +.. _1798: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1798 +.. _1816: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1816 +.. _1818: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1818 +.. _1821: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1821 +.. _1823: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1823 +.. _1826: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1826 +.. _1813: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1813 +.. _1810: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1810 +.. _1807: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1807 +.. _1804: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1804 +.. _1801: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1801 ================================ @@ -4489,7 +4489,7 @@ Varnish Cache 4.1.0 (2015-09-30) - Avoid compiler warning in zlib. - Bug 1792_: Avoid using fallocate() with -sfile on non-EXT4. -.. _1792: https://www.varnish-cache.org/trac/ticket/1792 +.. _1792: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1792 ====================================== @@ -4512,10 +4512,10 @@ Bugs fixed - 1781_ - Propagate gzip CRC upwards from nested ESI includes. - 1783_ - Align code with RFC7230 section 3.3.3 which allows POST without a body. -.. _1777: https://www.varnish-cache.org/trac/ticket/1777 -.. _1778: https://www.varnish-cache.org/trac/ticket/1778 -.. _1781: https://www.varnish-cache.org/trac/ticket/1781 -.. _1783: https://www.varnish-cache.org/trac/ticket/1783 +.. _1777: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1777 +.. _1778: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1778 +.. _1781: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1781 +.. _1783: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1783 ==================================== @@ -4547,11 +4547,11 @@ Bugs fixed - 1665_ - Be more accurate when computing client RX_TIMEOUT. - 1672_ - Do not panic on unsolicited 304 response to non-200 bereq. -.. _1462: https://www.varnish-cache.org/trac/ticket/1462 -.. _1539: https://www.varnish-cache.org/trac/ticket/1539 -.. _1637: https://www.varnish-cache.org/trac/ticket/1637 -.. _1665: https://www.varnish-cache.org/trac/ticket/1665 -.. _1672: https://www.varnish-cache.org/trac/ticket/1672 +.. _1462: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1462 +.. _1539: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1539 +.. _1637: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1637 +.. _1665: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1665 +.. _1672: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1672 ================================================ @@ -4571,14 +4571,14 @@ Bugs fixed - 1629_ - Ditch rest of waiting list on failure to reschedule. - 1660_ - Don't attempt range delivery on a synth response -.. _1479: https://www.varnish-cache.org/trac/ticket/1479 -.. _1566: https://www.varnish-cache.org/trac/ticket/1578 -.. _1616: https://www.varnish-cache.org/trac/ticket/1616 -.. _1620: https://www.varnish-cache.org/trac/ticket/1620 -.. _1621: https://www.varnish-cache.org/trac/ticket/1621 -.. _1628: https://www.varnish-cache.org/trac/ticket/1628 -.. _1629: https://www.varnish-cache.org/trac/ticket/1629 -.. _1660: https://www.varnish-cache.org/trac/ticket/1660 +.. _1479: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1479 +.. _1566: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1578 +.. _1616: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1616 +.. _1620: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1620 +.. _1621: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1621 +.. _1628: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1628 +.. _1629: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1629 +.. _1660: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1660 ============================================ @@ -4614,21 +4614,21 @@ Bugs fixed * 1648_ - Avoid partial IMS updates to replace old object. * 1650_ - Collapse multiple X-Forwarded-For headers -.. _1349: https://www.varnish-cache.org/trac/ticket/1349 -.. _1378: https://www.varnish-cache.org/trac/ticket/1378 -.. _1596: https://www.varnish-cache.org/trac/ticket/1596 -.. _1506: https://www.varnish-cache.org/trac/ticket/1506 -.. _1602: https://www.varnish-cache.org/trac/ticket/1602 -.. _1607: https://www.varnish-cache.org/trac/ticket/1607 -.. _1610: https://www.varnish-cache.org/trac/ticket/1610 -.. _1612: https://www.varnish-cache.org/trac/ticket/1612 -.. _1623: https://www.varnish-cache.org/trac/ticket/1623 -.. _1636: https://www.varnish-cache.org/trac/ticket/1636 -.. _1638: https://www.varnish-cache.org/trac/ticket/1638 -.. _1639: https://www.varnish-cache.org/trac/ticket/1639 -.. _1647: https://www.varnish-cache.org/trac/ticket/1647 -.. _1648: https://www.varnish-cache.org/trac/ticket/1648 -.. _1650: https://www.varnish-cache.org/trac/ticket/1650 +.. _1349: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1349 +.. _1378: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1378 +.. _1596: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1596 +.. _1506: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1506 +.. _1602: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1602 +.. _1607: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1607 +.. _1610: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1610 +.. _1612: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1612 +.. _1623: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1623 +.. _1636: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1636 +.. _1638: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1638 +.. _1639: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1639 +.. _1647: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1647 +.. _1648: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1648 +.. _1650: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1650 ============================================ @@ -4704,38 +4704,38 @@ Bugs fixed * 1532_ - Use correct VCL representation of reals. * 1531_ - Work around libedit bug in varnishadm. -.. _1553: https://www.varnish-cache.org/trac/ticket/1553 -.. _1551: https://www.varnish-cache.org/trac/ticket/1551 -.. _1591: https://www.varnish-cache.org/trac/ticket/1591 -.. _1592: https://www.varnish-cache.org/trac/ticket/1592 -.. _1538: https://www.varnish-cache.org/trac/ticket/1538 -.. _1584: https://www.varnish-cache.org/trac/ticket/1584 -.. _1407: https://www.varnish-cache.org/trac/ticket/1407 -.. _1466: https://www.varnish-cache.org/trac/ticket/1466 -.. _1580: https://www.varnish-cache.org/trac/ticket/1580 -.. _1583: https://www.varnish-cache.org/trac/ticket/1583 -.. _1585: https://www.varnish-cache.org/trac/ticket/1585 -.. _1572: https://www.varnish-cache.org/trac/ticket/1572 -.. _1569: https://www.varnish-cache.org/trac/ticket/1569 -.. _1579: https://www.varnish-cache.org/trac/ticket/1579 -.. _1578: https://www.varnish-cache.org/trac/ticket/1578 -.. _1574: https://www.varnish-cache.org/trac/ticket/1574 -.. _1555: https://www.varnish-cache.org/trac/ticket/1555 -.. _1568: https://www.varnish-cache.org/trac/ticket/1568 -.. _1567: https://www.varnish-cache.org/trac/ticket/1567 -.. _1512: https://www.varnish-cache.org/trac/ticket/1512 -.. _1563: https://www.varnish-cache.org/trac/ticket/1563 -.. _1561: https://www.varnish-cache.org/trac/ticket/1561 -.. _1562: https://www.varnish-cache.org/trac/ticket/1562 -.. _1521: https://www.varnish-cache.org/trac/ticket/1521 -.. _1547: https://www.varnish-cache.org/trac/ticket/1547 -.. _1503: https://www.varnish-cache.org/trac/ticket/1503 -.. _1581: https://www.varnish-cache.org/trac/ticket/1581 -.. _1588: https://www.varnish-cache.org/trac/ticket/1588 -.. _1575: https://www.varnish-cache.org/trac/ticket/1575 -.. _1577: https://www.varnish-cache.org/trac/ticket/1577 -.. _1532: https://www.varnish-cache.org/trac/ticket/1532 -.. _1531: https://www.varnish-cache.org/trac/ticket/1531 +.. _1553: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1553 +.. _1551: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1551 +.. _1591: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1591 +.. _1592: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1592 +.. _1538: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1538 +.. _1584: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1584 +.. _1407: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1407 +.. _1466: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1466 +.. _1580: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1580 +.. _1583: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1583 +.. _1585: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1585 +.. _1572: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1572 +.. _1569: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1569 +.. _1579: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1579 +.. _1578: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1578 +.. _1574: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1574 +.. _1555: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1555 +.. _1568: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1568 +.. _1567: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1567 +.. _1512: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1512 +.. _1563: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1563 +.. _1561: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1561 +.. _1562: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1562 +.. _1521: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1521 +.. _1547: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1547 +.. _1503: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1503 +.. _1581: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1581 +.. _1588: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1588 +.. _1575: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1575 +.. _1577: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1577 +.. _1532: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1532 +.. _1531: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1531 ======================================== @@ -4798,32 +4798,32 @@ Bugs fixed * 1519_ - Round-robin director does not support weight. [docs] -.. _1269: https://www.varnish-cache.org/trac/ticket/1269 -.. _1524: https://www.varnish-cache.org/trac/ticket/1524 -.. _1530: https://www.varnish-cache.org/trac/ticket/1530 -.. _1475: https://www.varnish-cache.org/trac/ticket/1475 -.. _1480: https://www.varnish-cache.org/trac/ticket/1480 -.. _1482: https://www.varnish-cache.org/trac/ticket/1482 -.. _1473: https://www.varnish-cache.org/trac/ticket/1473 -.. _1486: https://www.varnish-cache.org/trac/ticket/1486 -.. _1488: https://www.varnish-cache.org/trac/ticket/1488 -.. _1489: https://www.varnish-cache.org/trac/ticket/1489 -.. _1490: https://www.varnish-cache.org/trac/ticket/1490 -.. _1491: https://www.varnish-cache.org/trac/ticket/1491 -.. _1498: https://www.varnish-cache.org/trac/ticket/1498 -.. _1499: https://www.varnish-cache.org/trac/ticket/1499 -.. _1493: https://www.varnish-cache.org/trac/ticket/1493 -.. _1476: https://www.varnish-cache.org/trac/ticket/1476 -.. _1496: https://www.varnish-cache.org/trac/ticket/1496 -.. _1494: https://www.varnish-cache.org/trac/ticket/1494 -.. _1139: https://www.varnish-cache.org/trac/ticket/1139 -.. _1478: https://www.varnish-cache.org/trac/ticket/1478 -.. _1504: https://www.varnish-cache.org/trac/ticket/1504 -.. _1501: https://www.varnish-cache.org/trac/ticket/1501 -.. _1495: https://www.varnish-cache.org/trac/ticket/1495 -.. _1510: https://www.varnish-cache.org/trac/ticket/1510 -.. _1518: https://www.varnish-cache.org/trac/ticket/1518 -.. _1519: https://www.varnish-cache.org/trac/ticket/1519 +.. _1269: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1269 +.. _1524: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1524 +.. _1530: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1530 +.. _1475: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1475 +.. _1480: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1480 +.. _1482: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1482 +.. _1473: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1473 +.. _1486: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1486 +.. _1488: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1488 +.. _1489: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1489 +.. _1490: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1490 +.. _1491: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1491 +.. _1498: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1498 +.. _1499: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1499 +.. _1493: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1493 +.. _1476: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1476 +.. _1496: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1496 +.. _1494: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1494 +.. _1139: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1139 +.. _1478: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1478 +.. _1504: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1504 +.. _1501: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1501 +.. _1495: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1495 +.. _1510: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1510 +.. _1518: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1518 +.. _1519: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1519 ============================================== @@ -4846,10 +4846,10 @@ Bugs fixed * 1467_ - Fix missing clearing of oc->busyobj on HSH_Fail. -.. _1469: https://www.varnish-cache.org/trac/ticket/1469 -.. _1468: https://www.varnish-cache.org/trac/ticket/1468 -.. _1462: https://www.varnish-cache.org/trac/ticket/1462 -.. _1467: https://www.varnish-cache.org/trac/ticket/1467 +.. _1469: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1469 +.. _1468: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1468 +.. _1462: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1462 +.. _1467: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1467 ================================================== @@ -4895,19 +4895,19 @@ Bugs fixed * 1419_ - Don't put objcores on the ban list until they go non-BUSY. * 1405_ - Ban lurker does not always evict all objects. -.. _1460: https://www.varnish-cache.org/trac/ticket/1460 -.. _1450: https://www.varnish-cache.org/trac/ticket/1450 -.. _1320: https://www.varnish-cache.org/trac/ticket/1320 -.. _1458: https://www.varnish-cache.org/trac/ticket/1458 -.. _1417: https://www.varnish-cache.org/trac/ticket/1417 -.. _1455: https://www.varnish-cache.org/trac/ticket/1455 -.. _1454: https://www.varnish-cache.org/trac/ticket/1454 -.. _1436: https://www.varnish-cache.org/trac/ticket/1436 -.. _1440: https://www.varnish-cache.org/trac/ticket/1440 -.. _1441: https://www.varnish-cache.org/trac/ticket/1441 -.. _1434: https://www.varnish-cache.org/trac/ticket/1434 -.. _1419: https://www.varnish-cache.org/trac/ticket/1419 -.. _1405: https://www.varnish-cache.org/trac/ticket/1405 +.. _1460: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1460 +.. _1450: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1450 +.. _1320: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1320 +.. _1458: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1458 +.. _1417: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1417 +.. _1455: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1455 +.. _1454: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1454 +.. _1436: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1436 +.. _1440: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1440 +.. _1441: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1441 +.. _1434: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1434 +.. _1419: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1419 +.. _1405: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1405 ================================================ @@ -4947,21 +4947,21 @@ Open issues * 1405_ - Ban lurker does not always evict all objects. -.. _1405: https://www.varnish-cache.org/trac/ticket/1405 -.. _1404: https://www.varnish-cache.org/trac/ticket/1404 -.. _1401: https://www.varnish-cache.org/trac/ticket/1401 -.. _1399: https://www.varnish-cache.org/trac/ticket/1399 -.. _1398: https://www.varnish-cache.org/trac/ticket/1398 -.. _1397: https://www.varnish-cache.org/trac/ticket/1397 -.. _1395: https://www.varnish-cache.org/trac/ticket/1395 -.. _1391: https://www.varnish-cache.org/trac/ticket/1391 -.. _1390: https://www.varnish-cache.org/trac/ticket/1390 -.. _1385: https://www.varnish-cache.org/trac/ticket/1385 -.. _1383: https://www.varnish-cache.org/trac/ticket/1383 -.. _1382: https://www.varnish-cache.org/trac/ticket/1382 -.. _1381: https://www.varnish-cache.org/trac/ticket/1381 -.. _1323: https://www.varnish-cache.org/trac/ticket/1323 -.. _1268: https://www.varnish-cache.org/trac/ticket/1268 +.. _1405: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1405 +.. _1404: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1404 +.. _1401: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1401 +.. _1399: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1399 +.. _1398: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1398 +.. _1397: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1397 +.. _1395: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1395 +.. _1391: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1391 +.. _1390: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1390 +.. _1385: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1385 +.. _1383: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1383 +.. _1382: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1382 +.. _1381: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1381 +.. _1323: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1323 +.. _1268: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1268 ============================================ @@ -4992,8 +4992,8 @@ Changes from 3.0.6 to 3.0.7-rc1 (2015-03-18) - Avoid memory leak when adding bans. -.. _1627: http://varnish-cache.org/trac/ticket/1627 -.. _1690: http://varnish-cache.org/trac/ticket/1690 +.. _1627: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1627 +.. _1690: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1690 =========================================== @@ -5019,13 +5019,13 @@ Changes from 3.0.5 to 3.0.6rc1 (2014-06-24) - Stop handling gzip after gzip body end. Bug 1086_. - Document %D and %T for varnishncsa. -.. _1514: https://www.varnish-cache.org/trac/ticket/1514 -.. _1327: https://www.varnish-cache.org/trac/ticket/1327 -.. _1297: https://www.varnish-cache.org/trac/ticket/1297 -.. _1470: https://www.varnish-cache.org/trac/ticket/1470 -.. _1448: https://www.varnish-cache.org/trac/ticket/1448 -.. _1439: https://www.varnish-cache.org/trac/ticket/1439 -.. _1086: https://www.varnish-cache.org/trac/ticket/1086 +.. _1514: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1514 +.. _1327: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1327 +.. _1297: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1297 +.. _1470: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1470 +.. _1448: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1448 +.. _1439: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1439 +.. _1086: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1086 ============================================= @@ -5038,7 +5038,7 @@ varnishd - Always check the local address of a socket. This avoids a crash if server.ip is accessed after a client has closed the connection. `Bug #1376` -.. _bug #1376: https://www.varnish-cache.org/trac/ticket/1376 +.. _bug #1376: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1376 ================================ @@ -5058,9 +5058,9 @@ varnishd and things would go downhill from there. `Bug #1367` - Prettify backtraces on panic slightly. -.. _bug #1287: https://www.varnish-cache.org/trac/ticket/1287 -.. _bug #1272: https://www.varnish-cache.org/trac/ticket/1272 -.. _bug #1367: https://www.varnish-cache.org/trac/ticket/1367 +.. _bug #1287: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1287 +.. _bug #1272: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1272 +.. _bug #1367: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1367 varnishlog ---------- @@ -5069,14 +5069,14 @@ varnishlog to lack of matches. Also, emit BackendXID to signify the start of a transaction. `Bug #1325` -.. _bug #1325: https://www.varnish-cache.org/trac/ticket/1325 +.. _bug #1325: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1325 varnishadm ---------- - Handle input from stdin properly. `Bug #1314` -.. _bug #1314: https://www.varnish-cache.org/trac/ticket/1314 +.. _bug #1314: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1314 ============================================= @@ -5092,8 +5092,8 @@ varnishd negatives. CVE-2013-4090. `Bug #1312` - Return an error if the client sends multiple Host headers. -.. _bug #1285: https://www.varnish-cache.org/trac/ticket/1285 -.. _bug #1312: https://www.varnish-cache.org/trac/ticket/1312 +.. _bug #1285: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1285 +.. _bug #1312: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1312 ================================ @@ -5113,11 +5113,11 @@ varnishd - Add support for banning on http.status. `Bug #1076` - Make hit-for-pass correctly prefer the transient storage. -.. _bug #1076: https://www.varnish-cache.org/trac/ticket/1076 -.. _bug #1184: https://www.varnish-cache.org/trac/ticket/1184 -.. _bug #1224: https://www.varnish-cache.org/trac/ticket/1224 -.. _bug #1261: https://www.varnish-cache.org/trac/ticket/1261 -.. _bug #1275: https://www.varnish-cache.org/trac/ticket/1275 +.. _bug #1076: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1076 +.. _bug #1184: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1184 +.. _bug #1224: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1224 +.. _bug #1261: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1261 +.. _bug #1275: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1275 varnishlog @@ -5126,7 +5126,7 @@ varnishlog - If -m, but neither -b or -c is given, assume both. This filters out a lot of noise when -m is used to filter. `Bug #1071` -.. _bug #1071: https://www.varnish-cache.org/trac/ticket/1071 +.. _bug #1071: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1071 varnishadm ---------- @@ -5214,26 +5214,26 @@ varnishd - Better error reporting for some fetch errors. - Small performance optimizations. -.. _bug #897: https://www.varnish-cache.org/trac/ticket/897 -.. _bug #1023: https://www.varnish-cache.org/trac/ticket/1023 -.. _bug #1029: https://www.varnish-cache.org/trac/ticket/1029 -.. _bug #1035: https://www.varnish-cache.org/trac/ticket/1035 -.. _bug #1037: https://www.varnish-cache.org/trac/ticket/1037 -.. _bug #1038: https://www.varnish-cache.org/trac/ticket/1038 -.. _bug #1043: https://www.varnish-cache.org/trac/ticket/1043 -.. _bug #1044: https://www.varnish-cache.org/trac/ticket/1044 -.. _bug #1047: https://www.varnish-cache.org/trac/ticket/1047 -.. _bug #1069: https://www.varnish-cache.org/trac/ticket/1069 -.. _bug #1073: https://www.varnish-cache.org/trac/ticket/1073 -.. _bug #1080: https://www.varnish-cache.org/trac/ticket/1080 -.. _bug #1091: https://www.varnish-cache.org/trac/ticket/1091 -.. _bug #1092: https://www.varnish-cache.org/trac/ticket/1092 -.. _bug #1100: https://www.varnish-cache.org/trac/ticket/1100 -.. _bug #1104: https://www.varnish-cache.org/trac/ticket/1104 -.. _bug #1109: https://www.varnish-cache.org/trac/ticket/1109 -.. _bug #1125: https://www.varnish-cache.org/trac/ticket/1125 -.. _bug #1126: https://www.varnish-cache.org/trac/ticket/1126 -.. _bug #1140: https://www.varnish-cache.org/trac/ticket/1140 +.. _bug #897: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/897 +.. _bug #1023: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1023 +.. _bug #1029: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1029 +.. _bug #1035: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1035 +.. _bug #1037: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1037 +.. _bug #1038: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1038 +.. _bug #1043: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1043 +.. _bug #1044: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1044 +.. _bug #1047: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1047 +.. _bug #1069: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1069 +.. _bug #1073: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1073 +.. _bug #1080: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1080 +.. _bug #1091: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1091 +.. _bug #1092: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1092 +.. _bug #1100: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1100 +.. _bug #1104: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1104 +.. _bug #1109: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1109 +.. _bug #1125: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1125 +.. _bug #1126: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1126 +.. _bug #1140: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1140 varnishncsa ----------- @@ -5250,7 +5250,7 @@ varnishtest - Make it possible to test for the absence of an HTTP header. `Bug #1062`_. - Log the full panic message instead of shortening it to 512 characters. -.. _bug #1062: https://www.varnish-cache.org/trac/ticket/1062 +.. _bug #1062: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1062 varnishstat ----------- @@ -5268,7 +5268,7 @@ Other - Fix build on FreeBSD 10-current. - Fix libedit detection on \*BSD OSes. `Bug #1003`_. -.. _bug #1003: https://www.varnish-cache.org/trac/ticket/1003 +.. _bug #1003: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1003 ============================================= @@ -5332,13 +5332,13 @@ varnishd - `http_req_size` and `http_resp_size` have been increased to 8192 bytes. This better matches what other HTTPds have. `Bug #1016`_. -.. _bug #994: https://www.varnish-cache.org/trac/ticket/994 -.. _bug #992: https://www.varnish-cache.org/trac/ticket/992 -.. _bug #996: https://www.varnish-cache.org/trac/ticket/996 -.. _bug #1007: https://www.varnish-cache.org/trac/ticket/1007 -.. _bug #1008: https://www.varnish-cache.org/trac/ticket/1008 -.. _bug #1012: https://www.varnish-cache.org/trac/ticket/1012 -.. _bug #1016: https://www.varnish-cache.org/trac/ticket/1016 +.. _bug #994: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/994 +.. _bug #992: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/992 +.. _bug #996: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/996 +.. _bug #1007: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1007 +.. _bug #1008: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1008 +.. _bug #1012: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1012 +.. _bug #1016: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/1016 VCL --- @@ -5425,8 +5425,8 @@ varnishd object from the same backend unless health probes were enabled. This has been fixed and it will now retry a different backend. -.. _bug #965: https://www.varnish-cache.org/trac/ticket/965 -.. _bug #963: https://www.varnish-cache.org/trac/ticket/963 +.. _bug #965: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/965 +.. _bug #963: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/963 VCL --- @@ -5437,7 +5437,7 @@ VCL - The VCL compiler would fault if two IP comparisons were done on the same line. This now works correctly. `Bug #948`_. -.. _bug #948: https://www.varnish-cache.org/trac/ticket/948 +.. _bug #948: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/948 varnishncsa ----------- @@ -5470,7 +5470,7 @@ Other - The ABI of VMODs are now checked. This will require a rebuild of all VMODs against the new version of Varnish. -.. _bug #961: https://www.varnish-cache.org/trac/ticket/961 +.. _bug #961: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/961 ============================================= @@ -5488,7 +5488,7 @@ VCL - The `synthetic` keyword has now been properly marked as only available in `vcl_deliver`. `Bug #936`_. -.. _bug #936: https://www.varnish-cache.org/trac/ticket/936 +.. _bug #936: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/936 varnishadm ---------- @@ -5498,7 +5498,7 @@ varnishadm - Always exit if `varnishadm` can't connect to the backend for any reason. -.. _bug #935: https://www.varnish-cache.org/trac/ticket/935 +.. _bug #935: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/935 ===================================== @@ -5520,7 +5520,7 @@ varnishd single-threaded so we do not want to do this work there in the first place. Use varnishstat instead. -.. _bug #908: https://www.varnish-cache.org/trac/ticket/908 +.. _bug #908: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/908 VCL --- @@ -5539,7 +5539,7 @@ VCL - Varnish is now stricter in enforcing no duplication of probes, backends and ACLs. -.. _bug #913: https://www.varnish-cache.org/trac/ticket/913 +.. _bug #913: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/913 varnishncsa ----------- @@ -5642,11 +5642,11 @@ varnishd administrator errors when specifying the size of storage where the admin might have forgotten to specify units. -.. _bug #693: https://www.varnish-cache.org/trac/ticket/693 -.. _bug #683: https://www.varnish-cache.org/trac/ticket/683 -.. _bug #663: https://www.varnish-cache.org/trac/ticket/663 -.. _bug #880: https://www.varnish-cache.org/trac/ticket/880 -.. _bug #411: https://www.varnish-cache.org/trac/ticket/411 +.. _bug #693: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/693 +.. _bug #683: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/683 +.. _bug #663: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/663 +.. _bug #880: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/880 +.. _bug #411: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/411 Tools ----- @@ -5668,7 +5668,7 @@ varnishadm shared memory log file - add libedit support -.. _bug #875: https://www.varnish-cache.org/trac/ticket/875 +.. _bug #875: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/875 varnishstat *********** @@ -5688,8 +5688,8 @@ varnishncsa log formats are supported, as well as some Varnish-specific ones. See the documentation for further information. `Bug #712`_ and `bug #485`_ -.. _bug #712: https://www.varnish-cache.org/trac/ticket/712 -.. _bug #485: https://www.varnish-cache.org/trac/ticket/485 +.. _bug #712: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/712 +.. _bug #485: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/485 varnishtest *********** @@ -5764,9 +5764,9 @@ VCL - Add actual purge support. Doing ``purge`` will remove an object and all its variants. -.. _bug #481: https://www.varnish-cache.org/trac/ticket/481 -.. _bug #787: https://www.varnish-cache.org/trac/ticket/787 -.. _bug #782: https://www.varnish-cache.org/trac/ticket/782 +.. _bug #481: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/481 +.. _bug #787: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/787 +.. _bug #782: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/782 Libraries @@ -6751,18 +6751,18 @@ varnishd - When switching to a new VCL configuration, a race condition exists which may cause Varnish to reference a backend which no longer exists - (see `ticket #144 `_). + (see `ticket #144 `_). This race condition has not been entirely eliminated, but it should occur less frequently. - When dropping a TCP session before any requests were processed, an assertion would be triggered due to an uninitialized timestamp (see - `ticket #132 `_). The + `ticket #132 `_). The timestamp is now correctly initialized. - Varnish will now correctly generate a Date: header for every response instead of copying the one it got from the backend (see `ticket - #157 `_). + #157 `_). - Comparisons in VCL which involve a nonexistent string (usually a header which is not present in the request or object being processed) @@ -6779,7 +6779,7 @@ varnishd end up with a reference to an address structure which no longer exists, resulting in a crash. This race condition has been somewhat mitigated, but not entirely eliminated (see `ticket - #144 `_.) + #144 `_.) - Varnish will now pass the correct protocol version in pipe mode: the backend will get what the client sent, and vice versa. @@ -6797,12 +6797,12 @@ varnishd serviced, resulting in a assertion failure and a crash when the worker thread later tried to delete the session. This should no longer happen (see `ticket - #162 `_.) + #162 `_.) - A mismatch between the recorded length of a cached object and the amount of data actually present in cache for that object can occasionally occur (see `ticket - #167 `_.) This has been + #167 `_.) This has been partially fixed, but may still occur for error pages generated by Varnish when a problem arises while retrieving an object from the backend. @@ -7105,7 +7105,7 @@ varnishd new VCL hooks have been added, though they aren't much use yet. The only real user-visible change should be that Varnish now handles persistent backend connections correctly (see `ticket - #56 `_). + #56 `_). - Support for multiple listen addresses has been added. @@ -7181,7 +7181,7 @@ varnishlog corresponding return from VCL. When two VCL calls were made in succession, varnishlog would incorrectly omit the newline between the two calls (see `ticket - #95 `_). + #95 `_). - New -D and -P command-line options have been added to daemonize and create a pidfile, respectively. From 9d9a83be5204fd66c9316ff48ec26feb1ae46d9a Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sat, 14 Mar 2026 13:54:32 +0100 Subject: [PATCH 148/196] Manually update/delete two more varnish-cache.org links --- doc/changes.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/doc/changes.rst b/doc/changes.rst index 9aea3c0c65..2f5c8de2fb 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -4757,7 +4757,7 @@ New since 4.0.0: - fallback director is now documented. - %D format flag in varnishncsa is now truncated to an integer value. - persistent storage backend is now deprecated. - https://www.varnish-cache.org/docs/trunk/phk/persistent.html + https://vinyl-cache.org/docs/trunk/phk/persistent.html - Added format flags %I (total bytes received) and %O (total bytes sent) for varnishncsa. - python-docutils >= 0.6 is now required. @@ -6640,8 +6640,7 @@ varnishd to POST. - Change how backends are defined, to a constant structural definition - style. See https://www.varnish-cache.org/wiki/VclSyntaxChanges - for the details. + style. - Add directors, which wrap backends. Currently, there's a random director and a round-robin director. From 29b8f3f2cd82f3004c527f6e4960edaa4ecf9e69 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 15 Mar 2026 15:08:35 +0100 Subject: [PATCH 149/196] docs: fix two cases where "vinyl Cache" was used as a directory name One case was only a comment --- doc/sphinx/installation/install_source.rst | 2 +- doc/sphinx/users-guide/troubleshooting.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/sphinx/installation/install_source.rst b/doc/sphinx/installation/install_source.rst index cafd8fe13a..42dcded507 100644 --- a/doc/sphinx/installation/install_source.rst +++ b/doc/sphinx/installation/install_source.rst @@ -92,7 +92,7 @@ Then continue `Compiling Vinyl Cache`_ Build dependencies on Red Hat / CentOS -------------------------------------- -.. gawk '/^BuildRequires/ {print "* `" $2 "`"}' ../../../redhat/vinyl Cache.spec | sort | uniq | egrep -v '(systemd)' +.. gawk '/^BuildRequires/ {print "* `" $2 "`"}' ../../../redhat/vinyl-cache.spec | sort | uniq | egrep -v '(systemd)' in the following shell commands, replace ``sudo yum install`` if needed. diff --git a/doc/sphinx/users-guide/troubleshooting.rst b/doc/sphinx/users-guide/troubleshooting.rst index 5cd8d34b2d..1a908fe166 100644 --- a/doc/sphinx/users-guide/troubleshooting.rst +++ b/doc/sphinx/users-guide/troubleshooting.rst @@ -136,7 +136,7 @@ trace of the thread that caused the segfault. A basic debug session for vinyl Cache installed under ``/usr/local`` could look like this:: - $ cd /usr/local/var/vinyl Cache/`uname -n`/ + $ cd /usr/local/var/vinyl-cache/`uname -n`/ $ gdb /usr/local/sbin/vinyld core GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. From 43dcc6f024a8a2bd6bc6f2970046c08859e17749 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 15 Mar 2026 15:02:36 +0100 Subject: [PATCH 150/196] Use ${localstatedir}/vinyl-cache for VINYL_STATE_DIR ... unless localstatedir is /var, and only create it if used Closes #4475 --- Makefile.am | 5 +++-- configure.ac | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index 5523eeb633..673f06cf93 100644 --- a/Makefile.am +++ b/Makefile.am @@ -44,8 +44,9 @@ AM_DISTCHECK_CONFIGURE_FLAGS += --with-unwind endif install-data-local: - $(install_sh) -d -m 0755 $(DESTDIR)$(localstatedir)/vinyl - + if test "${VINYL_STATE_DIR}" = "$(DESTDIR)$(localstatedir)/vinyl-cache" ; then \ + $(install_sh) -d -m 0755 "${VINYL_STATE_DIR}"; \ + fi distclean-local: -find . '(' -name '*.gcda' -o -name '*.gcda' ')' -exec rm '{}' ';' diff --git a/configure.ac b/configure.ac index 0aa8e8f01f..4a5a5d1892 100644 --- a/configure.ac +++ b/configure.ac @@ -643,7 +643,7 @@ fi if test "${localstatedir}" = '${prefix}/var' ; then VINYL_STATE_DIR='/var/run' else - VINYL_STATE_DIR='${localstatedir}/vinyl' + VINYL_STATE_DIR='${localstatedir}/vinyl-cache' fi AC_SUBST(VINYL_STATE_DIR) From 7ef459c51f07c86a2d5c71bace9a2f63e4e70adf Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 15 Mar 2026 17:00:32 +0100 Subject: [PATCH 151/196] fix VINYL_LIBRARY_PATH --- vinyl.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vinyl.m4 b/vinyl.m4 index 53d2bee9f3..fde7ab4902 100644 --- a/vinyl.m4 +++ b/vinyl.m4 @@ -84,7 +84,7 @@ AC_DEFUN([_VINYL_PKG_CONFIG], [ PKG_CHECK_VAR([VSCTOOL], [vinylapi], [vsctool]) AC_SUBST([VINYL_LIBRARY_PATH], - [$VINYLAPI_LIBDIR:$VINYLAPI_LIBDIR/vinyl]) + [$VINYLAPI_LIBDIR:$VINYLAPI_LIBDIR/vinyl-cache]) AC_SUBST([VINYL_TEST_PATH], [$VINYLAPI_SBINDIR:$VINYLAPI_BINDIR:$PATH]) From 6c29dd42fc541df1b8c14980735d5f9b3dc4b327 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 15 Mar 2026 16:53:22 +0100 Subject: [PATCH 152/196] Search for vcls in /etc/vinyl-cache not /etc/vinyl ... for a default sysconfdir=/etc I had already adjusted the vinyld -x parameter output in 539b11f7a9335fb10e6ff944ef1105443473e38c but overlooked that the default was set differently than I thought. Also fix related docs Similar case as #4475 --- configure.ac | 2 +- doc/sphinx/reference/vcl.rst | 2 +- doc/sphinx/reference/vinyld.rst | 10 +++++----- doc/sphinx/tutorial/backend_servers.rst | 4 ++-- doc/sphinx/tutorial/peculiarities.rst | 2 +- doc/sphinx/tutorial/putting_vinyl_on_port_80.rst | 10 +++++----- doc/sphinx/tutorial/starting_vinyl.rst | 2 +- doc/sphinx/users-guide/run_security.rst | 2 +- vinyl.m4 | 2 +- 9 files changed, 18 insertions(+), 18 deletions(-) diff --git a/configure.ac b/configure.ac index 4a5a5d1892..26cb1b698b 100644 --- a/configure.ac +++ b/configure.ac @@ -648,7 +648,7 @@ fi AC_SUBST(VINYL_STATE_DIR) # Default configuration directory. -pkgsysconfdir='${sysconfdir}/vinyl' +pkgsysconfdir='${sysconfdir}/vinyl-cache' AC_SUBST(pkgsysconfdir) # VMOD variables diff --git a/doc/sphinx/reference/vcl.rst b/doc/sphinx/reference/vcl.rst index 91fcbf9c79..8f02c8994c 100644 --- a/doc/sphinx/reference/vcl.rst +++ b/doc/sphinx/reference/vcl.rst @@ -275,7 +275,7 @@ The included file can be specified as follows: Optionally, the ``include`` keyword can take a ``+glob`` flag to include all files matching a glob pattern:: - include +glob "/etc/vinyl/example.org/*.vcl"; + include +glob "/etc/vinyl-cache/example.org/*.vcl"; Note that the ``+glob`` option can only be used with absolute paths and relative paths starting with './', which means that ``+glob`` includes cannot diff --git a/doc/sphinx/reference/vinyld.rst b/doc/sphinx/reference/vinyld.rst index e8bad3f076..f02e39a334 100644 --- a/doc/sphinx/reference/vinyld.rst +++ b/doc/sphinx/reference/vinyld.rst @@ -567,14 +567,14 @@ particular, this is the way to load configurations, apply labels to them, and make a VCL instance active that uses those labels on startup:: - vcl.load panic /etc/vinyl_panic.vcl - vcl.load siteA0 /etc/vinyl_siteA.vcl - vcl.load siteB0 /etc/vinyl_siteB.vcl - vcl.load siteC0 /etc/vinyl_siteC.vcl + vcl.load panic /etc/vinyl-cache/panic.vcl + vcl.load siteA0 /etc/vinyl-cache/siteA.vcl + vcl.load siteB0 /etc/vinyl-cache/siteB.vcl + vcl.load siteC0 /etc/vinyl-cache/siteC.vcl vcl.label siteA siteA0 vcl.label siteB siteB0 vcl.label siteC siteC0 - vcl.load main /etc/vinyl_main.vcl + vcl.load main /etc/vinyl-cache/main.vcl vcl.use main Every line in the file, including the last line, must be terminated by diff --git a/doc/sphinx/tutorial/backend_servers.rst b/doc/sphinx/tutorial/backend_servers.rst index d0880960e6..ae4e558e85 100644 --- a/doc/sphinx/tutorial/backend_servers.rst +++ b/doc/sphinx/tutorial/backend_servers.rst @@ -14,8 +14,8 @@ server is the server providing the content Vinyl Cache will accelerate via the c Our first task is to tell Vinyl Cache where it can find its content. Start your favorite text editor and open the Vinyl Cache default configuration file. If you installed from source this is -`/usr/local/etc/vinyl/default.vcl`, if you installed from a package it -is probably `/etc/vinyl/default.vcl`. +`/usr/local/etc/vinyl-cache/default.vcl`, if you installed from a package it +is probably `/etc/vinyl-cache/default.vcl`. If you've been following the tutorial there is probably a section of the configuration that looks like this:: diff --git a/doc/sphinx/tutorial/peculiarities.rst b/doc/sphinx/tutorial/peculiarities.rst index 411a0271f6..f5a499cb41 100644 --- a/doc/sphinx/tutorial/peculiarities.rst +++ b/doc/sphinx/tutorial/peculiarities.rst @@ -29,7 +29,7 @@ handled. Vinyl Cache has an admin console. You can connect it through the :ref:`vinyladm(1)` command. In order to connect the user needs to be -able to read `/etc/vinyl/secret` in order to authenticate. +able to read `/etc/vinyl-cache/secret` in order to authenticate. Once you've started the console you can do quite a few operations on ``vinyld``, like stopping and starting the cache process, load VCL, diff --git a/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst b/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst index 22a2aad11f..704ab8557b 100644 --- a/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst +++ b/doc/sphinx/tutorial/putting_vinyl_on_port_80.rst @@ -22,16 +22,16 @@ some text that looks like this:: DAEMON_OPTS="-a :6081 \ -T localhost:6082 \ - -f /etc/vinyl/default.vcl \ - -S /etc/vinyl/secret \ + -f /etc/vinyl-cache/default.vcl \ + -S /etc/vinyl-cache/secret \ -s default,256m" Change it to:: DAEMON_OPTS="-a :80 \ -T localhost:6082 \ - -f /etc/vinyl/default.vcl \ - -S /etc/vinyl/secret \ + -f /etc/vinyl-cache/default.vcl \ + -S /etc/vinyl-cache/secret \ -s default,256m" Debian (v8+) / Ubuntu (v15.04+) @@ -45,7 +45,7 @@ Applying changes to the default service is best done by creating a new file [Service] ExecStart= - ExecStart=/usr/sbin/vinyld -a :80 -T localhost:6082 -f /etc/vinyl/default.vcl -S /etc/vinyl/secret -s default,256m + ExecStart=/usr/sbin/vinyld -a :80 -T localhost:6082 -f /etc/vinyl-cache/default.vcl -S /etc/vinyl-cache/secret -s default,256m This will override the ExecStart part of the default configuration shipped with Vinyl Cache. diff --git a/doc/sphinx/tutorial/starting_vinyl.rst b/doc/sphinx/tutorial/starting_vinyl.rst index 4f490b6300..df88f7d613 100644 --- a/doc/sphinx/tutorial/starting_vinyl.rst +++ b/doc/sphinx/tutorial/starting_vinyl.rst @@ -39,7 +39,7 @@ You might have a web application running on some other port or some other machine. Let's edit the configuration and make it point to something that actually works. -Fire up your favorite editor and edit `/etc/vinyl/default.vcl`. Most +Fire up your favorite editor and edit `/etc/vinyl-cache/default.vcl`. Most of it is commented out but there is some text that is not. It will probably look like this:: diff --git a/doc/sphinx/users-guide/run_security.rst b/doc/sphinx/users-guide/run_security.rst index 90662ceafc..5eb66d599d 100644 --- a/doc/sphinx/users-guide/run_security.rst +++ b/doc/sphinx/users-guide/run_security.rst @@ -123,7 +123,7 @@ it possible for (only!) these users to read it. A good way to create the secret file is:: - dd if=/dev/random of=/etc/vinyl_secret count=1 + dd if=/dev/random of=/etc/vinyl-cache/secret count=1 When you start :ref:`vinyld(1)`, you specify the filename with '-S', and it goes without saying that the :ref:`vinyld(1)` master process diff --git a/vinyl.m4 b/vinyl.m4 index fde7ab4902..2dbacd38f0 100644 --- a/vinyl.m4 +++ b/vinyl.m4 @@ -665,7 +665,7 @@ AC_DEFUN([VINYL_UTILITIES], [ # - pkgvcldir # # The vcldir is where Vinyl Cache will by default look up VCL files using relative -# paths not found in its sysconfdir (by default /etc/vinyl). The pkgvcldir on +# paths not found in its sysconfdir (by default /etc/vinyl-cache). The pkgvcldir on # the other hand is a recommended location for your package's VCL files, it # defaults to "${vcldir}/${PACKAGE}". # From 8b562dc22ebd90a8be3cc8ae66c1e2ce79cf2f6e Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 15 Mar 2026 23:12:47 +0100 Subject: [PATCH 153/196] Complement doc/changes.rst --- doc/changes.rst | 133 ++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 124 insertions(+), 9 deletions(-) diff --git a/doc/changes.rst b/doc/changes.rst index 2f5c8de2fb..5f763b60bd 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -41,7 +41,114 @@ Vinyl Cache 9.0 (2026-03-16) .. PLEASE keep this roughly in commit order as shown by git-log / tig (new to old) -* VCL variable ``beresp.storage_hint`` no longer exists. +* The project has been renamed from *Varnish Cache* to *Vinyl Cache*. *Vinyl + Cache* is the official project name, and we use *vinyl-cache* or *Vinyl-Cache* + with a dash only where a space is not technically possible, such as in domain + names and certain HTTP headers, or breaking with conventions, such as in + filenames. If neither of these work, the last resort is *Vinyl_Cache* or + *vinyl_cache*. Any other spelling should be avoided. A short ASCII + representation of the project name is ``\(``, which resembles our new logo. + + Our homepage is now https://vinyl-cache.org + + Our mastodon account is https://fosstodon.org/@vinyl_cache + + We have left github and the core code repository is now at + https://code.vinyl-cache.org/vinyl-cache/vinyl-cache + + For more information on the repository move see + https://vinyl-cache.org/organization/moving.html + +* Consequently, almost all references to the word *varnish* have been replaced + with *vinyl* or *vinyl-cache*. + +* In most cases, *varnish* has been replaced with *vinyl*, in particular: + + * ``varnishd`` is now ``vinyld`` + * ``varnishlog`` is now ``vinyllog`` + * ``varnishstat`` is now ``vinylstat`` + * ``libvarnishapi`` is now ``libvinylapi`` + * ``varnishapi.pc`` is now ``vinylapi.pc`` + * ``varnish.m4`` is now ``vinyl.m4`` + * ... + + In ``vinylncsa`` formats, ``%{Varnish:....}`` has been replaced with + ``%{Vinyl:....}`` + + The environment variable ``VARNISH_DEFAULT_N`` is now ``VINYL_DEFAULT_N`` + +* In other cases, *varnish* has been replaced with *vinyl-cache*, as in these + paths of a default installation, which have changed relative to the prefix: + + * ``include/varnish`` is now ``include/vinyl-cache`` + * ``lib/varnish`` is now ``lib/vinyl-cache`` + * ``share/doc/varnish`` is now ``share/doc/vinyl-cache`` + * ``share/varnish`` is now ``share/vinyl-cache`` + * ``etc/varnish`` is now ``etc/vinyl-cache`` + * ``var/varnish`` is now ``var/vinyl-cache`` if used, otherwise the state + directory is most likely ``/var/run`` + +* The default ``vcl_path`` has changed + + * from: ``${sysconfdir}/varnish:${datadir}/varnish/vcl`` + * to: ``${sysconfdir}/vinyl-cache:${datadir}/vinyl-cache/vcl`` + + So, most notably, for a default installation, the location for VCL files is + now ``/etc/vinyl-cache``. + +* The default ``vmod_path`` has changed + + * from: ``${libdir}/varnish/vmods`` + * to: ``${libdir}/vinyl-cache/vmods`` + +* The general exception where the name change has not been completed is historic + documentation, phks blog, past release documentation and the change log for + past releases. We will continue to call past releases up to and including 8.0 + Varnish Cache or Varnish. + + Releases of this project from 9.0 onwards will be called *Vinyl Cache*. + + Due to the amount of changes, we will almost certainly have overlooked places + where we did not carry out the name change correctly. Please let us know what + we have missed! + +* The default ``Server`` and ``Via`` headers have been changed from ``Varnish`` + to ``Vinyl-Cache``. + +* The ``X-Varnish`` header is now ``X-Vinyl`` + +* The unix user and group used by the unix and linux jails has been changed from + ``varnish`` to ``vinyl``. Users transitioning from Varnish Cache 8.0 might + find this snippet helpful to delete and create the relevant users/groups (see + also `vinyld(1)`):: + + userdel varnish || true + userdel vcache || true + userdel varnishlog || true # to remove reference to varnish group + groupdel varnish || true + + groupadd vinyl + useradd -g vinyl -d /nonexistent -s /bin/false \ + -c "Vinyl Cache Daemon User" vinyl + useradd -g vinyl -d /nonexistent -s /bin/false \ + -c "Vinyl Cache Worker User" vcache + useradd -g vinyl -d /nonexistent -s /bin/false \ + -c "Vinyl Log User" vinyllog + +* In ``vsc`` files, ``varnish_vsc`` is now ``vinyl_vsc`` + +* The VCL variable ``beresp.storage_hint`` no longer exists. + +* The VAI interface gained + + - the ``IOV_NIL`` macro to return leases once delivery has reached a certain + point, + + - the ``viov_take()`` function to transfer ownership of byte ranges from one + ``viov`` to another and + + - ``ObjVAInotify()`` / ``VDPIO_Notify()`` to allow filters to return + ``-EAGAIN`` and notify for delivery resumption at a later point. * ``VSL_Setup()`` has been replaced with ``VSL_Init()`` to initialize caller-provided space as a vsl buffer and ``VSL_Alloc()`` to allocate the default @@ -52,7 +159,6 @@ Vinyl Cache 9.0 (2026-03-16) ``tools/coccinelle/vsl_setup_retire.cocci`` can be used to partially automate the transition (it does not add ``VSL_Free()``). - .. _4452: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4452 * Fixed a bug in VCC where using ``false``/``true`` as a value for ``VCL_BOOL`` @@ -74,6 +180,15 @@ Vinyl Cache 9.0 (2026-03-16) * Added vmod ``math``. (`4422`_) + This adds all mathematical functions, macros and constants from ``math.h`` + like ``sqrt()`` , ``exp()``, ``pow()`` or ``log()`` (just to name a few + prominent ones) as well as + + - ``math.approx()`` implementing a notion of "approximately equal" + + - ``math.strfromd()`` for REAL formatting without the limitations of the + built-in formatter + .. _4427: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4427 * ``vmod_std`` has a new ``.rfc_ttl()`` to re-calculate the object timers @@ -90,10 +205,10 @@ Vinyl Cache 9.0 (2026-03-16) .. _4421: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4421 -* New ``unused`` VCL keyword to mark symbols as intentionally unused, which - prevents errors about them being unused during VCL compilation. This gives - finer grained control compared to the ``-err_unref`` VCC feature, which disables - the error globally for all symbols. (`4421`_) +* The new ``unused`` VCL keyword has been added to mark symbols as intentionally + unused, which prevents errors about them being unused during VCL compilation. + This gives finer grained control compared to the ``-err_unref`` VCC feature, + which disables the error globally for all symbols. (`4421`_) .. _4418: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/pulls/4418 @@ -126,10 +241,10 @@ Vinyl Cache 9.0 (2026-03-16) * A new ``bereq.retry_connect`` variable was added to VCL to control whether ``vinyld`` will make a second attempt to connect to the backend if a first connection reuse attempt failed. This can be useful to prevent undesired - retries of potentially non-idempotent requests. Setting to ``false`` means - that no retries will be made. However, setting this to ``true`` does not + retries of potentially non-idempotent requests. Setting this to ``false`` means + that no retries will be made. However, setting it to ``true`` does not guarantee that a retry will always be attempted, as there are other factors - involved in the decision (ex: a request body not being cached). This parameter + involved in the decision (e.g. a request body not being cached). This parameter only affects automatic retries triggered by connection reuse failures and does not affect VCL retries. (`4416`_) From b60cdf4b8cfca1c38e243972eeff33fa26a9c07e Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 15 Mar 2026 23:25:14 +0100 Subject: [PATCH 154/196] Update Copyright --- configure.ac | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 26cb1b698b..ec0144e5fa 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,8 @@ AC_PREREQ([2.69]) AC_COPYRIGHT([Copyright (c) 2006 Verdens Gang AS -Copyright (c) 2006-2025 Varnish Software -Copyright 2010-2025 UPLEX - Nils Goroll Systemoptimierung]) +Copyright (c) 2006-2026 Varnish Software +Copyright 2010-2026 UPLEX - Nils Goroll Systemoptimierung +Copyright 2026 The Vinyl Cache Project]) AC_REVISION([$Id$]) AC_INIT([Vinyl Cache], [trunk], [vinyl-dev@vinyl-cache.org], [vinyl-cache]) AC_CONFIG_SRCDIR(include/miniobj.h) From 23ce38e2ae6e9638bd8e0fbf849274ec7c4fd863 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 15 Mar 2026 23:29:45 +0100 Subject: [PATCH 155/196] Update Copyright --- lib/libvinyl/version.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/libvinyl/version.c b/lib/libvinyl/version.c index 651e739f6d..ee860eadec 100644 --- a/lib/libvinyl/version.c +++ b/lib/libvinyl/version.c @@ -76,8 +76,9 @@ VCS_String(const char *which) ")" "\n" "Copyright (c) 2006 Verdens Gang AS\n" - "Copyright (c) 2006-2025 Varnish Software\n" - "Copyright 2010-2025 UPLEX - Nils Goroll Systemoptimierung\n" + "Copyright (c) 2006-2026 Varnish Software\n" + "Copyright 2010-2026 UPLEX - Nils Goroll Systemoptimierung\n" + "Copyright 2026 The Vinyl Cache Project\n" ); default: WRONG("Wrong argument to VCS_String"); From 89b8bf424d362d7c5bf97adf6339b382d6bfa3a5 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Mon, 16 Mar 2026 00:20:20 +0100 Subject: [PATCH 156/196] Complement release docs --- doc/sphinx/whats-new/changes-9.0.rst | 27 ++++- doc/sphinx/whats-new/upgrading-9.0.rst | 141 +++++++++++++++++++++++-- 2 files changed, 154 insertions(+), 14 deletions(-) diff --git a/doc/sphinx/whats-new/changes-9.0.rst b/doc/sphinx/whats-new/changes-9.0.rst index 58b3bb8412..de57b8e009 100644 --- a/doc/sphinx/whats-new/changes-9.0.rst +++ b/doc/sphinx/whats-new/changes-9.0.rst @@ -4,8 +4,9 @@ Changes in Vinyl Cache 9.0 %%%%%%%%%%%%%%%%%%%%%%%%%% -For information about updating your current Varnish deployment to the -new version, see :ref:`whatsnew_upgrading_9.0`. +This version is released under a new name, which implies a number of relevant +changes to Vinyl Cache deployments. We strongly recommend to read +:ref:`whatsnew_upgrading_9.0` first. A more detailed and technical account of changes in Vinyl Cache, with links to issues that have been fixed and pull requests that have been @@ -19,7 +20,7 @@ vinyld Other changes in vinyld ~~~~~~~~~~~~~~~~~~~~~~~ -Varnish Extensions (VEXTs) can now be loaded by specifying their basename as +Vinyl Extensions (VEXTs) can now be loaded by specifying their basename as ``-E``. When ```` is not a path (does not contain ``/``), a search in ``vmod_path`` is conducted for ``libvmod_.so``. @@ -71,7 +72,14 @@ to suppress folding-related warnings during VCL compilation. VMODs ===== -A new ``vmod_math`` has been added, providing mathematical functions. +A new ``vmod_math`` has been added, which provides all mathematical functions, +macros and constants from ``math.h`` like ``sqrt()`` , ``exp()``, ``pow()`` or +``log()`` (just to name a few prominent ones) as well as + +- ``math.approx()`` implementing a notion of "approximately equal" + +- ``math.strfromd()`` for REAL formatting without the limitations of the + built-in formatter ``vmod_std`` has a new ``.rfc_ttl()`` function to re-calculate the object timers (``beresp.ttl``, ``beresp.grace`` and ``beresp.keep``) based on the @@ -115,4 +123,15 @@ Request methods are now represented as a bitmap in ``struct http``, which allows turning method evaluations into simple bitwise operations instead of string comparisons. +The VAI interface gained + +- the ``IOV_NIL`` macro to return leases once delivery has reached a certain + point, + +- the ``viov_take()`` function to transfer ownership of byte ranges from one + ``viov`` to another and + +- ``ObjVAInotify()`` / ``VDPIO_Notify()`` to allow filters to return + ``-EAGAIN`` and notify for delivery resumption at a later point. + *eof* diff --git a/doc/sphinx/whats-new/upgrading-9.0.rst b/doc/sphinx/whats-new/upgrading-9.0.rst index cbb084854e..1f43182a20 100644 --- a/doc/sphinx/whats-new/upgrading-9.0.rst +++ b/doc/sphinx/whats-new/upgrading-9.0.rst @@ -5,28 +5,114 @@ Upgrading to Vinyl Cache 9.0 %%%%%%%%%%%%%%%%%%%%%%%%%%%% This document only lists breaking changes that you should be aware of when -upgrading from varnish 8.x to vinyl 9.0. For a complete list of changes, -please refer to the `change log`_ or :ref:`whatsnew_changes_9.0`. +upgrading from Varnish Cache 8.x to Vinyl Cache 9.0. For a complete list of +changes, please refer to the `change log`_ and :ref:`whatsnew_changes_9.0`. .. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst Name change =========== -As you `may have noticed`_, the project name has been changed from "Varnish Cache" -to "Vinyl Cache", and this is the first release under the new name. All binaries, -documentation, and other references have been updated to reflect this change. -Starting from this release, the main binary is now ``vinyld`` instead of ``varnishd``. -Similarly, all VUTs were renamed accordingly (``vinyllog``, ``vinylncsa``.. etc). +.. _`may have noticed`: https://vinyl-cache.org/organization/20-years.html -Besides this cosmetic change, there are no functional changes related to the name change, -and the upgrade process should be as usual. +As you `may have noticed`_, the project name has been changed from *Varnish +Cache* to *Vinyl Cache*, and this is the first release under the new name. All +binaries, documentation, and other references have been updated to reflect this +change. Starting from this release, the main program is now ``vinyld`` instead +of ``varnishd``. Similarly, all tools were renamed accordingly (``vinyllog``, +``vinylncsa``.. etc). -.. _`may have noticed`: https://vinyl-cache.org/#years-old-and-it-is-time-to-get-serious-er +*Vinyl Cache* is the official project name, and we use *vinyl-cache* or +*Vinyl-Cache* with a dash only where a space is not technically possible, such +as in domain names and certain HTTP headers, or breaking with conventions, such +as in filenames. If neither of these work, the last resort is *Vinyl_Cache* or +*vinyl_cache*. Any other spelling should be avoided. A short ASCII +representation of the project name is ``\(``, which resembles our new logo. + +Our homepage is now https://vinyl-cache.org + +Our mastodon account is https://fosstodon.org/@vinyl_cache + +We have left github and the core code repository is now at +https://code.vinyl-cache.org/vinyl-cache/vinyl-cache + +For more information on the repository move see +https://vinyl-cache.org/organization/moving.html + +While the name change might look mostly cosmetic at first, besides, obviously, +needing to start ``vinyld`` instead of ``varnishd``, and running, for example, +``vinylstat`` instead of ``varnishstat``, there are some less obvious +consequences, so we recommend to read through the following changes. Other than +that, the upgrade should work as usual and, in particular, VCL should require +adjustments only in rare cases. + +Affecting multiple programs +=========================== + +The environment variable ``VARNISH_DEFAULT_N`` is now ``VINYL_DEFAULT_N`` + +The directory structure has been changed. Sparing details like differences +where ``etc`` and ``lib`` reside, the changes are: + +* ``include/varnish`` is now ``include/vinyl-cache`` +* ``lib/varnish`` is now ``lib/vinyl-cache`` +* ``share/doc/varnish`` is now ``share/doc/vinyl-cache`` +* ``share/varnish`` is now ``share/vinyl-cache`` +* ``etc/varnish`` is now ``etc/vinyl-cache`` +* ``var/varnish`` is now ``var/vinyl-cache`` if used, otherwise the state + directory is most likely ``/var/run`` + +Most notable of these is the default VCL location which, for most users, will +change from ``/etc/varnish`` to ``/etc/vinyl-cache``. vinyld ====== +Unix user changes +~~~~~~~~~~~~~~~~~ + +The Unix user and group used by the ``unix`` and ``linux`` jails have been +changed from ``varnish`` to ``vinyl``. Users transitioning from Varnish Cache +8.0 might find this snippet helpful to delete and create the relevant +users/groups (see also `vinyld(1)`):: + + userdel varnish || true + userdel vcache || true + userdel varnishlog || true # to remove reference to varnish group + groupdel varnish || true + + groupadd vinyl + useradd -g vinyl -d /nonexistent -s /bin/false \ + -c "Vinyl Cache Daemon User" vinyl + useradd -g vinyl -d /nonexistent -s /bin/false \ + -c "Vinyl Cache Worker User" vcache + useradd -g vinyl -d /nonexistent -s /bin/false \ + -c "Vinyl Log User" vinyllog + +Path changes +~~~~~~~~~~~~ + +The default ``vcl_path`` has changed + +* from: ``${sysconfdir}/varnish:${datadir}/varnish/vcl`` +* to: ``${sysconfdir}/vinyl-cache:${datadir}/vinyl-cache/vcl`` + +So, most notably, for a default installation, the location for VCL files is +now ``/etc/vinyl-cache``. + +The default ``vmod_path`` has changed + +* from: ``${libdir}/varnish/vmods`` +* to: ``${libdir}/vinyl-cache/vmods`` + +Default header changes +~~~~~~~~~~~~~~~~~~~~~~ + +The default ``Server`` and ``Via`` headers have been changed from ``Varnish`` +to ``Vinyl-Cache``. + +The ``X-Varnish`` header is now ``X-Vinyl`` + VCL variable ``beresp.storage_hint`` removed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -50,9 +136,44 @@ only be unset when the request method is one of: ``GET``, ``HEAD``, ``DELETE``, value 0 will be set instead. This may affect backends that are sensitive to the presence of the ``Content-Length`` header. +vinylncsa +========= + +In ``vinylncsa`` formats, ``%{Varnish:....}`` has been replaced with +``%{Vinyl:....}`` + Upgrade notes for VMOD developers ================================= +Name change +~~~~~~~~~~~ + +The ``libvarnishapi`` library is now ``libvinylapi``. + +The pkg-config file ``varnishapi.pc`` is now ``vinylapi.pc``. + +The autoconf macro file ``varnish.m4`` is now ``vinyl.m4``, and the +``VARNISH_*`` macros are now called ``VINYL_*``. + +In ``vsc`` files, ``varnish_vsc`` is now ``vinyl_vsc``. + +On a git repository with an autotools-based VMOD where file names do not contain +white space, the following one-liner should produce at least haft-decent +results:: + + sed -i 's/varnishtest/vtest/g;s/varnish/vinyl/g;s/VARNISH/VINYL/g;s/Varnish.Cache/Vinyl Cache/g;s/Varnish/Vinyl Cache/g;' $(git ls-files) + +Please note that these results should only be taken as the basis for manual +edits! + +The most important changes are: + +* In ``configure.ac``, replace ``VARNISH_`` macros with ``VINYL_``. +* In ``Makefile.am``\ s, replace ``VARNISHAPI_`` with ``VINYLAPI_`` and + ``VARNISH_`` with ``VINYL_``. +* In ``vtc`` files, replace ``varnishtest`` with ``vtest`` and ``varnish`` with + ``vinyl``. + ``VSL_Setup()`` replaced with ``VSL_Init()`` and ``VSL_Alloc()`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From 5ae682b50208446f99f414eb03106bba389ef9c2 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Mon, 16 Mar 2026 07:07:14 +0000 Subject: [PATCH 157/196] Make the copyright notice reflect Vinyl Cache is Varnish Cache renamed. --- doc/sphinx/conf.py.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/sphinx/conf.py.in b/doc/sphinx/conf.py.in index 8b56f64c9c..eb3b21308e 100644 --- a/doc/sphinx/conf.py.in +++ b/doc/sphinx/conf.py.in @@ -47,8 +47,8 @@ master_doc = 'index' # General information about the project. project = u'Vinyl Cache Project' -copyright = u'2016-2026, The Varnish Cache and Vinyl Cache Contributors. Vinyl Cache Logo & Mascot: CC-BY 4.0 Rhubarbe.design' -author = u'The Varnish Cache and Vinyl Cache Contributors' +copyright = u'2016-2026, The Vinyl Cache Project and contributors. Vinyl Cache Logo & Mascot: CC-BY 4.0 Rhubarbe.design' +author = u'The Vinyl Cache Project and contributors' # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the @@ -225,7 +225,7 @@ latex_elements = { # author, documentclass [howto, manual, or own class]). latex_documents = [ ('index', 'VinylCache.tex', u'Vinyl Cache Administrator documentation', - u'The Varnish Cache and Vinyl Cache Contributors', 'manual'), + u'The Vinyl Cache Project and contributors', 'manual'), ] # The name of an image file (relative to this directory) to place at the top of From d18c399893964991dba3122aa50c0b169f2aed86 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Mon, 16 Mar 2026 07:09:40 +0000 Subject: [PATCH 158/196] Update freebsd package info to reality --- doc/sphinx/installation/install_freebsd.rst | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/doc/sphinx/installation/install_freebsd.rst b/doc/sphinx/installation/install_freebsd.rst index 87e5953cc3..9f3fd94e4e 100644 --- a/doc/sphinx/installation/install_freebsd.rst +++ b/doc/sphinx/installation/install_freebsd.rst @@ -13,13 +13,9 @@ Installing on FreeBSD From package ------------ -FreeBSD offers two versions of Varnish Cache pre-packaged:: +FreeBSD offers Varnish Cache pre-packaged:: - pkg install varnish6 - -or, if for some reason you want the older version:: - - pkg install varnish4 + pkg install varnish7 From ports ---------- @@ -29,6 +25,6 @@ install Varnish Cache directly from ports if you prefer, for instance to get a newer version of Varnish Cache than the current set of prebuilt packages provide:: - cd /usr/ports/www/varnish6 + cd /usr/ports/www/varnish7 make all install clean From f03fdfc921aa56af3c744e3fdf17e6a4885fbfe3 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Tue, 3 Feb 2026 09:08:36 +0100 Subject: [PATCH 159/196] Test host header override for http/1.1 "absolute form" dissection RFC9112 section 3.2: the origin server MUST ignore the received Host header field (if any) and instead use the host information of the request-target. Note that if the request-target does not have an authority component, an empty Host header field will be sent in this case. We also add a test for the / path --- bin/vinyltest/tests/r01255.vtc | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/bin/vinyltest/tests/r01255.vtc b/bin/vinyltest/tests/r01255.vtc index 5a6b541b6c..b05c99e538 100644 --- a/bin/vinyltest/tests/r01255.vtc +++ b/bin/vinyltest/tests/r01255.vtc @@ -1,6 +1,6 @@ vtest "Test RFC2616 5.2 compliance" -server s1 { +server s1 -repeat 3 { rxreq txresp -hdr "Foo: 1" } -start @@ -9,11 +9,23 @@ vinyl v1 -vcl+backend { sub vcl_deliver { set resp.http.rxhost = req.http.host; + set resp.http.url = req.url; } } -start client c1 { - txreq -url http://www.example.com/bar + txreq -url http://www.example.com/bar -hdr "host: another" rxresp expect resp.http.rxhost == www.example.com + expect resp.http.url == /bar + + txreq -url http://www.example.com/ -hdr "host: another" + rxresp + expect resp.http.rxhost == www.example.com + expect resp.http.url == / + + txreq -url http:///bar -hdr "host: another" + rxresp + expect resp.http.rxhost == "" + expect resp.http.url == /bar } -run From 2d9f0c256811c206ded5346b0eb4708d1d087e26 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Tue, 3 Feb 2026 09:15:02 +0100 Subject: [PATCH 160/196] Fix http/1.1 "absolute form" dissection edge case RFC9110 4.2.3: When not being used as the target of an OPTIONS request, an empty path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. 7.7: For example, a proxy forwarding a request to an origin server via HTTP/1.1 will replace an empty path with "/" (Section 3.2.1 of [HTTP/1.1]) or "*" (Section 3.2.4 of [HTTP/1.1]), depending on the request method. (Pointed out by Dridi) Fixes VSV18 --- bin/vinyld/http1/cache_http1_proto.c | 14 ++++++++++---- bin/vinyltest/tests/r01255.vtc | 22 +++++++++++++++++++++- doc/changes.rst | 16 ++++++++++++++++ 3 files changed, 47 insertions(+), 5 deletions(-) diff --git a/bin/vinyld/http1/cache_http1_proto.c b/bin/vinyld/http1/cache_http1_proto.c index 23c1746234..a58a1dce30 100644 --- a/bin/vinyld/http1/cache_http1_proto.c +++ b/bin/vinyld/http1/cache_http1_proto.c @@ -376,10 +376,16 @@ HTTP1_DissectRequest(struct http_conn *htc, struct http *hp) b = hp->hd[HTTP_HDR_URL].b + 8; if (b) { e = strchr(b, '/'); - if (e) { - http_Unset(hp, H_Host); - http_PrintfHeader(hp, "Host: %.*s", (int)(e - b), b); - hp->hd[HTTP_HDR_URL].b = e; + if (e == NULL) + e = hp->hd[HTTP_HDR_URL].e; + http_Unset(hp, H_Host); + http_PrintfHeader(hp, "Host: %.*s", (int)(e - b), b); + hp->hd[HTTP_HDR_URL].b = e; + if (Tlen(hp->hd[HTTP_HDR_URL]) == 0) { + if (http_method_eq(hp->wkm, WKM_OPTIONS)) + hp->hd[HTTP_HDR_URL] = Tstr("*"); + else + hp->hd[HTTP_HDR_URL] = Tstr("/"); } } diff --git a/bin/vinyltest/tests/r01255.vtc b/bin/vinyltest/tests/r01255.vtc index b05c99e538..63cfac9a8a 100644 --- a/bin/vinyltest/tests/r01255.vtc +++ b/bin/vinyltest/tests/r01255.vtc @@ -1,6 +1,6 @@ vtest "Test RFC2616 5.2 compliance" -server s1 -repeat 3 { +server s1 -repeat 6 { rxreq txresp -hdr "Foo: 1" } -start @@ -24,8 +24,28 @@ client c1 { expect resp.http.rxhost == www.example.com expect resp.http.url == / + txreq -url http://www.example.com -hdr "host: another" + rxresp + expect resp.http.rxhost == www.example.com + expect resp.http.url == / + + txreq -method OPTIONS -url http://www.example.com -hdr "host: another" + rxresp + expect resp.http.rxhost == www.example.com + expect resp.http.url == * + txreq -url http:///bar -hdr "host: another" rxresp expect resp.http.rxhost == "" expect resp.http.url == /bar + + txreq -url http:// -hdr "host: another" + rxresp + expect resp.http.rxhost == "" + expect resp.http.url == / + + txreq -method OPTIONS -url http:// -hdr "host: another" + rxresp + expect resp.http.rxhost == "" + expect resp.http.url == * } -run diff --git a/doc/changes.rst b/doc/changes.rst index 5f763b60bd..c3973ec5bb 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -137,6 +137,22 @@ Vinyl Cache 9.0 (2026-03-16) * In ``vsc`` files, ``varnish_vsc`` is now ``vinyl_vsc`` +.. _VSV18: https://vinyl-cache.org/security/VSV00018.html + +* The handling of HTTP/1.1 requests to an "absolute form" URI has been fixed to + also cover the case where the absolute form has an empty path component: + + Previously, a request with an empty path like ``GET http://example.com + HTTP/1.1`` would cause ``req.url`` to contain ``http://example.com`` and the + ``Host:`` header to remain unchanged. This has now been fixed: + + - ``req.url`` gets set to ``*`` if the request method is ``OPTIONS`` and to + ``/`` otherwise + + - The ``Host:`` header gets set to ``example.com``. + + (`VSV18`_) + * The VCL variable ``beresp.storage_hint`` no longer exists. * The VAI interface gained From bb0d9fe59075973a96b4ac1ebe3a7a73ecf5f2a7 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 4 Mar 2026 09:46:28 +0100 Subject: [PATCH 161/196] Fix http/1.1 "absolute form" empty host handling RFC9110 4.2.1: A sender MUST NOT generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid. 4.2.2: A sender MUST NOT generate an "https" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid. Pointed out by Walid Related to VSV18 --- bin/vinyld/http1/cache_http1_proto.c | 4 ++++ bin/vinyltest/tests/r01255.vtc | 13 +++++++------ doc/changes.rst | 3 +++ 3 files changed, 14 insertions(+), 6 deletions(-) diff --git a/bin/vinyld/http1/cache_http1_proto.c b/bin/vinyld/http1/cache_http1_proto.c index a58a1dce30..5fcada098d 100644 --- a/bin/vinyld/http1/cache_http1_proto.c +++ b/bin/vinyld/http1/cache_http1_proto.c @@ -378,6 +378,10 @@ HTTP1_DissectRequest(struct http_conn *htc, struct http *hp) e = strchr(b, '/'); if (e == NULL) e = hp->hd[HTTP_HDR_URL].e; + if (e == b) { + // rfc9110 4.2.1 4.2.2 reject empty host + return (400); + } http_Unset(hp, H_Host); http_PrintfHeader(hp, "Host: %.*s", (int)(e - b), b); hp->hd[HTTP_HDR_URL].b = e; diff --git a/bin/vinyltest/tests/r01255.vtc b/bin/vinyltest/tests/r01255.vtc index 63cfac9a8a..69e657f247 100644 --- a/bin/vinyltest/tests/r01255.vtc +++ b/bin/vinyltest/tests/r01255.vtc @@ -36,16 +36,17 @@ client c1 { txreq -url http:///bar -hdr "host: another" rxresp - expect resp.http.rxhost == "" - expect resp.http.url == /bar + expect resp.status == 400 +} -run +client c2 { txreq -url http:// -hdr "host: another" rxresp - expect resp.http.rxhost == "" - expect resp.http.url == / + expect resp.status == 400 +} -run +client c3 { txreq -method OPTIONS -url http:// -hdr "host: another" rxresp - expect resp.http.rxhost == "" - expect resp.http.url == * + expect resp.status == 400 } -run diff --git a/doc/changes.rst b/doc/changes.rst index c3973ec5bb..0a2913555c 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -153,6 +153,9 @@ Vinyl Cache 9.0 (2026-03-16) (`VSV18`_) +* For requests to an absolute form URI, the host field is now required. Requests + without a host field are rejected with a Status 400 error. + * The VCL variable ``beresp.storage_hint`` no longer exists. * The VAI interface gained From dec64ef322e3f2b01d04dca76d6d8a7b165c0efb Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Tue, 3 Feb 2026 09:35:02 +0100 Subject: [PATCH 162/196] Improve RFC9112 3.2 coverage --- bin/vinyltest/tests/r01255.vtc | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/bin/vinyltest/tests/r01255.vtc b/bin/vinyltest/tests/r01255.vtc index 69e657f247..bbd4dc9983 100644 --- a/bin/vinyltest/tests/r01255.vtc +++ b/bin/vinyltest/tests/r01255.vtc @@ -1,11 +1,16 @@ vtest "Test RFC2616 5.2 compliance" -server s1 -repeat 6 { +server s1 -repeat 8 { rxreq txresp -hdr "Foo: 1" } -start vinyl v1 -vcl+backend { + sub vcl_req_method { + if (req.method == "CONNECT") { + return (pass); + } + } sub vcl_deliver { set resp.http.rxhost = req.http.host; @@ -16,24 +21,47 @@ vinyl v1 -vcl+backend { client c1 { txreq -url http://www.example.com/bar -hdr "host: another" rxresp + expect resp.status == 200 + expect resp.http.Foo == 1 expect resp.http.rxhost == www.example.com expect resp.http.url == /bar txreq -url http://www.example.com/ -hdr "host: another" rxresp + expect resp.status == 200 + expect resp.http.Foo == 1 expect resp.http.rxhost == www.example.com expect resp.http.url == / txreq -url http://www.example.com -hdr "host: another" rxresp + expect resp.status == 200 + expect resp.http.Foo == 1 expect resp.http.rxhost == www.example.com expect resp.http.url == / txreq -method OPTIONS -url http://www.example.com -hdr "host: another" rxresp + expect resp.status == 200 + expect resp.http.Foo == 1 expect resp.http.rxhost == www.example.com expect resp.http.url == * + # we do not actually handle CONNECT here + txreq -req CONNECT -url example.com:80 -hdr "host: another" + rxresp + expect resp.status == 200 + expect resp.http.Foo == 1 + expect resp.http.rxhost == "another" + expect resp.http.url == "example.com:80" + + txreq -req OPTIONS -url "*" -hdr "host: another" + rxresp + expect resp.status == 200 + expect resp.http.Foo == 1 + expect resp.http.rxhost == "another" + expect resp.http.url == "*" + txreq -url http:///bar -hdr "host: another" rxresp expect resp.status == 400 From 1b4be5a4c9157764428342b9b402d76f7debd50e Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Tue, 3 Feb 2026 10:33:14 +0100 Subject: [PATCH 163/196] Add more defensive req.url checks to builtin.vcl As a defensive measure, we add vcl_req_url, which requires req.url to start with "/" except for * the CONNECT method, where req.url contains hostname:port (for http/1.1) and * the OPTIONS method, where req.url can be "*" Note that, by default, we do not accept CONNECT requests. As with all built-in "hooks", vcl_req_url can be overridden selectively from the custom vcl. As a particular case, this, by default, prevents processing of https:// request targets, unless the https_scheme feature flag is set. --- bin/vinyld/builtin.vcl | 11 +++++++++++ bin/vinyltest/tests/b00026.vtc | 12 ++++++------ bin/vinyltest/tests/c00005.vtc | 4 ++-- bin/vinyltest/tests/e00009.vtc | 2 +- bin/vinyltest/tests/e00019.vtc | 8 ++++---- bin/vinyltest/tests/r01847.vtc | 3 +-- bin/vinyltest/tests/r02339.vtc | 24 ++++++++++++------------ doc/changes.rst | 5 +++++ 8 files changed, 42 insertions(+), 27 deletions(-) diff --git a/bin/vinyld/builtin.vcl b/bin/vinyld/builtin.vcl index 3a821a924c..398d7da460 100644 --- a/bin/vinyld/builtin.vcl +++ b/bin/vinyld/builtin.vcl @@ -59,6 +59,7 @@ sub vcl_recv { } sub vcl_builtin_recv { + call vcl_req_url; call vcl_req_host; call vcl_req_method; call vcl_req_authorization; @@ -77,6 +78,16 @@ sub vcl_req_host { } } +sub vcl_req_url { + if (req.url == "*" && req.method == "OPTIONS") { + return; + } + # NB: we do not allow connect by default (see vcl_req_method) + if (req.url !~ "^/" && req.method != "CONNECT") { + return (synth(400)); + } +} + sub vcl_req_method { if (req.method != "GET" && req.method != "HEAD" && diff --git a/bin/vinyltest/tests/b00026.vtc b/bin/vinyltest/tests/b00026.vtc index f4e0c38a93..336417f244 100644 --- a/bin/vinyltest/tests/b00026.vtc +++ b/bin/vinyltest/tests/b00026.vtc @@ -2,13 +2,13 @@ vtest "Check the precedence for timeouts" server s1 { rxreq - expect req.url == "from_backend" + expect req.url == "/from_backend" delay 1 txresp } -start server s2 { rxreq - expect req.url == "from_vcl" + expect req.url == "/from_vcl" delay 1.5 txresp } -start @@ -26,13 +26,13 @@ vinyl v1 -vcl { } sub vcl_recv { - if (req.url == "from_backend") { + if (req.url == "/from_backend") { return(pass); } } sub vcl_backend_fetch { set bereq.first_byte_timeout = 2s; - if (bereq.url == "from_backend") { + if (bereq.url == "/from_backend") { set bereq.backend = b1; } else { set bereq.backend = b2; @@ -42,10 +42,10 @@ vinyl v1 -vcl { vinyl v1 -cliok "param.set first_byte_timeout 0.5" client c1 { - txreq -url "from_backend" + txreq -url "/from_backend" rxresp expect resp.status == 200 - txreq -url "from_vcl" + txreq -url "/from_vcl" rxresp expect resp.status == 200 } -run diff --git a/bin/vinyltest/tests/c00005.vtc b/bin/vinyltest/tests/c00005.vtc index 5c04ac6c6c..b3f0f7cf9c 100644 --- a/bin/vinyltest/tests/c00005.vtc +++ b/bin/vinyltest/tests/c00005.vtc @@ -5,7 +5,7 @@ server s1 { expect req.url == "/" txresp -body "1111\n" rxreq - expect req.url == "foo" + expect req.url == "/foo" txresp -body "2222\n" } -start @@ -40,7 +40,7 @@ vinyl v1 -vcl+backend { } -start client c1 { - txreq -url "foo" + txreq -url "/foo" rxresp expect resp.status == 200 expect resp.http.acl == acl1 diff --git a/bin/vinyltest/tests/e00009.vtc b/bin/vinyltest/tests/e00009.vtc index 7f1225d7bf..47993d8483 100644 --- a/bin/vinyltest/tests/e00009.vtc +++ b/bin/vinyltest/tests/e00009.vtc @@ -40,7 +40,7 @@ vinyl v1 -expect MAIN.s_resp_bodybytes == 57 vinyl v1 -cli "param.set feature +esi_disable_xml_check" client c1 { - txreq -url bar + txreq -url /bar rxresp expect resp.status == 200 expect resp.bodylen == 22 diff --git a/bin/vinyltest/tests/e00019.vtc b/bin/vinyltest/tests/e00019.vtc index 990765f45a..0749e586b6 100644 --- a/bin/vinyltest/tests/e00019.vtc +++ b/bin/vinyltest/tests/e00019.vtc @@ -34,19 +34,19 @@ server s1 { # Vinyl 4 server s2 { rxreq - expect req.url == "bar/foo" + expect req.url == "/bar/foo" txresp -body {} } -start vinyl v1 -vcl+backend { sub vcl_backend_fetch { - if (bereq.url != "bar") { + if (bereq.url != "/bar/bazz") { set bereq.backend = s2; } } sub vcl_backend_response { - if (bereq.url == "bar") { + if (bereq.url == "/bar/bazz") { set beresp.do_esi = true; } } @@ -67,7 +67,7 @@ logexpect l1 -v v1 -g vxid -q "vxid == 1002" { } -start client c1 { - txreq -url bar + txreq -url /bar/bazz rxresp expect resp.status == 200 expect resp.bodylen == 65856 diff --git a/bin/vinyltest/tests/r01847.vtc b/bin/vinyltest/tests/r01847.vtc index b7a4b63d9d..0d4fc75810 100644 --- a/bin/vinyltest/tests/r01847.vtc +++ b/bin/vinyltest/tests/r01847.vtc @@ -26,8 +26,7 @@ client c1 { txreq -url https://www.example.com/bar rxresp - expect resp.http.rxhost == "${localhost}" - expect resp.http.rxurl == https://www.example.com/bar + expect resp.status == 400 } -run vinyl v1 -cliok "param.set feature +https_scheme" diff --git a/bin/vinyltest/tests/r02339.vtc b/bin/vinyltest/tests/r02339.vtc index a750ea9aa6..41a3fd53e4 100644 --- a/bin/vinyltest/tests/r02339.vtc +++ b/bin/vinyltest/tests/r02339.vtc @@ -11,10 +11,10 @@ vinyl v1 -vcl+backend { import purge; sub vcl_miss { - if (req.url == "miss") { purge.hard(); } + if (req.url == "/miss") { purge.hard(); } } sub vcl_hit { - if (req.url == "hit") { purge.hard(); } + if (req.url == "/hit") { purge.hard(); } } } -start @@ -39,15 +39,15 @@ logexpect l1 -v v1 { } -start client c1 { - txreq -url hit + txreq -url /hit rxresp expect resp.status == 200 - txreq -url hit + txreq -url /hit rxresp expect resp.status == 200 - txreq -url miss + txreq -url /miss rxresp expect resp.status == 200 } -run @@ -56,7 +56,7 @@ vinyl v1 -errvcl "Not available in subroutine 'vcl_purge'" { import purge; sub vcl_purge { - if (req.url == "purge") { purge.hard(); } + if (req.url == "/purge") { purge.hard(); } } } @@ -64,7 +64,7 @@ vinyl v1 -errvcl "Not available in subroutine 'vcl_pass'" { import purge; sub vcl_pass { - if (req.url == "pass") { purge.hard(); } + if (req.url == "/pass") { purge.hard(); } } } @@ -72,7 +72,7 @@ vinyl v1 -errvcl "Not available in subroutine 'vcl_deliver'" { import purge; sub vcl_deliver { - if (req.url == "deliver") { purge.hard(); } + if (req.url == "/deliver") { purge.hard(); } } } @@ -80,7 +80,7 @@ vinyl v1 -errvcl "Not available in subroutine 'vcl_synth'" { import purge; sub vcl_synth { - if (req.url == "synth") { purge.hard(); } + if (req.url == "/synth") { purge.hard(); } } } @@ -88,7 +88,7 @@ vinyl v1 -errvcl "Not available in subroutine 'vcl_backend_fetch'" { import purge; sub vcl_backend_fetch { - if (bereq.url == "fetch") { purge.hard(); } + if (bereq.url == "/fetch") { purge.hard(); } } } @@ -96,7 +96,7 @@ vinyl v1 -errvcl "Not available in subroutine 'vcl_backend_error'" { import purge; sub vcl_backend_error { - if (bereq.url == "error") { purge.hard(); } + if (bereq.url == "/error") { purge.hard(); } } } @@ -104,7 +104,7 @@ vinyl v1 -errvcl "Not available in subroutine 'vcl_backend_response'" { import purge; sub vcl_backend_response { - if (bereq.url == "response") { purge.hard(); } + if (bereq.url == "/response") { purge.hard(); } } } diff --git a/doc/changes.rst b/doc/changes.rst index 0a2913555c..e60637a048 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -156,6 +156,11 @@ Vinyl Cache 9.0 (2026-03-16) * For requests to an absolute form URI, the host field is now required. Requests without a host field are rejected with a Status 400 error. +* The built-in VCL has been changed to require ``req.url`` to start with ``/``, + unless the request method is ``CONNECT`` or ``OPTIONS``. For ``CONNECT``, no + additional check is applied, but ``CONNECT`` is not allowed by default. For + ``OPTIONS``, ``*`` is also allowed. + * The VCL variable ``beresp.storage_hint`` no longer exists. * The VAI interface gained From 9a3479869c2747f61b6ad2a83a8f3639d8ac18ca Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 4 Feb 2026 18:42:50 +0100 Subject: [PATCH 164/196] Add ReqTarget tag to log the HTTP1 request-target we add the ReqTarget VSL tag and log the request-target field from the HTTP1 request line, because we previously had only limited visibility into what it actually was. The ReqTarget tag is masked by default to retain the previous order of log records. --- bin/vinyld/http1/cache_http1_proto.c | 2 + bin/vinyltest/tests/r01255.vtc | 71 +++++++++++++++++++++++++++- doc/changes.rst | 5 ++ include/tbl/params.h | 1 + include/tbl/vsl_tags.h | 6 +++ lib/libvinylapi/vsl_glob_test.c | 2 +- 6 files changed, 85 insertions(+), 2 deletions(-) diff --git a/bin/vinyld/http1/cache_http1_proto.c b/bin/vinyld/http1/cache_http1_proto.c index 5fcada098d..c8e8f3ea51 100644 --- a/bin/vinyld/http1/cache_http1_proto.c +++ b/bin/vinyld/http1/cache_http1_proto.c @@ -368,6 +368,8 @@ HTTP1_DissectRequest(struct http_conn *htc, struct http *hp) http_SetWellKnownMethod(hp); + VSLbt(hp->vsl, SLT_ReqTarget, hp->hd[HTTP_HDR_URL]); + /* RFC2616, section 5.2, point 1 */ if (http_scheme_at(hp->hd[HTTP_HDR_URL].b, http)) b = hp->hd[HTTP_HDR_URL].b + 7; diff --git a/bin/vinyltest/tests/r01255.vtc b/bin/vinyltest/tests/r01255.vtc index bbd4dc9983..e362a323a0 100644 --- a/bin/vinyltest/tests/r01255.vtc +++ b/bin/vinyltest/tests/r01255.vtc @@ -5,7 +5,7 @@ server s1 -repeat 8 { txresp -hdr "Foo: 1" } -start -vinyl v1 -vcl+backend { +vinyl v1 -arg "-p vsl_mask=+ReqTarget" -vcl+backend { sub vcl_req_method { if (req.method == "CONNECT") { return (pass); @@ -18,7 +18,64 @@ vinyl v1 -vcl+backend { } } -start +logexpect l1001 -v v1 -g vxid -q "vxid == 1001" { + fail add * ReqURL + fail add * End + expect 3 * ReqTarget {^\Qhttp://www.example.com/bar\E$} + expect 0 = ReqUnset {^\Qhost: another\E$} + expect 0 = ReqHeader {^\QHost: www.example.com\E$} + fail clear +} -start + +logexpect l1003 -v v1 -g vxid -q "vxid == 1003" { + fail add * ReqURL + fail add * End + expect 3 * ReqTarget {^\Qhttp://www.example.com/\E$} + expect 0 = ReqUnset {^\Qhost: another\E$} + expect 0 = ReqHeader {^\QHost: www.example.com\E$} + fail clear +} -start + +logexpect l1005 -v v1 -g vxid -q "vxid == 1005" { + fail add * ReqURL + fail add * End + expect 3 * ReqTarget {^\Qhttp://www.example.com\E$} + expect 0 = ReqUnset {^\Qhost: another\E$} + expect 0 = ReqHeader {^\QHost: www.example.com\E$} + fail clear +} -start + +logexpect l1006 -v v1 -g vxid -q "vxid == 1006" { + fail add * ReqURL + fail add * End + expect 3 * ReqTarget {^\Qhttp://www.example.com\E$} + expect 0 = ReqUnset {^\Qhost: another\E$} + expect 0 = ReqHeader {^\QHost: www.example.com\E$} + fail clear + fail add * End + expect 3 = ReqMethod {^OPTIONS$} + expect 0 = ReqURL {^\Q*\E$} + fail clear +} -start + +logexpect l1008 -v v1 -g vxid -q "vxid == 1008" { + fail add * End + expect 3 * ReqTarget {^\Qexample.com:80\E$} + expect 2 = ReqMethod {^CONNECT$} + expect 0 = ReqURL {^\Qexample.com:80\E$} + fail clear +} -start + +logexpect l1010 -v v1 -g vxid -q "vxid == 1010" { + fail add * End + expect 3 * ReqTarget {^\Q*\E$} + expect 2 = ReqMethod {^OPTIONS$} + expect 0 = ReqURL {^\Q*\E$} + fail clear +} -start + client c1 { + # 1001 txreq -url http://www.example.com/bar -hdr "host: another" rxresp expect resp.status == 200 @@ -26,6 +83,7 @@ client c1 { expect resp.http.rxhost == www.example.com expect resp.http.url == /bar + # 1003 txreq -url http://www.example.com/ -hdr "host: another" rxresp expect resp.status == 200 @@ -33,6 +91,7 @@ client c1 { expect resp.http.rxhost == www.example.com expect resp.http.url == / + # 1005 txreq -url http://www.example.com -hdr "host: another" rxresp expect resp.status == 200 @@ -40,6 +99,7 @@ client c1 { expect resp.http.rxhost == www.example.com expect resp.http.url == / + # 1006 txreq -method OPTIONS -url http://www.example.com -hdr "host: another" rxresp expect resp.status == 200 @@ -47,6 +107,7 @@ client c1 { expect resp.http.rxhost == www.example.com expect resp.http.url == * + # 1008 # we do not actually handle CONNECT here txreq -req CONNECT -url example.com:80 -hdr "host: another" rxresp @@ -55,6 +116,7 @@ client c1 { expect resp.http.rxhost == "another" expect resp.http.url == "example.com:80" + # 1010 txreq -req OPTIONS -url "*" -hdr "host: another" rxresp expect resp.status == 200 @@ -78,3 +140,10 @@ client c3 { rxresp expect resp.status == 400 } -run + +logexpect l1001 -wait +logexpect l1003 -wait +logexpect l1005 -wait +logexpect l1006 -wait +logexpect l1008 -wait +logexpect l1010 -wait diff --git a/doc/changes.rst b/doc/changes.rst index e60637a048..f93aafa218 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -161,6 +161,11 @@ Vinyl Cache 9.0 (2026-03-16) additional check is applied, but ``CONNECT`` is not allowed by default. For ``OPTIONS``, ``*`` is also allowed. +* The ``ReqTarget`` Vinyl Shared Log (VSL) Tag has been added to log the + original request target before any handling of absolute form URIs. To preserve + the existing log format and ordering, the tag is marked by default. It can be + unmasked by adding ``+ReqTarget`` to the ``vsl_mask`` parameter. + * The VCL variable ``beresp.storage_hint`` no longer exists. * The VAI interface gained diff --git a/include/tbl/params.h b/include/tbl/params.h index 9745f147f4..0ac54338b7 100644 --- a/include/tbl/params.h +++ b/include/tbl/params.h @@ -2036,6 +2036,7 @@ PARAM_BITS( "-ObjProtocol," "-ObjReason," "-ObjStatus," + "-ReqTarget," "-VdpAcct," "-VfpAcct," "-WorkThread", diff --git a/include/tbl/vsl_tags.h b/include/tbl/vsl_tags.h index 61d8b82133..04d7d5b80e 100644 --- a/include/tbl/vsl_tags.h +++ b/include/tbl/vsl_tags.h @@ -704,6 +704,12 @@ SLTM(VdpAcct, 0, "Deliver filter accounting", NODEF_NOTICE ) +SLTM(ReqTarget, 0, "Request target as received", + "For HTTP1 connections, this is the *request-target* field from the request\n" + "line, which has the format *method* SP *request-target* SP *HTTP-Version*\n" + "(SP for space, 0x20)\n\n" + NODEF_NOTICE +) #undef NOSUP_NOTICE #undef NODEF_NOTICE diff --git a/lib/libvinylapi/vsl_glob_test.c b/lib/libvinylapi/vsl_glob_test.c index 84814647f7..5402be730e 100644 --- a/lib/libvinylapi/vsl_glob_test.c +++ b/lib/libvinylapi/vsl_glob_test.c @@ -72,7 +72,7 @@ main(int argc, char * const *argv) if (argc == 1) { i = tst_one_glob("Req*"); - assert(i == 10); + assert(i == 11); j = tst_one_glob("reQ*"); assert(i == j); assert(tst_one_glob("*Header") > 0); From 6b74c2e115d6ba93b00a8e012f3084473a550d5a Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 4 Feb 2026 19:04:30 +0100 Subject: [PATCH 165/196] Add MAIN.http1_absolute_form counter ... to count the number of times we have handled requests with an absolute form request target. To avoid overhead, this counter is neither locked nor added to the per-wrk counters, as the precise number is probably not of much interest. This can still easily be changed when a case arrives. --- bin/vinyld/http1/cache_http1_proto.c | 1 + bin/vinyltest/tests/r01255.vtc | 2 ++ doc/changes.rst | 4 ++++ lib/libvsc/VSC_main.vsc | 10 ++++++++++ 4 files changed, 17 insertions(+) diff --git a/bin/vinyld/http1/cache_http1_proto.c b/bin/vinyld/http1/cache_http1_proto.c index c8e8f3ea51..e6f0afb828 100644 --- a/bin/vinyld/http1/cache_http1_proto.c +++ b/bin/vinyld/http1/cache_http1_proto.c @@ -377,6 +377,7 @@ HTTP1_DissectRequest(struct http_conn *htc, struct http *hp) http_scheme_at(hp->hd[HTTP_HDR_URL].b, https)) b = hp->hd[HTTP_HDR_URL].b + 8; if (b) { + VSC_C_main->http1_absolute_form++; e = strchr(b, '/'); if (e == NULL) e = hp->hd[HTTP_HDR_URL].e; diff --git a/bin/vinyltest/tests/r01255.vtc b/bin/vinyltest/tests/r01255.vtc index e362a323a0..653d3dd878 100644 --- a/bin/vinyltest/tests/r01255.vtc +++ b/bin/vinyltest/tests/r01255.vtc @@ -141,6 +141,8 @@ client c3 { expect resp.status == 400 } -run +vinyl v1 -expect MAIN.http1_absolute_form == 7 + logexpect l1001 -wait logexpect l1003 -wait logexpect l1005 -wait diff --git a/doc/changes.rst b/doc/changes.rst index f93aafa218..09cfa13810 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -166,6 +166,10 @@ Vinyl Cache 9.0 (2026-03-16) the existing log format and ordering, the tag is marked by default. It can be unmasked by adding ``+ReqTarget`` to the ``vsl_mask`` parameter. +* The ``MAIN.http1_absolute_form`` counter has been added to track the number of + times an HTTP/1.1 request with an absolute form request target has been + handled. + * The VCL variable ``beresp.storage_hint`` no longer exists. * The VAI interface gained diff --git a/lib/libvsc/VSC_main.vsc b/lib/libvsc/VSC_main.vsc index 36e54e49d7..c68f7201cc 100644 --- a/lib/libvsc/VSC_main.vsc +++ b/lib/libvsc/VSC_main.vsc @@ -1018,4 +1018,14 @@ defined by the amount of free workspace for backend connections. +.. vinyl_vsc:: http1_absolute_form + :oneliner: Requests with absolute form request target + + Number of requests for which an absolute form request target (e.g. + http://example.com/ or https://example.com/) was handled. The https:// + scheme is only handled if the feature ``https_scheme`` is enabled (see + RUN TIME PARAMETERS in `vinyld(1)`). + + See also ReqTarget in `vsl(7)`. This counter is approximately correct. + .. vinyl_vsc_end:: main From 9f5477ce758d6e357825bab7673747f04349764d Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 4 Mar 2026 10:48:27 +0100 Subject: [PATCH 166/196] Enable https_scheme feature by default RFC9110 explicitly names https as "HTTP-related" and RFC9112 states that we MUST convert the host, so not parsing https:// is considered a violation of the standard, which, in turn, should be a deliberate decision. Related to VSV18 --- bin/vinyltest/tests/r01255.vtc | 10 +++++++++- bin/vinyltest/tests/r01847.vtc | 8 ++++---- doc/changes.rst | 3 +++ include/tbl/params.h | 1 + lib/libvsc/VSC_main.vsc | 4 ++-- 5 files changed, 19 insertions(+), 7 deletions(-) diff --git a/bin/vinyltest/tests/r01255.vtc b/bin/vinyltest/tests/r01255.vtc index 653d3dd878..f86c15cdfe 100644 --- a/bin/vinyltest/tests/r01255.vtc +++ b/bin/vinyltest/tests/r01255.vtc @@ -124,6 +124,14 @@ client c1 { expect resp.http.rxhost == "another" expect resp.http.url == "*" + # https, otherwise like 1005 + txreq -url https://www.example.com -hdr "host: another" + rxresp + expect resp.status == 200 + expect resp.http.Foo == 1 + expect resp.http.rxhost == www.example.com + expect resp.http.url == / + txreq -url http:///bar -hdr "host: another" rxresp expect resp.status == 400 @@ -141,7 +149,7 @@ client c3 { expect resp.status == 400 } -run -vinyl v1 -expect MAIN.http1_absolute_form == 7 +vinyl v1 -expect MAIN.http1_absolute_form == 8 logexpect l1001 -wait logexpect l1003 -wait diff --git a/bin/vinyltest/tests/r01847.vtc b/bin/vinyltest/tests/r01847.vtc index 0d4fc75810..a56d316704 100644 --- a/bin/vinyltest/tests/r01847.vtc +++ b/bin/vinyltest/tests/r01847.vtc @@ -26,10 +26,11 @@ client c1 { txreq -url https://www.example.com/bar rxresp - expect resp.status == 400 + expect resp.http.rxhost == www.example.com + expect resp.http.rxurl == /bar } -run -vinyl v1 -cliok "param.set feature +https_scheme" +vinyl v1 -cliok "param.set feature -https_scheme" client c1 { txreq -url http://www.example.com/bar @@ -39,6 +40,5 @@ client c1 { txreq -url https://www.example.com/bar rxresp - expect resp.http.rxhost == www.example.com - expect resp.http.rxurl == /bar + expect resp.status == 400 } -run diff --git a/doc/changes.rst b/doc/changes.rst index 09cfa13810..5633094ddb 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -170,6 +170,9 @@ Vinyl Cache 9.0 (2026-03-16) times an HTTP/1.1 request with an absolute form request target has been handled. +* The ``https_scheme`` parameter is now enabled by default to process + ``https://`` absolute form URLs by default. + * The VCL variable ``beresp.storage_hint`` no longer exists. * The VAI interface gained diff --git a/include/tbl/params.h b/include/tbl/params.h index 0ac54338b7..4d86b2aab7 100644 --- a/include/tbl/params.h +++ b/include/tbl/params.h @@ -1987,6 +1987,7 @@ PARAM_BITS( /* fld */ feature_bits, /* def */ "none," + "+https_scheme," "+validate_headers," "+vcl_req_reset", /* descr */ diff --git a/lib/libvsc/VSC_main.vsc b/lib/libvsc/VSC_main.vsc index c68f7201cc..917713117b 100644 --- a/lib/libvsc/VSC_main.vsc +++ b/lib/libvsc/VSC_main.vsc @@ -1023,8 +1023,8 @@ Number of requests for which an absolute form request target (e.g. http://example.com/ or https://example.com/) was handled. The https:// - scheme is only handled if the feature ``https_scheme`` is enabled (see - RUN TIME PARAMETERS in `vinyld(1)`). + scheme handled unless the feature ``https_scheme`` is disabled (see RUN + TIME PARAMETERS in `vinyld(1)`). See also ReqTarget in `vsl(7)`. This counter is approximately correct. From f27e9550aa30ad18e5196371d583e7131745088e Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 5 Mar 2026 14:28:02 +0100 Subject: [PATCH 167/196] Handle absolute form with empty path This patch now adds dissection of http://example.com?/foo into Host: example.com, url: /?/foo --- bin/vinyld/http1/cache_http1_proto.c | 10 +++++++++- bin/vinyltest/tests/r01255.vtc | 10 +++++++++- doc/changes.rst | 4 ++++ 3 files changed, 22 insertions(+), 2 deletions(-) diff --git a/bin/vinyld/http1/cache_http1_proto.c b/bin/vinyld/http1/cache_http1_proto.c index e6f0afb828..c7f5c38e3e 100644 --- a/bin/vinyld/http1/cache_http1_proto.c +++ b/bin/vinyld/http1/cache_http1_proto.c @@ -354,6 +354,7 @@ HTTP1_DissectRequest(struct http_conn *htc, struct http *hp) { uint16_t retval; const char *b = NULL, *e; + char c = '\0'; CHECK_OBJ_NOTNULL(htc, HTTP_CONN_MAGIC); CHECK_OBJ_NOTNULL(hp, HTTP_MAGIC); @@ -378,9 +379,11 @@ HTTP1_DissectRequest(struct http_conn *htc, struct http *hp) b = hp->hd[HTTP_HDR_URL].b + 8; if (b) { VSC_C_main->http1_absolute_form++; - e = strchr(b, '/'); + e = strpbrk(b, "/?"); if (e == NULL) e = hp->hd[HTTP_HDR_URL].e; + else + c = *e; if (e == b) { // rfc9110 4.2.1 4.2.2 reject empty host return (400); @@ -389,10 +392,15 @@ HTTP1_DissectRequest(struct http_conn *htc, struct http *hp) http_PrintfHeader(hp, "Host: %.*s", (int)(e - b), b); hp->hd[HTTP_HDR_URL].b = e; if (Tlen(hp->hd[HTTP_HDR_URL]) == 0) { + // empty path if (http_method_eq(hp->wkm, WKM_OPTIONS)) hp->hd[HTTP_HDR_URL] = Tstr("*"); else hp->hd[HTTP_HDR_URL] = Tstr("/"); + } else if (c == '?') { + hp->hd[HTTP_HDR_URL].b--; + char *t = TRUST_ME(hp->hd[HTTP_HDR_URL].b); + *t = '/'; } } diff --git a/bin/vinyltest/tests/r01255.vtc b/bin/vinyltest/tests/r01255.vtc index f86c15cdfe..f6b5bc0489 100644 --- a/bin/vinyltest/tests/r01255.vtc +++ b/bin/vinyltest/tests/r01255.vtc @@ -132,6 +132,14 @@ client c1 { expect resp.http.rxhost == www.example.com expect resp.http.url == / + # + txreq -url https://www.example.com?/foo -hdr "host: another" + rxresp + expect resp.status == 200 + expect resp.http.Foo == 1 + expect resp.http.rxhost == www.example.com + expect resp.http.url == /?/foo + txreq -url http:///bar -hdr "host: another" rxresp expect resp.status == 400 @@ -149,7 +157,7 @@ client c3 { expect resp.status == 400 } -run -vinyl v1 -expect MAIN.http1_absolute_form == 8 +vinyl v1 -expect MAIN.http1_absolute_form == 9 logexpect l1001 -wait logexpect l1003 -wait diff --git a/doc/changes.rst b/doc/changes.rst index 5633094ddb..c935d7000f 100644 --- a/doc/changes.rst +++ b/doc/changes.rst @@ -151,6 +151,10 @@ Vinyl Cache 9.0 (2026-03-16) - The ``Host:`` header gets set to ``example.com``. + For an empty path with query parameters like ``http://example.com?/foo``, + ``req.url`` gets normalized by addition of the leading slash. For the example, + ``req.url`` would contain ``/?/foo``. + (`VSV18`_) * For requests to an absolute form URI, the host field is now required. Requests From 77fd4c55ff404194220de879cb5cd9e6aa80891e Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Mon, 16 Mar 2026 10:22:45 +0100 Subject: [PATCH 168/196] VSV18 related release notes --- doc/sphinx/whats-new/changes-9.0.rst | 13 ++++++++++ doc/sphinx/whats-new/upgrading-9.0.rst | 33 ++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) diff --git a/doc/sphinx/whats-new/changes-9.0.rst b/doc/sphinx/whats-new/changes-9.0.rst index de57b8e009..95b24598b6 100644 --- a/doc/sphinx/whats-new/changes-9.0.rst +++ b/doc/sphinx/whats-new/changes-9.0.rst @@ -36,6 +36,10 @@ A conditional GET for object revalidation is now demoted to a regular fetch if the stale object being revalidated gets invalidated (e.g. by a ban or purge) while the backend request is in progress. +The ``https_scheme`` parameter is now enabled by default to process +``https://`` absolute form URLs by default. + + Changes to VCL ============== @@ -102,6 +106,11 @@ The session close reason descriptions ``REM_CLOSE`` and ``REQ_CLOSE`` have been generalized from "Client Closed" / "Client requested close" to "Peer Closed" / "Peer requested close" since they apply to both client and backend connections. +The ``ReqTarget`` Vinyl Shared Log (VSL) Tag has been added to log the +original request target before any handling of absolute form URIs. To preserve +the existing log format and ordering, the tag is marked by default. It can be +unmasked by adding ``+ReqTarget`` to the ``vsl_mask`` parameter. + vinylstat ========= @@ -109,6 +118,10 @@ The workspace overflow counters (``ws_backend_overflow``, ``ws_client_overflow`` ``ws_thread_overflow``, ``ws_session_overflow``) are now shown by default instead of requiring the ``diag`` level. +The ``MAIN.http1_absolute_form`` counter has been added to track the number of +times an HTTP/1.1 request with an absolute form request target has been +handled. + Changes for developers and VMOD authors ======================================= diff --git a/doc/sphinx/whats-new/upgrading-9.0.rst b/doc/sphinx/whats-new/upgrading-9.0.rst index 1f43182a20..d1186ec202 100644 --- a/doc/sphinx/whats-new/upgrading-9.0.rst +++ b/doc/sphinx/whats-new/upgrading-9.0.rst @@ -10,6 +10,8 @@ changes, please refer to the `change log`_ and :ref:`whatsnew_changes_9.0`. .. _change log: https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/src/branch/main/doc/changes.rst +Together with this release, we also announce a security issue, see `vsv18`_. + Name change =========== @@ -113,6 +115,37 @@ to ``Vinyl-Cache``. The ``X-Varnish`` header is now ``X-Vinyl`` +.. _VSV00018: https://vinyl-cache.org/security/VSV00018.html + +.. _vsv18: + +`VSV00018`_ +~~~~~~~~~~~ + +The handling of HTTP/1.1 requests to an "absolute form" URI has been fixed to +also cover the case where the absolute form has an empty path component: + +Previously, a request with an empty path like ``GET http://example.com +HTTP/1.1`` would cause ``req.url`` to contain ``http://example.com`` and the +``Host:`` header to remain unchanged. This has now been fixed: + +- ``req.url`` gets set to ``*`` if the request method is ``OPTIONS`` and to + ``/`` otherwise + +- The ``Host:`` header gets set to ``example.com``. + +For an empty path with query parameters like ``http://example.com?/foo``, +``req.url`` gets normalized by addition of the leading slash. For the example, +``req.url`` would contain ``/?/foo``. + +For requests to an absolute form URI, the host field is now required. Requests +without a host field are rejected with a Status 400 error. + +The built-in VCL has been changed to require ``req.url`` to start with ``/``, +unless the request method is ``CONNECT`` or ``OPTIONS``. For ``CONNECT``, no +additional check is applied, but ``CONNECT`` is not allowed by default. For +``OPTIONS``, ``*`` is also allowed. + VCL variable ``beresp.storage_hint`` removed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From c70af0a08d5f8eac5bdeb7f488cb091a3b269834 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Mon, 16 Mar 2026 10:58:37 +0100 Subject: [PATCH 169/196] Update vtc title --- bin/vinyltest/tests/r01255.vtc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/vinyltest/tests/r01255.vtc b/bin/vinyltest/tests/r01255.vtc index f6b5bc0489..6af9d93b95 100644 --- a/bin/vinyltest/tests/r01255.vtc +++ b/bin/vinyltest/tests/r01255.vtc @@ -1,4 +1,4 @@ -vtest "Test RFC2616 5.2 compliance" +vtest "Test RFC9112 3.2 compliance" server s1 -repeat 8 { rxreq From ef25f395fe668900032f4ebfb9b4fce158c75fc5 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Mon, 16 Mar 2026 11:13:08 +0100 Subject: [PATCH 170/196] css polish by rhubarbe --- doc/sphinx/_static/custom.css | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/doc/sphinx/_static/custom.css b/doc/sphinx/_static/custom.css index dcf63bf572..5b14d7af22 100644 --- a/doc/sphinx/_static/custom.css +++ b/doc/sphinx/_static/custom.css @@ -358,16 +358,21 @@ table.docutils { border: 2px solid var(--color-table-border); } -/* Sponsors sidebar */ +/* Follow and sponsors sidebar */ -.sidebar-tree + div { +.sidebar-scroll > div:not(.sidebar-tree) { margin-top: calc(2 * var(--sidebar-tree-space-above)); + margin-bottom: calc(3* var(--sidebar-tree-space-above)); padding-inline: var(--sidebar-item-spacing-horizontal); - font-family: var(--font-stack--headings); font-size: .8em; + text-wrap: balance; +} + +.sidebar-scroll > div:not(.sidebar-tree):has(img) { + font-family: var(--font-stack--headings); } -.sidebar-tree + div img { +.sidebar-scroll > div:not(.sidebar-tree):has(img) img { margin-bottom: 1.5em; } From d310c0c6e34f0277b62db8d5b44bf5b4299791d9 Mon Sep 17 00:00:00 2001 From: Walid Boudebouda Date: Mon, 16 Mar 2026 11:33:54 +0100 Subject: [PATCH 171/196] VSC_main: Polish --- lib/libvsc/VSC_main.vsc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/libvsc/VSC_main.vsc b/lib/libvsc/VSC_main.vsc index 917713117b..340848a4a1 100644 --- a/lib/libvsc/VSC_main.vsc +++ b/lib/libvsc/VSC_main.vsc @@ -1023,8 +1023,8 @@ Number of requests for which an absolute form request target (e.g. http://example.com/ or https://example.com/) was handled. The https:// - scheme handled unless the feature ``https_scheme`` is disabled (see RUN - TIME PARAMETERS in `vinyld(1)`). + scheme is handled unless the feature ``https_scheme`` is disabled (see + RUN TIME PARAMETERS in `vinyld(1)`). See also ReqTarget in `vsl(7)`. This counter is approximately correct. From e92852d957c86202329db242c879de1e134ba3d0 Mon Sep 17 00:00:00 2001 From: Walid Boudebouda Date: Mon, 16 Mar 2026 12:14:00 +0100 Subject: [PATCH 172/196] Prepare for 9.0.0 --- bin/vinyltest/tests/m00003.vtc | 10 +++++----- bin/vinyltest/tests/m00055.vtc | 2 +- configure.ac | 2 +- doc/sphinx/index.rst | 4 ++-- doc/sphinx/whats-new/index.rst | 4 ---- include/vrt.h | 14 ++++++++++++-- 6 files changed, 21 insertions(+), 15 deletions(-) diff --git a/bin/vinyltest/tests/m00003.vtc b/bin/vinyltest/tests/m00003.vtc index af6a68d8a3..656a8c70bb 100644 --- a/bin/vinyltest/tests/m00003.vtc +++ b/bin/vinyltest/tests/m00003.vtc @@ -99,7 +99,7 @@ filewrite -a ${tmpdir}/libvmod_wrong.so "\x03" vinyl v1 -errvcl {VMOD wants ABI version 1.0} { import wrong; } ############################################################# -# NB: in the tests below "21" should track VRT_MAJOR_VERSION +# NB: in the tests below "23" should track VRT_MAJOR_VERSION filewrite ${tmpdir}/libvmod_wrong.so "VMOD_JSON_SPEC\x02" filewrite -a ${tmpdir}/libvmod_wrong.so { @@ -111,7 +111,7 @@ filewrite -a ${tmpdir}/libvmod_wrong.so { "Vmod_vmod_wrong_Func", "0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000000", - "22", + "23", "0" ], [ "$FOOBAR" @@ -131,7 +131,7 @@ filewrite -a ${tmpdir}/libvmod_wrong.so { "Vmod_vmod_wrong_Func", "0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000000", - "22", + "23", "0" ] ] @@ -149,7 +149,7 @@ filewrite -a ${tmpdir}/libvmod_wrong.so { "Vmod_vmod_wrong_Func", "0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000000", - "22", + "23", "0" ], [ "$CPROTO" @@ -171,7 +171,7 @@ filewrite -a ${tmpdir}/libvmod_wrong.so { "Vmod_vmod_std_Func", "0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000000", - "22", + "23", "0" ], [ "$CPROTO", "/* blabla */" diff --git a/bin/vinyltest/tests/m00055.vtc b/bin/vinyltest/tests/m00055.vtc index 89c7775235..39aad260f8 100644 --- a/bin/vinyltest/tests/m00055.vtc +++ b/bin/vinyltest/tests/m00055.vtc @@ -21,7 +21,7 @@ filewrite -a ${tmpdir}/libvmod_wrong.so { "Vmod_vmod_wrong_Func", "0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000000", - "22", + "23", "0" ], [ diff --git a/configure.ac b/configure.ac index ec0144e5fa..a33b76a9cd 100644 --- a/configure.ac +++ b/configure.ac @@ -4,7 +4,7 @@ Copyright (c) 2006-2026 Varnish Software Copyright 2010-2026 UPLEX - Nils Goroll Systemoptimierung Copyright 2026 The Vinyl Cache Project]) AC_REVISION([$Id$]) -AC_INIT([Vinyl Cache], [trunk], [vinyl-dev@vinyl-cache.org], [vinyl-cache]) +AC_INIT([Vinyl Cache], [9.0.0], [vinyl-dev@vinyl-cache.org], [vinyl-cache]) AC_CONFIG_SRCDIR(include/miniobj.h) if ! test -f "${srcdir}/bin/vinyltest/vtest2/src/vtc_main.c" ; then AC_MSG_ERROR([vtest2 seems to be missing, use "git clone --recursive" or "git submodule update --init"]) diff --git a/doc/sphinx/index.rst b/doc/sphinx/index.rst index df15821552..b91c77533d 100644 --- a/doc/sphinx/index.rst +++ b/doc/sphinx/index.rst @@ -40,9 +40,9 @@ Conventions used in this manual include: Longer listings like example command output and VCL look like this:: $ /opt/vinyl/sbin/vinyld -V - vinyld (vinyl-8.0.0 revision 1234567) + vinyld (vinyl-9.0.0 revision 1234567) Copyright (c) 2006 Verdens Gang AS - Copyright (c) 2006-2025 Varnish Software + Copyright (c) 2006-2026 Varnish Software .. For maintainers: diff --git a/doc/sphinx/whats-new/index.rst b/doc/sphinx/whats-new/index.rst index c946ebb2fa..84a79559a6 100644 --- a/doc/sphinx/whats-new/index.rst +++ b/doc/sphinx/whats-new/index.rst @@ -20,10 +20,6 @@ Software as a fork. Vinyl Cache 9.0 --------------- -**Note: These are working documents for a future release, with running -updates for changes in the development branch. For changes in the -released versions of Varnish, see the chapters listed below.** - .. toctree:: :maxdepth: 2 diff --git a/include/vrt.h b/include/vrt.h index 71e12dce6f..f6128018be 100644 --- a/include/vrt.h +++ b/include/vrt.h @@ -46,7 +46,7 @@ # error "include vdef.h before vrt.h" #endif -#define VRT_MAJOR_VERSION 22U +#define VRT_MAJOR_VERSION 23U #define VRT_MINOR_VERSION 0U @@ -57,7 +57,17 @@ * Whenever something is deleted or changed in a way which is not * binary/load-time compatible, increment MAJOR version * - * 22.1 (trunk) + * 23.0 (2026-03-16) + * [cache.h] http_method_eq() added + * [cache.h] http_method_among() added + * [cache.h] http_SetWellKnownMethod() added + * VRT_r_req_max_age() added + * VRT_l_req_max_age() added + * VRT_u_req_max_age() added + * VRT_r_bereq_retry_connect() added + * VRT_l_bereq_retry_connect() added + * VRT_r_beresp_storage_hint() removed + * VRT_l_beresp_storage_hint() removed * "vcl_name" member added to vrt_backend_probe{} * VRT_PROBE_string() added * 22.0 (2025-09-15) From 9a14db0bcb24af01641c3493124c4c0219b98f2b Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Tue, 17 Mar 2026 14:47:31 +0100 Subject: [PATCH 173/196] Update css to keep in sync with the homepage --- doc/sphinx/_static/custom.css | 55 ++++++++++++++++++++++++++++++++++- 1 file changed, 54 insertions(+), 1 deletion(-) diff --git a/doc/sphinx/_static/custom.css b/doc/sphinx/_static/custom.css index 5b14d7af22..439f0af626 100644 --- a/doc/sphinx/_static/custom.css +++ b/doc/sphinx/_static/custom.css @@ -247,6 +247,34 @@ body { /* Elements */ +/* Mascot */ + +:has(.mascot) { + --mascot-min: 150px; + --mascot-mid: 30%; + --mascot-max: 300px; + --mascot-width: clamp(var(--mascot-min), var(--mascot-mid), var(--mascot-max)); +} + +.mascot { + --glow-color: rgba(from color-mix(in srgb, var(--color-vinyl-brand) 50%, white 50%) r g b / .75); + --glow: drop-shadow(0 0 5px var(--glow-color)) drop-shadow(0 0 10px var(--glow-color)) drop-shadow(0 0 20px var(--glow-color)) drop-shadow(0 0 40px var(--glow-color)); + display: block; + width: var(--mascot-width); +} + +:root:has([data-theme="dark"]) { + .mascot { + filter: var(--glow); + } +} + +@media (prefers-color-scheme: dark) { + .mascot { + filter: var(--glow); + } +} + /* Homepage introduction block */ .intro-card { @@ -254,8 +282,30 @@ body { var(--color-theme-main-10), var(--color-vinyl-brand) ); - padding: 1rem 1.5rem; + position: relative; + overflow: hidden; margin-inline: -1.5rem; + --mascot-min: 125px; + --mascot-mid: 25%; + --mascot-max: 250px; + padding: 1rem calc(var(--mascot-width) + 2rem) 1rem 2rem; + @media (width < 40em) { + padding: 1rem 3rem calc(var(--mascot-width) - 3rem) 2rem; + } +} + +.intro-card .mascot { + position: absolute; + float: right; + bottom: 0; + right: 0; + margin-left: 1rem; +} + +.intro-card::after { + clear: both; + display: block; + content: ''; } .intro-card h2 { @@ -285,6 +335,9 @@ body { background-color: var(--color-theme-main-80); } +/* custom.css | https://vinyl-cache.org/_static/custom.css */ + + /* Timestamps for news items */ time:has(+h3), From 322dbd9cc030b03ab125a328f44cbf1a9a874cfc Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 20 Mar 2026 15:42:20 +0100 Subject: [PATCH 174/196] RST polish --- include/tbl/params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/tbl/params.h b/include/tbl/params.h index 4d86b2aab7..cc49a49ab6 100644 --- a/include/tbl/params.h +++ b/include/tbl/params.h @@ -597,7 +597,7 @@ PARAM_SIMPLE( "objects from the backend and store them compressed. If a client " "does not support gzip encoding Vinyl Cache will uncompress compressed " "objects on demand. Vinyl Cache will also rewrite the Accept-Encoding " - "header of clients indicating support for gzip to:\n" + "header of clients indicating support for gzip to::\n\n" " Accept-Encoding: gzip\n" "\n" "Clients that do not support gzip will have their Accept-Encoding " From e4c9dc4245271ba02f8c762eab72f1529c1ba885 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 19 Mar 2026 14:44:26 +0100 Subject: [PATCH 175/196] Change VINYL_STATE_DIR default to ${localstatedir}/lib/vinyl-cache Partially reverts 879c9b37ca108e365d4eb16ad391e28a8cfccd46 This restores the option to set/keep localstatedir at ${prefix}/var and still have VINYL_STATE_DIR in {localstatedir}/lib/vinyl-cache, and not /var/run. Consequently, this fixes running vinyld with default options on systems where /var/run is mounted noexec (e.g. Debian) and restores the possibility to wholly contain the installation under ${prefix}. The patch does not use ${sharedstatedir}, because its default is ${prefix}/com Closes #4477 --- Makefile.am | 4 +--- configure.ac | 7 +------ 2 files changed, 2 insertions(+), 9 deletions(-) diff --git a/Makefile.am b/Makefile.am index 673f06cf93..e77d541875 100644 --- a/Makefile.am +++ b/Makefile.am @@ -44,9 +44,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS += --with-unwind endif install-data-local: - if test "${VINYL_STATE_DIR}" = "$(DESTDIR)$(localstatedir)/vinyl-cache" ; then \ - $(install_sh) -d -m 0755 "${VINYL_STATE_DIR}"; \ - fi + $(install_sh) -d -m 0755 "${VINYL_STATE_DIR}" distclean-local: -find . '(' -name '*.gcda' -o -name '*.gcda' ')' -exec rm '{}' ';' diff --git a/configure.ac b/configure.ac index ec0144e5fa..f3a37a6b55 100644 --- a/configure.ac +++ b/configure.ac @@ -640,12 +640,7 @@ if test "x$ac_cv_have_working_close_range" = xyes; then [Define if OS has working close_range()]) fi -# Run-time directory -if test "${localstatedir}" = '${prefix}/var' ; then - VINYL_STATE_DIR='/var/run' -else - VINYL_STATE_DIR='${localstatedir}/vinyl-cache' -fi +VINYL_STATE_DIR='${localstatedir}/lib/vinyl-cache' AC_SUBST(VINYL_STATE_DIR) # Default configuration directory. From da1450b78da945a4be664ac880d14d58b30de36d Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 19 Mar 2026 16:13:32 +0100 Subject: [PATCH 176/196] Add --with-statedir configure argument to set VINYL_STATE_DIR directly If VINYL_STATE_DIR could only be set to ${localstatedir}/lib/vinyl-cache, we can not (reliably, without additional lifecycle management) use an ephemeral ${localstatedir} like /dev/shm, simply because we create a subdirectory of VINYL_STATE_DIR for the actual state (see -n argument, defaulting to vinyld), and ${localstatedir}/lib/vinyl-cache might not exist. Adding recursive mkdir code to vinyld could also solve the problem, but would add the complication of which permissions to recursively create directories with, in particular considering that vinyld may or may not be started with elevated privileges. To avoid all these complications, we add a configure argument to directly set VINYL_STATE_DIR Related to #4477 --- configure.ac | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index f3a37a6b55..34acfe022c 100644 --- a/configure.ac +++ b/configure.ac @@ -640,7 +640,10 @@ if test "x$ac_cv_have_working_close_range" = xyes; then [Define if OS has working close_range()]) fi -VINYL_STATE_DIR='${localstatedir}/lib/vinyl-cache' +AC_ARG_WITH([statedir], + AS_HELP_STRING([--with-statedir=DIR], [Location of the local state directory, default ${localstatedir}/lib/vinyl-cache]), + [VINYL_STATE_DIR="$withval"], + [VINYL_STATE_DIR='${localstatedir}/lib/vinyl-cache']) AC_SUBST(VINYL_STATE_DIR) # Default configuration directory. From 4196617a1817a29ddf54a7a666099aa02fe510f1 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Mon, 23 Mar 2026 17:24:26 +0100 Subject: [PATCH 177/196] Fix DESTDIR builds Ref 43dcc6f024a8a2bd6bc6f2970046c08859e17749 --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index e77d541875..c1f87a253e 100644 --- a/Makefile.am +++ b/Makefile.am @@ -44,7 +44,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS += --with-unwind endif install-data-local: - $(install_sh) -d -m 0755 "${VINYL_STATE_DIR}" + $(install_sh) -d -m 0755 "$(DESTDIR)/${VINYL_STATE_DIR}" distclean-local: -find . '(' -name '*.gcda' -o -name '*.gcda' ')' -exec rm '{}' ';' From 673c6c61fd94735d96c274f2a4404423c36df62f Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 29 Mar 2026 19:37:08 +0200 Subject: [PATCH 178/196] Add a basic CI 'make distcheck' --- .forgejo/workflows/build.yaml | 36 +++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 .forgejo/workflows/build.yaml diff --git a/.forgejo/workflows/build.yaml b/.forgejo/workflows/build.yaml new file mode 100644 index 0000000000..12dfccfe33 --- /dev/null +++ b/.forgejo/workflows/build.yaml @@ -0,0 +1,36 @@ +on: [pull_request] +jobs: + distcheck: + runs-on: debian + steps: + - name: apt-get + run: | + apt-get update + apt-get install -y git + - name: setup + run: | + git config --global core.autocrlf false + git config --global --add safe.directory ${FORGEJO_WORKSPACE} + - uses: https://code.vinyl-cache.org/forgejo/sane-checkout.git@v0.3 + - name: prerequisites + run: | + apt-get install -y \ + make \ + automake \ + autotools-dev \ + libedit-dev \ + libjemalloc-dev \ + libncurses-dev \ + libpcre2-dev \ + libtool \ + pkg-config \ + python3-docutils \ + python3-sphinx \ + cpio \ + \ + graphviz \ + pip furo + - name: build + run: | + ./autogen.des + make -j10 distcheck || (find . -name test-suite.log | xargs cat) From f1daaf2b616d38e6cfd9327074c6fe317a51c2f7 Mon Sep 17 00:00:00 2001 From: Poul-Henning Kamp Date: Fri, 13 Mar 2026 12:41:03 +0000 Subject: [PATCH 179/196] Consistently rewrite both IPv4-compatible-IPv6 and IPv4-mapped-IPv6 addresses. --- bin/vinyltest/tests/i00002.vtc | 42 ++++++++++++++++++++++ lib/libvinyl/vsa.c | 66 ++++++++++++++++++++++++++++++---- lib/libvinyl/vtcp.c | 6 ---- 3 files changed, 102 insertions(+), 12 deletions(-) create mode 100644 bin/vinyltest/tests/i00002.vtc diff --git a/bin/vinyltest/tests/i00002.vtc b/bin/vinyltest/tests/i00002.vtc new file mode 100644 index 0000000000..aa3eb0ec78 --- /dev/null +++ b/bin/vinyltest/tests/i00002.vtc @@ -0,0 +1,42 @@ +vtest "Normalization of IPv4 compatible and mapped IPv6 addresses" + +feature ipv4 +feature ipv6 + +server s1 { + rxreq + txresp -body "012345\n" +} -start + +vinyl v1 -proto PROXY -vcl+backend { + + acl a0 { + "192.168/16"; + } + + acl a1 { + "168.192/16"; + } + + sub vcl_deliver { + set resp.http.ca = client.ip; + set resp.http.sa = server.ip; + set resp.http.la = local.ip; + set resp.http.ra = remote.ip; + set resp.http.cm = (client.ip ~ a0) + " - " + (client.ip ~ a1); + set resp.http.sm = (server.ip ~ a0) + " - " + (server.ip ~ a1); + } + +} -start + +client c1 -proxy1 "[::c0a8:c0a8]:1234 [::ffff:a8c0:a8c0]:5678" { + + txreq -url "/1" + rxresp + expect resp.status == 200 + expect resp.http.ca == "192.168.192.168" + expect resp.http.sa == "168.192.168.192" + expect resp.http.cm == "true - false" + expect resp.http.sm == "false - true" + +} -run diff --git a/lib/libvinyl/vsa.c b/lib/libvinyl/vsa.c index 7ea79685a8..288faf27fe 100644 --- a/lib/libvinyl/vsa.c +++ b/lib/libvinyl/vsa.c @@ -157,13 +157,16 @@ * I have decided to try to contain this crap in this single * source-file, with only minimum leakage into the rest of Vinyl, * which will only know of pointers to "struct suckaddr", the naming - * of which is my of the historical narrative above. + * of which is my considered opinion of the historical narrative above. * * And you don't need to take my word for this, you can see it all * in various #include files on your own system. If you are on * a Solaris derivative, don't miss the beautiful horror hidden in the * variant definition of IPv6 addresses between kernel and userland. * + * Update (2026): Gosh, who could ever have foreseen that IPv4 + * mapped into IPv6 would become a mess ? Now we normalize + * all such VSAs to IPv4 at the VSA level. */ struct suckaddr { @@ -188,6 +191,52 @@ const struct suckaddr *bogo_ip = &bogo_ip_vsa; static struct suckaddr bogo_ip6_vsa; const struct suckaddr *bogo_ip6 = &bogo_ip6_vsa; +static const uint8_t map4_0_80[10] = {0,0,0,0,0,0,0,0,0,0}; +static const uint8_t map4_0_104[13] = {0,0,0,0,0,0,0,0,0,0,0,0,0}; +static const uint8_t map4_0_96[12] = {0,0,0,0,0,0,0,0,0,0,0x00,0x00}; +static const uint8_t map4_ffff_96[12] = {0,0,0,0,0,0,0,0,0,0,0xff,0xff}; + +/* + * Rewrite IPv4-in-IPv6 suckaddr's in place + */ + +static void +vsa_normalize(struct suckaddr *sua) +{ + CHECK_OBJ_NOTNULL(sua, SUCKADDR_MAGIC); + if (sua->u.sa.sa_family != PF_INET6) + return; + uint8_t *p6 = (void*)&sua->u.sa6.sin6_addr; + + if (memcmp(p6, map4_0_80, sizeof map4_0_80)) { + // A "normal" IPv6 address. + return; + } + + if (!memcmp(p6, map4_0_104, sizeof map4_0_104)) { + // IPv6 loopback + // IPv6 "any" + // IPv4-compat-IPv6, but IPv4 is in 0/8 IPv4 + return; + } + + if (!memcmp(p6, map4_0_96, sizeof map4_0_96)) { + // RFC3513 2.5.5 - convert + } else if (!memcmp(p6, map4_ffff_96, sizeof map4_ffff_96)) { + // RFC4291 2.5.5.2 - convert + } else { + return; + } + + uint8_t *p4 = (void*)&sua->u.sa4.sin_addr; + sua->u.sa.sa_family = PF_INET; + memcpy(p4, p6+12, 4); + +#ifdef HAVE_STRUCT_SOCKADDR_SA_LEN + sua->u.sa.sa_len = sizeof(sua->u.sa4); +#endif +} + void VSA_Init(void) { @@ -228,8 +277,8 @@ VSA_GetPtr(const struct suckaddr *sua, const unsigned char ** dst) * Return the size of a struct sockaddr in a struck suckaddr * or 0 if unknown family */ -static inline -socklen_t sua_len(const struct sockaddr *sa) +static inline socklen_t +sua_len(const struct sockaddr *sa) { switch (sa->sa_family) { @@ -332,9 +381,11 @@ VSA_Build(void *d, const void *s, unsigned sal) switch (l) { case sizeof sua->u.sa4: memcpy(&sua->u.sa4, s, l); + assert(sua->u.sa.sa_family == PF_INET); break; case sizeof sua->u.sa6: memcpy(&sua->u.sa6, s, l); + assert(sua->u.sa.sa_family == PF_INET6); break; default: WRONG("VSA protocol vs. size"); @@ -342,6 +393,7 @@ VSA_Build(void *d, const void *s, unsigned sal) #ifdef HAVE_STRUCT_SOCKADDR_SA_LEN sua->u.sa.sa_len = (unsigned char)l; #endif + vsa_normalize(sua); return (sua); } @@ -451,9 +503,11 @@ VSA_get ## which ## name(int fd, void *d, size_t l) \ INIT_OBJ(sua, SUCKADDR_MAGIC); \ sl = sizeof(sua->u); \ r = get ## which ## name(fd, &sua->u.sa, &sl); \ - \ - return (r == 0 ? sua : NULL); \ -} \ + if (r != 0) \ + return (NULL); \ + vsa_normalize(sua); \ + return (sua); \ +} VSA_getname(sock) VSA_getname(peer) diff --git a/lib/libvinyl/vtcp.c b/lib/libvinyl/vtcp.c index b154921174..650905079f 100644 --- a/lib/libvinyl/vtcp.c +++ b/lib/libvinyl/vtcp.c @@ -83,12 +83,6 @@ vtcp_sa_to_ascii(const void *sa, socklen_t l, char *abuf, unsigned alen, (void)snprintf(pbuf, plen, "Failed"); return; } - /* XXX dirty hack for v4-to-v6 mapped addresses */ - if (abuf != NULL && strncmp(abuf, "::ffff:", 7) == 0) { - for (i = 0; abuf[i + 7]; ++i) - abuf[i] = abuf[i + 7]; - abuf[i] = '\0'; - } } /*--------------------------------------------------------------------*/ From d40c6ebfd7f4b9f26dc4245ba9bca171b0d8921b Mon Sep 17 00:00:00 2001 From: Dag Haavi Finstad Date: Thu, 26 Feb 2026 09:44:57 +0100 Subject: [PATCH 180/196] std_c00001: Set vsl_buffer before shrinking workspaces When vsl_buffer was increased from 4k to 16k in 8869801544, three tests with small workspaces were updated to explicitly set vsl_buffer to 4k. This test was missed, causing panics in VBO_GetBusyObj() and Req_New() when the 16k VSL buffer exceeds the 12000-byte pool allocation. The bug has been latent since July 2021 but was masked by mempool item reuse: the param.set happens mid-test after pool items have already been allocated at 96k, and those larger items keep getting recycled. A fresh 12k allocation (which deterministically panics) only occurs when the guard thread injects a new item before old ones are reused, which is timing-dependent. The recent move to github actions is likely the thing that made this visible. Committer edit: Adjusted to Vinyl Cache Fixes: https://github.com/varnish/varnish/issues/8 Fixes: https://github.com/varnish/varnish/issues/9 --- vmod/tests/std_c00001.vtc | 1 + 1 file changed, 1 insertion(+) diff --git a/vmod/tests/std_c00001.vtc b/vmod/tests/std_c00001.vtc index 17db110605..56f0af8583 100644 --- a/vmod/tests/std_c00001.vtc +++ b/vmod/tests/std_c00001.vtc @@ -79,6 +79,7 @@ client c1 { server s1 -wait +vinyl v1 -cliok "param.set vsl_buffer 4k" vinyl v1 -cliok "param.set workspace_client 12000" vinyl v1 -cliok "param.set workspace_backend 12000" From 8e83878e1f3934a073cef0d16ef8cb44a728c07c Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 11 Dec 2025 12:20:17 +0100 Subject: [PATCH 181/196] lru: Do not add failed objects Until now we kept failed objects momentarily on the LRU. This is wasteful, because they never get inserted into EXP (which happens via HSH_Unbusy() -> EXP_Insert), and as such will be removed from cache when the last reference goes away. Why is this change correct? - in HSH_Lookup(), we explicitly skip OC_F_FAILED - the only place where OC_F_FAILED can be gained is HSH_Fail() - HSH_Fail() asserts that the object is still busy - LRU_Add() gets called via HSH_DerefBoc() -> ObjBocDone() when the boc's last reference goes away --- bin/vinyld/storage/storage_lru.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/bin/vinyld/storage/storage_lru.c b/bin/vinyld/storage/storage_lru.c index 0a7db500b7..528d15968e 100644 --- a/bin/vinyld/storage/storage_lru.c +++ b/bin/vinyld/storage/storage_lru.c @@ -87,7 +87,7 @@ LRU_Add(struct objcore *oc, vtim_real now) CHECK_OBJ_NOTNULL(oc, OBJCORE_MAGIC); - if (oc->flags & OC_F_PRIVATE) + if (oc->flags & (OC_F_PRIVATE|OC_F_FAILED)) return; AZ(oc->boc); @@ -109,7 +109,7 @@ LRU_Remove(struct objcore *oc) CHECK_OBJ_NOTNULL(oc, OBJCORE_MAGIC); - if (oc->flags & OC_F_PRIVATE) + if (oc->flags & (OC_F_PRIVATE|OC_F_FAILED)) return; AZ(oc->boc); @@ -130,7 +130,7 @@ LRU_Touch(struct worker *wrk, struct objcore *oc, vtim_real now) CHECK_OBJ_NOTNULL(wrk, WORKER_MAGIC); CHECK_OBJ_NOTNULL(oc, OBJCORE_MAGIC); - if (oc->flags & OC_F_PRIVATE || isnan(oc->last_lru)) + if (oc->flags & (OC_F_PRIVATE|OC_F_FAILED) || isnan(oc->last_lru)) return; /* @@ -182,6 +182,7 @@ LRU_NukeOne(struct worker *wrk, struct lru *lru) Lck_Lock(&lru->mtx); VTAILQ_FOREACH_SAFE(oc, &lru->lru_head, lru_list, oc2) { CHECK_OBJ_NOTNULL(oc, OBJCORE_MAGIC); + AZ(oc->flags & OC_F_FAILED)); AZ(isnan(oc->last_lru)); VSLb(wrk->vsl, SLT_ExpKill, "LRU_Cand p=%p f=0x%x r=%d", From 70ab8d3d0af163631ad36ff928aa79c4b89ada6a Mon Sep 17 00:00:00 2001 From: Guillaume Quintard Date: Wed, 15 Oct 2025 14:24:34 -0700 Subject: [PATCH 182/196] [ci] update target distributions --- .circleci/config.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.circleci/config.yml b/.circleci/config.yml index 5b651d57ff..a10fa9147b 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -433,12 +433,13 @@ workflows: matrix: parameters: platform: - - ubuntu:focal - ubuntu:jammy - ubuntu:noble - debian:bookworm + - debian:trixie - almalinux:8 - almalinux:9 + - almalinux:10 - fedora:latest - alpine:latest rclass: From 3877858a93b1fa1725729fc92494bde9c598dd17 Mon Sep 17 00:00:00 2001 From: Guillaume Quintard Date: Wed, 15 Oct 2025 14:45:51 -0700 Subject: [PATCH 183/196] [ci] build-pkgs is a boolean --- .circleci/config.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.circleci/config.yml b/.circleci/config.yml index a10fa9147b..b42ee03b4b 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -23,8 +23,8 @@ parameters: --disable-stack-protector \ --with-persistent-storage \ build-pkgs: - type: string - default: "" + type: boolean + default: false jobs: dist: From f424e1633881cc0a30cedb172af9d68f34d98a12 Mon Sep 17 00:00:00 2001 From: Guillaume Quintard Date: Thu, 16 Oct 2025 18:45:28 -0700 Subject: [PATCH 184/196] [cci] also install epel for almalinux:10 --- .circleci/config.yml | 8 ++++---- .circleci/make-rpm-packages.sh | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/.circleci/config.yml b/.circleci/config.yml index b42ee03b4b..b27311dece 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -231,16 +231,16 @@ jobs: case "<< parameters.dist >>" in almalinux|fedora) case "<< parameters.dist >>:<< parameters.release >>" in - almalinux:9) + almalinux:8) dnf -y install "dnf-command(config-manager)" - dnf config-manager --set-enabled crb + dnf config-manager --set-enabled powertools dnf -y install diffutils dnf -y install epel-release dnf -y groupinstall "Development Tools" ;; - almalinux:8) + almalinux:*) dnf -y install "dnf-command(config-manager)" - dnf config-manager --set-enabled powertools + dnf config-manager --set-enabled crb dnf -y install diffutils dnf -y install epel-release dnf -y groupinstall "Development Tools" diff --git a/.circleci/make-rpm-packages.sh b/.circleci/make-rpm-packages.sh index 1b11342814..9f6cf77ab4 100755 --- a/.circleci/make-rpm-packages.sh +++ b/.circleci/make-rpm-packages.sh @@ -14,14 +14,14 @@ elif [ -z "$PARAM_DIST" ]; then fi case "$PARAM_DIST:$PARAM_RELEASE" in - almalinux:9) + almalinux:8) dnf -y install 'dnf-command(config-manager)' - dnf config-manager --set-enabled crb + dnf config-manager --set-enabled powertools dnf -y install epel-release ;; - almalinux:8) + almalinux:*) dnf -y install 'dnf-command(config-manager)' - dnf config-manager --set-enabled powertools + dnf config-manager --set-enabled crb dnf -y install epel-release ;; esac From 353a07655cce36cd982da2bf7a280d8665e11fbe Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Wed, 1 Apr 2026 15:47:33 +0200 Subject: [PATCH 185/196] fix sloppy commit 8e83878e1f3934a073cef0d16ef8cb44a728c07c I am sorry --- bin/vinyld/storage/storage_lru.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/vinyld/storage/storage_lru.c b/bin/vinyld/storage/storage_lru.c index 528d15968e..2771743670 100644 --- a/bin/vinyld/storage/storage_lru.c +++ b/bin/vinyld/storage/storage_lru.c @@ -182,7 +182,7 @@ LRU_NukeOne(struct worker *wrk, struct lru *lru) Lck_Lock(&lru->mtx); VTAILQ_FOREACH_SAFE(oc, &lru->lru_head, lru_list, oc2) { CHECK_OBJ_NOTNULL(oc, OBJCORE_MAGIC); - AZ(oc->flags & OC_F_FAILED)); + AZ(oc->flags & (OC_F_PRIVATE|OC_F_FAILED)); AZ(isnan(oc->last_lru)); VSLb(wrk->vsl, SLT_ExpKill, "LRU_Cand p=%p f=0x%x r=%d", From 7daa40f74c42176a32d0ccecea287156a4a35611 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Jun 2025 14:35:27 +0200 Subject: [PATCH 186/196] cache_expire: work the expire inbox in batches Before this change, we would strictly work the expire thread's inbox one item at a time: lock, take it off the list, update the exp flags, unlock, work it. This requires one lock/unlock cycle per object core in the exp inbox. We now create a batch array of items: Under the lock, we do all the work as before, but remember up to 1024 objcore pointers and their original exp flags in an array, which we then work outside the lock, increasing overall efficiency through less lock contention and better cache locality. Why an array of items, why not repurpose the inbox (exp_list)? In fact, we will do that in another commit, but at this point, the list is not the right data structure: The inbox semantics require to (atomically, under a lock) update the exp_flags to signify an oc being removed or the commands being processed. Yet to process the oc later, we need the original flags. So we use an array of pointers to the oc together with the original flags. (one alternative would be a list head for every possible flag combination, but that is probably overly complex). This changes the order of events slightly: exp_mail_it() inserts OC_EF_REMOVE jobs at the head of the list, because they will immediately free resources and are thus more important than additions to the expire binheap; also mailed object cores have a change of getting removed before even being added while waiting in the inbox. With batching, we no longer follow this priority strictly: By taking the first (up to) 1024 items from the inbox before re-checking it, we might process inbox commands which we would not have before. This is not (yet) a change in behavior for the case when the expire thread is under pressure, because the inbox will eventually contain more than 1024 OC_EF_REMOVE items at the start, and hence the expire thread will only work these. The choice of array size 1024 is arbitrary: It is deemed large enough for batching to have an effect, yet small enough to matter wrt available stack space (on 64bit, the array of this size needs 16KB). Also, we now unconditionally call exp_expire(), because either we have processed the inbox and need a new tnext for potentially blocking in the next iteration, or we did not, waited for the next due time and do need to process the binheap anyway. --- bin/vinyld/cache/cache_expire.c | 45 +++++++++++++++++++++++++++------ 1 file changed, 37 insertions(+), 8 deletions(-) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index 80666fd129..12c861a122 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -418,9 +418,20 @@ object_update(void *priv, void *p, unsigned u) oc->timer_idx = u; } +struct exp_inbox_item { + unsigned magic; +#define EXP_INBOX_ITEM_MAGIC 0x0519627d + unsigned flags; + struct objcore *oc; +}; + static void * v_matchproto_(bgthread_t) exp_thread(struct worker *wrk, void *priv) { + struct exp_inbox_item batch[1024]; + struct exp_inbox_item * const batch_lim = + batch + sizeof batch / sizeof *batch; + struct exp_inbox_item *todo, *item; struct objcore *oc; vtim_real t = 0, tnext = 0; struct exp_priv *ep; @@ -433,12 +444,22 @@ exp_thread(struct worker *wrk, void *priv) wrk->vsl = &ep->vsl; ep->heap = VBH_new(NULL, object_cmp, object_update); AN(ep->heap); + + for (item = batch; item < batch_lim; item++) + INIT_OBJ(item, EXP_INBOX_ITEM_MAGIC); + while (exp_shutdown == 0) { + todo = batch; + Lck_Lock(&ep->mtx); - oc = VSTAILQ_FIRST(&ep->inbox); - CHECK_OBJ_ORNULL(oc, OBJCORE_MAGIC); - if (oc != NULL) { + while ((oc = VSTAILQ_FIRST(&ep->inbox)) != NULL && + todo < batch_lim) { + CHECK_OBJ(oc, OBJCORE_MAGIC); + CHECK_OBJ(todo, EXP_INBOX_ITEM_MAGIC); + AZ(todo->flags); + AZ(todo->oc); + assert(oc->refcnt >= 1); assert(oc->exp_flags & OC_EF_POSTED); VSTAILQ_REMOVE(&ep->inbox, oc, objcore, exp_list); @@ -449,7 +470,12 @@ exp_thread(struct worker *wrk, void *priv) oc->exp_flags = 0; else oc->exp_flags &= OC_EF_REFD; - } else if (tnext > t) { + + todo->flags = flags; + todo->oc = oc; + todo++; + } + if (todo == batch && tnext > t) { VSL_Flush(&ep->vsl, 0); Pool_Sumstat(wrk); (void)Lck_CondWaitUntil(&ep->condvar, &ep->mtx, tnext); @@ -458,10 +484,13 @@ exp_thread(struct worker *wrk, void *priv) t = VTIM_real(); - if (oc != NULL) - exp_inbox(ep, oc, flags, t); - else - tnext = exp_expire(ep, t); + for (item = batch; item < todo; item++) { + CHECK_OBJ(item, EXP_INBOX_ITEM_MAGIC); + exp_inbox(ep, item->oc, item->flags, t); + INIT_OBJ(item, EXP_INBOX_ITEM_MAGIC); + } + + tnext = exp_expire(ep, t); } wrk->vsl = NULL; VSL_Free(&ep->vsl); From 87a3a0a8aea2ef074594d0a9b7875db52ce56c07 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Jun 2025 19:21:38 +0200 Subject: [PATCH 187/196] cache_expire: trivial refactor - move oc removal to own function --- bin/vinyld/cache/cache_expire.c | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index 12c861a122..2eb130477c 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -282,6 +282,26 @@ EXP_Rearm(struct objcore *oc, vtim_real now, } } +/*-------------------------------------------------------------------- + * Finish removal of an oc + */ + +static void +exp_remove_oc(struct worker *wrk, struct objcore *oc, vtim_real now) +{ + + CHECK_OBJ_NOTNULL(oc, OBJCORE_MAGIC); + + assert(oc->timer_idx == VBH_NOIDX); + assert(oc->refcnt > 0); + AZ(oc->exp_flags); + VSLb(wrk->vsl, SLT_ExpKill, "EXP_Removed x=%ju t=%.0f h=%jd", + VXID(ObjGetXID(wrk, oc)), EXP_Ttl(NULL, oc) - now, + (intmax_t)oc->hits); + ObjSendEvent(wrk, oc, OEV_EXPIRE); + (void)HSH_DerefObjCore(wrk, &oc); +} + /*-------------------------------------------------------------------- * Handle stuff in the inbox */ @@ -302,14 +322,7 @@ exp_inbox(struct exp_priv *ep, struct objcore *oc, unsigned flags, vtim_real now assert(oc->timer_idx != VBH_NOIDX); VBH_delete(ep->heap, oc->timer_idx); } - assert(oc->timer_idx == VBH_NOIDX); - assert(oc->refcnt > 0); - AZ(oc->exp_flags); - VSLb(&ep->vsl, SLT_ExpKill, "EXP_Removed x=%ju t=%.0f h=%jd", - VXID(ObjGetXID(ep->wrk, oc)), EXP_Ttl(NULL, oc) - now, - (intmax_t)oc->hits); - ObjSendEvent(ep->wrk, oc, OEV_EXPIRE); - (void)HSH_DerefObjCore(ep->wrk, &oc); + exp_remove_oc(ep->wrk, oc, now); return; } From 75216c9b831443b0941f5311d76ba1e042a283c3 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Jun 2025 19:01:44 +0200 Subject: [PATCH 188/196] cache_expire: trivial refactor - inbox head as named struct --- bin/vinyld/cache/cache_expire.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index 2eb130477c..d95191c3cd 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -42,12 +42,14 @@ #include "vbh.h" #include "vtim.h" +VSTAILQ_HEAD(exp_inbox_head, objcore); + struct exp_priv { unsigned magic; #define EXP_PRIV_MAGIC 0x9db22482 /* shared */ struct lock mtx; - VSTAILQ_HEAD(,objcore) inbox; + struct exp_inbox_head inbox; pthread_cond_t condvar; /* owned by exp thread */ From a67cb458aa3a349a1b43ef80cf82e6f9e9a6d3ec Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Jun 2025 19:01:44 +0200 Subject: [PATCH 189/196] cache_expire: move OC_EF_REMOVE handling to exp_thread() This is in preparation of offloading exp_remove_oc(): The inbox list (exp_list linkage in struct oc) is free to use for OC_EF_REMOVE commands once we have processed the inbox, because the respective object core will be removed from cache and the exp_flags set to zero signal to exp_mailit() to keep out. So we now use the list to collect ocs which need to be dereferenced. Object cores with OC_EF_REMOVE and no OC_EF_INSERT set (that is, those on the binheap), will also continue to be collected on the batch array to have them deleted from the binheap. We also add a bit of abstraction around the list head, which will be extended in follow-up commits. For now, it serves for tracking the number of elements on the list and asserting on it. So once the batch is processed, we end up with a neat list of objects to de-reference. --- bin/vinyld/cache/cache_expire.c | 78 ++++++++++++++++++++++++++------- 1 file changed, 63 insertions(+), 15 deletions(-) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index d95191c3cd..1b0ad54cf4 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -304,12 +304,56 @@ exp_remove_oc(struct worker *wrk, struct objcore *oc, vtim_real now) (void)HSH_DerefObjCore(wrk, &oc); } +/*-------------------------------------------------------------------- + * keep track of ocs to deref + */ + +struct exp_deref { + unsigned magic; +#define EXP_DEREF_MAGIC 0xb5854b59 + unsigned n; + struct exp_inbox_head remove_head; +}; + +static void +exp_deref_work(struct worker *wrk, struct exp_deref *deref, vtim_real now) +{ + struct objcore *oc, *save; + unsigned n = 0; + + CHECK_OBJ_NOTNULL(deref, EXP_DEREF_MAGIC); + VSTAILQ_FOREACH_SAFE(oc, &deref->remove_head, exp_list, save) { + exp_remove_oc(wrk, oc, now); + n++; + } + assert(deref->n == n); + memset(deref, 0, sizeof *deref); +} + +// trivial function to wrap n increment. +static void +exp_deref_add_remove(struct exp_deref *deref, struct objcore *oc) +{ + + CHECK_OBJ_NOTNULL(deref, EXP_DEREF_MAGIC); + VSTAILQ_INSERT_TAIL(&deref->remove_head, oc, exp_list); + deref->n++; +} + +static void +exp_deref_init(struct exp_deref *deref) +{ + + INIT_OBJ(deref, EXP_DEREF_MAGIC); + VSTAILQ_INIT(&deref->remove_head); +} + /*-------------------------------------------------------------------- * Handle stuff in the inbox */ static void -exp_inbox(struct exp_priv *ep, struct objcore *oc, unsigned flags, vtim_real now) +exp_inbox(struct exp_priv *ep, struct objcore *oc, unsigned flags) { CHECK_OBJ_NOTNULL(ep, EXP_PRIV_MAGIC); @@ -319,14 +363,7 @@ exp_inbox(struct exp_priv *ep, struct objcore *oc, unsigned flags, vtim_real now VSLb(&ep->vsl, SLT_ExpKill, "EXP_Inbox flg=%x p=%p e=%.6f f=0x%x", flags, oc, oc->timer_when, oc->flags); - if (flags & OC_EF_REMOVE) { - if (!(flags & OC_EF_INSERT)) { - assert(oc->timer_idx != VBH_NOIDX); - VBH_delete(ep->heap, oc->timer_idx); - } - exp_remove_oc(ep->wrk, oc, now); - return; - } + AZ(flags & OC_EF_REMOVE); // handled in exp_thread if (flags & OC_EF_MOVE) { oc->timer_when = EXP_WHEN(oc); @@ -447,6 +484,7 @@ exp_thread(struct worker *wrk, void *priv) struct exp_inbox_item * const batch_lim = batch + sizeof batch / sizeof *batch; struct exp_inbox_item *todo, *item; + struct exp_deref deref; struct objcore *oc; vtim_real t = 0, tnext = 0; struct exp_priv *ep; @@ -464,7 +502,7 @@ exp_thread(struct worker *wrk, void *priv) INIT_OBJ(item, EXP_INBOX_ITEM_MAGIC); while (exp_shutdown == 0) { - + exp_deref_init(&deref); todo = batch; Lck_Lock(&ep->mtx); @@ -481,8 +519,12 @@ exp_thread(struct worker *wrk, void *priv) VSC_C_main->exp_received++; tnext = 0; flags = oc->exp_flags; - if (flags & OC_EF_REMOVE) + if (flags & OC_EF_REMOVE) { oc->exp_flags = 0; + exp_deref_add_remove(&deref, oc); + if (flags & OC_EF_INSERT) + continue; + } else oc->exp_flags &= OC_EF_REFD; @@ -490,22 +532,28 @@ exp_thread(struct worker *wrk, void *priv) todo->oc = oc; todo++; } - if (todo == batch && tnext > t) { + if (todo == batch && deref.n == 0 && tnext > t) { VSL_Flush(&ep->vsl, 0); Pool_Sumstat(wrk); (void)Lck_CondWaitUntil(&ep->condvar, &ep->mtx, tnext); } Lck_Unlock(&ep->mtx); - t = VTIM_real(); - for (item = batch; item < todo; item++) { CHECK_OBJ(item, EXP_INBOX_ITEM_MAGIC); - exp_inbox(ep, item->oc, item->flags, t); + if (item->flags & OC_EF_REMOVE) { + AZ(item->flags & OC_EF_INSERT); + VBH_delete(ep->heap, item->oc->timer_idx); + } + else + exp_inbox(ep, item->oc, item->flags); INIT_OBJ(item, EXP_INBOX_ITEM_MAGIC); } + t = VTIM_real(); tnext = exp_expire(ep, t); + + exp_deref_work(ep->wrk, &deref, t); } wrk->vsl = NULL; VSL_Free(&ep->vsl); From 48431f1b9562237ae593f37679d2b6e7dc6d71c5 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 15 Jun 2025 15:37:34 +0200 Subject: [PATCH 190/196] cache_expire: push stats every once in a while Otherwise, for big batches (think: 100Ks of objects) the n_object counter can get out of sync at human scales. --- bin/vinyld/cache/cache_expire.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index 1b0ad54cf4..d4fe4b55ee 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -325,6 +325,8 @@ exp_deref_work(struct worker *wrk, struct exp_deref *deref, vtim_real now) VSTAILQ_FOREACH_SAFE(oc, &deref->remove_head, exp_list, save) { exp_remove_oc(wrk, oc, now); n++; + if (n % 1024 == 0) + Pool_Sumstat(wrk); } assert(deref->n == n); memset(deref, 0, sizeof *deref); From 543cfeb31f8a9a5df26d49836afc9a7e837c4eb4 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Thu, 12 Jun 2025 19:38:28 +0200 Subject: [PATCH 191/196] cache_expire: limit scope of flags variable Yes, I know this is against our cstyle, but this is very useful to avoid confusion with item->flags. --- bin/vinyld/cache/cache_expire.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index d4fe4b55ee..3043a97094 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -490,7 +490,6 @@ exp_thread(struct worker *wrk, void *priv) struct objcore *oc; vtim_real t = 0, tnext = 0; struct exp_priv *ep; - unsigned flags = 0; CAST_OBJ_NOTNULL(ep, priv, EXP_PRIV_MAGIC); ep->wrk = wrk; @@ -510,6 +509,8 @@ exp_thread(struct worker *wrk, void *priv) Lck_Lock(&ep->mtx); while ((oc = VSTAILQ_FIRST(&ep->inbox)) != NULL && todo < batch_lim) { + unsigned flags; + CHECK_OBJ(oc, OBJCORE_MAGIC); CHECK_OBJ(todo, EXP_INBOX_ITEM_MAGIC); AZ(todo->flags); From 5d223c1e6c8fb9be6ee5489170c0b632117789b1 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Jun 2025 09:21:52 +0200 Subject: [PATCH 192/196] cache_expire: offload exp_remove_oc() to worker threads Now that we have a collection of objcores in a list, we can easily hand it off to another worker thread to run all the de-references. This step is the first building block towards exp scalability beyond the capacity of a single thread. We now hand the list of objects to be removed to a worker thread, once an (arbitrary) threshold of 128 objects to be removed is reached. If the expire inbox keeps growing, we keep tasking more and more worker threads, which will apply back pressure by allocating more system resources to expiry, and ultimately by no threads being available for entry of new objects into the cache. --- bin/vinyld/cache/cache_expire.c | 126 +++++++++++++++++++++++++++++++- 1 file changed, 125 insertions(+), 1 deletion(-) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index 3043a97094..b25378cecc 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -38,6 +38,7 @@ #include "cache_vinyld.h" #include "cache_objhead.h" +#include "cache_pool.h" // taskhead #include "vbh.h" #include "vtim.h" @@ -52,6 +53,9 @@ struct exp_priv { struct exp_inbox_head inbox; pthread_cond_t condvar; + /* shared with exp_remove_oc tasks */ + struct taskhead free_tasks; + /* owned by exp thread */ struct worker *wrk; struct vsl_log vsl; @@ -315,6 +319,21 @@ struct exp_deref { struct exp_inbox_head remove_head; }; +/* take lists from src to dsk */ +static void +exp_deref_take(struct exp_deref *dst, struct exp_deref *src) +{ + + AN(dst); + INIT_OBJ(dst, EXP_DEREF_MAGIC); + CHECK_OBJ_NOTNULL(src, EXP_DEREF_MAGIC); + + dst->n = src->n; + src->n = 0; + VSTAILQ_INIT(&dst->remove_head); + VSTAILQ_SWAP(&dst->remove_head, &src->remove_head, objcore); +} + static void exp_deref_work(struct worker *wrk, struct exp_deref *deref, vtim_real now) { @@ -350,6 +369,54 @@ exp_deref_init(struct exp_deref *deref) VSTAILQ_INIT(&deref->remove_head); } +/*-------------------------------------------------------------------- + * task to finish removal of ocs + * + * the struct is only needed until the task is running and has taken the + * remove_head, when it returns the struct to the free_tasks list + */ + +struct exp_deref_task_s { + // initialized once + unsigned magic; +#define EXP_DEREF_TASK_MAGIC 0xaf5a6732 + struct exp_priv *ep; + + // per invocation + struct exp_deref deref; + struct pool_task task; +}; + +static void +exp_deref_task(struct worker *wrk, void *priv) +{ + struct exp_deref_task_s *deref_task; + struct exp_deref deref; + struct exp_priv *ep; + struct vsl_log vsl; + char vsl_buf[4096]; + + CAST_OBJ_NOTNULL(deref_task, priv, EXP_DEREF_TASK_MAGIC); + ep = deref_task->ep; + CHECK_OBJ_NOTNULL(ep, EXP_PRIV_MAGIC); + + exp_deref_take(&deref, &deref_task->deref); + + Lck_Lock(&ep->mtx); + VTAILQ_INSERT_TAIL(&ep->free_tasks, &deref_task->task, list); + PTOK(pthread_cond_signal(&ep->condvar)); + Lck_Unlock(&ep->mtx); + + VSL_Setup(&vsl, vsl_buf, sizeof vsl_buf); + AZ(wrk->vsl); + wrk->vsl = &vsl; + + exp_deref_work(wrk, &deref, VTIM_real()); + VSL_Flush(wrk->vsl, 0); + Pool_Sumstat(wrk); + wrk->vsl = NULL; +} + /*-------------------------------------------------------------------- * Handle stuff in the inbox */ @@ -486,6 +553,14 @@ exp_thread(struct worker *wrk, void *priv) struct exp_inbox_item * const batch_lim = batch + sizeof batch / sizeof *batch; struct exp_inbox_item *todo, *item; + /* a small number of task structs is sufficient because + * exp_deref_task() immediately returns the task struct to the free + * tasks list. + */ + const unsigned ntasks = 4; + struct exp_deref_task_s tasks[ntasks]; + struct exp_deref_task_s *deref_task; + struct pool_task *task; struct exp_deref deref; struct objcore *oc; vtim_real t = 0, tnext = 0; @@ -502,6 +577,13 @@ exp_thread(struct worker *wrk, void *priv) for (item = batch; item < batch_lim; item++) INIT_OBJ(item, EXP_INBOX_ITEM_MAGIC); + VTAILQ_INIT(&ep->free_tasks); + for (deref_task = tasks; deref_task < tasks + ntasks; deref_task++) { + INIT_OBJ(deref_task, EXP_DEREF_TASK_MAGIC); + deref_task->ep = ep; + VTAILQ_INSERT_TAIL(&ep->free_tasks, &deref_task->task, list); + } + while (exp_shutdown == 0) { exp_deref_init(&deref); todo = batch; @@ -556,8 +638,50 @@ exp_thread(struct worker *wrk, void *priv) t = VTIM_real(); tnext = exp_expire(ep, t); - exp_deref_work(ep->wrk, &deref, t); + if (deref.n == 0) + continue; + + /* arbitrary threshold to not start a task, + * probably does not matter much */ + if (deref.n < 128) { + exp_deref_work(ep->wrk, &deref, t); + continue; + } + + Lck_Lock(&ep->mtx); + while ((task = VTAILQ_FIRST(&ep->free_tasks)) == NULL) { + VSL_Flush(&ep->vsl, 0); + Pool_Sumstat(wrk); + (void)Lck_CondWait(&ep->condvar, &ep->mtx); + } + VTAILQ_REMOVE(&ep->free_tasks, task, list); + Lck_Unlock(&ep->mtx); + + deref_task = + __containerof(task, struct exp_deref_task_s, task); + CHECK_OBJ(deref_task, EXP_DEREF_TASK_MAGIC); + exp_deref_take(&deref_task->deref, &deref); + task->func = exp_deref_task; + task->priv = deref_task; + AZ(Pool_Task_Any(task, TASK_QUEUE_BO)); } + + Lck_Lock(&ep->mtx); + unsigned u = 0; + do { + u = 0; + VTAILQ_FOREACH(task, &ep->free_tasks, list) + u++; + if (u == ntasks) + break; + (void)Lck_CondWait(&ep->condvar, &ep->mtx); + } while (u < ntasks); + Lck_Unlock(&ep->mtx); + + VTAILQ_INIT(&ep->free_tasks); + + VSL_Flush(&ep->vsl, 0); + Pool_Sumstat(wrk); wrk->vsl = NULL; VSL_Free(&ep->vsl); return (NULL); From ade82bf10f3a96f8bd8238bd30a9d92547d64bdb Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 15 Jun 2025 15:59:40 +0200 Subject: [PATCH 193/196] cache_expire: refactor - move expire deref code to own function --- bin/vinyld/cache/cache_expire.c | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index b25378cecc..e276a1f76f 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -301,6 +301,7 @@ exp_remove_oc(struct worker *wrk, struct objcore *oc, vtim_real now) assert(oc->timer_idx == VBH_NOIDX); assert(oc->refcnt > 0); AZ(oc->exp_flags); + // no objhead check VSLb(wrk->vsl, SLT_ExpKill, "EXP_Removed x=%ju t=%.0f h=%jd", VXID(ObjGetXID(wrk, oc)), EXP_Ttl(NULL, oc) - now, (intmax_t)oc->hits); @@ -308,6 +309,30 @@ exp_remove_oc(struct worker *wrk, struct objcore *oc, vtim_real now) (void)HSH_DerefObjCore(wrk, &oc); } +/*-------------------------------------------------------------------- + * Finish expiry of an oc + * This is subtly different from exp_remove_oc, also besides the VSL: + * - assert ob objhead + * - do not assert on exp_flags + */ + +static void +exp_expire_oc(struct worker *wrk, struct vsl_log *vsl, struct objcore *oc, vtim_real now) +{ + + CHECK_OBJ_NOTNULL(oc, OBJCORE_MAGIC); + + assert(oc->timer_idx == VBH_NOIDX); + assert(oc->refcnt > 0); + // no exp_flags check + CHECK_OBJ_NOTNULL(oc->objhead, OBJHEAD_MAGIC); + VSLb(vsl, SLT_ExpKill, "EXP_Expired x=%ju t=%.0f h=%jd", + VXID(ObjGetXID(wrk, oc)), EXP_Ttl(NULL, oc) - now, + (intmax_t)oc->hits); + ObjSendEvent(wrk, oc, OEV_EXPIRE); + (void)HSH_DerefObjCore(wrk, &oc); +} + /*-------------------------------------------------------------------- * keep track of ocs to deref */ @@ -501,14 +526,8 @@ exp_expire(struct exp_priv *ep, vtim_real now) /* Remove from binheap */ assert(oc->timer_idx != VBH_NOIDX); VBH_delete(ep->heap, oc->timer_idx); - assert(oc->timer_idx == VBH_NOIDX); - CHECK_OBJ_NOTNULL(oc->objhead, OBJHEAD_MAGIC); - VSLb(&ep->vsl, SLT_ExpKill, "EXP_Expired x=%ju t=%.0f h=%jd", - VXID(ObjGetXID(ep->wrk, oc)), EXP_Ttl(NULL, oc) - now, - (intmax_t)oc->hits); - ObjSendEvent(ep->wrk, oc, OEV_EXPIRE); - (void)HSH_DerefObjCore(ep->wrk, &oc); + exp_expire_oc(ep->wrk, &ep->vsl, oc, now); } return (0); } From afafb9b815a3c0ac3c81fabaa1b69fb50086be6e Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Jun 2025 14:51:24 +0200 Subject: [PATCH 194/196] cache_expire: move HSH_Kill() to exp_expire_oc() This moves the HSH_kill() to after binheap removal, which makes no difference, other than prepare for batching, were it will be run outside the critical section. --- bin/vinyld/cache/cache_expire.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index e276a1f76f..19c4839872 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -312,6 +312,7 @@ exp_remove_oc(struct worker *wrk, struct objcore *oc, vtim_real now) /*-------------------------------------------------------------------- * Finish expiry of an oc * This is subtly different from exp_remove_oc, also besides the VSL: + * - additional HSH_Kill() * - assert ob objhead * - do not assert on exp_flags */ @@ -322,6 +323,9 @@ exp_expire_oc(struct worker *wrk, struct vsl_log *vsl, struct objcore *oc, vtim_ CHECK_OBJ_NOTNULL(oc, OBJCORE_MAGIC); + if (!(oc->flags & OC_F_DYING)) + HSH_Kill(oc); + assert(oc->timer_idx == VBH_NOIDX); assert(oc->refcnt > 0); // no exp_flags check @@ -520,8 +524,6 @@ exp_expire(struct exp_priv *ep, vtim_real now) } Lck_Unlock(&ep->mtx); if (oc != NULL) { - if (!(oc->flags & OC_F_DYING)) - HSH_Kill(oc); /* Remove from binheap */ assert(oc->timer_idx != VBH_NOIDX); From cbc175b4f22c0fd0a184217df8bd3cd8bdc34e73 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Fri, 13 Jun 2025 15:09:00 +0200 Subject: [PATCH 195/196] cache_expire: add batching also for the expire case Similar to the changes for cache removal batching, we now gather all object cores to be expired in another head of the deref struct in one go within a single critical region (as before, exp_list is free when the respective object is not in the inbox) and run the derefs in the existing exp_deref_work() function, which optionally gets offloaded to a separate worker thread. For efficiency, we also change handling of expired object cores with OC_EF_POSTED: Previously, they would just be ignored, only to be handled by the exp_inbox(). But now more than ever it does not make sense to keep them around, so we just remove them from the inbox and add them to our list to expire. (diff best viewed ignoring whitespace (-b option)) --- bin/vinyld/cache/cache_expire.c | 76 ++++++++++++++++++++++----------- 1 file changed, 52 insertions(+), 24 deletions(-) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index 19c4839872..3adef12f8b 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -346,6 +346,7 @@ struct exp_deref { #define EXP_DEREF_MAGIC 0xb5854b59 unsigned n; struct exp_inbox_head remove_head; + struct exp_inbox_head expire_head; }; /* take lists from src to dsk */ @@ -361,6 +362,8 @@ exp_deref_take(struct exp_deref *dst, struct exp_deref *src) src->n = 0; VSTAILQ_INIT(&dst->remove_head); VSTAILQ_SWAP(&dst->remove_head, &src->remove_head, objcore); + VSTAILQ_INIT(&dst->expire_head); + VSTAILQ_SWAP(&dst->expire_head, &src->expire_head, objcore); } static void @@ -376,11 +379,17 @@ exp_deref_work(struct worker *wrk, struct exp_deref *deref, vtim_real now) if (n % 1024 == 0) Pool_Sumstat(wrk); } + VSTAILQ_FOREACH_SAFE(oc, &deref->expire_head, exp_list, save) { + exp_expire_oc(wrk, wrk->vsl, oc, now); + n++; + if (n % 1024 == 0) + Pool_Sumstat(wrk); + } assert(deref->n == n); memset(deref, 0, sizeof *deref); } -// trivial function to wrap n increment. +// trivial functions to wrap n increment. static void exp_deref_add_remove(struct exp_deref *deref, struct objcore *oc) { @@ -390,12 +399,22 @@ exp_deref_add_remove(struct exp_deref *deref, struct objcore *oc) deref->n++; } +static void +exp_deref_add_expire(struct exp_deref *deref, struct objcore *oc) +{ + + CHECK_OBJ_NOTNULL(deref, EXP_DEREF_MAGIC); + VSTAILQ_INSERT_TAIL(&deref->expire_head, oc, exp_list); + deref->n++; +} + static void exp_deref_init(struct exp_deref *deref) { INIT_OBJ(deref, EXP_DEREF_MAGIC); VSTAILQ_INIT(&deref->remove_head); + VSTAILQ_INIT(&deref->expire_head); } /*-------------------------------------------------------------------- @@ -495,43 +514,50 @@ exp_inbox(struct exp_priv *ep, struct objcore *oc, unsigned flags) */ static vtim_real -exp_expire(struct exp_priv *ep, vtim_real now) +exp_expire(struct exp_priv *ep, struct exp_deref *deref, vtim_real now) { struct objcore *oc; + vtim_real ret; CHECK_OBJ_NOTNULL(ep, EXP_PRIV_MAGIC); - oc = VBH_root(ep->heap); - if (oc == NULL) - return (now + 355. / 113.); - VSLb(&ep->vsl, SLT_ExpKill, "EXP_Inspect p=%p e=%.6f f=0x%x", oc, - oc->timer_when - now, oc->flags); + Lck_Lock(&ep->mtx); + while (1) { + oc = VBH_root(ep->heap); + if (oc == NULL) { + ret = now + 355. / 113.; + break; + } + VSLb(&ep->vsl, SLT_ExpKill, "EXP_Inspect p=%p e=%.6f f=0x%x", + oc, oc->timer_when - now, oc->flags); - CHECK_OBJ_NOTNULL(oc, OBJCORE_MAGIC); + CHECK_OBJ_NOTNULL(oc, OBJCORE_MAGIC); - /* Ready ? */ - if (oc->timer_when > now) - return (oc->timer_when); + /* Ready ? */ + if (oc->timer_when > now) { + ret = oc->timer_when; + break; + } - VSC_C_main->n_expired++; + VSC_C_main->n_expired++; - Lck_Lock(&ep->mtx); - if (oc->exp_flags & OC_EF_POSTED) { - oc->exp_flags |= OC_EF_REMOVE; - oc = NULL; - } else { - oc->exp_flags &= ~OC_EF_REFD; - } - Lck_Unlock(&ep->mtx); - if (oc != NULL) { + if (oc->exp_flags & OC_EF_POSTED) { + VSTAILQ_REMOVE(&ep->inbox, oc, objcore, exp_list); + oc->exp_flags = 0; + } + else + oc->exp_flags &= ~OC_EF_REFD; + exp_deref_add_expire(deref, oc); /* Remove from binheap */ assert(oc->timer_idx != VBH_NOIDX); VBH_delete(ep->heap, oc->timer_idx); - exp_expire_oc(ep->wrk, &ep->vsl, oc, now); + assert(oc->timer_idx == VBH_NOIDX); } - return (0); + Lck_Unlock(&ep->mtx); + + return (ret); } /*-------------------------------------------------------------------- @@ -625,6 +651,7 @@ exp_thread(struct worker *wrk, void *priv) VSC_C_main->exp_received++; tnext = 0; flags = oc->exp_flags; + assert(flags & OC_EF_POSTED); if (flags & OC_EF_REMOVE) { oc->exp_flags = 0; exp_deref_add_remove(&deref, oc); @@ -657,7 +684,7 @@ exp_thread(struct worker *wrk, void *priv) } t = VTIM_real(); - tnext = exp_expire(ep, t); + tnext = exp_expire(ep, &deref, t); if (deref.n == 0) continue; @@ -669,6 +696,7 @@ exp_thread(struct worker *wrk, void *priv) continue; } + /* call exp_deref_work() in a task */ Lck_Lock(&ep->mtx); while ((task = VTAILQ_FIRST(&ep->free_tasks)) == NULL) { VSL_Flush(&ep->vsl, 0); From d0a46ab6db8f164c04ee8b5d5ed96e96f9ba8b42 Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Mon, 16 Jun 2025 09:23:56 +0200 Subject: [PATCH 196/196] cache_expire: Avoid double counting of OC_EF_REMOVE objects When the exp_expire() finds the expired object also in the inbox, it would still count it as expired. We now avoid the double count by excluding objects with OC_EF_REMOVE set. And we also reduce traffic on the global counter by using a local variable for the loop. --- bin/vinyld/cache/cache_expire.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/bin/vinyld/cache/cache_expire.c b/bin/vinyld/cache/cache_expire.c index 3adef12f8b..1b43e6328c 100644 --- a/bin/vinyld/cache/cache_expire.c +++ b/bin/vinyld/cache/cache_expire.c @@ -518,6 +518,7 @@ exp_expire(struct exp_priv *ep, struct exp_deref *deref, vtim_real now) { struct objcore *oc; vtim_real ret; + unsigned n = 0; CHECK_OBJ_NOTNULL(ep, EXP_PRIV_MAGIC); @@ -539,9 +540,11 @@ exp_expire(struct exp_priv *ep, struct exp_deref *deref, vtim_real now) break; } - VSC_C_main->n_expired++; + n++; if (oc->exp_flags & OC_EF_POSTED) { + if (oc->exp_flags & OC_EF_REMOVE) + n--; VSTAILQ_REMOVE(&ep->inbox, oc, objcore, exp_list); oc->exp_flags = 0; } @@ -556,6 +559,7 @@ exp_expire(struct exp_priv *ep, struct exp_deref *deref, vtim_real now) assert(oc->timer_idx == VBH_NOIDX); } Lck_Unlock(&ep->mtx); + VSC_C_main->n_expired += n; return (ret); }