[master] 9ca3df8fe s/varnish/Varnish/g in docs.

Lasse Karstensen lasse.karstensen at gmail.com
Wed Feb 20 21:32:08 UTC 2019


commit 9ca3df8fec3d7647e469ac5ae5a02c04621219db
Author: Lasse Karstensen <lasse.karstensen at gmail.com>
Date:   Wed Feb 20 22:28:15 2019 +0100

    s/varnish/Varnish/g in docs.
    
    Because it looks better.

diff --git a/doc/sphinx/users-guide/esi.rst b/doc/sphinx/users-guide/esi.rst
index a88e9cc91..b85d18f23 100644
--- a/doc/sphinx/users-guide/esi.rst
+++ b/doc/sphinx/users-guide/esi.rst
@@ -115,7 +115,7 @@ 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 encryption
+by default, because Varnish has no way to fetch it encryption
 enabled.  If you want to treat HTTPS in ESI:include tags as if
 it were HTTP, set::
 
diff --git a/doc/sphinx/users-guide/purging.rst b/doc/sphinx/users-guide/purging.rst
index 58fa52e45..d91ad57a1 100644
--- a/doc/sphinx/users-guide/purging.rst
+++ b/doc/sphinx/users-guide/purging.rst
@@ -45,7 +45,7 @@ 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) Varnish
 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
 it has purge the object.
@@ -78,7 +78,7 @@ the following command from the shell::
 See :ref:`vcl(7)_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 Varnish 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*.
diff --git a/doc/sphinx/users-guide/storage-backends.rst b/doc/sphinx/users-guide/storage-backends.rst
index 3dd71408a..9ba6076a4 100644
--- a/doc/sphinx/users-guide/storage-backends.rst
+++ b/doc/sphinx/users-guide/storage-backends.rst
@@ -71,11 +71,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, Varnish will only use it for
 storage allocations and keep the default libc allocator for all other
-varnish memory allocation purposes.
+Varnish memory allocation purposes.
 
-If `libumem`_ is already loaded when varnish initializes, this message
+If `libumem`_ is already loaded when Varnish initializes, this message
 is output::
 
   notice: libumem was already found to be loaded
@@ -91,15 +91,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
+Varnish 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
 
 This recommendation should be followed to achieve an optimal
-`libumem`_ configuration for varnish. Setting this environment
-variable before starting varnish is required becuase `libumem`_ cannot
+`libumem`_ configuration for Varnish. Setting this environment
+variable before starting Varnish is required becuase `libumem`_ cannot
 be reconfigured once loaded.
 
 .. _libumem: http://dtrace.org/blogs/ahl/2004/07/13/number-11-of-20-libumem/
diff --git a/doc/sphinx/users-guide/vcl-backends.rst b/doc/sphinx/users-guide/vcl-backends.rst
index 58448916f..7867140eb 100644
--- a/doc/sphinx/users-guide/vcl-backends.rst
+++ b/doc/sphinx/users-guide/vcl-backends.rst
@@ -74,7 +74,7 @@ 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, Varnish 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.
 
diff --git a/doc/sphinx/users-guide/vcl-built-in-subs.rst b/doc/sphinx/users-guide/vcl-built-in-subs.rst
index 690f337ef..95c9885a9 100644
--- a/doc/sphinx/users-guide/vcl-built-in-subs.rst
+++ b/doc/sphinx/users-guide/vcl-built-in-subs.rst
@@ -345,7 +345,7 @@ The `vcl_backend_fetch` subroutine may terminate with calling
     background fetch, control is passed to :ref:`vcl_synth` on the
     client side with ``resp.status`` preset to 503.
 
-Before calling `vcl_backend_fetch`, varnish core prepares the `bereq`
+Before calling `vcl_backend_fetch`, Varnish core prepares the `bereq`
 backend request as follows:
 
 * Unless the request is a `pass`,
@@ -411,7 +411,7 @@ The `vcl_backend_response` subroutine may terminate with calling
 304 handling
 ~~~~~~~~~~~~
 
-For a 304 response, varnish core code amends ``beresp`` before calling
+For a 304 response, Varnish core code amends ``beresp`` before calling
 `vcl_backend_response`:
 
 * If the gzip status changed, ``Content-Encoding`` is unset and any
diff --git a/doc/sphinx/users-guide/vcl-grace.rst b/doc/sphinx/users-guide/vcl-grace.rst
index dddfac5f7..fcaa301bb 100644
--- a/doc/sphinx/users-guide/vcl-grace.rst
+++ b/doc/sphinx/users-guide/vcl-grace.rst
@@ -61,7 +61,7 @@ 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
+Varnish behaves, then you should know some of the details on how this
 works.
 
 When ``sub vcl_recv`` ends with ``return (lookup)`` (which is the
diff --git a/doc/sphinx/users-guide/vcl-separate.rst b/doc/sphinx/users-guide/vcl-separate.rst
index 031807cb3..a654fe9ed 100644
--- a/doc/sphinx/users-guide/vcl-separate.rst
+++ b/doc/sphinx/users-guide/vcl-separate.rst
@@ -17,7 +17,7 @@ First load the two VCL files::
     vcl.load vc_1 /somewhere/vc.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 Varnish instance.
 
 Next we need to point VCL labels to them::
 


More information about the varnish-commit mailing list