Fix typos in tutorial

doc/sphinx/tutorial/increasing_your_hitrate.rst

@@ -19,11 +19,11 @@ the web server. If you have Varnish the easiest is to use varnishlog
 and varnishtop but sometimes a client-side tool makes sense. Here are
 the ones I use.
 
-Tool: varnistop
-~~~~~~~~~~~~~~~
+Tool: varnishtop
+~~~~~~~~~~~~~~~~
 
 You can use varnishtop to identify what URLs are hitting the backend
-the most. ``varnishtop -i txurl`` is a essential command. You can see
+the most. ``varnishtop -i txurl`` is an essential command. You can see
 some other examples of varnishtop usage in :ref:`tutorial-statistics`.
 
 
@@ -39,13 +39,13 @@ from the client (-c) matching /foo/bar.
 Tool: lwp-request
 ~~~~~~~~~~~~~~~~~
 
-lwp-request is part of The World-Wide Web library for Perl. It's
-couple of really basic programs that can execute a HTTP request and
+lwp-request is part of The World-Wide Web library for Perl. It's a
+couple of really basic programs that can execute an 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 clue-full. So its interesting to look at their HTTP
-Headers. Lets send a GET request for their home page.::
+there are quite clueful. So it's interesting to look at their HTTP
+Headers. Let's send a GET request for their home page::
 
   $ GET -H 'Host: www.vg.no' -Used http://vg.no/
   GET http://vg.no/
@@ -66,16 +66,16 @@ Headers. Lets send a GET request for their home page.::
 
 OK. Let me explain what it does. GET usually send off HTTP 0.9
 requests, which lack the Host header. So I add a Host header with the
--H option. -U print request headers, -s prints response status -e
-prints repsonse headers and -d discards the actual content. We dont
+-H option. -U print request headers, -s prints response status, -e
+prints response headers and -d discards the actual content. We don't
 really care about the content, only the headers.
 
-As you can see VG ads quite a bit of information in their
+As you can see, VG adds quite a bit of information in their
 headers. Some of the headers, like the X-Rick-Would-Never are specific
 to vg.no and their somewhat odd sense of humour. Others, like the
 X-VG-Webcache are for debugging purposes. 
 
-So, to check whether a site sets cookies for a specific URL just do::
+So, to check whether a site sets cookies for a specific URL, just do::
 
   GET -Used http://example.com/ |grep ^Set-Cookie
 
@@ -83,7 +83,7 @@ Tool: Live HTTP Headers
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 There is also a plugin for Firefox. *Live HTTP Headers* can show you
-what headers are beeing sent and recieved. Live HTTP Headers can be
+what headers are being sent and recieved. Live HTTP Headers can be
 found at https://addons.mozilla.org/en-US/firefox/addon/3829/ or by
 googling "Live HTTP Headers".
 
@@ -97,14 +97,14 @@ it is appropriate to cache the contents and how long Varnish can keep
 the content.
 
 Please note that when considering these headers Varnish actually
-considers itself *part of* the actual webserver. The ratinonale being
+considers itself *part of* the actual webserver. The rationale being
 that both are under your control. 
 
 The term *surrogate origin cache* is not really well defined by the
 IETF so RFC 2616 so the various ways Varnish works might differ from
 your expectations.
 
-Lets take a look at the importent headers you should be aware of:
+Let's take a look at the important headers you should be aware of:
 
 Cache-Control
 ~~~~~~~~~~~~~
@@ -114,11 +114,11 @@ cares about the *max-age* parameter and uses it to calculate the TTL
 for an object. 
 
 "Cache-Control: nocache" is ignored but if you need this you can
-easyli add support for it.
+easily add support for it.
 
 So make sure use issue a Cache-Control header with a max-age
-header. You can have a look at what Varnish Softwares drupal server
-issues:::
+header. You can have a look at what Varnish Software's drupal server
+issues::
 
   $ GET -Used http://www.varnish-software.com/|grep ^Cache-Control
   Cache-Control: public, max-age=600
@@ -126,7 +126,7 @@ issues:::
 Age
 ~~~
 
-Varnish adds a Age header to indicate how long the object has been
+Varnish adds an Age header to indicate how long the object has been
 kept inside Varnish. You can grep out Age from varnishlog like this::
 
   varnishlog -i TxHeader -I ^Age
@@ -134,9 +134,8 @@ kept inside Varnish. You can grep out Age from varnishlog like this::
 Pragma
 ~~~~~~
 
-
 HTTP 1.0 server might send "Pragma: nocache". Varnish ignores this
-header. You could easly add support for this header in VCL.
+header. You could easily add support for this header in VCL.
 
 In vcl_fetch::
 
@@ -147,18 +146,18 @@ In vcl_fetch::
 Authorization
 ~~~~~~~~~~~~~
 
-If Varnish sees a Authorization header it will pass the request. If
+If Varnish sees an Authorization header it will pass the request. If
 this is not what you want you can unset the header.
 
 Overriding the time-to-live (ttl)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Sometimes your backend will misbehave. It might, depending on your
-setup, be easier to override the ttl in Varnish then to fix your
+setup, be easier to override the ttl in Varnish than to fix your
 somewhat cumbersome backend. 
 
 You need VCL to identify the objects you want and then you set the
-beresp.ttl to whatever you want.::
+beresp.ttl to whatever you want::
 
   sub vcl_fetch {
       if (req.url ~ "^/legacy_broken_cms/") {
@@ -171,12 +170,12 @@ Normalizing your namespace
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Some sites are accessed via lots of
-hostnames. http://www.varnish-software.com ,
-http://varnish-software.com and http://varnishsoftware.com/ all point
-at the same site. Since Varnish doesn't know they are different
+hostnames. http://www.varnish-software.com/,
+http://varnish-software.com/ and http://varnishsoftware.com/ all point
+at the same site. Since Varnish doesn't know they are different,
 Varnish will cache different versions of every page for every
 hostname. You can mitigate this in your web server configuration by
-setting up redirects or by using the following VCL:::
+setting up redirects or by using the following VCL::
 
   if (req.http.host ~ "^(www.)?varnish-?software.com") {
     set req.http.host = "varnish-software.com";