HTTP design: priorities, WebTransport, and semantic correctness

HTTP multiplexes streams. But without priorities, the server streams them in arrival order — which may put a low-priority image before the blocking CSS that pauses rendering. RFC 9218 replaces HTTP/2’s abandoned priority tree with a two-field urgency signal. Meanwhile, WebTransport turns the QUIC connection into a general-purpose bidirectional tunnel — and semantic mistakes in status codes and Vary headers quietly break CDN caching for millions of users.

RFC 9218: Extensible Priorities

HTTP/2’s original priority scheme (dependency trees with weights, RFC 7540 § 5) was complex and poorly implemented. Browsers and servers disagreed on interpretation — Cloudflare reported that in some deployments, priorities made performance worse than no priorities at all, because mismatched implementations caused servers to delay high-priority streams while serving junk.

RFC 9218 (Extensible Priorities for HTTP) deprecates the tree-based scheme and defines a simpler two-field signal:

Priority: u=0, i

• u (urgency, 0–7): lower number = more urgent. u=0 for render-blocking HTML, u=1 for critical CSS, u=3 for stylesheets, u=5 for async scripts and fonts, u=7 for background prefetch.
• i (incremental flag): when set, the server streams this response incrementally — sending a chunk, then switching to higher-urgency streams, then returning. Used for large bodies where partial data is useful.

The client sends a Priority: header (HTTP/2 and HTTP/3) or a PRIORITY_UPDATE frame (HTTP/3). The server honours these to schedule DATA frame transmission order across streams.

Browser support as of 2026: Chrome, Edge, Safari, and Firefox all ship Priority header support. Cloudflare, Fastly, and major CDNs have enabled it. Reported page-load improvements: up to 37% in some Cloudflare scenarios (by delivering render-blocking resources before images).

MASQUE and QUIC Datagrams

MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a family of IETF protocols that use HTTP/3 as a tunnelling layer:

• CONNECT-UDP (RFC 9298): the client sends a CONNECT-UDP request to an HTTP/3 proxy; the request body becomes a tunnel for encapsulated UDP traffic.
• CONNECT-IP: tunnels IP packets, enabling a full IP-over-QUIC VPN.

Apple’s iCloud Private Relay uses MASQUE: traffic flows through Apple Relay 1 (sees IP, not content) → Apple Relay 2 (sees content, not IP) → origin. This splits trust between two providers: neither alone can correlate IP and content.

QUIC DATAGRAM frames (RFC 9221) carry unreliable encrypted payloads inside a QUIC connection — sent once, not retransmitted if lost. This enables:

• Real-time media with strict latency budgets (voice, video — where retransmission arrives too late to be useful).
• Game state updates where a missed position update is harmless and a delayed one is wrong.

WebTransport (W3C + RFC 9298-related) exposes QUIC’s full capability to browser JavaScript: both reliable streams (like WebSocket) and unreliable datagrams (like UDP) from a browser page. Unlike WebSocket, WebTransport supports multiple concurrent streams per connection and does not require the upgrade dance. Chromium ships WebTransport; Firefox 124+ as well; Safari is behind a flag as of 2026.

Authentication schemes

Modern web apps use Authorization: Bearer <token> carrying a JWT or opaque session token. The HTTP layer transports the credential; OAuth 2.0 / OIDC defines how tokens are obtained.

• Bearer tokens in headers — correct. Tokens in HTTP headers do not leak via Referer, browser history, or server access logs (which log the URL but typically redact headers).
• Tokens in URLs — dangerous. ?token=abc appears in Referer headers sent to third-party resources, in browser history, in CDN and reverse-proxy access logs, and in analytics systems. Never put sensitive credentials in query strings.
• Basic auth (Authorization: Basic base64(user:pass)) — survives for internal API tooling. Digest auth is effectively retired.
• WWW-Authenticate — a 401 response includes this header to tell the client which scheme to use and with what parameters (realm for Basic, issuer for Bearer).

HTTP semantic correctness pitfalls

The HTTP machinery — browser retry logic, CDN caching, proxy rewriting — depends on correct status codes and headers. Common mistakes that cause production bugs:

Wrong status codes:

• 200 OK for an error body {"error": "not found"} — CDNs cache the 200, proxy retry logic doesn’t trigger, browser console shows no error.
• 200 OK with { "success": false } — breaks circuit breakers and health checks.
• 301 Moved Permanently when the redirect is temporary — browsers cache 301 forever; changing it back requires clearing browser caches.

Vary header mistakes:

• No Vary: Accept-Encoding on compressed responses — a cache may serve a Brotli-compressed body to a client that declared Accept-Encoding: gzip only, causing garbled content.
• No Vary: Authorization on auth-differentiated cacheable responses — the CDN serves one user’s private data to another. Cache-Control: private prevents this at CDN level but Vary: Authorization is the correct signal.
• Overly broad Vary: Cookie — causes a cache miss on every request since cookies differ per user; defeats caching entirely for authenticated users.

Cache-Control: private vs Vary: Authorization: use Cache-Control: private for user-specific data that must not be shared via CDN (and add no-store for sensitive data). Vary: Authorization tells shared caches to store separate variants per Authorization header value — correct for API responses that differ by token but are otherwise cacheable (e.g. by-user configuration data).

Auth endpoints returning 403 instead of 401: 401 Unauthorized means “authenticate first”; 403 Forbidden means “authenticated but not permitted”. Browsers and API clients handle these differently — 401 triggers credential prompts or refresh-token flows; 403 should not.