RFC 3986 Quiz

**Explanation:** **Terms:** authority, delimiter, scheme. generic syntaxでは, authorityは"//"に続いて現れ, その後にpath, query, fragmentへ進む. **Correct (C):** "//"がauthorityの開始を示す. authorityは userinfo, host, port を含み得る. **Options:** - A (incorrect): #はfragmentの開始. - B (incorrect): ?はqueryの開始. - C (correct): //がauthority introducer. **Related:** 全てのschemeがauthorityを使うわけではない. 例えばschemeによっては//を使わないopaqueな形式もある.

**Explanation:** **Terms:** authority, userinfo, host, port. authorityは `//` の直後から, 次の `/`, `?`, `#` の手前までです. その中に userinfo, host, port が含まれます. **RFCを読むときの見方:** URI の問題で迷ったら, まず `scheme -> authority -> path -> query -> fragment` の順に線を引くように見ます. RFC 3986 は component ごとの責務を定義しているので, 文字列全体を一気に読もうとするより, 区切り記号ごとに切る方が理解しやすいです. **Correct (A):** この例では userinfo が `user:pass`, host が `example.com`, port が `8443` です. つまり authority 全体は `user:pass@example.com:8443` になります. host だけを抜き出した `example.com` は authority の一部にすぎません. **Options:** - A (correct): `[userinfo@]host[:port]` の形に一致しています. - B (incorrect): `example.com` は host 部分だけで, authority 全体ではありません. - C (incorrect): `/a` は authority の後ろに来る path です. **Related:** userinfoはセキュリティ上の理由で推奨されないことが多いが, 文法としては存在する.

**Explanation:** **Terms:** reserved, unreserved, gen-delims, sub-delims. reservedは, コンポーネントによって区切りとして意味を持ち得るため, データとして使うならpercent-encodingが必要になることがある. **Correct (A,B,C):** ?, # はgen-delims, & はsub-delims. ~ はunreservedで, 通常はエンコード不要. **Options:** - A (correct): ?はpathとqueryの区切りとして使われる. - B (correct): #はfragmentの開始. - C (correct): & はsub-delimsで, query内ではアプリ側の区切りとして使われがち. - D (incorrect): ~はunreservedなのでreservedではない. **Related:** reservedは"危険"ではなく"区切りとして解釈され得る"という意味. どこでエンコードすべきかはコンテキスト依存.

**Explanation:** **Terms:** percent-encoding, component, delimiter vs data. percent-encodingは%HHでoctetを表し, 構文を壊さず曖昧性を無くす仕組み. **Correct (C):** 文字がそのコンポーネントで許可されない場合や, reservedが区切りではなくデータとして必要な場合にエンコードする. **Options:** - A (incorrect): schemeやIRI処理などで扱いが変わる. 一律ルールはround-tripを壊し得る. - B (incorrect): reservedはデータとして出したいこともある. その場合はエンコードして区切り解釈を避ける. - C (correct): 目的が"構文的に正しい"と"意図した意味"を両立させること. **Related:** 早すぎるdecodeは, 区切りとデータの区別を失ってバグの原因になる.

**Explanation:** **Terms:** normalization, scheme, host, path, fragment. 正規化は表記を変えつつ同じ参照を維持しようとする操作. **Correct (A):** schemeとhostは一般に大文字小文字を区別しないので, 小文字化はよくある安全な手順. **Options:** - A (correct): 多くの処理で意味が変わらない. - B (incorrect): pathの大文字小文字はschemeやサーバ実装依存で, 変えると別リソースになる可能性がある. - C (incorrect): fragmentはサーバへ送られないが, クライアント側で意味を持つので常に削除は安全ではない. **Related:** 署名付きURL, キャッシュキー, ルーティングは正規化の影響を強く受ける.

**Explanation:** **Terms:** fragment component. RFC 3986では, #の後ろはfragmentで, 二次リソースやクライアント側参照を指す. **Correct:** fragment. **Why others are wrong:** queryは?で始まり, pathはauthorityの後の階層部分, schemeは:の前. これを取り違えるとパースが崩れる. **Related:** fragmentは通常HTTPリクエストとしてサーバへ送信されない.