[master] 7841984 Spelling

[Federico G. Schwindt]

commit 78419843f4286748ca6fd0d15a227c738d0fb27a
Author: Federico G. Schwindt <fgsch at lodoss.net>
Date:   Fri Mar 10 16:58:47 2017 +0000

    Spelling

diff --git a/doc/sphinx/whats-new/changes-5.1.rst b/doc/sphinx/whats-new/changes-5.1.rst
index f0c4015..efdddb8 100644
--- a/doc/sphinx/whats-new/changes-5.1.rst
+++ b/doc/sphinx/whats-new/changes-5.1.rst
@@ -13,7 +13,7 @@ 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
+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.
 
@@ -30,7 +30,7 @@ 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.
+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::
@@ -51,7 +51,7 @@ 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, labeling VCL programs
+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::
 
@@ -113,7 +113,7 @@ 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 mininal
+``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,
diff --git a/doc/sphinx/whats-new/upgrading-5.1.rst b/doc/sphinx/whats-new/upgrading-5.1.rst
index ab6104f..a7180fa 100644
--- a/doc/sphinx/whats-new/upgrading-5.1.rst
+++ b/doc/sphinx/whats-new/upgrading-5.1.rst
@@ -89,7 +89,7 @@ All VCL subroutines (except ``vcl_fini``)
   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 whan a VCL instance in unloaded (enters the
+  ``vcl_fini`` is executed when a VCL instance in unloaded (enters the
   COLD state) and has no failure condition.
 
 Client-side VCL subroutines
@@ -125,7 +125,7 @@ command-line option for varnishd, but none is explicitly set in
 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 specfied, Varnish went through
+``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