docs: fix spelling mistakes (#507)

Signed-off-by: Daniel Hochman <danielhochman@users.noreply.github.com>

bazel/api_build_system.bzl

@@ -21,7 +21,7 @@ def _LibrarySuffix(library_name, suffix):
 
 # TODO(htuch): has_services is currently ignored but will in future support
 # gRPC stub generation.
-# TOOD(htuch): Convert this to native py_proto_library once
+# TODO(htuch): Convert this to native py_proto_library once
 # https://github.com/bazelbuild/bazel/issues/3935 and/or
 # https://github.com/bazelbuild/bazel/issues/2626 are resolved.
 def api_py_proto_library(name, srcs = [], deps = [], has_services = 0):

docs/root/api-v1/access_log.rst

@@ -69,7 +69,7 @@ value
   *(required, integer)* Default value to compare against if runtime value is not available.
 
 runtime_key
-  *(optional, string)* Runtime key to get value for comparision. This value is used if defined.
+  *(optional, string)* Runtime key to get value for comparison. This value is used if defined.
 
 Duration
 ^^^^^^^^
@@ -94,7 +94,7 @@ value
   *(required, integer)* Default value to compare against if runtime values is not available.
 
 runtime_key
-  *(optional, string)* Runtime key to get value for comparision. This value is used if defined.
+  *(optional, string)* Runtime key to get value for comparison. This value is used if defined.
 
 
 Not health check

docs/root/configuration/cluster_manager/cluster_hc.rst

@@ -60,7 +60,7 @@ binary block can be of arbitrary length and is just concatenated together when s
 into multiple blocks can be useful for readability).
 
 When checking the response, "fuzzy" matching is performed such that each binary block must be found,
-and in the order specified, but not necessarly contiguous. Thus, in the example above,
+and in the order specified, but not necessarily contiguous. Thus, in the example above,
 "FFFFFFFF" could be inserted in the response between "EEEEEEEE" and "01000000" and the check
 would still pass. This is done to support protocols that insert non-deterministic data, such as
 time, into the response.

docs/root/configuration/http_conn_man/stats.rst

@@ -108,7 +108,7 @@ All http2 statistics are rooted at *http2.*
    tx_reset, Counter, Total number of reset stream frames transmitted by Envoy.
    header_overflow, Counter, Total number of connections reset due to the headers being larger than `Envoy::Http::Http2::ConnectionImpl::StreamImpl::MAX_HEADER_SIZE` (63k).
    trailers, Counter, Total number of trailers seen on requests coming from downstream.
-   headers_cb_no_stream, Counter, Total number of errors where a header callback is called without an associated stream. This tracks an unexpected occurance due to an as yet undiagnosed bug.
+   headers_cb_no_stream, Counter, Total number of errors where a header callback is called without an associated stream. This tracks an unexpected occurrence due to an as yet undiagnosed bug.
    too_many_header_frames, Counter, Total number of times an HTTP2 connection is reset due to receiving too many headers frames. Envoy currently supports proxying at most one header frame for 100-Continue one non-100 response code header frame and one frame with trailers.
 
 

docs/root/configuration/http_filters/grpc_http1_bridge_filter.rst

@@ -16,7 +16,7 @@ response trailers to a compliant gRPC server. It works by doing the following:
   *grpc-status* code. If it is not zero, the filter switches the HTTP response code to 503. It also copies
   the *grpc-status* and *grpc-message* trailers into the response headers so that the client can look
   at them if it wishes.
-* The client should send HTTP/1.1 requests that translate to the following psuedo headers:
+* The client should send HTTP/1.1 requests that translate to the following pseudo headers:
 
   * *\:method*: POST
   * *\:path*: <gRPC-METHOD-NAME>

docs/root/configuration/tools/router_check.rst

@@ -29,7 +29,7 @@ Validate
   The validate fields specify the expected values and test cases to check. At least one test
   case is required.
 
-A simple tool configuration json has one test case and is writen as follows. The test
+A simple tool configuration json has one test case and is written as follows. The test
 expects a cluster name match of "instant-server".::
 
    [
@@ -143,7 +143,7 @@ validate
   cluster_name
     *(optional, string)* Match the cluster name.
 
-  virutal_cluster_name
+  virtual_cluster_name
     *(optional, string)* Match the virtual cluster name.
 
   virtual_host_name

docs/root/install/sandboxes/front_proxy.rst

@@ -197,7 +197,7 @@ enter the ``front-envoy`` container, and ``curl`` for services locally::
 When envoy runs it also attaches an ``admin`` to your desired port. In the example
 configs the admin is bound to port ``8001``. We can ``curl`` it to gain useful information.
 For example you can ``curl`` ``/server_info`` to get information about the
-envoy version you are running. Addionally you can ``curl`` ``/stats`` to get
+envoy version you are running. Additionally you can ``curl`` ``/stats`` to get
 statistics. For example inside ``frontenvoy`` we can get::
 
   $ docker-compose exec front-envoy /bin/bash

docs/root/install/tools/route_table_check_tool.rst

@@ -16,7 +16,7 @@ Input
   2. A tool config JSON file. The tool config JSON file schema is found in
      :ref:`config <config_tools_router_check_tool>`.
      The tool config input file specifies urls (composed of authorities and paths)
-     and expected route parameter values. Additonal parameters such as additonal headers are optional.
+     and expected route parameter values. Additional parameters such as additional headers are optional.
 
 Output
   The program exits with status EXIT_FAILURE if any test case does not match the expected route parameter
@@ -48,7 +48,7 @@ Building
 
 Running
   The tool takes two input json files and an optional command line parameter ``--details``. The
-  expected order of command line arguements is:
+  expected order of command line arguments is:
   1. The router configuration json file.
   2. The tool configuration json file.
   3. The optional details flag. ::

docs/root/operations/admin.rst

@@ -163,7 +163,7 @@ The fields are:
 
   Outputs /stats in `Prometheus <https://prometheus.io/docs/instrumenting/exposition_formats/>`_
   v0.0.4 format. This can be used to integrate with a Prometheus server. Currently, only counters and
-  gauges are outputed. Histograms will be outputed in a future update.
+  gauges are output. Histograms will be output in a future update.
 
 .. http:get:: /runtime
 

envoy/api/v2/cds.proto

@@ -262,7 +262,7 @@ message Cluster {
 
   // Optional configuration used to bind newly established upstream connections.
   // This overrides any bind_config specified in the bootstrap proto.
-  // If the addres and port are empty, no bind will be performed.
+  // If the address and port are empty, no bind will be performed.
   core.BindConfig upstream_bind_config = 21;
 
   // Optionally divide the endpoints in this cluster into subsets defined by

envoy/api/v2/endpoint/load_report.proto

@@ -29,7 +29,7 @@ message UpstreamLocalityStats {
   //
   // The total number of requests successfully completed by the endpoints in the
   // locality. These include non-5xx responses for HTTP, where errors
-  // originate at the client and the endpoint responded successfuly. For gRPC,
+  // originate at the client and the endpoint responded successfully. For gRPC,
   // the grpc-status values are those not covered by total_error_requests below.
   uint64 total_successful_requests = 2;
 

envoy/config/filter/accesslog/v2/accesslog.proto

@@ -95,7 +95,7 @@ message AccessLogCommon {
   // The upstream cluster that *upstream_remote_address* belongs to.
   string upstream_cluster = 15;
 
-  // Flags indicating occurences during request/response processing.
+  // Flags indicating occurrences during request/response processing.
   ResponseFlags response_flags = 16;
 
   // All metadata encountered during request processing, including endpoint
@@ -110,7 +110,7 @@ message AccessLogCommon {
 }
 
 // [#not-implemented-hide:] Not configuration. TBD how to doc proto APIs.
-// Flags indicating occurences during request/response processing.
+// Flags indicating occurrences during request/response processing.
 message ResponseFlags {
   // Indicates local server healthcheck failed.
   bool failed_local_healthcheck = 1;

tools/protodoc/protodoc.py

@@ -59,7 +59,7 @@ VALID_ANNOTATIONS = set([
     PROTO_STATUS_ANNOTATION,
 ])
 
-# These can propagate from file scope to message/enum scope (and be overriden).
+# These can propagate from file scope to message/enum scope (and be overridden).
 INHERITED_ANNOTATIONS = set([
     PROTO_STATUS_ANNOTATION,
 ])