HTTP/2 over cleartext, known as h2c, is defined in the specification but almost never seen on the public web. Why is that, and where does cleartext HTTP/2 still get used?

## What h2c is `h2c` is the protocol identifier for HTTP/2 over cleartext TCP. The HTTP/2 specification defines it, so a conforming implementation may serve HTTP/2 with no TLS at all. It is a real, usable protocol - it simply lost the public web. ## Why it lost **Browsers refused.** During HTTP/2 standardisation there was a long argument about mandatory encryption. The RFC did not require TLS, but the browser vendors independently decided to implement HTTP/2 only over TLS. Since browsers are the overwhelming majority of public HTTP clients, that decision settled it: on the public web, HTTP/2 means HTTPS. **Negotiation is clumsy without TLS.** Over TLS, ALPN selects the protocol for free inside a handshake you were already doing. Cleartext has neither, so HTTP/2 defined two mechanisms: - **Upgrade**: the client sends an HTTP/1.1 request carrying `Connection: Upgrade, HTTP2-Settings`, `Upgrade: h2c` and a base64 `HTTP2-Settings` header; the server may answer `101 Switching Protocols` and the connection becomes HTTP/2. It costs a round trip on the first request and requires every intermediary in the path to pass Upgrade through correctly. RFC 9113 deprecated it, largely for lack of use. - **Prior knowledge**: the client simply opens TCP and sends the HTTP/2 connection preface (`PRI * HTTP/2.0` followed by `SM` and a SETTINGS frame). No negotiation at all - the client must already know the server speaks h2c, by configuration. This is what actually gets used. **Middleboxes.** A great deal of deployed infrastructure - transparent proxies, corporate filters, old load balancers - parses and rewrites cleartext HTTP/1.1. Feed it binary HTTP/2 frames and it may drop, hang or corrupt the connection, and there is no way to detect this in advance. TLS made HTTP/2 deployable precisely because encrypted bytes are opaque and get forwarded untouched. The same argument later drove QUIC's encryption of nearly its entire header. ## Where cleartext HTTP/2 is genuinely common Inside networks you control, where there are no browsers and no hostile middleboxes: - **gRPC.** gRPC requires HTTP/2 for multiplexed concurrent RPCs and bidirectional streaming. Service-to-service gRPC inside a cluster very often runs h2c with prior knowledge, because both peers are configured together and mutual TLS may be handled by a sidecar or by the network layer instead. - **TLS-terminating front proxies.** An edge load balancer or ingress terminates TLS and forwards to the application over h2c on loopback or the pod network. This is a common misconfiguration point too: many ingress controllers default to HTTP/1.1 on the backend leg, which silently breaks gRPC and quietly discards HTTP/2's benefits. - **Internal APIs, metrics and admin endpoints** in trusted environments. ## What to watch for operationally - The backend protocol is a deliberate setting in most proxies (nginx grpc_pass and upstream http2 options, Envoy's explicit HTTP/2 upstream protocol option, Kubernetes ingress annotations). Assume HTTP/1.1 on the back leg unless you configured otherwise, and verify. - Prior-knowledge h2c fails ugly against an HTTP/1.1-only server: the server sees the `PRI * HTTP/2.0` preface as a malformed request and typically answers 400 or closes the connection. - 'Cleartext inside the cluster' is a security posture decision, not a free choice. If your threat model includes an attacker on the pod network, h2c between services needs mutual TLS somewhere - usually a service mesh - and then you are back to TLS with ALPN anyway. ## The compact answer h2c is legal but browserless. Without TLS you lose ALPN, so you get either a deprecated Upgrade dance or configured prior knowledge, and cleartext binary traffic trips middleboxes. It survives where both ends are yours and there is no middlebox in between - chiefly gRPC and proxy-to-origin hops.