[4.0] e90fce3 Be consistent with capitalisation and whitepace.
Lasse Karstensen
lkarsten at varnish-software.com
Thu Mar 13 10:24:21 CET 2014
commit e90fce30053424791fcb87af41c05b579be699fb
Author: Lasse Karstensen <lkarsten at varnish-software.com>
Date: Mon Jan 27 14:07:50 2014 +0100
Be consistent with capitalisation and whitepace.
diff --git a/doc/sphinx/installation/bugs.rst b/doc/sphinx/installation/bugs.rst
index dde28bf..b1cb06a 100644
--- a/doc/sphinx/installation/bugs.rst
+++ b/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
diff --git a/doc/sphinx/installation/platformnotes.rst b/doc/sphinx/installation/platformnotes.rst
index 048442c..bacc57e 100644
--- a/doc/sphinx/installation/platformnotes.rst
+++ b/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::
diff --git a/doc/sphinx/installation/prerequisites.rst b/doc/sphinx/installation/prerequisites.rst
index 3508c1e..ad92ee0 100644
--- a/doc/sphinx/installation/prerequisites.rst
+++ b/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
diff --git a/doc/sphinx/reference/varnish-cli.rst b/doc/sphinx/reference/varnish-cli.rst
index 834a776..d820d69 100644
--- a/doc/sphinx/reference/varnish-cli.rst
+++ b/doc/sphinx/reference/varnish-cli.rst
@@ -1,6 +1,6 @@
-=======
-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
diff --git a/doc/sphinx/reference/varnishadm.rst b/doc/sphinx/reference/varnishadm.rst
index 3521474..95113fa 100644
--- a/doc/sphinx/reference/varnishadm.rst
+++ b/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
diff --git a/doc/sphinx/reference/varnishd.rst b/doc/sphinx/reference/varnishd.rst
index 201c99a..a430fc2 100644
--- a/doc/sphinx/reference/varnishd.rst
+++ b/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
diff --git a/doc/sphinx/reference/varnishhist.rst b/doc/sphinx/reference/varnishhist.rst
index ffc8289..017bb55 100644
--- a/doc/sphinx/reference/varnishhist.rst
+++ b/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
diff --git a/doc/sphinx/reference/varnishreplay.rst b/doc/sphinx/reference/varnishreplay.rst
index da3df36..b8b89e9 100644
--- a/doc/sphinx/reference/varnishreplay.rst
+++ b/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
diff --git a/doc/sphinx/reference/varnishstat.rst b/doc/sphinx/reference/varnishstat.rst
index c27af28..40951e1 100644
--- a/doc/sphinx/reference/varnishstat.rst
+++ b/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
diff --git a/doc/sphinx/reference/varnishtest.rst b/doc/sphinx/reference/varnishtest.rst
index a0df5e2..8a3124c 100644
--- a/doc/sphinx/reference/varnishtest.rst
+++ b/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.
diff --git a/doc/sphinx/reference/vcl.rst b/doc/sphinx/reference/vcl.rst
index d769e81..9aea743 100644
--- a/doc/sphinx/reference/vcl.rst
+++ b/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
diff --git a/doc/sphinx/reference/vmod.rst b/doc/sphinx/reference/vmod.rst
index 88a511d..95987e1 100644
--- a/doc/sphinx/reference/vmod.rst
+++ b/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.
diff --git a/doc/sphinx/reference/vmod_std.rst b/doc/sphinx/reference/vmod_std.rst
index d80cb5b..36a2678 100644
--- a/doc/sphinx/reference/vmod_std.rst
+++ b/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
diff --git a/doc/sphinx/tutorial/backend_servers.rst b/doc/sphinx/tutorial/backend_servers.rst
index ebc05ad..69d1c28 100644
--- a/doc/sphinx/tutorial/backend_servers.rst
+++ b/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
diff --git a/doc/sphinx/users-guide/command-line.rst b/doc/sphinx/users-guide/command-line.rst
index ea44323..65dec6a 100644
--- a/doc/sphinx/users-guide/command-line.rst
+++ b/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*
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/doc/sphinx/users-guide/intro.rst b/doc/sphinx/users-guide/intro.rst
index 3d2fb0d..e497e00 100644
--- a/doc/sphinx/users-guide/intro.rst
+++ b/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
diff --git a/doc/sphinx/users-guide/operation-logging.rst b/doc/sphinx/users-guide/operation-logging.rst
index f15425d..856cbfa 100644
--- a/doc/sphinx/users-guide/operation-logging.rst
+++ b/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
diff --git a/doc/sphinx/users-guide/operation-statistics.rst b/doc/sphinx/users-guide/operation-statistics.rst
index ad57037..8736c5e 100644
--- a/doc/sphinx/users-guide/operation-statistics.rst
+++ b/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.
diff --git a/doc/sphinx/users-guide/purging.rst b/doc/sphinx/users-guide/purging.rst
index 3c652ea..5604d96 100644
--- a/doc/sphinx/users-guide/purging.rst
+++ b/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
diff --git a/doc/sphinx/users-guide/run_security.rst b/doc/sphinx/users-guide/run_security.rst
index 7eda18e..a2557a2 100644
--- a/doc/sphinx/users-guide/run_security.rst
+++ b/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)
diff --git a/doc/sphinx/users-guide/sizing-your-cache.rst b/doc/sphinx/users-guide/sizing-your-cache.rst
index 7d48200..8f2dfba 100644
--- a/doc/sphinx/users-guide/sizing-your-cache.rst
+++ b/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.
diff --git a/doc/sphinx/users-guide/troubleshooting.rst b/doc/sphinx/users-guide/troubleshooting.rst
index b6f6558..fa01890 100644
--- a/doc/sphinx/users-guide/troubleshooting.rst
+++ b/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
diff --git a/doc/sphinx/users-guide/vcl-backends.rst b/doc/sphinx/users-guide/vcl-backends.rst
index 7dc8c95..dc9a3cb 100644
--- a/doc/sphinx/users-guide/vcl-backends.rst
+++ b/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
diff --git a/doc/sphinx/users-guide/vcl-built-in-subs.rst b/doc/sphinx/users-guide/vcl-built-in-subs.rst
index d1c31e6..0ab6ced 100644
--- a/doc/sphinx/users-guide/vcl-built-in-subs.rst
+++ b/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
diff --git a/doc/sphinx/whats-new/upgrading.rst b/doc/sphinx/whats-new/upgrading.rst
index f1fcd99..97e3a0d 100644
--- a/doc/sphinx/whats-new/upgrading.rst
+++ b/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);
}
More information about the varnish-commit
mailing list