Offer PROXY protocol listeners in addition to HTTP(S) listeners

[bgagnon]

Currently, the --use-proxy-protocol adds the filter on all listeners (HTTP and HTTPS). This prevents Envoy from answering direct requests that do not speak the PROXY protocol.

Example:

--envoy-service-http-port=80
--envoy-service-https-port=443
--use-proxy-protocol

With this feature, the PROXY protocol listener would be separated from the http and https listeners.

Keeping backward compatibility, something like this could work:

--envoy-service-http-port=80
--envoy-service-https-port=443
--envoy-service-proxy-protocol-port=8443
--use-proxy-protocol

The use cases are the following:

• ability to port-forward to a live Envoy pod on port 443 without needing an HAProxy to produce the PROXY packet
• ability to fail over a broken cloud load balancer by replacing the DNS record to a couple A records directly to the nodes (this doesn't work today because clients talk HTTPS, not PROXY)

Ideally, Envoy would simply detect the presence or absence of the PROXY headers, but this is explicitly forbidden by the protocol, according to the Envoy docs:

Protocol must be present on the connection (either version 1 or version 2), the standard does not allow parsing to determine if it is present or not.

[davecheney]

Thank you for raising this issue. Its not on the roadmap for Contour 1.0, but I'll add it to the unplanned milestone for consideration after Contour 1.0 ships.