HTTP design: priorities, WebTransport, and semantic correctness

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.

All three mistakes share the same root: the HTTP machinery acts on the status code, not the response body. When you return the wrong code, you lose every layer of automatic behaviour that HTTP infrastructure provides.

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.

These three Vary mistakes share a pattern: the cache stores or serves the wrong variant. When you add or change a Vary header, always ask: which request header actually changes the response body, and which cache layer will see both variants?

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.