Chapter 13 · Implementation Guidance and Interoperability Testing
Check your understanding
16 questionsself-scored · offline
Answer to check your grasp of Chapter 13. Multiple-choice and true/false questions score themselves and reveal an explanation; short-answer questions reveal a model answer. Nothing leaves your browser.
- Q1multiple choiceWhich four things must every HTTP/3 deployment configure?WhyNegotiate ALPN 'h3', present a TLS certificate, declare transport parameters, and send SETTINGS as the first control-stream frame. The rest are deployment choices layered on top. [§13.1, RFC 9114 §3.1, §7.2.4]
- Q2multiple choiceWhy can't a QUIC load balancer route by the four-tuple like a TCP one?WhyBecause the client can migrate and NATs rebind, the four-tuple isn't stable. A QUIC-aware balancer routes on the connection ID, which the server encodes with routing info, so migration and load balancing coexist. [§13.1, RFC 9000 §5.1]
- Q3multiple choiceHow does a client typically discover that a server supports HTTP/3?WhyThe server advertises its h3 endpoint via Alt-Svc (or the HTTPS DNS record); the client caches it and tries QUIC next time, falling back to TCP if UDP is blocked. [§13.1, RFC 9114 §3.1.1]
- Q4multiple choiceThe core interoperability rule for HTTP/3 is:WhyMUST ignore unknown values in extensible elements (enabling extensions and GREASE), but HTTP/2-reserved code points (frames 0x02/0x06/0x08/0x09, settings 0x00/0x02-0x05) MUST be treated as errors. Getting the asymmetry backwards is a common bug. [§13.2, RFC 9114 §9, §7.2.8]
- Q5true / falseThe reserved (GREASE) code-point formula is the same (0x1f·N + 0x21) for HTTP/3 frames and for QUIC transport parameters.WhyHTTP/3 frames/settings/stream types use 0x1f·N + 0x21; QUIC transport parameters use 0x1f·N + 0x1b (31·N + 27) — a different base. Conflating them is itself a pitfall. [§13.2, RFC 9114 §7.2.8, RFC 9000 §18.1]
- Q6multiple choiceWhy should an endpoint deliberately SEND reserved (GREASE) code points?WhyGREASE is offensive testing of the ignore-unknown rule. Endpoints SHOULD include a reserved setting; if a peer errors on it, the bug is theirs and would break against any greasing browser. [§13.2, RFC 9114 §7.2.4.1]
- Q7multiple choiceSETTINGS_QPACK_MAX_TABLE_CAPACITY defaults to 0. What does that mean for an encoder before the peer advertises a non-zero value?WhyWith capacity 0 (the default), the encoder MUST NOT use the dynamic table. Assuming a non-zero default is the classic QPACK interop bug; exceeding the advertised max is QPACK_ENCODER_STREAM_ERROR. [§13.2, RFC 9204 §3.2.3, §5]
- Q8true / falseHandling valid traffic correctly is sufficient to consider a stack robust.WhyThe wire is hostile. A stack must also handle malformed frames, limit violations, and illegal state transitions with the SPECIFIC error code, bounded memory, and no crash. Every MUST-error is a test case. [§13.3]
- Q9multiple choiceA fuzzer sets a DATA frame's Length varint larger than the bytes present, and the parser reads past the buffer and crashes. What was the correct behavior?WhyA frame whose Length runs past the data is a FRAME_ENCODING_ERROR (0x07); the parser must bounds-check, not trust the length. Only negative/fuzz testing surfaces such bugs. [§13.3, RFC 9000 §12.4]
- Q10multiple choiceFor a single malformed FRAME vs a single oversized/unprocessable REQUEST, the correct error scopes are:WhyA framing violation means the peer can't be trusted → connection error. An application problem with one request should be a stream error so other requests continue. Getting the scope wrong in either direction is a bug. [§13.3, §5.4]
- Q11multiple choiceWhen ALPN negotiation fails (no compatible application protocol), the endpoint must:WhyALPN is mandatory; a client MUST use error 0x0178 to terminate when negotiation fails, rather than assuming a protocol. [§13.4, RFC 9001 §8.1]
- Q12true / falseAn endpoint may keep using the same AEAD keys indefinitely as long as the connection is healthy.WhyEach AEAD has a confidentiality limit (2^23 packets for AES-GCM); the endpoint MUST key-update before reaching it, and if a key update is impossible or the integrity limit is hit, MUST close with AEAD_LIMIT_REACHED. [§13.4, RFC 9001 §6.6]
- Q13multiple choiceWhy are missing security checks (e.g. skipping certificate verification) especially dangerous?WhyUnlike a framing bug, a missing security check doesn't announce itself; the stack interops fine until an adversary attacks. That's why security needs an explicit adversarial test plan, not an assumption. [§13.4]
- Q14multiple choiceThe §13.5 production-readiness gate ships a stack only when which categories pass?WhyEach of the six categories is a hard gate grounded in the book's chapters; the stack ships only when all pass, and any gap sends it back to fix and re-run. [§13.5]
- Q15short answerTwo HTTP/3 stacks each pass their own conformance suite but fail to interoperate. Give two likely causes and how you'd find them.Model answer(1) One stack errors on an unknown/reserved (GREASE) code point instead of ignoring it — e.g. it closes with H3_SETTINGS_ERROR on a reserved setting the peer greases. (2) A stack ported from HTTP/2 leaves HTTP/2 code points active (frame 0x02/0x06/0x08/0x09 or setting 0x00/0x02-0x05), sending something the peer must reject as H3_FRAME_UNEXPECTED/H3_SETTINGS_ERROR. (3) A QPACK default-zero bug — an encoder using the dynamic table before the peer advertised a non-zero capacity. Find them with a decrypted capture (§11.3) to see the offending frame/setting, and by testing against real peers that grease aggressively (browsers, the interop runner) rather than only against your own suite. [§13.2, §11.3]
- Q16short answerOutline the six categories of a QUIC/HTTP-3 production-readiness gate and one thing each verifies.Model answer(1) Conformance — correct behavior on valid input: handshake+ALPN, SETTINGS-first, request/response ordering, QPACK, RFC 9002 recovery. (2) Interoperability — talks to other stacks: ignore-unknown + GREASE, reject HTTP/2 code points, pass real browsers/interop runner. (3) Robustness — survives hostile input: malformed frames, limit violations, and illegal transitions yield the specific error code with bounded memory and no crash (fuzzing). (4) Security — safe against a hostile peer: cert+ALPN auth, 3x anti-amplification, AEAD key-update limits, 0-RTT idempotent-only, anti-abuse (optimistic ACK, constant-time reset compare). (5) Performance — fast and stays fast: golden signals (queueing delay, goodput+ceiling, loss/PTO, TTFB) at p50/p99, gated vs baseline under emulated profiles. (6) Resilience/deployment — holds up in the real topology: migration, NAT rebinding, resumption, CID-based load balancing, and HTTP/2-over-TCP fallback. Ship only when all six pass, automate with emulation + qlog artifacts, and ramp behind the fallback. [§13.5]