[4.1] 199de9b Spelling and formatting

[Federico G. Schwindt]

commit 199de9bef274ea923d87a06495aea8226c8ff8f7
Author: Federico G. Schwindt <fgsch at lodoss.net>
Date:   Fri Aug 28 08:41:58 2015 +0100

    Spelling and formatting

diff --git a/doc/sphinx/whats-new/changes.rst b/doc/sphinx/whats-new/changes.rst
index 7b6eeba..b71cc85 100644
--- a/doc/sphinx/whats-new/changes.rst
+++ b/doc/sphinx/whats-new/changes.rst
@@ -3,7 +3,8 @@
 Changes in Varnish 4.1 (unreleased)
 ===================================
 
-Varnish 4.1 is the continuation of the new streaming architecture seen in Varnish 4.0.
+Varnish 4.1 is the continuation of the new streaming architecture seen
+in Varnish 4.0.
 
 
 Proactive security features
@@ -12,25 +13,26 @@ 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.
+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.
+``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.
+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.
+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.
 
@@ -60,16 +62,17 @@ Example::
     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`).
+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.
+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::
 
@@ -94,11 +97,12 @@ in ``vcl_recv`` to see if traffic came in over the HTTP listening socket
 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 necesserally speak HTTP/1 over TCP to fetch
-resources. More details in the :ref:`ref-writing-a-director` documentation.
+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.
 
 
 Surrogate keys
@@ -109,8 +113,8 @@ Not yet documented.
 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.
+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 subrequests it lead to.
@@ -119,7 +123,9 @@ and any ESI subrequests it lead to.
 Other noteworthy small changes
 ==============================
 
-* Varnish will now use the ``stale-while-revalidate`` defined in RFC5861 to set object grace time.
-* Varnish will now discard remaining/older open backend connections when a failing connection is found.
+* Varnish will now use the ``stale-while-revalidate`` defined in RFC5861
+  to set object grace time.
+* Varnish will now discard remaining/older open backend connections when
+  a failing connection is found.
 * -smalloc storage is now recommended over -sfile on Linux systems.