Easegress response with 403 when a domain name is used for server URL

[localvar]

Describe the bug
Easegress response with 403 when a domain name is used for server URL.

To Reproduce
Steps to reproduce the behavior:

1. Start Easegress with the default configuration
2. Create HTTP server as the spec below
3. Create a pipeline as the spec below, note to use a domain name for the backend server
4. Send a request with curl HTTP://127.0.0.1:10080/
5. Easegress response with 403 Forbidden

Expected behavior
Easegress returns the correct response.

Version
All version.

Configuration

• Easegress Configuration
  default

• HTTP server configuration

kind: HTTPServer
name: http-server-example
port: 10080
https: false
keepAlive: true
keepAliveTimeout: 75s
maxConnection: 10240
cacheSize: 0
rules:
  - paths:
    - pathPrefix: /
      backend: pipeline

• Pipeline Configuration

name: pipeline
kind: HTTPPipeline

flow:
  - filter: proxy

filters:
  - name: proxy
    kind: Proxy
    mainPool:
      servers:
      - url: https://www.megaease.com
      loadBalance:
        policy: roundRobin
    compression:
      minLength: 1024

Additional context
Investigation shows that the request has been sent to the backend server, a possible cause is a wrong Host in the request.

[localvar]

confirmed that Host of the request sent to the backend server is incorrect in this case.

[localvar]

Currently, Easegress always uses Host of the source request when sending requests to backend, this works fine when the server URL is in IP:port form. But it could fail when the URL contains a domain name, depending on whether the backend server checks Host or not.

We can use a RequestAdaptor to modify Host, this could resolve the cause above.

But there's another case, we cannot prevent users from configuring the server pool as below, and I think the case could be reasonable.

      servers:
      - url: https://www.megaease.com
      - url: https://www.megaease.cn

In this case, setting a fixed Host will not work.

I propose to check the server URL before sending the request, and clear Host if the URL contains a domain name, that's the Go HTTP library will set a correct Host to the request.

However, there's still an issue with the solution: the user will find his/her configuration failed to take effect if he/she does want to set a fixed Host by using a RequestAdaptor. Not sure if this is a reasonable case.

[samutamm]

Using Go HTTP library for setting the correct Host for domain names sounds like a good idea.

I don't know either if someone would like to provide another value for Host than the real domain name. To keep things simple, I vote for not supporting it. If really needed, it could be supported with a new parameter fixedHost: bool for example, that would fall back to current behavior.

[xxx7xxxx]

Here's how I think about this problem. First, we need to set up a final requirement/validation of the request to the endpoint, which is that the two parameters URL and Host are coherent. So the only question left is which host we should choose when there are different ones? The simple policy I propose would be:

Use the host in the URL of the server in filter Proxy by default without using the host from the client or request adaptor. Supporting changing host dynamically seems not useful for now, we could do it if there were a real requirement elsewhere.