- Envoy Server configure listener with http1.1 ALPN and TLS enabled, DirectResponse. Two filter chains, one matching the alpn == http1.1, one is default filter chain, returns response "hello world, selected from alpn http1.1."
- Envoy Client configures Cluster with http1.1 ALPN and TLS enabled, cluster requests sends to server Envoy.
- Sending request from curl -> Client Envoy -> Server Envoy, returns "hello world alpn 1.1"
- However ALPN "http1.1" can't be fetched via SslSocket::protocol(), returns empy.
Note, these two parts are using different SSL methods.
- FilterChainMatch uses
boringssl::SSL_early_callback_ctx_extension_get
- SslSocket::protocol invokes
borgingssl::SSL_get0_alpn_selected
, link
Question, is it possible the server envoy just use the ALPN data for filter chain match purpose, but the next stage ALPN is not selected and used as part of TLS process?