You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Envoy Gateway sets ALPN to h2, http/1.1 by default. When Envoy is not handling the application layer protocol (e.g. TLS termination for TCP), Envoy should not advertise application layer protocols that may not be supported by the backend, and keep the downstream TLS socket ALPN settings undefined.
In general, it seems that Envoy Gateway should perhaps support more flexibility around ALPN:
Supporting non-HTTP ALPN protos for TLS routes that proxy non-HTTP protos
curl -v -HHost:www.example.com --resolve "www.example.com:8443:127.0.0.1" --cacert example.com.crt https://www.example.com:8443/get
* Added www.example.com:8443:127.0.0.1 to DNS cache
* Hostname www.example.com was found in DNS cache
* Trying 127.0.0.1:8443...
* Connected to www.example.com (127.0.0.1) port 8443
* ALPN: server accepted h2
[...]
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.example.com:8443/get
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.example.com]
* [HTTP/2] [1] [:path: /get]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET /get HTTP/2
> Host:www.example.com
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
* Remote peer returned unexpected data while we expected SETTINGS frame. Perhaps, peer does not support HTTP/2 properly.
Envoy encourages the client the use HTTP/2, which is not supported by the upstream server, leading to a failure. If the client is explicitly using HTTP/1, the request succeeds:
curl -v --http1.1 -HHost:www.example.com --resolve "www.example.com:8443:127.0.0.1" --cacert example.com.crt https://www.example.com:8443/get
[...]
* using HTTP/1.x
> GET /get HTTP/1.1
> Host:www.example.com
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
The text was updated successfully, but these errors were encountered:
Description:
Envoy Gateway sets ALPN to
h2, http/1.1
by default. When Envoy is not handling the application layer protocol (e.g. TLS termination for TCP), Envoy should not advertise application layer protocols that may not be supported by the backend, and keep the downstream TLS socket ALPN settings undefined.In general, it seems that Envoy Gateway should perhaps support more flexibility around ALPN:
Repro steps:
Follow the the official guide: https://gateway.envoyproxy.io/docs/tasks/security/tls-termination/
Envoy encourages the client the use HTTP/2, which is not supported by the upstream server, leading to a failure. If the client is explicitly using HTTP/1, the request succeeds:
The text was updated successfully, but these errors were encountered: