Fix typos

CONTRIBUTING

@@ -25,5 +25,5 @@ Github pull requests
 
 Pull requests are handled like other tickets.
 
-Trivial pull requests (fix typos, etc) are welcomed, but they may be commited
+Trivial pull requests (fix typos, etc) are welcomed, but they may be committed
 by a core team member and the author credited in the commit message.

bin/varnishd/cache/cache_fetch_proc.c

@@ -41,7 +41,7 @@ static unsigned fetchfrag;
 
 /*--------------------------------------------------------------------
  * We want to issue the first error we encounter on fetching and
- * supress the rest.  This function does that.
+ * suppress the rest.  This function does that.
  *
  * Other code is allowed to look at busyobj->fetch_failed to bail out
  *

bin/varnishd/cache/cache_panic.c

@@ -806,7 +806,7 @@ pan_ic(const char *func, const char *file, int line, const char *cond,
 			VSL_Flush(bo->vsl, 0);
 		VMOD_Panic(pan_vsb);
 	} else {
-		VSB_cat(pan_vsb, "Feature short panic supressed details.\n");
+		VSB_cat(pan_vsb, "Feature short panic suppressed details.\n");
 	}
 	VSB_cat(pan_vsb, "\n");
 	VSB_putc(pan_vsb, '\0');	/* NUL termination */

bin/varnishd/cache/cache_tcp_pool.h

@@ -76,7 +76,7 @@ void VTP_Rel(struct tcp_pool **);
 
 int VTP_Open(struct tcp_pool *, vtim_dur tmo, const void **, int*);
 	/*
-	 * Open a new connection and return the adress used.
+	 * Open a new connection and return the address used.
 	 * errno will be returned in the last argument.
 	 */
 

bin/varnishd/hash/hash_critbit.c

@@ -188,7 +188,7 @@ hcb_crit_bit(const uint8_t *digest, const struct objhead *oh2, struct hcb_y *y)
 /*---------------------------------------------------------------------
  * Unless we have the lock, we need to be very careful about pointer
  * references into the tree, we cannot trust things to be the same
- * in two consequtive memory accesses.
+ * in two consecutive memory accesses.
  */
 
 static struct objhead *

bin/varnishd/mgt/mgt_jail.c

@@ -101,7 +101,7 @@ VJ_Init(const char *j_arg)
 		if (av[0] != NULL)
 			ARGV_ERR("-j argument: %s\n", av[0]);
 		if (av[1] == NULL)
-			ARGV_ERR("-j argument is emtpy\n");
+			ARGV_ERR("-j argument is empty\n");
 		vjt = MGT_Pick(vj_choice, av[1], "jail");
 		CHECK_OBJ_NOTNULL(vjt, JAIL_TECH_MAGIC);
 		(void)vjt->init(av + 2);

bin/varnishd/mgt/mgt_param_tcp.c

@@ -30,7 +30,7 @@
  *
  * Parameters related to TCP keepalives are not universally available
  * as socket options, and probing for system-wide defaults more appropriate
- * than our own involves slightly too much grunt-work to be neglible
+ * than our own involves slightly too much grunt-work to be negligible
  * so we sequestrate that code here.
  */
 

doc/sphinx/reference/varnish-cli.rst

@@ -213,7 +213,7 @@ Backend Pattern
 A backend pattern can be a backend name or a combination of a VCL name
 and backend name in "VCL.backend" format.  If the VCL name is omitted,
 the active VCL is assumed.  Partial matching on the backend and VCL
-names is supported using shell-style wilcards, e.g. asterisk (*).
+names is supported using shell-style wildcards, e.g. asterisk (*).
 
 Examples::
 

doc/sphinx/reference/varnishtest.rst

@@ -144,9 +144,9 @@ they look roughly like this::
 
     exec varnishd [varnishtest -p params] [testing params] [vtc -arg params]
 
-Parameters you define with ``varnishtest -p`` may be overriden by
+Parameters you define with ``varnishtest -p`` may be overridden by
 parameters needed by ``varnishtest`` to run properly, and they may in
-turn be overriden by parameters set in test scripts.
+turn be overridden by parameters set in test scripts.
 
 There's also a special mode in which ``varnishtest`` builds itself a
 PATH and a *vmod_path* in order to find Varnish binaries (programs and

doc/sphinx/users-guide/devicedetection.rst

@@ -55,7 +55,7 @@ Example 1: Send HTTP header to backend
 
 The basic case is that Varnish adds the 'X-UA-Device' HTTP header on the backend
 requests, and the backend mentions in the response 'Vary' header that the content
-is dependant on this header.
+is dependent on this header.
 
 Everything works out of the box from Varnish' perspective.
 

doc/sphinx/users-guide/esi.rst

@@ -98,7 +98,7 @@ Ignoring BOM in ESI objects
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you backend spits out a Unicode Byte-Order-Mark as the first
-bytes of the reponse, the "<" check will fail unless you set::
+bytes of the response, the "<" check will fail unless you set::
 
    param.set feature +esi_remove_bom
 

doc/sphinx/users-guide/increasing-your-hitrate.rst

@@ -438,7 +438,7 @@ A stale object is not removed from the cache for the duration of
 increase the storage requirements for your cache, but if you have the
 space, it might be worth it to keep stale objects that can be
 validated for a fairly long time. If the backend can send a 304
-response long after the TTL has expired, you save bandwith on the
+response long after the TTL has expired, you save bandwidth on the
 fetch and reduce pressure on the storage; if not, then it's no
 different from any other cache miss.
 

doc/sphinx/users-guide/storage-backends.rst

@@ -99,7 +99,7 @@ Varnish will also output this message to recommend settings for using
 
 This recommendation should be followed to achieve an optimal
 `libumem`_ configuration for Varnish. Setting this environment
-variable before starting Varnish is required becuase `libumem`_ cannot
+variable before starting Varnish is required because `libumem`_ cannot
 be reconfigured once loaded.
 
 .. _libumem: http://dtrace.org/blogs/ahl/2004/07/13/number-11-of-20-libumem/
@@ -208,7 +208,7 @@ for transient (short lived) objects. This includes the temporary
 objects created when returning a synthetic object. By default Varnish
 would use an unlimited malloc backend for this.
 
-.. XXX: Is this another paramater? In that case handled in the same manner as above? benc
+.. XXX: Is this another parameter? In that case handled in the same manner as above? benc
 
 Varnish will consider an object short lived if the TTL is below the
 parameter 'shortlived'.