HTTP/3 gets the headlines, but most teams still spend their time deciding how traffic should move between browser, CDN, load balancer, reverse proxy, and origin. That is where h2, h2c, and HTTP/1.1 still matter. If you run a business website or client platform, the goal is not to chase protocol fashion. It is to choose defaults that are fast, compatible, easy to debug, and cheap to maintain.
Current standards and vendor docs still support a simple rule of thumb: use h2 for normal public HTTPS delivery, keep HTTP/1.1 available as a fallback, and reserve h2c for controlled internal cases where you explicitly know both ends support cleartext HTTP/2. That approach keeps the stack modern without turning protocol choice into a science project.
What These Protocol Names Mean in Practice
h2 is HTTP/2 over TLS. For browser-facing sites, this is the practical baseline. It is negotiated during the TLS handshake, works well with modern CDNs and browsers, and usually gives you the benefits people actually care about: fewer connections, multiplexing, and cleaner delivery of many small assets.
h2c is HTTP/2 over cleartext TCP. That makes it useful in narrower situations: internal service hops, trusted proxy-to-service traffic, or lab environments. The important current detail is that the old upgrade path around h2c is no longer something to design around. RFC 9113 deprecates the old h2c upgrade token, and cleartext HTTP/2 for http:// URIs now depends on prior knowledge between client and server.
HTTP/1.1 is still a respectable operational choice. It remains the default for many plain-HTTP tools, and it is often the simplest option for older upstreams, appliances, low-traffic admin apps, or inherited integrations where predictability matters more than squeezing out protocol-level gains.
When to Use h2, h2c, or HTTP/1.1
For public websites, campaign landing pages, and logged-in SaaS interfaces, the default answer is usually h2 plus HTTP/1.1 fallback. If your edge platform also offers HTTP/3, treat that as an extra visitor-facing benefit, not a reason to stop caring about what the rest of the delivery chain is doing.
For CDN-to-origin or load-balancer-to-origin traffic, do not assume every hop must use the same protocol. Many healthy production stacks serve visitors over HTTP/2 or HTTP/3 at the edge and talk HTTP/1.1 to the origin. That is not automatically wrong. If keep-alives are stable, headers are sane, and the origin is fast enough, the bigger bottlenecks are often caching, application latency, or asset weight, not the transport label on the last hop.
For internal service-to-service traffic, h2c can make sense when you control both ends and want connection reuse or multiplexing. But choose it intentionally. If the service mostly handles POST and PUT bodies, upgrade-based switching is a poor assumption; current Apache docs still note that HTTP/1.1 upgrades are only accepted for requests without a body. In those cases, prior-knowledge setups or a clean HTTP/1.1 baseline are usually safer than wishful auto-upgrade behavior.
For agencies and operations teams inheriting mixed client stacks, simplicity wins. If nobody on the team can quickly explain which protocol each hop is using and why, you probably do not have a protocol strategy yet. You have accumulated defaults.
Current Config Patterns That Still Make Sense
On Apache, the normal TLS pattern is still straightforward:
Protocols h2 http/1.1If you genuinely need cleartext HTTP/2 in a controlled network, Apache documents this broader pattern:
Protocols h2 h2c http/1.1
H2Direct onThat second pattern is for specific internal cases, not public-web theatre. It lines up with current HTTP/2 guidance: direct, prior-knowledge cleartext HTTP/2 is viable inside trusted environments, while old-style upgrade assumptions are limited and dated.
On NGINX, the current HTTP/2 enablement pattern is also simple:
server {
listen 443 ssl;
http2 on;
}What deserves more attention is old inherited tuning. Current NGINX docs mark http2_push and http2_push_preload as obsolete, so stale push snippets are a good signal that the config needs review. On Apache, current mod_http2 docs also warn that HTTP/2 changes resource behavior by adding worker threads and using more memory than HTTP/1.1 processing. On a busy estate, that is a reason to load-test before wide rollout, not a reason to avoid HTTP/2 entirely.
How to Verify What the Live Stack Is Actually Using
Do not trust control panels, old tickets, or what someone remembers from the migration six months ago. Test the live endpoint.
curl -I -sS -o /dev/null -w '%{http_version}\n' https://example.com
curl --http1.1 -I https://example.com
curl --http2 -I https://example.com
curl --http2-prior-knowledge http://internal-service:8080/health
curl -VThe first command tells you which HTTP version was actually used. The next two force HTTP/1.1 or HTTP/2 so you can compare behavior. The prior-knowledge test is the right way to probe a cleartext HTTP/2 endpoint you already expect to speak h2c directly. curl -V is the quick sanity check when your local build lacks HTTP/2 support and the problem is your tool, not the server.
This is also where protocol conversations become more honest. If the browser is already getting h2 but pages are still slow, the answer is rarely more protocol. It is usually better cache policy, lower origin latency, or fewer bytes shipped to the page.
Mistakes That Waste Time
- Treating
h2cas a default for public traffic instead of a controlled internal tool. - Assuming the browser protocol and the origin protocol must match.
- Keeping old push or upgrade recipes without checking current vendor docs.
- Forcing HTTP/2 everywhere before measuring backend latency, cache hit rate, and asset delivery.
If you want a quick review of how your CDN, proxy, and origin are negotiating today, Greg can help map the hops, remove stale configuration, and leave your team with a simpler baseline to operate. Talk with Greg about your stack.
Need help with this kind of work?
Need a clearer plan for CDN, proxy, and origin protocol choices? Talk with Greg. Get in touch with Greg.