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
{{ message }}
This repository has been archived by the owner on Jul 6, 2018. It is now read-only.
A client that makes a request to an "https" URI uses TLS [TLS12] with the application-layer protocol negotiation (ALPN) extension [TLS-ALPN].
HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c" protocol identifier MUST NOT be sent by a client or selected by a server; the "h2c" protocol identifier describes a protocol that does not use TLS.
Once TLS negotiation is complete, both the client and the server MUST send a connection preface (Section 3.5).
Using the TLS ALPN mechanism, a server can theoretically be written to listen for both HTTP/1 and HTTP/2 requests, allowing the client to determine which to use based on the protocol identified via ALPN. To support this, a new TLSServer implementation would need to be created that selects either HTTP/1 or HTTP/2 based on the ALPN value. Since HTTP/1 and HTTP/2 will be two separate code paths, requiring different handlers, this could be a bit tricky to implement.
The text was updated successfully, but these errors were encountered:
For anyone who may want to take this one on...
Starting HTTP/2 for "https" URIs
Using the TLS ALPN mechanism, a server can theoretically be written to listen for both HTTP/1 and HTTP/2 requests, allowing the client to determine which to use based on the protocol identified via ALPN. To support this, a new TLSServer implementation would need to be created that selects either HTTP/1 or HTTP/2 based on the ALPN value. Since HTTP/1 and HTTP/2 will be two separate code paths, requiring different handlers, this could be a bit tricky to implement.
The text was updated successfully, but these errors were encountered: