2025/02/19
状況
- 「httpは本来ステートレスで」って説明したら、「そもそもステートレスって何？」と質問された。
目的
- ステートレス、ステートフルの考え方を理解する。 ＃ステートレスは平等。退かぬ、媚びぬ、顧みぬ、って感じ
- httpの基本仕様を理解する ＃文書運搬規約でしかない
- httpで何がしたいか理解する ＃さっき送った文書に書いてある名前を相手に覚えてほしい
- httpに何をさせているか理解する ＃運搬内容にIDとか入れておいてもらっている
ステートレス、ステートフルとは
ステート（state）： 状態、状況、様子、健康状態などを意味する英語の単語
ステートレス、ステートフル ： ステート（前後の状況）に応じて処理の仕方を変えるかという考え方、アーキテクチャ。変えない場合ステートレス。変える場合ステートフル。
→相手が誰であろうと、絶体絶命の状況であろうと、帝王に逃走はない、とか、誰にでも平等な対応でステートレス。
→この文書の対象読者なら、主にwebの文脈の言葉で、ログイン関係と思って良いはず。
→他の文脈だと、セキュリティの文脈で、ステートフルインスペクション、とかで出てくるけど、今は気にしなくて良いと思う。
→webサイトの挙動の例
- qiita ： ログイン前後で「ログイン」ボタンの表示有無を制御 ： ステートフルな挙動
- デジタル庁HP ： 多分誰がアクセスしても同じ情報が表示される ： ステートレスな挙動
httpの基本仕様
以下のページが必要十分に分かりやすく解説してくれています。
- 文書などの情報をやりとりする時に使われる通信手順(プロトコル)
- 1990年前後に開発
- 別途cookieなどの技術を組み合わせて使うことで複数回のやりとりを追跡
httpで何がしたいのか
1990年以降、みんなが「web」を使い始めたので、「web」で通販とか商売したくなった。
→「認証」「認可」「アカウンティング」（AAA）などが必要になってきた。 ＃今回の話。
→「機密性」なども必要になってきた。 ＃また別の話。
＞別途cookieなどの技術を組み合わせて使うことで複数回のやりとりを追跡
→クッキーってなにそれ？おいしいの？
「Cookie」：HTTPの状態管理メカニズム。webサーバーとクライアント間で状態を保持し、セッション管理やユーザー認証などの機能を実現。
2000年10月 RFC2965 https://tex2e.github.io/rfc-translater/html/rfc2965.html
2011年04月 RFC6265 https://tex2e.github.io/rfc-translater/html/rfc6265.html
ということで、HTTPクライアントとサーバー間でのセッション管理のために、
httpというプロトコルの開発後10年とか20年かけて技術的な拡張をしていったという感じですね。
↓万能ということではないよ、という話。法律対応で良くクッキーのポップアップ出るようになりましたね。
7. プライバシーに関する考慮事項
Cookieは、サーバーにユーザーを追跡させるためにしばしば批判されます。
8.1. 概観
Cookieには、多くのセキュリティ上の落とし穴があります。このセクションでは、いくつかの重要な問題について概説します。
7. Privacy Considerations .........................................28
7.1. Third-Party Cookies .......................................28
7.2. User Controls .............................................28
7.3. Expiration Dates ..........................................29
8. Security Considerations ........................................29
8.1. Overview ..................................................29
8.2. Ambient Authority .........................................30
8.3. Clear Text ................................................30
8.4. Session Identifiers .......................................31
8.5. Weak Confidentiality ......................................32
8.6. Weak Integrity ............................................32
8.7. Reliance on DNS ...........................................33
↓実装イメージ
1. はじめに
このドキュメントでは、HTTP CookieおよびSet-Cookieヘッダーフィールドを定義します。
Set-Cookieヘッダーフィールドを使用して、HTTPサーバーは名前/値のペアと関連するメタデータ（Cookieと呼ばれる）をユーザーエージェントに渡すことができます。
ユーザーエージェントがサーバーに後続のリクエストを行うと、ユーザーエージェントはメタデータとその他の情報を使用して、Cookieヘッダーで名前と値のペアを返すかどうかを決定します。
ということで、キーバリューの形式のテキストデータ、となります。json形式も可能。
自分のブラウザがどんなクッキーを食べているのか、何が書いてあるのか、見てみましょう。
chromeでの確認方法
httpに何をさせているか
結局、http自体は変わらず運搬しているだけ。
クライアント側は求められるデータの送信、もらったクッキーの保管をしているだけ。
httpサーバ、webサーバ側が、送られてきたデータから、クッキーを確認して、業務ロジックを実装、実行しているというだけ。
ログインなら、ログインのロジックを実装、実行し、ユーザ名をDBなどから取得して、画面に変数として埋め込んでブラウザに返却、などなど。
詰まり、あくまで「httpはステートレス」。記憶する主体はhttpサーバである。認証のデータはCookieとしてやり取りされる。
補足 httpの歴史
とても分かりやすく、また、最近の把握すべき用語である「QUIC」の説明もあります。
補足 なぜ「クッキー」？
The name
I had heard the term "magic cookie" from an operating systems course from college.
The term has a somewhat similar meaning to the way Web Cookies worked
and I liked the term "cookies" for aesthetic reasons.
Cookies was the first thing I came up with and the name stuck.
由来はUNIXの機能みたいですね。
そして詰まりは、やり取りするデータ、くらいの意味合いみたいですね。
以上