docs: GRPC -> gRPC (#75)

docs/configuration/http_filters/grpc_http1_bridge_filter.rst

@@ -1,12 +1,12 @@
 .. _config_http_filters_grpc_bridge:
 
-GRPC HTTP/1.1 bridge
+gRPC HTTP/1.1 bridge
 ====================
 
-GRPC :ref:`architecture overview <arch_overview_grpc>`.
+gRPC :ref:`architecture overview <arch_overview_grpc>`.
 
 This is a simple filter which enables the bridging of an HTTP/1.1 client which does not support
-response trailers to a compliant GRPC server. It works by doing the following:
+response trailers to a compliant gRPC server. It works by doing the following:
 
 * When a request is sent, the filter sees if the connection is HTTP/1.1 and the request content type
   is *application/grpc*.
@@ -17,7 +17,7 @@ response trailers to a compliant GRPC server. It works by doing the following:
 * The client should send HTTP/1.1 requests that translate to the following psuedo headers:
 
   * *\:method*: POST
-  * *\:path*: <GRPC-METHOD-NAME>
+  * *\:path*: <gRPC-METHOD-NAME>
   * *content-type*: application/grpc
 
 * The body should be the serialized grpc body which is:
@@ -27,12 +27,12 @@ response trailers to a compliant GRPC server. It works by doing the following:
   * serialized proto message.
 
 * Because this scheme must buffer the response to look for the *grpc-status* trailer it will only
-  work with unary GRPC APIs.
+  work with unary gRPC APIs.
 
 More info: http://www.grpc.io/docs/guides/wire.html
 
-This filter also collects stats for all GRPC requests that transit, even if those requests are
-normal GRPC requests over HTTP/2.
+This filter also collects stats for all gRPC requests that transit, even if those requests are
+normal gRPC requests over HTTP/2.
 
 .. code-block:: json
 

docs/configuration/overview/rate_limit.rst

@@ -29,10 +29,10 @@ config
     service. The client will connect to this cluster when it needs to make rate limit service
     requests.
 
-GRPC service IDL
+gRPC service IDL
 ----------------
 
-Envoy expects the rate limit service to support the GRPC IDL specified in
+Envoy expects the rate limit service to support the gRPC IDL specified in
 :repo:`/source/common/ratelimit/ratelimit.proto`. See the IDL documentation for more information
 on how the API works. In the future Lyft will open source a reference service implementation
 written in Go.

docs/intro/arch_overview/global_rate_limiting.rst

@@ -13,7 +13,7 @@ tight enough circuit breaking limit on each downstream host such that the system
 normally during typical request patterns but still prevent cascading failure when the system starts
 to fail. Global rate limiting is a good solution for this case.
 
-Envoy integrates directly with a global GRPC rate limiting service. Although any service that
+Envoy integrates directly with a global gRPC rate limiting service. Although any service that
 implements the defined RPC/IDL protocol can be used, Lyft provides a reference implementation
 written in Go which uses a Redis backend. Envoy’s rate limit integration has the following features:
 

docs/intro/arch_overview/grpc.rst

@@ -1,18 +1,18 @@
 .. _arch_overview_grpc:
 
-GRPC
+gRPC
 ====
 
-`GRPC <http://www.grpc.io/>`_ is a new RPC framework from Google. It uses protocol buffers as the
+`gRPC <http://www.grpc.io/>`_ is a new RPC framework from Google. It uses protocol buffers as the
 underlying serialization/IDL format. At the transport layer it uses HTTP/2 for request/response
-multiplexing. Envoy has first class support for GRPC both at the transport layer as well as at the
+multiplexing. Envoy has first class support for gRPC both at the transport layer as well as at the
 application layer:
 
-* GRPC makes use of HTTP/2 trailers to convey request status. Envoy is one of very few HTTP proxies 
+* gRPC makes use of HTTP/2 trailers to convey request status. Envoy is one of very few HTTP proxies 
   that correctly supports HTTP/2 trailers and is thus one of the few proxies that can transport 
-  GRPC requests and responses.
-* The GRPC runtime for some languages is relatively immature. Envoy supports a GRPC :ref:`bridge
-  filter <config_http_filters_grpc_bridge>` that allows GRPC requests to be sent to Envoy over
+  gRPC requests and responses.
+* The gRPC runtime for some languages is relatively immature. Envoy supports a gRPC :ref:`bridge
+  filter <config_http_filters_grpc_bridge>` that allows gRPC requests to be sent to Envoy over
   HTTP/1.1. Envoy then translates the requests to HTTP/2 for transport to the target server.
   The response is translated back to HTTP/1.1.
 * When installed, the bridge filter gathers per RPC statistics in addition to the standard array

docs/intro/comparison.rst

@@ -97,10 +97,10 @@ versus a library that must be built into something by each project individually.
 `gRPC <http://www.grpc.io/>`_
 -----------------------------
 
-GRPC is a new multi-platform message passing system out of Google. It uses an IDL to describe an RPC
+gRPC is a new multi-platform message passing system out of Google. It uses an IDL to describe an RPC
 library and then implements application specific runtimes for a variety of different languages. The
-underlying transport is HTTP/2.  Although GRPC likely has the goal of implementing many Envoy like
+underlying transport is HTTP/2.  Although gRPC likely has the goal of implementing many Envoy like
 features in the future (load balancing, etc.), as of this writing the various runtimes are somewhat
-immature and are primarily focused on serialization/de-serialization. We consider GRPC to be a
-companion to Envoy versus a competitor. How Envoy integrates with GRPC is described :ref:`here
+immature and are primarily focused on serialization/de-serialization. We consider gRPC to be a
+companion to Envoy versus a competitor. How Envoy integrates with gRPC is described :ref:`here
 <arch_overview_grpc>`.

docs/intro/deployment_types/service_to_service.rst

@@ -14,7 +14,7 @@ Service to service egress listener
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This is the port used by applications to talk to other services in the infrastructure. For example,
-*http://localhost:9001*. HTTP and GRPC requests use the HTTP/1.1 *host* header or the HTTP/2
+*http://localhost:9001*. HTTP and gRPC requests use the HTTP/1.1 *host* header or the HTTP/2
 *:authority* header to indicate which remote cluster the request is destined for. Envoy handles
 service discovery, load balancing, rate limiting, etc. depending on the details in the
 configuration. Services only need to know about the local Envoy and do not need to concern
@@ -30,7 +30,7 @@ Service to service ingress listener
 This is the port used by remote Envoys when they want to talk to the local Envoy. For example,
 *http://localhost:9211*. Incoming requests are routed to the local service on the configured
 port(s). Multiple application ports may be involved depending on application or load balancing
-needs (for example if the service needs both an HTTP port and a GRPC port). The local Envoy
+needs (for example if the service needs both an HTTP port and a gRPC port). The local Envoy
 performs buffering, circuit breaking, etc. as needed.
 
 Our default configurations use HTTP/2 for all Envoy to Envoy communication, regardless of whether

docs/intro/what_is_envoy.rst

@@ -60,9 +60,9 @@ requests based on path, authority, content type, :ref:`runtime <arch_overview_ru
 This functionality is most useful when using Envoy as a front/edge proxy but is also leveraged when
 building a service to service mesh.
 
-**GRPC support:** `GRPC <http://www.grpc.io/>`_ is a new RPC framework from Google that uses HTTP/2
+**gRPC support:** `gRPC <http://www.grpc.io/>`_ is a new RPC framework from Google that uses HTTP/2
 as the underlying multiplexed transport. Envoy :ref:`supports <arch_overview_grpc>` all of the
-HTTP/2 features required to be used as the routing and load balancing substrate for GRPC requests
+HTTP/2 features required to be used as the routing and load balancing substrate for gRPC requests
 and responses. The two systems are very complementary.
 
 **MongoDB L7 support:** `MongoDB <https://www.mongodb.com/>`_ is a popular database used in modern

docs/landing_generated/index.html

@@ -108,7 +108,7 @@ <h4 class="introduction-item-header">
        </p>
     <p><b>TLS:</b> Envoy supports both TLS termination and initiation, client certificate
         verification, and certificate pinning.</p>
-    <p><b>GRPC:</b>  Envoy has first class support for Google's GRPC framework.</p>
+    <p><b>gRPC:</b>  Envoy has first class support for Google's gRPC framework.</p>
     <p><b>MongoDB:</b> Envoy contains a full MongoDB wire format parser that is used to gather
        statistics about database connections.</p>
     <p><b>DynamoDB:</b> Envoy contains a full DynamoDB API parser that is used to gather

docs/landing_source/source/localizable/index.html.erb

@@ -70,7 +70,7 @@ layout: layout
        </p>
     <p><b>TLS:</b> Envoy supports both TLS termination and initiation, client certificate
         verification, and certificate pinning.</p>
-    <p><b>GRPC:</b>  Envoy has first class support for Google's GRPC framework.</p>
+    <p><b>gRPC:</b>  Envoy has first class support for Google's gRPC framework.</p>
     <p><b>MongoDB:</b> Envoy contains a full MongoDB wire format parser that is used to gather
        statistics about database connections.</p>
     <p><b>DynamoDB:</b> Envoy contains a full DynamoDB API parser that is used to gather