Skip to content

V
varnishevent3
Commit 8749c295 authored by Per Andreas Buer's avatar Per Andreas Buer
Browse files
Options

spelling 

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@5593 d4fa192b-c00b-0410-8231-f00ffab90ce4
parent ed1ab480
Hide whitespace changes
Inline Side-by-side
Showing with 15 additions and 15 deletions
doc/sphinx/tutorial/advanced_backend_servers.rst
View file @ 8749c295
......@@ -45,7 +45,7 @@ Directors
You can also group several backend into a group of backends. These
groups are called directors. This will give you increased performance
and resillience. You can define several backends and group them
and resilience. You can define several backends and group them
together in a director.::
backend server1 {
......@@ -70,7 +70,7 @@ Now we create the director.::
This director is a round-robin director. This means the director will
distribute the incomming requests on a round-robin basis. There is
distribute the incoming requests on a round-robin basis. There is
also a *random* director which distributes requests in a, you guessed
it, random fashion.
......@@ -145,7 +145,7 @@ Now we define the director.::
You use this director just as you would use any other director or
backend. Varnish will not send traffic to hosts that are marked as
unhealty. Varnish can also serve stale content if all the backends are
unhealthy. Varnish can also serve stale content if all the backends are
down. See :ref:`tutorial-handling_misbehaving_servers` for more
information on how to enable this.
......
doc/sphinx/tutorial/advanced_topics.rst
View file @ 8749c295
......@@ -16,14 +16,14 @@ few more subroutines available and there a few actions that we haven't
discussed. For a complete(ish) guide to VCL have a look at the VCL man
page - ref:`reference-vcl`.
Using Inline C to extend Varnish
Using In-line C to extend Varnish
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can use *inline C* to extend Varnish. Please note that you can
You can use *in-line C* to extend Varnish. Please note that you can
seriously mess up Varnish this way. The C code runs within the Varnish
Cache process so if your code generates a segfault the cache will crash.
One of the first uses I saw of Inline C was logging to syslog.::
One of the first uses I saw of In-line C was logging to syslog.::
# The include statements must be outside the subroutines.
C{
......@@ -45,7 +45,7 @@ together. These *fragments* can have individual cache policies. If you
have a web site with a list showing the 5 most popular articles on
your site this list can probably be cached as a fragment and included
in all the other pages. Used properly it can dramatically increase
your hitrate and reduce the load on your servers. ESI looks like this::
your hit rate and reduce the load on your servers. ESI looks like this::
<HTML>
<BODY>
......
doc/sphinx/tutorial/cookies.rst
View file @ 8749c295
......@@ -3,18 +3,18 @@
Cookies
-------
Varnish will not cache a object comming from the backend with a
Varnish will not cache a object coming from the backend with a
Set-Cookie header present. Also, if the client sends a Cookie header,
Varnish will bypass the cache and go directly to the backend.
This can be overly conservative. A lot of sites use Google Analytics
(GA) to analyse their traffic. GA sets a cookie to track you. This
(GA) to analyze their traffic. GA sets a cookie to track you. This
cookie is used by the client side java script and is therefore of no
interest to the server.
For a lot of web application it makes sense to completly disregard the
For a lot of web application it makes sense to completely disregard the
cookies unless you are accessing a special part of the web site. This
VCL snipplet in vcl_recv will disregard cookies unless you are
VCL snippet in vcl_recv will disregard cookies unless you are
accessing /admin/.::
if ( !( req.url ~ ^/admin/) ) {
......@@ -23,7 +23,7 @@ accessing /admin/.::
Quite simple. If, however, you need to do something more complicated,
like removing one out of several cookies, things get
difficult. Unfornunatly Varnish doesn't have good tools for
difficult. Unfortunately Varnish doesn't have good tools for
manipulating the Cookies. We have to use regular expressions to do the
work. If you are familiar with regular expressions you'll understand
whats going on. If you don't I suggest you either pick up a book on
......
doc/sphinx/tutorial/esi.rst
View file @ 8749c295
......@@ -9,7 +9,7 @@ over HTTP.
On most web sites a lot of content is shared between
pages. Regenerating this content for every page view is wasteful and
ESI tries to address that lettting you decide the cache policy for
ESI tries to address that letting you decide the cache policy for
each fragment individually.
In Varnish we've only implemented a small subset of ESI. As of 2.1 we
......@@ -59,7 +59,7 @@ Example: esi remove
~~~~~~~~~~~~~~~~~~~
The *remove* keyword allows you to remove output. You can use this to make
a fallback of sorts, when ESI is not available, like this:::
a fall back of sorts, when ESI is not available, like this:::
<esi:include src="http://www.example.com/ad.html"/>
<esi:remove>
......
doc/sphinx/tutorial/increasing_your_hitrate.rst
View file @ 8749c295
......@@ -44,7 +44,7 @@ couple of really basic programs that can execute a HTTP request and
give you the result. I mostly use two programs, GET and HEAD.
vg.no was the first site to use Varnish and the people running Varnish
there are quite cluefull. So its interesting to look at their HTTP
there are quite clue-full. So its interesting to look at their HTTP
Headers. Lets send a GET request for their home page.::
$ GET -H 'Host: www.vg.no' -Used http://vg.no/
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment