ToppyMicroServices

RFC 7807 Quiz

Problem Details for HTTP APIs

🇺🇸 🇯🇵
0 / 0

一次資料と仕様の状態

RFC 7807はRFC 9457によって廃止・置換されています。このページはRFC 7807の公開時点の内容を扱います。現行仕様はRFC 9457クイズで確認してください。以下のSection番号はRFC 7807を指します。

Q1: JSON Problem Details responseを示すmedia typeはどれ？

単一選択
RFC 7807 Section 6.1は`application/problem+json`を登録しています。`application/json`は汎用JSONを示しますが、Problem Detailsの意味までは示しません。ほかの2つはRFC 7807の登録対象ではありません。Section 6.2はXML用の`application/problem+xml`を別に登録しています。

Q2: 汎用clientはこのresponseをどう処理すべきか？

単一選択

responseにはtype、title、status、detail、instanceと、problem固有のretry_token memberがある。clientは5つのbase memberを理解するが、retry_tokenは理解しない。

A: Section 3.2は、problem typeを進化可能にするため、認識できないextensionを無視するようclientへ求めます。B: Section 3.1が定義するbase memberは5つで、retry_tokenはtype固有です。C: 共通semanticsを処理しつつ、未定義の動作を作らない方法です。D: Section 3.1はmachine情報をdetailから解析しないよう勧めます。理解できるextensionを使う方が安全です。

Q3: member semanticsに沿うclient修正はどれ？

単一選択

2つのresponseは同じtype URIを使う。titleは英語と日本語へlocalizeされ、detailはaccountごとに異なる。clientは現在、英語titleで処理を分岐している。

A: detailは人向けで発生事象ごとに変わり、machine contractではありません。B: Section 3.1はlocalizationによるtitle変更を許します。C: localizationは新しいtypeを作りません。D: consumerはtypeをprimary identifierとして使わなければならず、titleはadvisory、detailは今回の発生事象の説明です。

Q4: このstatus不一致をどう解釈するのが妥当か？

単一選択

originはHTTP 409とbodyのstatus: 409を生成した。gatewayがHTTP statusだけを502へ変更し、bodyはそのまま転送した。汎用clientは502とstatus: 409を受信する。

A: status memberはadvisoryで、汎用HTTP softwareは実際のresponse statusを使います。B: Sections 3.1と5はintermediaryによる変更を明記し、両者の相対的優先順位は不明確だとします。C: premiseではoriginの値は一致し、gatewayが不一致を作っています。D: RFC 7807に値を統合するalgorithmはありません。

Q5: typeの省略からclientが結論できることはどれ？

単一選択

429 responseがtypeを省略し、title: "Quota exhausted"を返した。clientはこのtitleを標準化されたquota-exhaustion subtypeとして扱いたい。

A: Section 4.2はabout:blankをdefaultとし、HTTP status codeを超えるsemanticsを与えません。そのtitleはlocalizationを除き推奨status phraseとすべきです。B: titleはprimary identifierになりません。C: 省略は明示的に許されています。D: status codeだけでは、このapplication固有subtypeを作れません。

Q6: wording変更に強いvalidation-error clientはどれ？

単一選択

validation-error typeはinvalid_params arrayを定義する。Client Aはdetailへ正規表現を適用してfield名を抽出する。Client Bはtypeを確認し、そのextensionを理解する場合だけinvalid_paramsを読む。

A: Section 3.1はdetailから情報を解析しないよう勧めます。B: 未知extensionは無視しますが、problem type定義を理解するclientはそのextensionを利用できます。C: Sections 3.1と3.2がこの分担を支えます。D: extensionはarrayを含むproblem固有構造を持てます。

Q7: clientはこのtype URIを自動取得すべきか？

単一選択

agentは未知のtype URIを受け取った。そのhostはinternal addressへ解決される。汎用error handlerは未知typeをすべてdereferenceして説明を取得する設計である。

A: 人向けdocumentationへresolveできることは推奨ですが、validity要件ではありません。B: URIはtypeを識別し、request実行を指示しません。C: Section 4はHTML documentationへのresolutionを推奨します。D: Section 3.1はtype URIを自動dereferenceしないよう勧めます。任意の取得前にuntrusted valueとして扱えば、error parsingがSSRF経路になることも防げます。

Q8: clientはこのrelative referenceをどう解釈すべきか？

単一選択

base URIがhttps://api.example/tasks/7であるproblem documentに、type: "../problems/quota"とinstance: "#attempt-2"が含まれる。

A: Section 3.1は両memberにrelative URI referenceを許します。B: RFC 3986 Section 5に従い、documentのbase URIへresolveする必要があります。C: instanceにも同じbase-resolution ruleが適用されます。D: type URIはinstanceのbaseではありません。

Q9: RFCを過大解釈しないreview findingはどれ？

単一選択

APIはdatabase stack traceをdetailで返し、改行を含むattacker-controlled detailをencodeせずline-oriented audit logへコピーする。

A: Sections 4と5はProblem Detailsを実装debug toolとせず、stack dump公開を警告します。B: logへのcopyはdataをauthenticateせず、raw delimiterはlog recordを壊し得ます。C: public detailの最小化はRFCに基づきます。入力を安全にencodeしたstructured loggingは別のapplication防御であり、RFC 7807の一律要件ではありません。D: RFC 7807はlogging canonicalization algorithmを定義しません。

Q10: 3つのboundary failureを捉えるend-to-end評価はどれ？

単一選択

backendはHTTP 403とspecific problem typeを返す。gatewayはHTTP statusを200へ変え、bodyのstatus: 403を残し、titleをlocalizeする。A2A clientは200をsuccessとして扱い、bodyに気付くと英語titleで分岐する。

A: RFC 7807 Sections 3.1と5では、HTTP statusが汎用softwareへ一般的error semanticsを伝え、generatorはbody statusと一致させる必要があります。typeがprimary machine identifierです。gatewayが別envelopeへ意図的にmappingするなら、説明のない200/403分離ではなくapplication semanticsを明示する必要があります。B: body statusはadvisoryです。C: titleはadvisoryでlocalize可能です。D: statusとtitleはspecific type URIを置き換えません。