From a93696f1cf544f3a065f3d67434da8b2145c4933 Mon Sep 17 00:00:00 2001 From: Yun Long Date: Thu, 4 Jan 2024 10:24:57 +0800 Subject: [PATCH] Fix errors in documents (#1186) Signed-off-by: Yun Long --- docs/02.Tutorials/2.3.Pipeline-Explained.md | 10 +++++----- docs/02.Tutorials/2.4.Resilience.md | 4 +--- docs/07.Reference/7.02.Filters.md | 18 +++++++++--------- 3 files changed, 15 insertions(+), 17 deletions(-) diff --git a/docs/02.Tutorials/2.3.Pipeline-Explained.md b/docs/02.Tutorials/2.3.Pipeline-Explained.md index f9736d6d05..9910b32fe4 100644 --- a/docs/02.Tutorials/2.3.Pipeline-Explained.md +++ b/docs/02.Tutorials/2.3.Pipeline-Explained.md @@ -141,7 +141,7 @@ filters: ### Built-in Filter `END` * `END` is a built-in filter, that's we can use without defining it. From the above example, we already see that `END` can be used as the target of `jumpIf`, and we can also use it directly in the flow. - + ```bash $ echo ' name: pipeline-demo @@ -172,7 +172,7 @@ filters: pools: - servers: - url: http://127.0.0.1:9095 -- name: responseBuilder +- name: buildFailureResponse kind: ResponseBuilder template: | statusCode: 400 @@ -314,7 +314,7 @@ In this case, all requests in `HTTPServer` `server-example` go through `GlobalFi The reverse proxy is the common middleware that is accessed by clients, forwards them to backend servers. The reverse proxy is a very core role played by Easegress. -The filter `Proxy` is the filter to fire requests to backend servers. +The filter `Proxy` is the filter to fire requests to backend servers. It contains servers group under load balance, whose policy support `roundRobin`, `random`, `weightedRandom`, `ipHash`, `headerHash`. For more information, please check [load balance](../07.Reference/7.02.Filters.md#proxyloadbalancespec). @@ -412,7 +412,7 @@ filters: # response validation criteria (default: 2xx and 3xx status codes) match: - # acceptable status code ranges + # acceptable status code ranges statusCodes: - [200, 299] # 2xx - [300, 399] # 3xx @@ -568,7 +568,7 @@ $ curl -X GET http://127.0.0.1:10080/api -v In #Example 1, if one of the backend services encounters a failure, the pipeline will result a wrong result. We can improve the pipeline to handle this kind of -failures. +failures. 1. Update the pipeline spec diff --git a/docs/02.Tutorials/2.4.Resilience.md b/docs/02.Tutorials/2.4.Resilience.md index fb9170df03..ebe5b98daa 100644 --- a/docs/02.Tutorials/2.4.Resilience.md +++ b/docs/02.Tutorials/2.4.Resilience.md @@ -199,7 +199,6 @@ name: pipeline-reverse-proxy kind: Pipeline flow: -- filter: retryer - filter: proxy filters: @@ -214,7 +213,7 @@ filters: policy: roundRobin retryPolicy: retry3Times failureCodes: [500, 503, 504] - + resilience: - name: retry3Times kind: Retry @@ -247,7 +246,6 @@ name: pipeline-reverse-proxy kind: Pipeline flow: -- filter: retryer - filter: proxy filters: diff --git a/docs/07.Reference/7.02.Filters.md b/docs/07.Reference/7.02.Filters.md index b8620cb552..095beda133 100644 --- a/docs/07.Reference/7.02.Filters.md +++ b/docs/07.Reference/7.02.Filters.md @@ -228,13 +228,13 @@ pools: # response validation criteria (default: 2xx and 3xx status codes) match: - # acceptable status code ranges + # acceptable status code ranges statusCodes: - [200, 299] # 2xx - [300, 399] # 3xx # response header validation # name is header key. - # value is header value, can be empty. + # value is header value, can be empty. # type is type of value, can be "exact" or "regexp". headers: - name: X-Status @@ -394,7 +394,7 @@ rules: ``` ### Health Check -Perform a health check on the servers in the pool. If a server fails the check, it will be marked as unhealthy, and requests will be rerouted to other healthy servers until it regains health. Health check for websocket proxy contains both http way or websocket way. The HTTP check involves a request-response evaluation similar to a Proxy filter. In the WebSocket method, a successful connection yields a 101 status code. Additional headers can be set and evaluated in both methods. +Perform a health check on the servers in the pool. If a server fails the check, it will be marked as unhealthy, and requests will be rerouted to other healthy servers until it regains health. Health check for websocket proxy contains both http way or websocket way. The HTTP check involves a request-response evaluation similar to a Proxy filter. In the WebSocket method, a successful connection yields a 101 status code. Additional headers can be set and evaluated in both methods. If you send both two ways of health check, then a server passes both HTTP and WebSocket health checks, it will be considered healthy. ```yaml @@ -426,12 +426,12 @@ pools: # response validation criteria (default: 101 Switching Protocols) match: - # acceptable status code ranges + # acceptable status code ranges statusCodes: - [101, 101] # 101 # response header validation # name is header key. - # value is header value, can be empty. + # value is header value, can be empty. # type is type of value, can be "exact" or "regexp". headers: - name: X-Status @@ -456,13 +456,13 @@ pools: # response validation criteria (default: 2xx and 3xx status codes) match: - # acceptable status code ranges + # acceptable status code ranges statusCodes: - [200, 299] # 2xx - [300, 399] # 3xx # response header validation # name is header key. - # value is header value, can be empty. + # value is header value, can be empty. # type is type of value, can be "exact" or "regexp". headers: - name: X-Status @@ -771,9 +771,9 @@ urls: | Name | Type | Description | Required | | ---------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | -| policies | [][ratelimiter.Policy](#ratelimiter.Policy) | Policy definitions | Yes | +| policies | [][ratelimiter.Policy](#ratelimiterPolicy) | Policy definitions | Yes | | defaultPolicyRef | string | The default policy, if no `policyRef` is configured in one of the `urls`, it uses this policy | No | -| urls | [][urlrule.URLRule](#urlrule.URLRule) | An array of request match criteria and policy to apply on matched requests. Note that a standalone RateLimiter instance is created for each item of the array, even two or more items can refer to the same policy | Yes | +| urls | [][urlrule.URLRule](#urlruleURLRule) | An array of request match criteria and policy to apply on matched requests. Note that a standalone RateLimiter instance is created for each item of the array, even two or more items can refer to the same policy | Yes | ### Results