docs: fix typos (envoyproxy#2265)

Signed-off-by: Thomas Broadley <[email protected]>

DEPRECATED.md

@@ -40,4 +40,4 @@ The following features have been DEPRECATED and will be removed in the specified
 * The direction of network and HTTP filters in the configuration will be ignored from 1.4.0 and
   later removed from the configuration in the v2 APIs. Filter direction is now implied at the C++ type
   level. The `type()` methods on the `NamedNetworkFilterConfigFactory` and
-  `NamedHttpFilterConfigFactory` intefaces have been removed to reflect this.
+  `NamedHttpFilterConfigFactory` interfaces have been removed to reflect this.

RAW_RELEASE_NOTES.md

@@ -16,7 +16,7 @@ final version.
 * Added DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT header formatter. CLIENT_IP header formatter has been
   deprecated.
 * Added transport socket interface to allow custom implementation of transport socket. A transport socket
-  provides read and write logic with buffer encryption and decryption. The exising TLS implementation is
+  provides read and write logic with buffer encryption and decryption. The existing TLS implementation is
   refactored with the interface.
 * Added support for dynamic response header values (`%CLIENT_IP%` and `%PROTOCOL%`).
 * Added native DogStatsD support. :ref:`DogStatsdSink <envoy_api_msg_DogStatsdSink>`

SECURITY_RELEASE_PROCESS.md

@@ -210,7 +210,7 @@ New membership requests are sent to [email protected].
 In the body of your request please specify how you qualify and fulfill each
 criterion listed in [Membership Criteria](#membership-criteria).
 
-Here is a psuedo example:
+Here is a pseudo example:
 
 ```
 To: [email protected]

bazel/README.md

@@ -252,7 +252,7 @@ on the Bazel command line.
 
 The default maximum number of stats in shared memory, and the default
 maximum length of a cluster/route config/listener name, can be
-overriden at compile-time by defining `ENVOY_DEFAULT_MAX_STATS` and
+overridden at compile-time by defining `ENVOY_DEFAULT_MAX_STATS` and
 `ENVOY_DEFAULT_MAX_OBJ_NAME_LENGTH`, respectively, to the desired
 value. For example:
 

configs/original-dst-cluster/README.md

@@ -16,7 +16,7 @@ is set to 10000, which matches the configuration in
 `proxy_config.json`.
 
 This creates a network namespace `ns1` and redirects traffic from
-there to Envoy listening on port 10000 if the desination address of
+there to Envoy listening on port 10000 if the destination address of
 the traffic matches `173.194.222.0/24` :
 
 ```
@@ -65,7 +65,7 @@ thread.
 
 # Cleaning up
 
-To propertly remove the added network namespace and the iptables
+To properly remove the added network namespace and the iptables
 configuration run `netns_cleanup.sh` with the same arguments as
 the setup before:
 

source/docs/flow_control.md

@@ -5,7 +5,7 @@ buffer contains more data than the configured limit, the high watermark callback
 off a chain of events which eventually informs the data source to stop sending data. This back-off
 may be immediate (stop reading from a socket) or gradual (stop HTTP/2 window updates) so all
 buffer limits in Envoy are considered soft limits. When the buffer eventually drains (generally to
-half of of the high watermark to avoid thrashing back and forth) the low watermark callback will
+half of the high watermark to avoid thrashing back and forth) the low watermark callback will
 fire, informing the sender it can resume sending data.
 
 ### TCP implementation details
@@ -82,7 +82,7 @@ responsible for intercepting watermark events for its own buffers, the individua
 any events to the connection manager, which has the ability to call `readDisable()` to enable and
 disable further data from downstream. On the reverse path, when the downstream connection
 backs up, the connection manager collects events for the downstream streams and
-the downstream conection. It passes events to the router filter via
+the downstream connection. It passes events to the router filter via
 `Envoy::Http::DownstreamWatermarkCallbacks` and the router can then call `readDisable()` on the
 upstream stream. Filters opt into subscribing to `DownstreamWatermarkCallbacks` as a performance
 optimization to avoid each watermark event on a downstream HTTP/2 connection resulting in
@@ -92,7 +92,7 @@ the router filter only subscribes to notifications when it has an upstream
 connection, the connection manager tracks how many outstanding high watermark
 events have occurred and passes any on to the router filter when it subscribes.
 
-It is worth noting that the router does not unwind`readDisable(true)` calls on
+It is worth noting that the router does not unwind `readDisable(true)` calls on
 destruction. Each codec must ensure that any necessary readDisable calls are
 unwound. In the case of HTTP/2 the `Envoy::Http::Http2::ConnectionImpl` will consume
 any outstanding flow control window on stream deletion to avoid leaking the connection-level
@@ -123,7 +123,7 @@ configured bytes without calling the appropriate watermark callbacks or sending
 an error response.
 
 Filters may override the default limit with calls to `setDecoderBufferLimit()`
-and `setEncoderBufferLimit()`. These limits are applied as filters are creaeted
+and `setEncoderBufferLimit()`. These limits are applied as filters are created
 so filters later in the chain can override the limits set by prior filters.
 
 Most filters do not buffer internally, but instead push back on data by
@@ -323,7 +323,7 @@ The low watermark path is as follows:
 # HTTP/2 network downstream network buffer
 
 When a downstream network connection buffers too much data, it informs the
-connection manager which passes theh high watermark event to all of the streams
+connection manager which passes the high watermark event to all of the streams
 on the connection. They pass the watermark event to the router, which calls
 `readDisable()` on the upstream streams.
 

test/config/integration/certs/README.md

@@ -6,7 +6,7 @@ There are 5 identities:
   *clientkey.pem* is its private key.
 - **Server**: It has the certificate *servercert.pem*, which is signed by the
   **CA** using the config *servercert.cfg*. *serverkey.pem* is its private key.
-- **Upsteam CA**: Certificate Authority for **Upstream**. It has the self-signed
+- **Upstream CA**: Certificate Authority for **Upstream**. It has the self-signed
   certificate *upstreamcacert.pem*. *upstreamcakey.pem* is its private key.
 - **Upstream**: It has the certificate *upstreamcert.pem*, which is signed by
   the **Upstream CA** using the config *upstreamcert.cfg*. *upstreamkey.pem* is