News
HTTP/2 vs HTTP/3 for Public Marketing Sites
May 1, 2024
HTTP/2 vs HTTP/3 for public marketing sites is which application protocol the edge offers after TLS, not whether the URL is HTTPS. HTTP/2 (h2) multiplexes streams over TLS/TCP. HTTP/3 (h3) multiplexes over QUIC/UDP. Both are performance and reliability choices. Neither is a security header, a WAF, or a substitute for TLS 1.3 and HSTS. Enable h2 everywhere the CDN supports it. Enable h3 on the same public hostname when the edge actually speaks it, advertised with a boring Alt-Svc — not an origin IP. RoastMyOpsec confirms HTTPS and the runtime trust store. It does not score missing HTTP/3, does not speak QUIC as a finding, and does not probe origin IPs.
The practical difference
HTTP/1.1 is still the compatibility floor. HTTP/2 is the default modern TCP stack. HTTP/3 helps on lossy mobile networks because one lost packet does not stall every stream the way TCP head-of-line blocking can. TLS 1.2 vs 1.3 is the handshake generation; h2/h3 is the HTTP generation. You can have TLS 1.3 with HTTP/2 only.
Alt-Svc is how browsers learn h3 exists for this name. Keep that advertisement on the CDN hostname. See Alt-Svc vs origin IP exposure.
How to choose a policy
Brochure on a major CDN: leave HTTP/2 on, turn on HTTP/3 if the dashboard offers it and UDP 443 is not blocked in your enterprise clients. Government or locked-down corp browsers: keep HTTP/2; missing h3 is not an incident. Do not terminate HTTP/3 on a second hostname that skips the WAF. UDP to the origin should stay firewalled; only the edge speaks QUIC to the internet.
| Protocol | Typical 2026 role | OPSEC note | Takeaway |
|---|---|---|---|
| HTTP/1.1 | Compatibility | Still fine behind h2 | Do not require it for the roast |
| HTTP/2 | Default on public edges | Not a scored finding | Enable it |
| HTTP/3 | Optional speed on the same name | Alt-Svc must not name an origin IP | Nice; not a roast F if absent |
| TLS 1.3 | Handshake generation | Orthogonal to h2 vs h3 | See TLS 1.2 vs 1.3 |
When HTTP/3 wins
HTTP/3 wins for mobile-heavy marketing traffic on a CDN that already filters UDP 443. HTTP/2 wins as the must-have modern baseline. TLS 1.3 wins independently. 0-RTT on QUIC is an ops/product setting: do not enable it for state-changing requests if you do not understand replay; that is a configuration caution, not a roast check.
What the roast can prove
Scheme and trust-store acceptance. HTTP version, Alt-Svc, and QUIC are out of scope. Confirm in the CDN dashboard. Pair with CDN fingerprints if the Via or Server header still names the origin stack.
Common mistakes
The first mistake is advertising h3 in Alt-Svc while the edge still only speaks HTTP/2.
The second mistake is opening UDP 443 to the origin so clients can skip the CDN.
The third mistake is treating missing HTTP/3 as an OPSEC vulnerability.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is HTTP/2 a vulnerability?
- No. It is the usual modern default. HTTP/1.1-only is slower, not an automatic roast F.
- Must marketing sites enable HTTP/3?
- Only if the edge supports it on the public name. Missing h3 is not a roast finding.
- Does RoastMyOpsec score HTTP/3?
- No. It does not treat protocol generation as a vulnerability and does not probe origin IPs.