RFC 9457 Quiz

Q1: How does RFC 9457 relate to RFC 7807?

Multiple Choice

A. It adds HTTP status codes and leaves RFC 7807 unchanged B. It obsoletes RFC 7807 and revises its Problem Details guidance C. It defines the mandatory error envelope for every Agent-to-Agent protocol

**Explanation:** A: RFC 9457 does not create a new family of HTTP status codes, and it does not leave RFC 7807 as the current specification. B: RFC 9457 obsoletes RFC 7807, retains the general Problem Details model, and adds clarifications including registries and guidance for multiple problems. C: Problem Details is a general HTTP API format. An application protocol can specify a different error representation and is not automatically replaced by this RFC.

Q2: Which response representation carries the JSON form of a Problem Details object?

Multiple Choice

A. application/json with a required errorCode member B. application/problem+xml as the canonical JSON encoding C. application/problem+json as the JSON serialization

**Explanation:** A: A generic JSON media type does not signal the Problem Details semantics, and errorCode is not one of the standard members defined by RFC 9457. B: application/problem+xml is the XML representation described in the RFC appendix, not a JSON encoding. C: application/problem+json is the registered media type for the JSON serialization of the canonical Problem Details data model.

Q3: A response contains a standard member with the wrong JSON type. What must a conforming consumer do with that member?

Multiple Choice

A. Ignore that member and continue processing the object B. Reject the entire HTTP response as invalid JSON C. Coerce the value into the expected type before use

**Explanation:** A: RFC 9457 requires a consumer to ignore a standard member whose value has the wrong JSON type, so other valid information can still be processed. B: The JSON object itself can be syntactically valid even when a member has the wrong type. The RFC does not require rejecting the complete response. C: Automatic coercion can create different interpretations across implementations. Ignoring the malformed member is the specified interoperable behavior.

Q4: Which design best follows the rules for the type member?

Multiple Choice

A. Use a different relative URI for each occurrence and fetch it on every failure B. Use a stable absolute URI and treat dereferenceable documentation as optional at runtime C. Omit type and interpret the detail string as the primary machine identifier

**Explanation:** A: Relative type URIs can be confusing when resolved under different bases, and ordinary consumers should not automatically dereference every type URI. B: type is the primary problem-type identifier. Absolute URIs are recommended, and a locator URI should resolve to human-readable documentation without making runtime fetching necessary. C: If type is absent, its value is assumed to be about:blank. Human-readable detail text is occurrence-specific and is not a stable machine identifier.

Q5: A gateway changes an origin response from HTTP 404 to HTTP 502 but leaves status: 404 in the body. Which value should a generic client use?

Multiple Choice

A. Always use the body member because it came from the origin B. Combine both numbers into a new application status code C. Use the actual HTTP response status and treat the body member as advisory

**Explanation:** A: The status member is advisory and can disagree after an intermediary changes the response. It is not a second authoritative status channel. B: RFC 9457 does not define an algorithm for inventing a combined status code, and doing so would reduce interoperability. C: Generic HTTP software uses the actual HTTP status code. A generator must make the status member match its response, but a recipient can observe a mismatch after transit.

Q6: How should title and detail differ across occurrences of the same problem type?

Multiple Choice

A. Keep title stable except for localization, and put occurrence-specific help in detail B. Put a unique machine code in title, and keep detail identical for every occurrence C. Let clients parse either prose field to select automated recovery actions

**Explanation:** A: title summarizes the problem type and should not change except for localization. detail explains the specific occurrence and can help the client correct it. B: A changing title no longer acts as a stable summary of the type, while an invariant detail cannot describe occurrence-specific circumstances. C: Both fields are human-readable. Consumers should use type and documented extension members, rather than parse prose, for machine decisions.

Q7: A quota problem must tell clients the limit and reset time. What is the best representation?

Multiple Choice

A. Encode both values only in detail and require clients to parse the sentence B. Define documented extension members while keeping detail readable for humans C. Reuse status for the quota limit and title for the reset timestamp

**Explanation:** A: Parsing human prose is brittle across wording and localization changes. detail is not a machine-readable extension channel. B: A problem type can define extension members for structured data. Consumers must ignore extensions they do not recognize, enabling compatible evolution. C: Redefining standard members breaks their specified meanings. status remains an HTTP status code and title remains a summary of the problem type.

Q8: An operation detects several failures. Which response strategy matches RFC 9457 guidance?

Multiple Choice

A. Always return a generic batch problem containing unrelated problem types B. Emit several HTTP status lines so every failure has an independent status C. Use a same-type extension; otherwise return the most relevant type

**Explanation:** A: A generic container for unrelated problems maps poorly to HTTP status and can make client behavior ambiguous. It is not the universal recommendation. B: A single HTTP response has one status line. Problem Details does not create multiple independent HTTP responses inside one response. C: A type-specific extension can represent multiple occurrences of the same type. For different types, returning the most relevant or urgent problem is recommended.

Q9: Which redesign gives clients a stable contract without exposing internals?

Multiple Choice

An API returns type: about:blank, HTTP 400, and detail: "account locked in AuthService.java:418". Clients retry or stop by matching the English detail text. The server also wants to convey a lock reason and an unlock time.

A. Keep about:blank and standardize the Java stack-frame wording for parsers B. Put the lock reason in title and require clients to parse localized titles C. Define a stable problem type and typed extensions, while keeping detail non-sensitive D. Use a unique instance URI as the problem type and embed diagnostics in its query

**Explanation:** RFC 9457 Sections 3.1.1 and 3.1.4 make type the primary machine identifier and discourage parsing detail. Section 3.2 provides typed extension members, while Sections 4 and 5 distinguish API problem semantics from debugging data and warn against exposing implementation internals. C gives clients stable fields for reason and unlock time. The other choices turn human or occurrence-specific data into a protocol contract and retain disclosure risk.

Q10: Which review recommendation preserves interoperability and limits disclosure?

Multiple Choice

An A2A binding specifies a google.rpc.Status-style error body. A browser-facing gateway translates it to application/problem+json, agents decide whether to retry by parsing detail, and a central logger stores the entire translated object. The instance URI contains a bearer token in its query, while detail contains an internal path.

A. Replace the A2A wire contract implicitly because RFC 9457 always overrides other formats B. Keep retry parsing and full logging because problem+json sanitizes every member C. Specify the adapter mapping, use stable machine fields, and redact before response and logging D. Remove the HTTP status and make detail the only authoritative error signal

**Explanation:** RFC 9457 does not override another protocol's chosen error envelope. An adapter can use it only through an explicit mapping. Sections 3.1.1, 3.1.4, and 3.2 support stable type and extension semantics instead of parsing detail; Section 5 requires careful review of generated information because Problem Details does not sanitize secrets or implementation data. C addresses the wire, decision, response, and logging boundaries. The HTTP status remains authoritative to generic HTTP software.

Problem Details for HTTP APIs

References (URLs)

Q1: How does RFC 9457 relate to RFC 7807?

Q2: Which response representation carries the JSON form of a Problem Details object?

Q3: A response contains a standard member with the wrong JSON type. What must a conforming consumer do with that member?

Q4: Which design best follows the rules for the type member?

Q5: A gateway changes an origin response from HTTP 404 to HTTP 502 but leaves status: 404 in the body. Which value should a generic client use?

Q6: How should title and detail differ across occurrences of the same problem type?

Q7: A quota problem must tell clients the limit and reset time. What is the best representation?

Q8: An operation detects several failures. Which response strategy matches RFC 9457 guidance?

Q9: Which redesign gives clients a stable contract without exposing internals?

Q10: Which review recommendation preserves interoperability and limits disclosure?