👻

君たちは本当のHTTPを知らない(RFC9110)

2023/01/15に公開約3,000字

年末年始にRFC9110を読んだので備忘録を兼ねてアウトプットしていきたいと思います。
https://www.rfc-editor.org/rfc/rfc9110.html

501 Not Implemented

ルーティングされているが、中身が未実装 の場合に返すことが推奨されている番号になります。
とても便利なステータスコードですが、筆者の肌感では意外と知られていないと感じます。
筆者もRFCを読むまで知らなかったですが、最も実務に反映しやすい知識かなと思います。
https://developer.mozilla.org/ja/docs/Web/HTTP/Status/501

If-*

ここでは特筆してIf-MatchとIf-None-Matchについて取り上げていきます。
これらはPOST・PUTなどの更新系で利用されます。
並行的なHTTP通信処理での上書きや、変更の衝突を防ぎます。

If-Match

If-Matchがあるリクエストを受け取ったサーバーは、メソッド実行前にIf-Matchを評価する必要があります(MUST)

フィールド値 結果
* 最新の情報と一致していればTrue
ETagのリスト リストのどれか一つにでも一致すればTrue
それ以外 False

Falseになった場合、サーバーは412を返す必要があります。

If-None-Match

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/If-None-Match

リクエストで指定されたものとマッチしなかった場合 ・・・サーバーはメソッド実行し200を返す必要があります。
リクエストで指定されたものとマッチした場合    ・・・サーバーは304を返す

フィールド値 結果
* 最新の情報と一致していればFalse
ETagのリスト リストのどれか一つにでも一致すればFalse
それ以外 True

べき等性

簡単にいうと、「何度試行しても結果が変わらないこと」です

HTTPでは

  • GET
  • HEAD
  • PUT
  • DELETE

はべき等なメソッドとして定義されています。
https://developer.mozilla.org/ja/docs/Glossary/Idempotent

Information Hiding

こちらは筆者が最も理解に苦しんだ部分になります。ですがこのセクションはHTTPの根幹を表現しているセクションと言っても過言ではありません。

まずは、RFCの原文を引用します。

HTTP allows "information hiding" behind its uniform interface by defining communication with respect to a transferable representation of the resource state, rather than transferring the resource itself. This allows the resource identified by a URI to be anything, including temporal functions like "the current weather in Laguna Beach", while potentially providing information that represents that resource at the time a message is generated [REST].

日本語訳すると以下のようになります。

HTTPは、リソースそのものを転送するのではなく、リソースの状態の転送可能な表現に関して通信を定義することで、その統一的なインターフェースの背後にある「情報の隠蔽」を可能にします。これにより、URIで特定されるリソースは、「ラグナビーチの現在の天気」のような時間的な機能を含むものであっても、メッセージが生成された時点でそのリソースを表す情報を提供できる可能性があります

微妙に意味が分かりづらいですね・・・

要約するとこの文章は「HTTPはあくまでもレスポンス内容に依存しない転送手段を提供する」ことを意味しています。

こちらはHTTPの歴史を紐解くことで理解できるので、紐解いていきましょう。

元々HTTPは、1990年に論文などの 「文章共有システム」 として誕生しました。
そのため、当時レスポンスは固定された静的な情報でした。
ですが、時が経つにつれ 動的な情報 を返すことが要求されてくるようになりました。
(天気情報やブログ投稿数など)

そのため「静的データ」と「動的データ」どちらも返せることを実現しなければなりません。
そこで、HTTPはあくまでも「レスポンス内容に依存しない転送手段を提供する」ことにしました。これを表現している文章が引用した文章となります。

今となってはあまりにも当たり前なことですが、この数文に30年程の歴史がと先人たちの努力が詰まっていると思うとものすごくロマンを感じますね・・・

終わりに

さて、いかがだったでしょうか?
個人的にはRFCはやはりとてもタメになるので読むべきだなぁと再認識しました。
ただ、とてつもなく疲れる!!!
母国語でも理解しにくい内容の外文を読むのはエネルギーをごっそり持っていかれますね・・・
そして、RFCを読むにあたり翻訳機能の進化に驚くとともにものすごく助けられました。
便利な世の中になったなぁと改めて感じた筆者でした。

Discussion

ログインするとコメントできます