Fix errors in documents (#1186)

Signed-off-by: Yun Long <[email protected]>

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:https://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:https://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
 

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:

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