From 01a34917cdb6ebe16b8d4cd30a543146dae51bbf Mon Sep 17 00:00:00 2001 From: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com> Date: Mon, 15 Aug 2022 14:02:46 -0700 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Nathan Coleman --- .../content/docs/api-gateway/configuration/meshservice.mdx | 2 +- website/content/docs/api-gateway/configuration/routes.mdx | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/website/content/docs/api-gateway/configuration/meshservice.mdx b/website/content/docs/api-gateway/configuration/meshservice.mdx index ef085f2f5e..0307b3a4be 100644 --- a/website/content/docs/api-gateway/configuration/meshservice.mdx +++ b/website/content/docs/api-gateway/configuration/meshservice.mdx @@ -11,7 +11,7 @@ This topic provides full details about the `MeshService` resource. ## Introduction -A `MeshService` is a resource in the Kubernetes cluster that represents a service in the Consul service mesh outside the Kubernetes cluster where Consul API Gateway is deployed. The service must be in the same Consul datacenter. The MeshService exists so that other configuration models in Kubernetes, such as HTTPRoute and TCPRoute, can reference services that only exist in Consul. +A `MeshService` is a resource in the Kubernetes cluster that enables Kubernetes configuration models, such as `HTTPRoute` and `TCPRoute`, to reference services that only exist in Consul. A `MeshService` represents a service in the Consul service mesh outside the Kubernetes cluster where Consul API Gateway is deployed. The service represented by the `MeshService` resource must be in the same Consul datacenter as the Kubernetes cluster. ## Configuration Model diff --git a/website/content/docs/api-gateway/configuration/routes.mdx b/website/content/docs/api-gateway/configuration/routes.mdx index 58a07758d3..acce1d68e8 100644 --- a/website/content/docs/api-gateway/configuration/routes.mdx +++ b/website/content/docs/api-gateway/configuration/routes.mdx @@ -220,7 +220,7 @@ Specifies rules for matching incoming requests. You can apply [`filters`](#rules * [headers](#rules-matches-headers) * [query parameters](#rules-matches-queryparams) * [request method](#rules-matches-method) - +Each rule matches requests independently. As a result, a request matching any of the conditions is considered a match. You can configure several matching rules for each type to widen or narrow matches. ### rules.matches.path Specifies a list of objects that define matches based on URL path. The following table describes the parameters for the `path` field: @@ -228,7 +228,7 @@ Specifies a list of objects that define matches based on URL path. The following | Parameter | Description | Type | Required | | --- | --- | --- | --- | | `type` | Specifies the type of comparison to use for matching the path value. You can specify the following types. | String | Required | -| `value` | Specifies value to match on. You can specify a specific string or a regular expression. | String | Required | +| `value` | Specifies the value to match on. You can specify a specific string when `type` is `Exact` or `PathPrefix`. You can specify a regular expression if `type` is `RegularExpression`. | String | Required | ### rules.matches.headers