RFC 9110 Quiz

**Explanation:** HTTP semantics remain shared across protocol versions, while framing and transport mechanisms change. API design, proxy behavior, client libraries, and cache review depend on method and response meaning rather than the wire format. semantics, transport, method meaning. Semantics describe what a request means and what a response means, regardless of whether it is carried by HTTP/1.1, HTTP/2, or HTTP/3. Safety, idempotency, cacheability, and status code meaning are semantic concepts. - A (correct): This is about meaning and allowed effects. - B (incorrect): Framing is a transport mapping detail. - C (incorrect): QUIC packet behavior is transport protocol detail, not HTTP semantics. Keeping semantics stable across versions is why tools like proxies can reason about methods and caching independent of the underlying transport.

**Explanation:** Safe is often misread as “the server performs no write,” rather than a property of the action requested by the client. safe method. A safe method has essentially read-only defined semantics: the client does not request or expect a state change. Incidental server-side effects such as logging can still occur. GET is defined as safe because its requested semantics are retrieval, even though an implementation can have incidental effects that the client did not request. - A (correct): GET has safe defined semantics. - B (incorrect): POST is not safe. It is generally used to create or process resources and can change server state. - C (incorrect): DELETE is not safe. It removes a resource and changes state. Safe describes the client's requested semantics, not a guarantee that the server performs no writes internally. It is also separate from cacheability.

**Explanation:** Idempotency is commonly confused with identical responses or with a guarantee that every retry is operationally risk-free. idempotent method. Idempotent means making the same request multiple times has the same intended effect as making it once. PUT and DELETE are defined as idempotent. Repeating the same request has the same intended effect as one request, although individual responses and incidental side effects can differ. - A (correct): PUT replaces the target state with the provided representation, so repeating should converge to the same result. - B (incorrect): POST is not idempotent by default. Repeating might create multiple resources or trigger repeated processing. - C (correct): DELETE is idempotent. Deleting twice results in the same end state: the resource is gone. - D (incorrect): CONNECT establishes a tunnel and is not generally treated as idempotent. Idempotency is central for retries, load balancers, and safe recovery from network errors.

**Explanation:** The status-code class is the first layer of response meaning, before the client applies code-specific behavior. Clients, gateways, monitoring, and retry logic use status classes to choose broad handling paths before examining a specific code. status code class. The first digit indicates a broad category of response semantics. 3xx responses are redirections: the client may need to take additional action or use another URI. - A (incorrect): 4xx are client errors. - B (correct): 3xx indicates redirection semantics. - C (incorrect): 5xx are server errors. Redirection is not only 301 and 302. 304 Not Modified is also a 3xx related to cache validation.

**Explanation:** A: RFC 9110 Section 13.2.1 says a server ignores received preconditions when the same request without them would produce a status other than 2xx or 412 before content processing. B: Evaluating after the action cannot prevent the stale update that If-Match is intended to guard. C: The independently detectable authorization failure takes precedence, and the server performs no state change. If authorization later succeeds, the precondition is evaluated immediately before content processing or the method action. D: An entity tag identifies representation state; it is not an authentication credential. Decision rule: Determine whether the unconditional request is eligible for success, then evaluate representation preconditions before applying the method.

**Explanation:** A: RFC 9110 Section 15.6.5 defines 504 as the gateway not receiving a timely upstream response. It does not prove the backend performed no action. B: Section 9.2.2 distinguishes automatic retry by method semantics; a lost response does not erase a possible effect. C: Section 9.2.2 permits a client to retry a non-idempotent method only when it knows the request semantics are effectively idempotent or can detect that the original was never applied. D: POST is not universally non-repeatable. An application-specific operation identifier, deduplication contract, or state check can supply the needed knowledge, but RFC 9110 does not invent that contract. Decision rule: Retry depends on evidence about the operation's effect, not on the absence of a response or the validity of the authorization grant.