先日こんなツイートをしました。
思ったより多くの反響をいただいて、その内容を見て「これはあまり良くない質問だったかもな」と思ったので今後封印すると共に「自分だったらこう答える」というのを書いておこうと思いました。
元が面接の話なので、調べないで時間をかけないように書いてるので間違ってたら教えてください!!
POSTとGETの違い
- どちらもHTTPメソッドでプロトコル的に本質的な違いは無い。
- リクエストが「GET URL HTTPバージョン」になるか「POST URL HTTPバージョン」になるかの違い。
- 世の中の実装ではパラメタの受け渡しがGETではURL、POSTではHTTPボディがメイン。
- ブラウザ実装面ではリロードする時にGETは確認なし、POSTは確認を伴う実装が多い。
- 検索エンジンbotなどはGETを辿ることがあり、GETで取得できる画面には副作用が無いものを置くのが望ましい。
- そういえばちゃんとRFC読んだことないのでちゃんと答えるには読んだ方がいいな…。(URLの「?」の後ろがどういう扱いになるべきかを理解していない。POSTで「?」を使うことも実装上は可能。)
Cookieの仕組み
- ステートレスなHTTPでステートを実装するための仕組み。
- サーバはHTTPレスポンスヘッダの Set-Cookie でキーと値、送信して欲しいドメイン、有効期限を送信する。
- ブラウザは Set-Cookie ヘッダを見たらその内容をローカルファイルなどに保存する。
- ブラウザはHTTPリクエスト時に保存したローカルファイルを検索してドメインで検索して以前に受信したCookieがあればHTTPリクエストヘッダ Cookie として送信する。
- ローカルに情報が保存され、改竄される可能性があるため秘匿情報を保存する用途では使用しない。
PHPのセッション
- Cookie同様にステートレスなHTTPでステートを実装するための仕組み。
- Cookieと違い情報をサーバ側に保存する。
- サーバは情報を保存したいタイミングでファイルなどに値を保存しそれにキーを割り当て、Cookieでそのキーを送信する。
- ブラウザ側から見ると通常のCookieと同じ。
- サーバに情報が保存されるので、データの改竄の心配はしなくて良い。
- Cookieの盗難や、キーの生成規則の脆弱性、不適切なキーの受け渡しによる経路での盗難によってセッションをハイジャックされる可能性がある。
- 情報がいつまで使えるかはCookieの期限に依存するが、サーバ側に情報を保存するため無限にそれを保存することは難しく、言語やミドルウェアによってセッションの有効期限を決めてそれを過ぎた情報は削除される実装になっていることが多く、2つの期限を意識する必要がある。PHPもそう。
- PHPの場合、セッションキーのやり取りはPHPに隠蔽され、スーパーグローバル $_SESSION経由でアクセスできる。Cookieのキーを振り直す関数など、セッションの運用をサポートする関数が実装されている。
そんな感じですかね!皆さんの想定とあってます?「そんなので良いの??」という方!いいですね!ぜひ一緒に働きましょう!!!
こういうのを見て「なるほど〜!」「そうだったのか〜」「もっと知りたい!」という方もぜひ!