Project: Easegress (Orchestration & Management / API Gateway)
File: 2.2.HTTP-Proxy-Usage.md

- - - - - Creating an HTTP Proxy allows for traffic routing and management. You can set one up using the `egctl create httpproxy` command. For comprehensive instructions, refer to . For more advanced features, you might consider setting up `HTTPServer` and `Pipelines`. An `HTTPServer` acts as a listening server on a specified port, directing traffic to designated `Pipelines`. Below is a basic configuration example: ```yaml name: demo kind: HTTPServer port: 10080 # Listening port http3: false # HTTP3 usage; default is false keepAlive: true # Keep the connection alive; default is true https: false autoCert: false certs: cert1: <public-key-data> cert2: <public-key-data> keys: cert1: <private-key-data> cert2: <private-key-data> clientMaxBodySize: 4 1024 1024 maxConnections: 10240 caCertBase64: <your-ca-cert> globalFilter: global-filter-name tracing: {} ipFilter: blockIPs: [] allowIPs: [] blockByDefault: false rules: host: <your-host> paths: path: /pipeline backend: demo-0 ``` You can create, update, edit, or delete `HTTPServer` with `egctl` commands. More details in . For managing HTTPServer (create, update, edit, delete, check), use `egctl` commands. Further details can be found in the section. For a deep dive into available parameters, consult: Within an HTTPServer configuration, the rules section enables precise traffic routing based on various conditions, such as host names, IP addresses, paths, methods, headers, and query parameters. Here's a more concise and structured breakdown of the rules section: ```yaml name: demo kind: HTTPServer port: 10080 ... rules: host: <your-host> hostRegexp: <your-host-regexp> hosts: value: *.example.com isRegexp: false value: www.example.* isRegexp: false ipFilter: {} paths: path: /abc # Exact path match backend: abc-pipeline pathPrefix: /xyz # Matches any path with the given prefix backend: xyz-pipeline path: /efg methods: [PUT] # Path and HTTP method condition backend: efg-pipeline pathRegexp: /[a-z]+ # Path and HTTP method condition backend: az-pipeline path: /hig backend: newhig-pipeline rewriteTarget: /newhig path: /headers headers: key: "X-Test" values: [test1, test2] # Matches if any of these values are found key: "AllMatch" regexp: "^true$" # Matches the exact regular expression matchAllHeader: false # If true, all header conditions must match backend: headers-pipeline path: /query matchAllQuery: false # If true, all query conditions must match queries: key: "q" values: ["v1", "v2"] key: "q2" values: ["v3", "v4"] backend: query-pipeline host: ... ... ``` Rules are checked sequentially. Place frequently matched rules at the top to optimize performance. Similarly, within each rule, path conditions are also checked in order. Prioritize commonly used

By carefully structuring the `rules` section, you can ensure optimal and precise traffic management within Easegress. With the provided configuration, When a request is made to `http://127.0.0.1:10080/abc`, it gets directed to the `abc-pipeline`` based on the path-based routing rule: ```yaml path: /abc backend: abc-pipeline ``` A request to any URL with the prefix `/xyz`, like `http://127.0.0.1:10080/xyz123`, will be directed to `xyz-pipeline` due to: ```yaml pathPrefix: /xyz backend: xyz-pipeline ``` Only `PUT` requests to `http://127.0.0.1:10080/efg` will be routed to `efg-pipeline`: ```yaml path: /efg methods: [PUT] backend: efg-pipeline ``` Requests with paths that match the regular expression, like `http://127.0.0.1:10080/abcd`, get routed to `az-pipeline`: ```yaml pathRegexp: /[a-z]+ backend: az-pipeline ``` If a request has the header `X-Test` with values `test1` or `test2`, it will be directed to headers-pipeline. For instance, a request to `http://127.0.0.1:10080/headers` with the header `X-Test`: `test1` will match: ```yaml path: /headers headers: key: "X-Test" values: [test1, test2] backend: headers-pipeline ``` A request to `http://127.0.0.1:10080/query?q=v1` matches the condition and will be routed to `query-pipeline`: ```yaml path: /query queries: key: "q" values: ["v1", "v2"] backend: query-pipeline ``` In Easegress, Pipelines are fundamental constructs that enable the arrangement and execution of filters in a sequence to process incoming requests. Think of it as a production line in a factory; each filter can alter or process the request in a specific way before passing it to the next filter (or the final destination). Here's a simple pipeline configuration: ```yaml name: pipeline-demo kind: Pipeline flow: filter: proxy filters: name: proxy kind: Proxy pools: servers: url: http://127.0.0.1:9095 url: http://127.0.0.1:9096 loadBalance: policy: roundRobin ``` Explanation: `flow`: Defines the order in which filters are executed. In this case, we only have one filter named "proxy". `filters`: Contains configurations for each filter. Here, we have: `name`: The filter's identifier. `kind`: The type of filter, which is "Proxy" in this case. other spec details: The configuration details and settings will differ and be specific to the chosen filter type. This means each filter has its unique parameters and settings based on its functionality and role. In this example, incoming requests to the pipeline are simply proxied to either `http://127.0.0.1:9095` or `http://127.0.0.1:9096` in a `round-robin` fashion. Further Reading: `Pipeline Details`: To delve deeper into how pipelines work, their capabilities, and various configurations, consult . `Proxy Filter`: For specifics on the Proxy filter, its functionalities, and configurations, refer to . `Other Filters`: Easegress offers a multitude of filters for various purposes. To explore them, visit .