Merge branch 'master' of ssh://git.varnish-cache.org/git/varnish-cache

doc/sphinx/conf.py.in

@@ -64,7 +64,7 @@ release = '@VERSION@'
 
 # List of directories, relative to source directory, that shouldn't be searched
 # for source files.
-exclude_trees = ['=build']
+exclude_patterns = ['=build','reference/params.rst']
 
 # The reST default role (used for this markup: `text`) to use for all documents.
 #default_role = None
@@ -147,7 +147,7 @@ html_title = "Varnish version @VERSION@ documentation"
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['=static']
+#html_static_path = ['=static']
 
 # If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
 # using the given strftime format.

doc/sphinx/faq/general.rst

@@ -337,7 +337,7 @@ Varnish has a feature called **hit for pass**, which is used when Varnish gets a
           * Client 2..N are now given the **hit for pass** object instructing them to go to the backend
 
 The **hit for pass** object will stay cached for the duration of its ttl. This means that subsequent clients requesting /foo will be sent straight to the backend as long as the **hit for pass** object exists.
-The :command:`varnishstat` can tell you how many **hit for pass** objects varnish has served. The default vcl will set ttl for a hit_for_pass object to 120s. But you can override this, using the following logic:
+The :command:`varnishstat` can tell you how many **hit for pass** objects varnish has served. The default vcl will set ttl for a hit_for_pass object to 120s. But you can override this, using the following logic::
 
         sub vcl_fetch {
           if (!obj.cacheable) {

doc/sphinx/installation/upgrade.rst

@@ -42,7 +42,7 @@ becomes
 
 	ban("req.url = " + req.url);
 
-``purge`` does not take any arguments anymore, but can be used in vcl_hit or vcl_miss to purge the item from the cache, where you would reduce ttl to 0 in Varnish 2.1.
+``purge`` does not take any arguments anymore, but can be used in vcl_hit or vcl_miss to purge the item from the cache, where you would reduce ttl to 0 in Varnish 2.1::
 
 	sub vcl_hit {
 	  if (req.request == "PURGE") {
@@ -51,7 +51,7 @@ becomes
 	  }
 	}
 
-becomes
+becomes::
 
 	sub vcl_hit {
 	  if (req.request == "PURGE") {
@@ -68,13 +68,13 @@ becomes
 returns are now done with the ``return()`` function
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-``pass``, ``pipe``, ``lookup``, ``deliver``, ``fetch``, ``hash``, ``pipe`` and ``restart`` are no longer keywords, but arguments to ``return()``, so
+``pass``, ``pipe``, ``lookup``, ``deliver``, ``fetch``, ``hash``, ``pipe`` and ``restart`` are no longer keywords, but arguments to ``return()``, so::
 
 	sub vcl_pass {
 	  pass;
 	}
 
-becomes
+becomes::
 
 	sub vcl_pass {
 	  return(pass);

doc/sphinx/reference/params.rst

@@ -128,6 +128,7 @@ diag_bitmap
 	  0x00020000 - synchronous start of persistence.
 	  0x00040000 - release VCL early.
 	  0x80000000 - do edge-detection on digest.
+
 	Use 0x notation and do the bitor in your head :-)
 
 esi_syntax
@@ -140,6 +141,7 @@ esi_syntax
 	  0x00000002 - Ignore non-esi elements
 	  0x00000004 - Emit parsing debug records
 	  0x00000008 - Force-split parser input (debugging)
+
 	Use 0x notation and do the bitor in your head :-)
 
 expiry_sleep
@@ -203,6 +205,7 @@ gzip_tmp_space
 	  0 - malloc
 	  1 - session workspace
 	  2 - thread workspace
+
 	If you have much gzip/gunzip activity, it may be an advantage to use workspace for these allocations to reduce malloc activity.  Be aware that gzip needs 256+KB and gunzip needs 32+KB of workspace (64+KB if ESI processing).
 
 gzip_window
@@ -216,7 +219,7 @@ http_gzip_support
 	- Default: on
 	- Flags: experimental
 
-	Enable gzip support. When enabled Varnish will compress uncompressed objects before they are stored in the cache. If a client does not support gzip encoding Varnish will uncompress compressed objects on demand. Varnish will also rewrite the Accept-Encoding header of clients indicating support for gzip to::
+	Enable gzip support. When enabled Varnish will compress uncompressed objects before they are stored in the cache. If a client does not support gzip encoding Varnish will uncompress compressed objects on demand. Varnish will also rewrite the Accept-Encoding header of clients indicating support for gzip to:
 
 	Accept-Encoding: gzip