昨日、HTTP/Tokyo という初めて開催された勉強会に参加して来ました。そこで得た知見を書こうと思います。
HTTP/Tokyo について
以下のイベントページにも書いてありますが、HTTPというプロトコルについて理解し、HTTPを正しく使えるようになることを目指す勉強会です。HTTP(s)に特化した勉強会って無かったので、面白そうと思い参加しました。
会場提供 株式会社トレタ様について
- 外食産業の生産性を向上させるための事業を展開している。
- 飲食店向け予約/顧客管理サービスを展開
- 超直前予約アプリToreta nowの開発元
- 立ち呑みトレタ 1/29 19:30から
会場はおしゃれできれいな雰囲気でした。全従業員の自宅勤務を推奨していたことからも、フレキシブルに働けそうな感じがしました。立ち呑みトレタ、興味あります!
Response Status Codes 3xx あらや @arayaryoma さん
資料
https://slides.araya.dev/http-tokyo-1/#slide=1
概要
ステータスコード 3xx系についての話でした。302はよく聞きますが、それ以外はあまり聞かないので、3xx系のステータスコードの多さに驚きました!!3xx系のコードについてはもっと勉強する必要あるのかと思いますが、登壇と資料で学んだこととしては以下の通りです。
- ステータスコード 3xx は、リクエストを果たすためには UA によるさらなるアクションが必要ということを指示する。
- 301と302はHTTP/1.0で定義されたもの
初期の UA では、301, 302 だったとき、リクエストターゲットへの適用に差があった。
- HTTP1.1で実際の差分に影響されない307が追加された
300 Multiple Choices
- リダイレクト先の候補がいくつかある、クライアント側は優先したいものを選ぶという仕組み。
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
- 条件付きGET/HEADリクエストが受け取られ、条件がfalseと評価されていなければ、200で応答するかのように返す挙動をとる。
307 Temporary Redirect
308 Permanent Redirect
Status425 @flano_yuki さん
資料
概要
ステータスコード425とTLS1.3でも使われるEarly Dataについての説明でした。コード425なんて初めて知りました(汗)Early Dataも初めて知りましたので、興味深く聞くことができました。TLS1.3についても話が聞けるとは思ってもいなかったため、得した気分でした!
TLS1.3について
TLS1.3を踏まえた上で、425 Too Early とは?
- RFC8470 Using Early Data in HTTP で定義されるステータスコード
- 安全にEarly Dataを送信できるようにするための仕様
ProxyやCDNを経由させている場合の問題点
問題解決のために
おまけ 418 vs 425
- Too Early のステータスコードを決める際に418にするか425にするか議論したが、418はIANAの管理上使われていなかった。
- しかし、エイプリルフールに発行されたジョークRFC(RFC2324 Hyper Text Coffee Pot Control Protocol)で定義された、418 I'm a tea pot があり、あちこちに実装されていた。そのため425になった。
- RFC7230 - 7237 から仕様を再改定することとなり、418はUnusedとなった。
@flano_yuki さんのブログ
Cookieについて Jxck さん
概要
Cookieについての説明をホワイトボードに書きながら登壇されていました。あまり見たことない登壇スタイルだったので驚きました。聞き漏らさないよう真剣に聞きました。途中から理解が追い付かなったところがあり、Cookieについて再勉強しなければと思いました。
資料はありませんでしたが、RFC6265とHTTP State Tokenをもとにした話でした。
※自分の理解が追い付かなかったため、わかった(と思う)ところのみ書きます。誤認識の恐れもあります。申し訳ありません。
- Cookieはリクエスト送信者を識別するために作られた。そのため、格納情報のほとんどはクレデンシャル情報である。
- サーバは最初のレスポンスでSet-Cookieを送り、クライアントにCookieを保管させる。次回以降はそのCookieを送信させることでアクセス元を判断している。
- しかし、CookieがSame Originの原則に乗っ取っていないため、悪意ある人が成りすまして正規のCookieを含んだリクエストを送っても、サーバはリクエストを受け付けてしまう。その性質を悪用したのがCSRFである。
- CSRFトークンでリクエストの正否を判断する必要がある。
- Cookieの方が歴史が古く、SameOriginの概念の方が新た強い。だから、ドメインの扱いが歪になっている。
- 一般的にCookieを悪用されないための対策は以下の通り。
- Set-Cookieを送信する際に「SameSite」というプロパティを付けることができるようになった。
- クロスサイトオリジンなサイトの場合は、SameSIteを明示的に"none"にする必要がある。
- SameSiteをlaxに設定すると、サイトの挙動を壊す恐れがある。
- サードパーティCookieによるトラッキングを防ぐため、ブラウザ側で対策が施されている。
- Cookieをなくすことはできないが、ChromeはCookieに頼らない情報収集(APIの利用等)を考えている。
- Prefix __secureを付けることでHTTPSの時のみ送信を許可。Set-Cookieの上書きを防ぐことができる。
- 画面を遷移してきたときにどこから来たのかを識別するために、できれば、ReadとWriteのCookieを判別できるようにするのがよい。そうすれば、SameSiteの属性を使い分けられる。
- Cookieではなく、「クライアント側でトークンを生成してサーバに送る」http state tokenの提案がされている。
最後に
HTTP(s)は、Webサービスがある以上、なくなることも廃れることもないプロトコルであり、アップデートされていくものだと再認識しました。奥が深いです!途中ついていけなかったくらいでした(汗)勉強し直します!もちろん、httpに限らず、Webサーバ、Webプログラミングなど、Web周辺のことはもっと知りたいと思います!
次回が開催されたら、また参加したいと思えた勉強会でした。