処理中のPOSTリクエストを別のサーバで引き継ぐPartial POST Replayについて

なんらかの理由でWebサーバを停止する場合に、処理中のPOSTリクエストをそのまま別のサーバで引き継げるようにする「HTTP Partial POST Replay」という仕様がFacebookのAlan Frindell氏から提出されています (HTTP Workshopの資料はこちら)。

スポットインスタンスを利用していたり、サーバの設定を変えて再起動したい場合、新しいリクエストは受け付けないようにし、すでに来ているリクエストのみ処理をするのは一般的です。それでも大きなファイルをアップロードしているPOSTリクエストは処理が終わるまで時間がかかってしまう場合がありあります。

やむをえずPOSTリクエストの処理を中断してしまうと、ユーザは再度大きなファイルをアップロードしなおす必要があり、とてもストレスがかかります。

「HTTP Partial POST Replay」では、ユーザの接続を切ることなく別のサーバでPOSTリクエストを引き継ぐことができます。

Partial POST Replay

ひとことで「HTTP Partial POST Replay」の説明をすると、POSTリクエストを処理しているWebサーバがリバースプロキシまで処理中のリクエストを差し戻し、別のサーバで改めて続きを処理します。そのため、構成としてはPartial POST Replayに対応したリバースプロキシがいる前提となります。

クライアントとProxy間の接続は切断することなく、処理を引き継ぐことができます。

流れ

処理の引継ぎを行うWebサーバはPOSTリクエストに対して「3xx Partial POST Replay」(ステータスコードは未定)を返します。このHTTPレスポンスには、Webサーバが引き継ごうとしているHTTPリクエスト情報が格納されています。リクエストヘッダと疑似ヘッダは、echo-というプレフィクスをつけてレスポンスヘッダに格納されます。POSTしていたデータはレスポンスボディに格納されています。

このレスポンスを受け取ることで、Proxyは元のリクエストと現時点でPOSTされているデータを復元することができます。

Proxyは復元できたPOSTリクエストを別のWebサーバに割り振りなおします。このときクライアントとのコネクションは切断することなく、送信されてくるデータはProxyがバッファリングし続けています。

また、再度同じWebサーバに割り振られるのを防ぐために、partial-post-replayリクエストヘッダをつけることで、Partial POST Replayであることを明示します。

Cross-Origin-Embedder-Policyヘッダについて

ChromeがCross-Origin-Embedder-Policy (COEP)の実装に着手しそうなので、ざっと仕様を眺める(議論段階であり、正式な仕様ではありません)
mikewest.github.io

ちょっと話が難しいので間違ってたらすみません。

なお以前は、仕様名は「Cross-Origin-Resource-Policy-Policy(CORP-P)」などとも呼ばれていた。仕様自体の議論や、名称の変遷については下記Issueを参照のこと
Opting into a CORS-only mode (Cross-Origin) · Issue #4175 · whatwg/html · GitHub

Cross-Origin-Embedder-Policy

Spectre攻撃以後、サイドチャネル攻撃を用いてメモリの内容を推測できる場合、Same-Originポリシーは十分ではないことがわかっています。つまり、ブラウザにクロスオリジンのリソースを読み込ませることに成功すれば、内容を推測できる可能性が出てきたわけです。

Cross-Origin-Embedder-Policyヘッダでは、埋め込むリソースがCross-Origin-Resource-Policyを明示するように強制します。また、そのためにCross-Origin-Resource-Policy: same-site (仕様上だとcross-originという表記もある)を指定できるように拡張します。

CORP自体は以前書いたとおりです
asnokaze.hatenablog.com

このドキュメントでは変更に合わせ、HTMLやFetchの仕様に対してモンキーパッチを当てています。

流れ

ブラウザは、example.comからhtmlファイルを読み込みます。このとき、レスポンスにCross-Origin-Embedder-Policy:require-corpヘッダがついています。これによって、サブリソースは Cross-Origin-Resource-Policyが必須になります。

サブリソースのレスポンスにCross-Origin-Resource-Policy:cross-siteとクロスオリジンでの読み込みを明示すると、ブラウザはそのリソースを読み込めるようになります。

安全なコンテンツを要求するPrefer:safeヘッダ （RFC8674）

『追記』RFC 8674になりました
https://www.rfc-editor.org/rfc/rfc8674.html

---

Webサービスによっては、子供に見せたくない有害なコンテンツを非表示にできるサービスもあります。

それの多くはcookieを使い、設定を保存するケースが多く個別に設定を有効にしていく必要があります。また、広告といった設定がし辛い部分もあります。

こういった要求をブラウザの設定でできるように、「The "safe" HTTP Preference」という提案がMark Nottingham氏から出されています。

この提案仕様は、「rfc7240 Prefer Header for HTTP」で定義されている、preferヘッダPreference-Appliedヘッダを使用します。

Prefer: safe

この仕様では、以下のように「Prefer: safe」をヘッダに指定することで安全なコンテンツを要求していることを示します。

   GET /foo.html HTTP/1.1
   Host: www.example.org
   User-Agent: ExampleBrowser/1.0
   Prefer: safe

もちろん、サーバが対応しているか、その要求を尊重するかは実装次第です。サーバはPreference-Appliedヘッダを使うことで、その要求を適応したことを示せます。

   HTTP/1.1 200 OK
   Transfer-Encoding: chunked
   Content-Type: text/html
   Preference-Applied: safe
   Server: ExampleServer/2.0
   Vary: Prefer

標準化

もちろん、安全なコンテンツを明確に仕様化することは難しいです。この提案仕様でもその曖昧性のためIESGからの承認が得られず標準とはなっていないと述べられています。

しかし、すでに実装があり有用性の観点からドキュメントとして提出されています。

実装

• Microsoft Internet Explorer https://support.microsoft.com/en-hk/help/2980016/
• Microsoft Bing https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/familysearch/
• Mozilla Firefox https://support.mozilla.org/en-US/kb/block-and-unblock-websites-parental-controls-firef
• Cisco - see http://blogs.cisco.com/security/filtering-explicit-content

サービスやリソースの廃止時間を示すSunset HTTP ヘッダ (RFC8594)

Webサービス、古いバージョンのWeb API、期限付きのデータなど、そのURLで提供しているリソースが将来的に廃止するということはよくあることです。

RFC 8594 「The Sunset HTTP Header Field」では、そのようなリソースの廃止時間をHTTPレスポンスヘッダで示せるようになります。

ただしこれはヒントに過ぎず、示した時間までの提供を保証するものではありません。

例

2016年から、10年間のみ保存されるデータなどには、下記のようなレスポンスヘッダをつけることで、2026年にリソースが取得できなくなることを示すことができます。
(フォーマットは、RFC7231 の通り 「Date/Time Formats」)

Sunset: Wed, 11 Nov 2026 11:11:11 GMT

廃止に関する追加の情報は、Linkヘッダで示すことができます。relation typeとして sunsetを指定します。

Link: <http://example.net/sunset>;rel="sunset";type="text/html"

このポリシーの中では、廃止の範囲(リクエストを受けたURLだけなのか、それとももっと広い範囲なのか)、廃止後の移行先などを書けます。

Cookie の SameSite=Lax をデフォルトにする提案仕様

20191226 追記
SameSite属性のついたCookie自体を拒否する古いクライアントにご注意ください
https://sites.google.com/a/chromium.org/dev/updates/same-site/incompatible-clients

20190823 追記
suidenOTI さまよりご指摘いただきました

不具合があったためChrome80でのリリースに延期になったようです。
https://www.chromestatus.com/feature/5088147346030592
https://www.chromestatus.com/feature/5633521622188032

20190523 追記
Firefoxでも同様の動きがあります
https://groups.google.com/forum/#!msg/mozilla.dev.platform/nx2uP0CzA9k/BNVPWDHsAQAJ

---

開催中のGoogle I/O で、SameSite属性のないCookieをSameSite=Laxとして扱うようにしていくという話があったようです
blog.chromium.org

SameSite=Laxになると、img, iframeやxhrなど送信される他サイトへのHTTPリクエストにおいてthird party cookieがつかなくなります。これによって、cookieの露出を控える事ができます。(SameSite = None とすることで引き続きトラッキングは可能)

Googleの調査によると SameSite属性のついたCookieはまだ0.1%以下であり、まだまだ普及できておらず、今回デフォルトでSameSite=Laxとする動きになったのだと思います。

この挙動は、すでにChrome Canaryでchrome://flagsより設定することができます。

提案仕様

また、上記のアナウンスに続いて、IETF側でもGoogleのMike West氏より「Incrementally Better Cookies」という提案仕様が出ております。

同氏がメーリングリスト投げた「Incremental improvements to cookies.」でも書かれている通り、Cookieを段階的に改善しようとしており、この仕様では

• 1. デフォルトで、Cookieを「SameSite = Lax」として扱う
• 2. 開発者が明示的に `SameSite = None`を設定することにより現状の振る舞いのようにできるが、そうするときは` Secure`属性が必要

にするという提案である。

同氏の関連活動

Mike West氏は、Cookieに関わる多くの改善を提案している

SameSite属性の仕様自体は「Same-Site Cookies」で書かれているが、下記の記事の通り、RFC6265bisに統合される流れである
asnokaze.hatenablog.com

また、新しい仕組みも検討中であったが、フィードバックをうけCookieを段階的に改善しようという流れのようだ
asnokaze.hatenablog.com

Cross-Origin-Opener-Policyについて

Cross-Origin-Opener-Policy (COOP)は現在、ChromeやFirefoxで実装が進められている機能です。

• Chrome: Implement Cross-Origin-Opener-Policy
• firefox: Implement Cross-Origin-Opener-Policy

仕様としては、whatwgで長らく議論がされており、おそらく仕様に入るでしょう

• Restricting cross-origin WindowProxy access (Cross-Origin-Opener-Policy) · Issue #3740 · whatwg/html · GitHub
• Cross-Origin-Opener-Policy: provide a clearer spec. · Issue #4580 · whatwg/html · GitHub

面白そうなので、簡単に読んで見る。今の所下記ドキュメントが定義のようだが、適宜議論を参照のこと

• coop.md · GitHub

間違ってたらご指摘ください

Cross-Origin-Opener-Policy とは

ユーザがサイトAを閲覧しているとき

サイトA から サイトBをウィンドウとして開いた場合 (noopnerはつけてない)、Bはwindow.openerを介してAにアクセスすることができます（仮にAとBのオリジンが違っていても、制限はありますがAのプロパティにアクセスできます。）

このようなアクセスは、サイトのアイソレーション上好ましくありません。このようなことを防ぐために、Cross-Origin-Opener-Policyヘッダを利用します。もし、指定されたPolicyに合わない場合は、上記のような繋がりは解除されます(ウィンドウを閉じて開き直したのと同じ状態)

Cross-Origin-Opener-Policyは下記のような値を取ります。

Cross-Origin-Opener-Policy = same-origin
Cross-Origin-Opener-Policy = same-site
Cross-Origin-Opener-Policy = same-origin unsafe-allow-outgoing

A及び、Bそれぞれへのアクセスした際はポリシーに合わず、openerがnullを返すようになります

• Aもしくは、BのどちらかのみにレスポンスヘッダでCross-Origin-Opener-Policyが設定される
• AとBのCross-Origin-Opener-Policyのsameness (same-origin or same-site)が異なる
• 値がsame-originだが、AとBのオリジンが異なる
• 値がsame-siteだが、AとBのホスト名が異なる

こうすることで、noopenerを指定できる開く側だけでなく、開かれる側からもopenerのつながりを解除することができるようになります。(unsafe-allow-outgoingを指定すると開く側のときだけ許可する)

おまけ

議論の変遷のなかで、openerのポリシーへとヘッダ名とともに変遷しており、議論を追うのが大変だった...

• Cross-Origin-Options
• Cross-Origin-Isolate
• Cross-Origin-Window-Policy

新しいWebの双方向通信 "WebTransport" について

関連記事

• WebTransport over QUICのサンプルサーバを試してみる - ASnoKaze blog
• WebTransport over HTTP/2 の仕様について - ASnoKaze blog
• WebTransport over QUIC について - ASnoKaze blog

---

WebTransportという新しい双方向通信フレームワークの議論が始まっている。

GoogleのPeter Thatcher氏らによって、W3C WICGにプロポーザルが投げられています。
discourse.wicg.io

WebTransportは、WebSocketのようなAPIをもち、QUICやHTTP/3上で多重化されたストリームを利用し、ヘッドオブラインブロックのない通信を行えるようにするというのがモチベーションのようです。（実際に使用する"トランスポート"はプラガブルな設計になっている）

また、TCPとは異なり、パケロスしても再送を行わないPartial reliabilityなども使えるようになる。そのようなAPIも改めて定められる。

その他にもコネクションのマイグレーションをサポートしているトランスポートであればIPが変わってもコネクションを維持できる。

WEBRTC-QUICで同様のことは可能だが、ICEを必要とせずクライアント・サーバの通信ユースケースに絞っている。

QUICについては以前簡単に書いたとおり
asnokaze.hatenablog.com

仕様

すでにAPIとプロトコルの仕様が書かれている。

API

「WebTransport」として、WebRTC-QUICのリポジトリ下に、APIに関する仕様が書かれている。

その中で書かれている例の一つをとりあげると、再送を行わないメッセージの送信は以下のようになっている。

let transport = getTransport();
let messages = getMessages();
for (msg in messages) {
  transport.createSendStream({disableRetransmissions: true}).write({data: msg, finished: true});
}

プロトコル

プロトコルの仕様としてすでに下記の3つのドキュメントがIETFに提出されている。

• The WebTransport Protocol Framework
• WebTransport over HTTP/3
• WebTransport over QUIC

１つ目は概要であり、WebTransportのトランスポートが持つ機能要件について書かれている。

例えば、データ通信としてストリーム方式・データグラム方式を持つ（パケットのデータ境界をアプリケーション側で維持するか）などである。

その他にも追加の機能として、トランスポートのストリームの独立性、Partial reliability、コネクションプール (1つのコネクションを再利用し輻輳制御を行える)、Connection mobility (IPが変わってもコネクションが維持可能)といった項目だしを行っている。

2つ目と3つ目はそれぞれ、WebTransportをHTTP/3、QUIC上で行えるようにする仕様を定義している。特にHTTP/3ではサーバからストリームを開始できるうようにWebTransport用のストリームを定義している他、追加のフレームも定義している。

(詳細は機会があればまた今度)

リンク

vせんせいも、WebTransportついて書かれております
medium.com