Finalise docs

* fix links to FOSHttpCache docs
* a little clean-up

Resources/doc/features/headers.rst

@@ -49,7 +49,7 @@ For instance:
                     headers:
                         cache_control: { public: true, max_age: 15, s_maxage: 30, last_modified: "-1 hour" }
 
-See :doc:`/reference/configuration/headers`.
+See the :doc:`/reference/configuration/headers` configuration reference.
 
 .. _manually setting cache headers: http://symfony.com/doc/current/book/http_cache.html#the-cache-control-header
 .. _setting caching headers through annotations: http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/cache.html

Resources/doc/features/helpers/flash-message.rst

@@ -1,7 +1,7 @@
 Flash Message Subscriber
 ========================
 
-**Prerequisites**: *None*
+**Prerequisites**: *none*
 
 When flash messages are rendered into the content of a page, you can't cache
 the page anymore. When enabled, this subscriber reads all flash messages into a

Resources/doc/features/invalidation.rst

@@ -1,7 +1,7 @@
 Invalidation
 ============
 
-**Prerequisites**: :ref:`Configure caching proxy <foshttpcache:proxy-configuration>`.
+**Prerequisites**: :ref:`configure caching proxy <foshttpcache:proxy-configuration>`.
 
 By *invalidating* a piece of content, you tell your HTTP caching proxy (Varnish
 or Nginx) to no longer serve it to clients. When next requested, the proxy will
@@ -64,8 +64,8 @@ You can add invalidation rules to your application configuration:
 
 Now when a request to either route ``villain_edit`` or route ``villain_delete``
 returns a succesful response, both routes ``vilains_index`` and
-``villain_details`` will be purged. See
-:doc:`/reference/configuration/invalidation` for more.
+``villain_details`` will be purged. See the
+:doc:`/reference/configuration/invalidation` configuration reference.
 
 Annotations
 -----------
@@ -84,7 +84,7 @@ invalidation from your controllers::
     {
     }
 
-See further :doc:`/reference/annotations`.
+See the :doc:`/reference/annotations` reference.
 
 Console Commands
 ----------------
@@ -100,7 +100,8 @@ and will automatically talk to all configured cache instances.
   them. See :ref:`cache manager refreshing`.
 * ``fos:httpcache:invalidate:regex`` expects a regular expression and invalidates
   all cache entries matching that expression. To invalidate your entire cache,
-  you can specify ``.`` which will match everything. See :ref:`cache manager invalidation`.
+  you can specify ``.`` (dot) which will match everything.
+  See :ref:`cache manager invalidation`.
 * ``fos:httpcache:invalidate:tag`` accepts one or more tags and invalidates all
   cache entries matching any of those tags. See :doc:`tagging`.
 

Resources/doc/features/tagging.rst

@@ -1,11 +1,13 @@
 Tagging
 =======
 
-**Prerequisites**: :ref:`Configure caching proxy for banning <foshttpcache:varnish-configuration#ban>` (only supported with Varnish).
+**Prerequisites**: :ref:`configure caching proxy for tagging <foshttpcache:varnish_tagging>`
+(Varnish only).
 
 If your application has many intricate relationships between cached items,
 which makes it complex to invalidate them by route, cache tagging will be
-useful.
+useful. It helps you with invalidating many-to-many relationships between
+content items.
 
 Cache tagging, or more precisely `Tagged Cache Invalidation`_, a simpler
 version of `Linked Cache Invalidation`_ (LCI), allows you to:

Resources/doc/features/user-context.rst

@@ -1,7 +1,7 @@
 User Context
 ============
 
-**Prerequisites**: :ref:`Configure caching proxy for user context <foshttpcache:varnish-configuration#user-context>` (only supported with Varnish).
+**Prerequisites**: :ref:`configure caching proxy for user context <foshttpcache:varnish user context>` (Varnish only).
 
 If your application serves different content depending on the user’s group
 or context (guest, editor, admin), you can cache that content per user context.

Resources/doc/overview.rst

@@ -78,8 +78,8 @@ Configuration
 -------------
 
 Now you can configure the bundle under the ``fos_http_cache`` key. The
-:doc:`features` section contains configuration examples, for
-a reference see the :doc:`reference/configuration` section.
+:doc:`features` section introduces the bundle’s features. The
+:doc:`reference/configuration` section lists all configuration options.
 
 Functionality
 -------------

Resources/doc/reference/configuration/match.rst

@@ -1,17 +1,12 @@
-Matching
-========
-
-Several parts of the configuration use ``match`` sections to limit
-configuration to specific requests and responses. Matches are used for
-:doc:`caching headers <headers>`, :doc:`invalidation <invalidation>` and
-:doc:`tag rules <tags>`.
 match
------
+=====
 
-**type**: ``array``
+The :doc:`cache <headers>`, :doc:`invalidation <invalidation>` and
+:doc:`tag rule <tags>` configurations all use ``match`` sections
+to limit the configuration to specific requests and responses.
 
-A match contains one or more match criteria for requests. All matching criteria
-are regular expressions. For instance:
+Each ``match`` section contains one or more match criteria for requests.
+All criteria are regular expressions. For instance:
 
 .. code-block:: yaml