ALPN
A proxy receiving a CONNECT request sees only a host and port, not what will flow through the tunnel. The ALPN request header closes the gap: the client names the application-layer protocols it intends to negotiate inside the tunnel, using the same protocol identifiers TLS ALPN negotiation uses.
Usage
The header rides only on CONNECT
requests. A client tunneling TLS through a proxy
copies the protocol identifiers it plans to offer in
the TLS handshake into the header, giving the proxy
enough information for policy decisions, such as
allowing h2 tunnels while flagging unknown
protocols, without breaking the tunnel open.
The value is advisory and unverifiable: the proxy
never sees inside an end-to-end encrypted tunnel, so
the header states intent rather than proof. Each
identifier is percent-encoded where the ALPN
protocol ID contains bytes outside the token
character set, which is why http/1.1 appears as
http%2F1.1 on the wire.
The header differs from the TLS extension in scope. TLS ALPN negotiates the protocol between the two TLS endpoints, while the ALPN header informs the intermediary carrying the tunnel, one hop earlier in the chain.
Values
A comma-separated list of ALPN protocol identifiers from the TLS ALPN registry, percent-encoded as needed.
Example
A client asks a proxy for a tunnel and announces the protocols the inner TLS handshake will offer.
CONNECT www.example.re:443 HTTP/1.1
Host: www.example.re:443
ALPN: h2, http%2F1.1