RFC 9457 Quiz

**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.

**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.

**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.

**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.

**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.

**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.

**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.

**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.

**Explanation:** A: A new problem type definition must document the type URI, a short title, and the HTTP status code used with it. B: A plain HTTP status code is often enough for a generic failure. New types are useful when clients need problem-specific semantics. C: RFC 9457 establishes an HTTP Problem Types registry, so reusing a suitable registered type avoids unnecessary incompatible vocabularies. D: A type URI identifies a category and may provide documentation. It should not expose implementation details or occurrence-specific secrets.

**Explanation:** A: A general HTTP RFC does not silently change an application's specified wire representation. Such a migration requires an explicit protocol decision. B: Stable error identifiers, status alignment, extensibility, and disclosure limits are useful review criteria even when the binding uses another error envelope. C: instance identifies an occurrence and does not sanitize other members. Stack traces, tokens, internal paths, and log data can still disclose sensitive information.