RFC 7807 Quiz

Q1: Which media type identifies a JSON Problem Details response?

Multiple Choice

A. application/json B. application/problem+json C. text/problem+json D. application/http-error

RFC 7807 Section 6.1 registers `application/problem+json`. `application/json` describes generic JSON but not the Problem Details semantics; the other two types are not registered by RFC 7807. Section 6.2 separately registers `application/problem+xml`.

Q2: How should the generic client process this response?

Multiple Choice

A response contains type, title, status, detail, instance, and a problem-specific retry_token member. The client understands the five base members but not retry_token.

A. Reject the whole document because every member must be standardized B. Treat retry_token as another standardized base member C. Process the base members and ignore the unknown extension D. Parse detail to infer the missing retry_token semantics

A: Section 3.2 requires clients to ignore extensions they do not recognize, enabling problem types to evolve. B: Section 3.1 defines the five base members; retry_token is type-specific. C: This preserves the common semantics without inventing extension behavior. D: Section 3.1 says consumers SHOULD NOT parse detail for machine information; an understood extension is the safer channel.

Q3: Which client change follows the member semantics?

Multiple Choice

Two responses use the same type URI. Their titles are localized into English and Japanese, and their detail strings differ by account. A client currently branches on the English title.

A. Branch on detail because occurrence text is the stable machine identifier B. Require title to remain English for every recipient C. Treat each localized title as a different problem type D. Branch on type; present title to people and detail for this occurrence

A: detail is human-readable, occurrence-specific, and not a machine contract. B: Section 3.1 permits title changes for localization. C: Localization does not create a new type. D: Consumers MUST use type as the primary identifier; title is advisory and detail explains this occurrence.

Q4: What is the defensible interpretation of this status mismatch?

Multiple Choice

An origin generates HTTP 409 with status: 409 in the problem body. A gateway later changes the HTTP status to 502 but forwards the body unchanged. A generic client receives 502 and status: 409.

A. The body always overrides HTTP, so generic software must behave as if it received 409 B. Generic HTTP uses 502; status may preserve the origin value, but the mismatch has no universal precedence C. The mismatch proves the origin violated its generator requirement D. The client should average both values and retry as a 4xx response

A: The status member is advisory and generic HTTP software uses the actual response status. B: Sections 3.1 and 5 explicitly describe intermediary changes and say relative precedence is unclear. C: The premise says the origin emitted matching values; the gateway created the mismatch. D: RFC 7807 defines no merge algorithm.

Q5: What may a client conclude from this omitted type?

Multiple Choice

A 429 response omits type and sends title: "Quota exhausted". A client wants to treat that title as a standardized quota-exhaustion subtype.

A. The implicit type is about:blank; a custom subtype needs an explicit type URI B. The title automatically becomes the type identifier when type is absent C. The response has no problem type and is invalid JSON D. Every 429 response has quota-exhaustion semantics under RFC 7807

A: Section 4.2 makes about:blank the default and gives it no semantics beyond the HTTP status code; its title SHOULD be the recommended status phrase, subject to localization. B: title never becomes the primary identifier. C: omission is explicitly allowed. D: A status code does not create the proposed application-specific subtype.

Q6: Which validation-error client is robust to wording changes?

Multiple Choice

The validation-error type defines an invalid_params array. Client A extracts field names with a regular expression over detail. Client B first checks type, then reads invalid_params when it understands that extension.

A. Client A, because detail is the normative machine interface B. Client A, because extension members must be ignored even when understood C. Client B, because type namespaces extension semantics and detail is for people D. Neither, because problem types cannot define arrays

A: Section 3.1 discourages parsing detail for information. B: Unknown extensions MUST be ignored, but a client may use an extension whose problem-type definition it understands. C: Sections 3.1 and 3.2 support this division. D: Extensions can carry problem-specific structures, including arrays.

Q7: Should the client automatically fetch this type URI?

Multiple Choice

An agent receives an unrecognized type URI whose host resolves to an internal address. Its generic error handler would dereference every unknown type to discover instructions.

A. Yes, because every type URI MUST resolve before the response is valid B. Yes, because an HTTP URI is executable recovery metadata C. No, because type is forbidden from resolving to documentation D. No. Use type as an identifier; do not automatically dereference it

A: Dereferenceability is encouraged for human documentation, not required for validity. B: The URI identifies a type; it is not an instruction to execute a request. C: Section 4 encourages HTML documentation at the URI. D: Section 3.1 says consumers SHOULD NOT automatically dereference type. Treating the value as untrusted before any optional fetch also avoids turning error parsing into an SSRF path.

Q8: How should the client interpret these relative references?

Multiple Choice

A problem document whose base URI is https://api.example/tasks/7 contains type: "../problems/quota" and instance: "#attempt-2".

A. Reject both because type and instance must be absolute URIs B. Resolve both against the document base URI under RFC 3986 C. Resolve type against the API origin but leave instance as an opaque string D. Resolve both against the type documentation URI

A: Section 3.1 permits relative URI references for both members. B: It requires both to be resolved relative to the document's base URI under RFC 3986 Section 5. C: instance follows the same base-resolution rule. D: The type URI is not the base for instance.

Q9: Which review finding is grounded without overstating the RFC?

Multiple Choice

An API returns a database stack trace in detail and copies attacker-controlled detail, including line breaks, into a line-oriented audit log without encoding.

A. RFC 7807 requires stack traces so clients can debug the implementation B. Logging makes attacker-controlled detail trusted and safe to expose C. Remove sensitive internals and encode untrusted detail safely in structured logs D. RFC 7807 defines a mandatory Unicode canonicalization algorithm for audit logs

A: Sections 4 and 5 say Problem Details is not an implementation debugging tool and warn against exposing stack dumps. B: Moving data into a log does not authenticate it; raw delimiters can corrupt log records. C: Minimizing public details is RFC-grounded; input-safe structured logging is a separate application defense, not an RFC 7807 mandate. D: RFC 7807 specifies no logging canonicalization algorithm.

Q10: Which end-to-end assessment identifies all three boundary failures?

Multiple Choice

A backend returns HTTP 403 with a specific problem type. A gateway changes the HTTP status to 200, leaves status: 403 in the body, and localizes title. An A2A client treats 200 as success, then branches on the English title when it notices the body.

A. Preserve HTTP error semantics and branch on type, not localized title B. Keep 200 because the body status always controls generic HTTP behavior C. Keep title-based branching but disable localization at the backend D. Remove type because status and title together are the primary identifier

A: RFC 7807 Sections 3.1 and 5 make HTTP status the general error signal for generic software, require generators to align the body status with it, and define type as the primary machine identifier. If a gateway intentionally maps the response into another envelope, that mapping needs explicit application semantics rather than an unexplained 200/403 split. B: status is advisory. C: title is advisory and may be localized. D: status and title do not replace a specific type URI.

Problem Details for HTTP APIs

Primary reference and status

Q1: Which media type identifies a JSON Problem Details response?

Q2: How should the generic client process this response?

Q3: Which client change follows the member semantics?

Q4: What is the defensible interpretation of this status mismatch?

Q5: What may a client conclude from this omitted type?

Q6: Which validation-error client is robust to wording changes?

Q7: Should the client automatically fetch this type URI?

Q8: How should the client interpret these relative references?

Q9: Which review finding is grounded without overstating the RFC?

Q10: Which end-to-end assessment identifies all three boundary failures?