s/varnish/Varnish/g in docs.

Because it looks better.

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

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

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/

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.
 

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

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

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