RFC 6585 Quiz

**Explanation:** The point of RFC 6585 is not “more status codes for trivia.” It is to improve interoperability when generic responses such as 400, 403, or 503 hide the next action clients should take. **status codes** are part of the protocol contract between server and client. A **more precise** status code narrows the meaning of the failure and suggests a better retry or recovery strategy. In practice this helps API gateways, SDKs, browsers, and operators distinguish rate limiting, precondition failures, header-size problems, and captive-portal interception. A specialized status code is useful when its more precise meaning leads the client to a better recovery or retry action. A: RFC 6585 adds a few targeted codes. It does not replace the whole status-code space. B: This is the core motivation of the RFC. C: The RFC is not defining a new auth scheme.

**Explanation:** `428 Precondition Required` is easy to confuse with generic conflict handling, but the RFC frames it around making clients use conditional requests to avoid the lost-update problem. A **precondition** is something like `If-Match` that must evaluate successfully before the method is applied. A **lost update** happens when one client overwrites another client's newer change without realizing it. This shows up in document editing APIs, config stores, and admin panels where multiple actors may update the same resource. The important design move is not merely returning an error, but forcing the client to prove which version it intended to update. A: Requiring a conditional update makes the client identify the version it intends to change, preventing a stale write from silently replacing a newer one. B: Per-minute quota exceedance is the domain of `429 Too Many Requests`, optionally with timing guidance such as `Retry-After`. C: Network login interception is what `511 Network Authentication Required` is for; it is not a lost-update condition.

**Explanation:** RFC 6585 Section 3 makes the recovery path part of `428 Precondition Required`: the response SHOULD explain how to resubmit the request successfully. It should steer the client toward a conditional request, not a blind retry loop. A **validator** is metadata such as an `ETag` that helps identify a specific version of a representation. `If-Match` is a conditional header commonly used to say “apply this update only if the resource still matches this validator.” This is the difference between safe collaborative editing and accidental data loss in dashboards, CMS tools, and admin APIs. A server that emits 428 should usually help the client understand which conditional mechanism it expects, rather than making the client guess. A: Retrying without a precondition leaves the lost-update risk unchanged. B: This follows the RFC's intended fix. C: `503 Service Unavailable` is not a substitute for missing preconditions.

**Explanation:** Teams often blur per-client throttling with whole-service overload. RFC 6585 gives `429 Too Many Requests` so that clients can distinguish “you are over the limit” from “the service is down.” **429 Too Many Requests** is about request-rate or quota policy for the client. **503 Service Unavailable** is about broader service availability. **511 Network Authentication Required** is about local network access mediation, not ordinary API auth. This affects SDK retry logic, dashboards, rate-limit observability, and whether on-call engineers page the whole service team or just adjust one tenant's traffic profile. If clients cannot tell quota exhaustion from server unavailability, they either retry too aggressively or route the incident to the wrong team. A: This is the best fit when the service is healthy but the client exceeded a limit. B: 503 implies a service-level availability problem rather than a client-specific quota issue. C: 511 is for captive portals or intercepting proxies.

**Explanation:** `Retry-After` matters because a status code alone often says only “not now.” Well-designed clients also need timing guidance. **Retry-After** is a response header that indicates when the client may retry. It can be expressed as **delay-seconds** or as an **HTTP date**, depending on the response semantics. This shapes SDK backoff policy, browser behavior, and API client fairness during rate limiting or temporary outages. A precise backoff hint is often the difference between graceful recovery and a retry storm. A: This is one of the most useful roles of `Retry-After`. B: `Retry-After` is not limited to integer seconds. An HTTP date is also valid. C: This is exactly why the header improves client behavior. D: It is helpful, but not universally mandatory on every 429 or 503.

**Explanation:** `431 Request Header Fields Too Large` is not only about one bad header line. The RFC allows it for either a single oversized header field or an oversized set of headers. A **header field** is one named header entry. The **request header section** is the total set of request headers sent with the message. This is common with cookie bloat, oversized auth tokens, forwarding chains, and proxy limits that are lower than application developers expect. Good 431 handling helps teams debug whether the problem lives in cookies, auth middleware, proxy forwarding, or client header construction. A: The code can cover the total header set being too large. B: Syntax errors are not the defining point here, and the issue is not limited to one field. C: The RFC encourages the response to identify the offending field when that is possible. D: Oversized bodies are a different problem from oversized headers.

**Explanation:** RFC 6585 Section 4 says a 429 response MUST NOT be stored by a cache. A **shared cache** can reuse a stored response across multiple users or clients. **request-specific conditions** include missing preconditions, quota state, header-size mistakes, or captive-portal network state. This matters in CDNs, reverse proxies, and API gateways where accidental reuse of a 429 or 428 can create tenant bleed, misleading failures, or very confusing support tickets. Status codes are not just UI messages. They also guide intermediaries, and that includes telling caches what not to reuse. A: Replaying one tenant's 429 to other clients is exactly the kind of mistake the RFC tries to avoid. B: RFC 6585 says these specific responses must not be stored by caches. C: Rewriting protocol errors into 200 hides semantics and breaks client logic.

**Explanation:** RFC 6585 Section 7 says a server under attack is not required to emit these status codes and can take other action, such as dropping connections. This permits, but does not require, dropping connections. A **request flood** or **header-bomb** attack tries to consume server resources. A **defensive action** can include dropping the connection or otherwise refusing to spend more CPU on a detailed response. This matters in DDoS mitigation, bot control, and edge-proxy defense where response generation itself may be expensive enough to worsen the incident. Precise semantics are valuable, but survivability comes first when the response itself becomes part of the attack cost. A: The RFC explicitly leaves room for cheaper defensive behavior. B: 503 is not a universal replacement for all attack-related failures. C: This is the RFC-consistent operational mindset.

**Explanation:** `511 Network Authentication Required` is one of the easiest RFC 6585 codes to misuse. It is not a generic “authentication failed” response for ordinary origin applications. An **intercepting proxy** or **captive portal** sits on the network path and blocks broader access until the user satisfies some local network-login requirement. An **origin API** is the actual target application server. This distinction matters in Wi-Fi onboarding, hotel portals, enterprise guest networks, and browsers or operating systems trying to detect network mediation cleanly. If an app uses 511 for normal login failures, clients will misunderstand both the layer and the recovery path. A: Origin application session problems are not what 511 is for. B: This is the intended deployment model. C: Cache staleness is unrelated to 511.

**Explanation:** RFC 6585 Section 5 says that `431 Request Header Fields Too Large` means the server is unwilling to process the request because its header fields are too large. The request may be resubmitted after reducing their size; when one field is at fault, the response should identify it. A 431 response must not be stored by a cache, so a later corrected request is evaluated rather than answered from that error response. A: It changes the condition named by the response before retrying. B: `If-Match` addresses a precondition and lost-update risk; it does not reduce an oversized header field. C: Waiting is useful for rate limiting, but time does not make an unchanged Cookie field smaller.

**Explanation:** A: A status code inside an unauthenticated TLS stream cannot authenticate the intermediary that supplied it. B: RFC 6585 Section 7.4 says captive-portal interception on TLS produces a certificate error. RFC 6585 defines 511 semantics after HTTP is available; it does not authorize bypassing TLS peer authentication. C: A different link target can be expected in a valid 511 representation, but it cannot retroactively authenticate the failed TLS connection. D: Omitting credentials reduces some exposure but does not make the presented certificate valid for `api.example`.