本セッションの登壇者
セッション動画
＠flano_yukiと言います。普段はXのこのアカウントでHTTP関連の情報発信をしています。この領域に10年ぐらい前に興味を持って取り組んできて、ウェブやHTTPが進化し続けていくおもしろさを感じて追い続けています。今回、HTTPがまだまだ進化しているということを、HTTPそのものの話として皆様にご紹介できればと思います。
HTTPのセマンティクスと、ヘッダやCookieなどの仕様動向をご紹介します。今回は議論中の内容を含んでいることと、HTTPの仕様上の話で、ブラウザやクラウドの側でサポートされるかというと必ずしもそういうわけではないことはご注意ください。
ヘッダの高機能化、アップロード途中の再開
早速ですがセマンティクスについてです。今、HTTP 1.1、/2、/3といったバージョンがありますが、HTTPリクエストの部分はバージョンにかかわらず一緒です。ただし、通信相手に対する届け方がそれぞれ違います。それが、これからお話しするHTTPそのものの機能、セマンティクスと呼ばれる部分です。
GET/POSTの意味、ヘッダの意味、レスポンスのステータスコードの意味などは、HTTPのバージョンで変わりません。HTTP 1.1だとASCII文字でこのように表現されますし、HTTP/2だったらバイナリで転送されていますが、HTTP/2でも/3でもこのGETリクエストの意味合いというものは変わらないんですね。そして、このセマンティクスの部分も進化しているというのが今回の本題になります。
「HTTPってまだ新しくなってるんですか？」とよく聞かれます。大学の授業で習うぐらい、HTTPの歴史は長いですけれども、まだまだ新しくなっています。
この1年で、周辺技術を除くHTTP関連でRFCになっているものが5本あります。メジャーなものとしては「RFC 9421 HTTP Message Signatures」があります。これはHTTPメッセージに署名する仕組みで、ヘッダに署名を格納することでプロキシやロードバランサを経由しても、HTTPメッセージの完全性を確認できる機能です。APIを叩く時やAWS S3からアップロードする時などに署名の仕組みが入っていますが、いろいろなサービスで似たようなAPIがあったのを標準化しています。
この中でもシチュエーションとしてマニアックなものが「RFC 9440 Client-Cert HTTP Header Field」です。TLSハンドシェイクをする時に、クライアントが自分は本物ですよと証明するためにクライアント証明書を投げる場合があります。
これはTLSレイヤーで行いますが、今まではTLSを終端するとバックエンドに証明書の情報を投げる仕組みがありませんでした。そのため、証明書情報をヘッダで中継する仕組みを標準化しています。Mutual TLS（mTLS）やCloudflareなどには似たような仕組みが入っていて、それを標準化する流れで出来上がった仕様です。
また、IETFで行われるHTTPの標準化の過程で、ドラフトと呼ばれるRFCになる前の仕様があります。今、HTTPbisというワーキンググループを明示的に管轄とするドラフトがこれぐらいあります。さらに、管轄になる前のディスカッションまで含めると、もっとたくさんのHTTPに関する機能追加が議論されています。その中でいくつかおもしろいものを深掘りしてご紹介したいと思います。
「Resumable Uploads Protocol」という、アップロード中に切断しても途中から再開する機能がディスカッションされています。AWSなど一部の実装で、オブジェクトストレージにファイルをアップロードする場合にクライアント側で小間切れにして、途中で失敗しても途中からやり直せるものはあるんですが、今回の提案はあくまでHTTPとして再開の仕組みを導入するというものです。
これが提案資料の中に書かれている通信プロトコルです。クライアントからPOSTでファイルアップロード中に104 Upload Resumption Supported with upload resource URL で、サーバー側がアップロードの再開に対応しているというシグナルと共にアップロード用のURLを通知します。
通信が切断すると、クライアントがもう一回途中からUpload-Offsetを送信して、どこまでアップロードできたか確認を入れます。そこからアップロードを再開して、全部送り終わったら201を返すという流れになっています。
一部でサーバー実装が出てきているので、試してみたい方は、この仕様名でググってみてください。今後RFCになると、より利用できるシチュエーションが増えていくと思います。
ホットなCookie仕様
次はCookieの仕様改訂版です。
IETFではバグフィックスや機能追加で一度出したRSCをメンテナンスするということがよくあります。仕様改訂版はそのメンテナンスワークの一環で行われているので、仕組みがガラリと変わるのではなく、機能追加や修正が主です。
「Cookie Name Prefixes」は、一回払い出したCookieが、どこでどのように属性が変わったかサーバー側からは検知できないので、クライアント側で属性が変わらないよう強制するものです。google.com などにアクセスすると、このようなCookieが入ってくることが確認できます。
2つ目のSameSite属性は、Cookieの共有範囲を同じサイトに限定するオプションです。
3つ目は非セキュアサイトからのsecure属性の上書きを禁止するものです。今まではセキュア属性の付いたCookieをセキュアではないURLから上書きできたので、たとえば、HTTPSで https://example.com にアクセスした時に、中間者攻撃で http://example.com にアクセスさせることが可能でしたが、これができなくなります。これらの機能追加3つは主なブラウザにすでに実装されています。その他、曖昧だった挙動の修正があります。
CookieといえばサードパーティーCookieの制限の話がホットですが、この仕様改訂版には含まれていない話でChromeチームの方々が提案しているCHIPSという機能があります。追加機能として現在IETFで別途ディスカッションされています。
「HTTP Compression Dictionary」も個人的に好きな仕様で、一度読み込んだリソースをdeflateというアルゴリズムの辞書として利用するという提案です。現在ChromeチームがIETFで提案しています。ユースケースとして、JavaScriptで1行だけ書き換えたなど差分の少ないファイルがある時に有効です。読み込んだファイルを辞書データとしてブラウザが保存しておきます。新しいデータを読み込む時は、辞書に登録されているのでデータ圧縮率が高くなります。実証実験で圧縮率が95%でした。WebコンテンツのJSやCSSなどが全部書き換わることはそう多くないので、かなりの圧縮率が得られると考えられます。
もう少しマニアックな機能では、「Secondary Certificate」があります。コネクションが確立した後に、サーバー側から追加の証明書を提供する機能で、HTTP/2や/3では、一度確立したワイルドカード証明書を再利用して A.example.com も、B.example.com も提供できます。アイソレーションの都合上、ブラウザがこの機能をサポートするのかどうかは未定ですが、このような提案が出ています。
HTTPヘッダに構造を定義、QUIC支援
また、「Structured Field Values」（SFV）という仕様改訂版も動いています。RFC 8941の改訂版です。そもそもSFVは、HTTPヘッダに構造というものを与えます。Example-List:とするとこれはリストである、Dictを付けると辞書データであるなど、データ構造をHTTPヘッダに定義して、パースアルゴリズムや実装を再利用できるようにするのがこのSFVです。
google.com などにアクセスすると、ゼロが付いたヘッダが返ってくることがありますが、これがまさにSFVのブーリアン型を持ったヘッダ値です。
改訂版では日付データのDateや、データにUTF、非ASCII文字を含むことを示すDisplayStringという構造が新しく定義されています。
最後に、個人的に結構気に入っているスペックをご紹介します。IPV4とV6を両方試して早く繋がった方を使うフレームワーク、Happy Eyeball v3です。IETFでディスカッションしているHTTP/3ではトランスポートプロトコルとして、新しくQUICを使いますが、必ずしも100パーセント疎通するわけではないので、順番に試行していく必要があります。その試行の順番を定義してより早くウェブサーバーに接続できるようにしようというのが今回のHappy Eyeball v3という仕様です。
ここで紹介できなかった提案仕様も含めて、HTTPにはまだまだ楽しいトピックがたくさんあるので、引き続き今日のセッションを楽しんでください。
