Be consistent with capitalisation and whitepace.

doc/sphinx/installation/bugs.rst

@@ -31,9 +31,9 @@ Varnish is split over two processes, the manager and the child.  The child
 does all the work, and the manager hangs around to resurect 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 Varnish 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 Varnish restarting every 10 minutes and *still* provide better
 service than their CMS system.)
 
 When it crashes, if at all possible, Varnish will spew out a crash dump
@@ -116,7 +116,7 @@ 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 Varnish process issues.  Be aware that this may generate a lot
 of very repetitive data, usually one second worth is more than enough.
 
 Also, run ``varnishlog`` for a second, and collect the output

doc/sphinx/installation/platformnotes.rst

@@ -26,7 +26,7 @@ performance.
 If you are running on 64bit OpenVZ (or Parallels VPS), you must reduce
 the maximum stack size before starting Varnish.
 
-The default allocates to much memory per thread, which will make varnish fail
+The default allocates to much memory per thread, which will make Varnish fail
 as soon as the number of threads (traffic) increases.
 
 Reduce the maximum stack size by running::

doc/sphinx/installation/prerequisites.rst

@@ -8,12 +8,12 @@ In order for you to install Varnish you must have the following:
     - Linux
     - FreeBSD
     - Solaris (x86 only)
-  * root access to said system
+  * root access to said system.
 
 
 Varnish can be installed on other UNIX systems as well, but it is not
-tested particularly well on these plattforms. Varnish is, from time to
-time, said to work on: 
+tested particularly well on these platforms. Varnish is, from time to
+time, said to work on:
 
   * 32 bit versions of the before-mentioned systems.
   * OS X

doc/sphinx/reference/varnish-cli.rst

-=======
-varnish
-=======
+===========
+Varnish CLI
+===========
 
 ------------------------------
 Varnish Command Line Interface
@@ -142,7 +142,7 @@ ping  [timestamp]
       Ping the Varnish cache process, keeping the connection alive.
 
 quit
-      Close the connection to the varnish admin port.
+      Close the connection to the Varnish admin port.
 
 start
       Start the Varnish cache process if it is not already running.
@@ -214,7 +214,7 @@ code and length field always is exactly 13 characters long, including
 the NL character.
 
 For your reference the sourcefile lib/libvarnish/cli_common.h contains
-the functions varnish code uses to read and write CLI response.
+the functions Varnish code uses to read and write CLI response.
 
 .. _ref_psk_auth:
 
@@ -318,9 +318,9 @@ SEE ALSO
 HISTORY
 =======
 
-The varnish manual page was written by Per Buer in 2011. Some of the
+The Varnish manual page was written by Per Buer in 2011. Some of the
 text was taken from the Varnish Cache wiki, the varnishd(7) man page
-or the varnish source code.
+or the Varnish source code.
 
 COPYRIGHT
 =========
@@ -328,4 +328,4 @@ COPYRIGHT
 This document is licensed under the same licence as Varnish
 itself. See LICENCE for details.
 
-* Copyright (c) 2011 Varnish Software AS
+* Copyright (c) 2011-2014 Varnish Software AS

doc/sphinx/reference/varnishadm.rst

@@ -3,7 +3,7 @@ varnishadm
 ==========
 
 ----------------------------------
-Control a running varnish instance
+Control a running Varnish instance
 ----------------------------------
 
 :Author: Cecilie Fritzvold
@@ -90,4 +90,4 @@ COPYRIGHT
 This document is licensed under the same licence as Varnish
 itself. See LICENCE for details.
 
-* Copyright (c) 2007-2011 Varnish Software AS
+* Copyright (c) 2007-2014 Varnish Software AS

doc/sphinx/reference/varnishd.rst

@@ -70,7 +70,7 @@ OPTIONS
             Specifies the hash algorithm.  See Hash Algorithms for a list of supported algorithms.
 
 -i identity
-            Specify the identity of the varnish server.  This can be accessed using server.identity
+            Specify the identity of the Varnish server.  This can be accessed using server.identity
             from VCL
 
 -l shmlogsize

doc/sphinx/reference/varnishhist.rst

@@ -90,4 +90,4 @@ This document is licensed under the same licence as Varnish
 itself. See LICENCE for details.
 
 * Copyright (c) 2006 Verdens Gang AS
-* Copyright (c) 2006-2011 Varnish Software AS
+* Copyright (c) 2006-2014 Varnish Software AS

doc/sphinx/reference/varnishreplay.rst

@@ -20,14 +20,14 @@ varnishreplay [-D] -a address:port -r file
 DESCRIPTION
 ===========
 
-The varnishreplay utility parses varnish logs and attempts to
-reproduce the traffic. It is typcally used to *warm* up caches or
+The varnishreplay utility parses Varnish logs and attempts to
+reproduce the traffic. It is typically used to *warm* up caches or
 various forms of testing.
 
 The following options are available:
 
--a backend           Send the traffic over tcp to this server, specified by an 
-   		     address and a port.  This option is 
+-a backend           Send the traffic over tcp to this server, specified by an
+   		     address and a port.  This option is
    		     mandatory. Only IPV4 is supported at this time.
 
 -D                   Turn on debugging mode.
@@ -54,4 +54,4 @@ COPYRIGHT
 This document is licensed under the same licence as Varnish
 itself. See LICENCE for details.
 
-* Copyright (c) 2007-2010 Varnish Software AS
+* Copyright (c) 2007-2014 Varnish Software AS

doc/sphinx/reference/varnishstat.rst

@@ -125,4 +125,4 @@ This document is licensed under the same licence as Varnish
 itself. See LICENCE for details.
 
 * Copyright (c) 2006 Verdens Gang AS
-* Copyright (c) 2006-2011 Varnish Software AS
+* Copyright (c) 2006-2014 Varnish Software AS

doc/sphinx/reference/varnishtest.rst

@@ -109,7 +109,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 backend
+different requests. It will start a Varnish server (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.
 

doc/sphinx/reference/vcl.rst

@@ -467,7 +467,7 @@ vcl_pass
 
   restart
     Restart the transaction. Increases the restart counter. If the number 
-    of restarts is higher than *max_restarts* varnish emits a guru meditation 
+    of restarts is higher than *max_restarts* Varnish emits a guru meditation 
     error.
 
 vcl_hash
@@ -497,7 +497,7 @@ vcl_hit
 
   restart
     Restart the transaction. Increases the restart counter. If the number 
-    of restarts is higher than *max_restarts* varnish emits a guru meditation 
+    of restarts is higher than *max_restarts* Varnish emits a guru meditation 
     error.
 
 vcl_miss
@@ -546,7 +546,7 @@ vcl_fetch
 
   restart
     Restart the transaction. Increases the restart counter. If the number 
-    of restarts is higher than *max_restarts* varnish emits a guru meditation 
+    of restarts is higher than *max_restarts* Varnish emits a guru meditation 
     error.
 
 vcl_deliver
@@ -560,7 +560,7 @@ vcl_deliver
 
   restart
     Restart the transaction. Increases the restart counter. If the number 
-    of restarts is higher than *max_restarts* varnish emits a guru meditation 
+    of restarts is higher than *max_restarts* Varnish emits a guru meditation 
     error.
 
 vcl_error
@@ -575,7 +575,7 @@ vcl_error
 
   restart
     Restart the transaction. Increases the restart counter. If the number 
-    of restarts is higher than *max_restarts* varnish emits a guru meditation 
+    of restarts is higher than *max_restarts* Varnish emits a guru meditation 
     error.
 
 vcl_fini
@@ -755,7 +755,7 @@ other words, they are available in vcl_fetch:
 
 beresp.do_stream 
   Deliver the object to the client directly without fetching the whole
-  object into varnish. If this request is pass'ed it will not be
+  object into Varnish. If this request is pass'ed it will not be
   stored in memory. As of Varnish Cache 3.0 the object will marked as busy
   as it is delivered so only client can access the object.
 
@@ -883,7 +883,7 @@ Grace and saint mode
 
 If the backend takes a long time to generate an object there is a risk
 of a thread pile up.  In order to prevent this you can enable *grace*.
-This allows varnish to serve an expired version of the object while a
+This allows Varnish to serve an expired version of the object while a
 fresh object is being generated by the backend.
 
 The following vcl code will make Varnish serve expired objects.  All
@@ -1035,4 +1035,4 @@ This document is licensed under the same license as Varnish
 itself. See LICENSE for details.
 
 * Copyright (c) 2006 Verdens Gang AS
-* Copyright (c) 2006-2011 Varnish Software AS
+* Copyright (c) 2006-2014 Varnish Software AS

doc/sphinx/reference/vmod.rst

@@ -25,9 +25,9 @@ function shown above.  The full contents of the "std" module is
 documented in vmod_std(7).
 
 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 
+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 Varnish source tree handy may be a good
 idea.
 
 VMOD Directory
@@ -35,7 +35,8 @@ VMOD Directory
 
 The VMOD directory is an up-to-date compilation of maintained
 extensions written for Varnish Cache:
-https://www.varnish-cache.org/vmods
+
+    https://www.varnish-cache.org/vmods
 
 The vmod.vcc file
 =================
@@ -47,11 +48,11 @@ data structures that does all the hard work.
 
 The std VMODs vmod.vcc file looks somewhat like this::
 
-	Module std
-	Init init_function
-	Function STRING toupper(PRIV_CALL, STRING_LIST)
-	Function STRING tolower(PRIV_VCL, STRING_LIST)
-	Function VOID set_ip_tos(INT)
+	$Module std
+	$Init init_function
+	$Function STRING toupper(PRIV_CALL, STRING_LIST)
+	$Function STRING tolower(PRIV_VCL, STRING_LIST)
+	$Function VOID set_ip_tos(INT)
 
 The first line gives the name of the module, nothing special there.
 

doc/sphinx/reference/vmod_std.rst

@@ -153,8 +153,8 @@ Description
 	fails, *fallback* will be returned.
 Example
 	if (std.ip(req.http.X-forwarded-for, "0.0.0.0") ~ my_acl) { ... }
-	
-	
+
+
 SEE ALSO
 ========
 
@@ -174,4 +174,4 @@ COPYRIGHT
 This document is licensed under the same licence as Varnish
 itself. See LICENCE for details.
 
-* Copyright (c) 2011 Varnish Software
+* Copyright (c) 2011-2014 Varnish Software

doc/sphinx/tutorial/backend_servers.rst

@@ -7,7 +7,7 @@ Varnish has a concept of "backend" or "origin" servers. A backend
 server is the server providing the content Varnish will accelerate.
 
 Our first task is to tell Varnish where it can find its content. Start
-your favorite text editor and open the varnish default configuration
+your favorite text editor and open the Varnish 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.
@@ -21,7 +21,7 @@ the configuration that looks like this:::
   }
 
 This means we set up a backend in Varnish that fetches content from
-the host www.varnish-cache.org on port 80. 
+the host www.varnish-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

doc/sphinx/users-guide/command-line.rst

@@ -24,7 +24,7 @@ You will most likely want to set this to ":80" which is the Well
 Known Port for HTTP.
 
 You can specify multiple addresses separated by a comma, and you
-can use numeric or host/service names if you like, varnish will try
+can use numeric or host/service names if you like, Varnish will try
 to open and service as many of them as possible, but if none of them
 can be opened, varnishd will not start.
 
@@ -38,7 +38,7 @@ Here are some examples::
 
 If your webserver runs on the same computer, you will have to move
 it to another port number first.
- 
+
 -f *VCL-file* or -b *backend*
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

doc/sphinx/users-guide/intro.rst

@@ -33,7 +33,7 @@ Interface, which can be used manually, from scripts or programs.
 
 The CLI offers almost full control of what Varnish 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
+that you should not need to restart the Varnish processes, unless
 you need to change something very fundamental.
 
 The CLI can be safely accessed remotely, using a simple and flexible

doc/sphinx/users-guide/operation-logging.rst

@@ -18,7 +18,7 @@ is logging. Varnishlog gives you the raw logs, everything that is
 written to the logs. There are other clients as well, we'll show you
 these later.
 
-In the terminal window you started varnish now type *varnishlog* and
+In the terminal window you started Varnish now type *varnishlog* and
 press enter.
 
 You'll see lines like these scrolling slowly by.::
@@ -27,7 +27,7 @@ You'll see lines like these scrolling slowly by.::
     0 CLI          - Wr 200 PONG 1273698726 1.0
 
 These is the Varnish master process checking up on the caching process
-to see that everything is OK. 
+to see that everything is OK.
 
 Now go to the browser and reload the page displaying your web
 app. You'll see lines like these.::
@@ -55,10 +55,10 @@ Now, you can filter quite a bit with varnishlog. The basic option 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 Varnish and the backend
  servers. This will be useful when we want to optimize cache hit rates.
 
--c 
+-c
  Same as -b but for client side traffic.
 
 -m tag:regex

doc/sphinx/users-guide/operation-statistics.rst

@@ -4,7 +4,7 @@
 Statistics
 ----------
 
-Now that your varnish is up and running let's have a look at how it is
+Now that your Varnish is up and running let's have a look at how it is
 doing. There are several tools that can help.
 
 varnishtop
@@ -48,10 +48,10 @@ varnishstat
 Varnish has lots of counters. We count misses, hits, information about
 the storage, threads created, deleted objects. Just about
 everything. varnishstat will dump these counters. This is useful when
-tuning varnish. 
+tuning Varnish.
 
 There are programs that can poll varnishstat 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.
+the Varnish source code.
 

doc/sphinx/users-guide/purging.rst

@@ -11,7 +11,7 @@ bad for business.
 
 The solution is to notify Varnish when there is fresh content
 available. This can be done through three mechanisms. HTTP purging,
-banning and forced cache misses. First, let me explain the HTTP purges. 
+banning and forced cache misses. First, let me explain the HTTP purges.
 
 
 HTTP Purges
@@ -31,7 +31,7 @@ following VCL in place::
 	  "localhost";
 	  "192.168.55.0"/24;
   }
-  
+
   sub vcl_recv {
       	  # allow PURGE from localhost and 192.168.55...
 
@@ -42,14 +42,14 @@ following VCL in place::
 		  return (lookup);
 	  }
   }
-  
+
   sub vcl_hit {
 	  if (req.method == "PURGE") {
 	          purge;
 		  error 200 "Purged.";
 	  }
   }
-  
+
   sub vcl_miss {
 	  if (req.method == "PURGE") {
 	          purge;
@@ -93,7 +93,7 @@ the following command::
 Quite powerful, really.
 
 Bans are checked when we hit an object in the cache, but before we
-deliver it. *An object is only checked against newer bans*. 
+deliver it. *An object is only checked against newer 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
@@ -168,7 +168,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, Varnish 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

doc/sphinx/users-guide/run_security.rst

@@ -79,9 +79,9 @@ only allow specific CLI commands.
 It is also possible to configure varnishd for "reverse mode", using
 the '-M' argument.  In that case varnishd will attempt to open a
 TCP connection to the specified address, and initiate a CLI connection
-to your central varnish management facility.
+to your central Varnish management facility.
 
-The connection is also in this case without secrecy, but 
+The connection is also in this case without secrecy, but
 the remote end must still satisfy -S/PSK authentication.
 
 Finally, if you run varnishd with the '-d' option, you get a CLI
@@ -217,4 +217,4 @@ If you have "administrative" HTTP requests, for instance PURGE
 requests, we strongly recommend that you restrict them to trusted
 IP numbers/nets using VCL's Access Control Lists.
 
-(XXX: missing ref to ACL)
+.. (XXX: missing ref to ACL)

doc/sphinx/users-guide/sizing-your-cache.rst

@@ -19,7 +19,7 @@ task. A few things to consider:
 
 Be aware that every object that is stored also carries overhead that
 is kept outside the actually storage area. So, even if you specify -s
-malloc,16G varnish might actually use **double** that. Varnish has a
+malloc,16G Varnish might actually use **double** that. Varnish has a
 overhead of about 1k per object. So, if you have lots of small objects
 in your cache the overhead might be significant.
 

doc/sphinx/users-guide/troubleshooting.rst

@@ -5,7 +5,7 @@ Troubleshooting Varnish
 
 Sometimes Varnish misbehaves. In order for you to understand whats
 going on there are a couple of places you can check. varnishlog,
-/var/log/syslog, /var/log/messages are all places where varnish might
+/var/log/syslog, /var/log/messages are all places where Varnish might
 leave clues of whats going on. This section will guide you through
 basic troubleshooting in Varnish.
 
@@ -19,7 +19,7 @@ permissions on /dev/null to other processes blocking the ports.
 
 Starting Varnish in debug mode to see what is going on.
 
-Try to start varnish by::
+Try to start Varnish by::
 
     # varnishd -f /usr/local/etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1: 2000  -a 0.0.0.0:8080 -d
 
@@ -31,7 +31,7 @@ listening on its port.::
     storage_malloc: max size 1024 MB.
     Using old SHMFILE
     Platform: Linux,2.6.32-21-generic,i686,-smalloc,-hcritbit
-    200 193     
+    200 193
     -----------------------------
     Varnish Cache CLI.
     -----------------------------
@@ -45,7 +45,7 @@ instruct the master process to start the cache by issuing "start".::
 
 	 start
 	 bind(): Address already in use
-	 300 22      
+	 300 22
 	 Could not open sockets
 
 And here we have our problem. Something else is bound to the HTTP port

doc/sphinx/users-guide/vcl-backends.rst

@@ -29,7 +29,7 @@ connect to port 8080 on localhost (127.0.0.1).
 
 Varnish can have several backends defined and can you can even join
 several backends together into clusters of backends for load balancing
-purposes. 
+purposes.
 
 
 Multiple backends
@@ -72,7 +72,7 @@ It's quite simple, really. Lets stop and think about this for a
 moment. As you can see you can define how you choose backends based on
 really arbitrary data. You want to send mobile devices to a different
 backend? No problem. if (req.User-agent ~ /mobile/) .. should do the
-trick. 
+trick.
 
 
 Backends and virtual hosts in Varnish
@@ -104,7 +104,7 @@ more tight, maybe relying on the == operator in stead, like this:::
     if (req.http.host == "foo.com" or req.http.host == "www.foo.com") {
       set req.backend = foo;
     }
-  } 
+  }
 
 
 .. _users-guide-advanced_backend_servers-directors:
@@ -181,7 +181,7 @@ Whats new here is the probe. Varnish will check the health of each
 backend with a probe. The options are
 
 url
- What URL should varnish request.
+ What URL should Varnish request.
 
 interval
  How often should we poll
@@ -193,10 +193,10 @@ window
  Varnish will maintain a *sliding window* of the results. Here the
  window has five checks.
 
-threshold 
+threshold
  How many of the .window last polls must be good for the backend to be declared healthy.
 
-initial 
+initial
  How many of the of the probes a good when Varnish starts - defaults
  to the same amount as the threshold.
 
@@ -206,11 +206,11 @@ Now we define the director.::
         {
                 .backend = server1;
         }
-        # server2 
+        # server2
         {
                 .backend = server2;
         }
-	
+
         }
 
 You use this director just as you would use any other director or

doc/sphinx/users-guide/vcl-built-in-subs.rst

@@ -23,20 +23,20 @@ vcl_recv
  been received and parsed.  Its purpose is to decide whether or not
  to serve the request, how to do it, and, if applicable, which backend
  to use.
-  
+
  The vcl_recv subroutine may terminate with calling ``return()`` on one of
  the following keywords:
 
   error code [reason]
     Return the specified error code to the client and abandon the request.
 
-  pass    
+  pass
     Switch to pass mode.  Control will eventually pass to vcl_pass.
 
-  pipe    
+  pipe
     Switch to pipe mode.  Control will eventually pass to vcl_pipe.
 
-  lookup  
+  lookup
     Look up the requested object in the cache.  Control will
     eventually pass to vcl_hit or vcl_miss, depending on whether the
     object is in the cache.  The ``bereq.method`` value will be set
@@ -50,7 +50,7 @@ vcl_pipe
  on to the backend, and any further data from either client or
  backend is passed on unaltered until either end closes the
  connection.
-  
+
  The vcl_pipe subroutine may terminate with calling return() with one of
  the following keywords:
 
@@ -67,10 +67,10 @@ vcl_pass
  on to the backend, and the backend's response is passed on to the
  client, but is not entered into the cache.  Subsequent requests
  submitted over the same client connection are handled normally.
-  
+
  The vcl_pass subroutine may terminate with calling return() with one
  of the following keywords:
-  
+
   error code [reason]
     Return the specified error code to the client and abandon the request.
 
@@ -78,8 +78,8 @@ vcl_pass
     Proceed with pass mode.
 
   restart
-    Restart the transaction. Increases the restart counter. If the number 
-    of restarts is higher than *max_restarts* varnish emits a guru meditation 
+    Restart the transaction. Increases the restart counter. If the number
+    of restarts is higher than *max_restarts* Varnish emits a guru meditation
     error.
 
 vcl_miss
@@ -88,7 +88,7 @@ vcl_miss
 Called after a cache lookup if the requested document was not found in
 the cache.  Its purpose is to decide whether or not to attempt to
 retrieve the document from the backend, and which backend to use.
-  
+
 The vcl_miss subroutine may terminate with calling return() with one
 of the following keywords:
 
@@ -106,7 +106,7 @@ vcl_fetch
 ~~~~~~~~~
 
 Called after a document has been successfully retrieved from the backend.
-  
+
 The vcl_fetch subroutine may terminate with calling return() with one
 of the following keywords:
 
@@ -117,7 +117,7 @@ of the following keywords:
   error code [reason]
     Return the specified error code to the client and abandon the request.
 
-  hit_for_pass 
+  hit_for_pass
     Pass in fetch. Passes the object without caching it. This will
     create a so-called hit_for_pass object which has the side effect
     that the decision not to cache will be cached. This is to allow
@@ -131,15 +131,15 @@ of the following keywords:
     object.
 
   restart
-    Restart the transaction. Increases the restart counter. If the number 
-    of restarts is higher than *max_restarts* varnish emits a guru meditation 
+    Restart the transaction. Increases the restart counter. If the number
+    of restarts is higher than *max_restarts* Varnish emits a guru meditation
     error.
 
 vcl_deliver
 ~~~~~~~~~~~
 
 Called before a cached object is delivered to the client.
-  
+
 The vcl_deliver subroutine may terminate with one of the following
 keywords:
 
@@ -147,25 +147,25 @@ keywords:
     Deliver the object to the client.
 
   restart
-    Restart the transaction. Increases the restart counter. If the number 
-    of restarts is higher than *max_restarts* varnish emits a guru meditation 
+    Restart the transaction. Increases the restart counter. If the number
+    of restarts is higher than *max_restarts* Varnish emits a guru meditation
     error.
 
 vcl_error
 ~~~~~~~~~
 
-Called when we hit an error, either explicitly or implicitly due to 
+Called when we hit an error, either explicitly or implicitly due to
 backend or internal errors.
 
 The vcl_error subroutine may terminate by calling return with one of
 the following keywords:
- 
+
   deliver
     Deliver the error object to the client.
 
   restart
-    Restart the transaction. Increases the restart counter. If the number 
-    of restarts is higher than *max_restarts* varnish emits a guru meditation 
+    Restart the transaction. Increases the restart counter. If the number
+    of restarts is higher than *max_restarts* Varnish emits a guru meditation
     error.
 
 vcl_fini

doc/sphinx/whats-new/upgrading.rst

@@ -11,7 +11,7 @@ Much of the VCL syntax has changed in Varnish 4. We've tried to compile a list o
 
 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::
+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;
 
@@ -30,7 +30,7 @@ Since the client director was already a special case of the hash director, it ha
         	h.add_backend(b1, 1);
         	h.add_backend(b2, 1);
 	}
-	
+
 	sub vcl_recv {
 		set req.backend = h.backend(client.ip);
 	}