Incremental HTTP

Transcript

1. Incremental HTTP Kazuho Oku
2. 新しいRFCが出ました • RFC 10036: Incremental Forwarding of HTTP Messages • 発行: August 2026 • 著者: ◦ Kazuho Oku, Fastly ◦ Tommy Pauly, Apple ◦ Martin Thomson, Mozilla
3. 通常のHTTP POST 200 OK クライアント サーバ
4. 早期 (early) レスポンス POST 200 OK クライアント サーバ
5. 通常のHTTPによる双方向通信 POST 200 OK クライアント サーバ
6. イベント通知 POST 200 OK イベント発生！ クライアント サーバ
7. 背景にある期待 • リクエストやレスポンスを徐々に送受信 (インクリメンタル ) ◦ vs. 完成するまでバッファリング POST POST 200 OK 200 OK イベント発生！ クライアント サーバ クライアント サーバ
8. インクリメンタル HTTPの使用例 • • • • • Server-sent Events gRPC (streaming) Resumable Uploads Chunked OHTTP …
9. インクリメンタル HTTPの使用例 • • • • • Server-sent Events gRPC (streaming) Resumable Uploads Chunked OHTTP … プロ る な 異 と P 方 T 双 T H て 」し tは e ド k ー c So グレ . b e プ ッ W .. ア 「 み に トコル を行う仕組 向通信
10. インクリメンタル HTTPの使用例 • • • • • Server-sent Events gRPC (streaming) Resumable Uploads Chunked OHTTP … プロ る な 異 と P 方 T 双 T H て 」し tは e ド k ー c So グレ . b e プ ッ W .. ア 「 み ね に トコル を行う仕組 どくさいよ ん 向通信 どアレめ … だけ
11. インクリメンタル HTTPって危ないんじゃないの？ なんで、危なくないよ だって合法なの？ もちろん合法だよ なんで？ だってインクリメンタルということはリクエストレスポ ンスじゃないんでしょ？ 違うよ。全然違うよ
12. インクリメンタル HTTPは合法なの ? An HTTP message can be parsed as a stream for incremental processing or forwarding downstream. However, senders and recipients cannot rely on incremental delivery of partial messages, since some implementations will buffer or delay message forwarding for the sake of network efficiency, security checks, or content transformations. RFC 9110 Section 7.6 訳: HTTPメッセージの送受信において、部分的なメッセージの逐次配送を前提とする ことはできない。なぜなら、効率化やセキュリティチェック、コンテンツ変換などのため にメッセージをバッファリングしたり、転送を遅延させるHTTP実装も存在するからであ る
13. インクリメンタル HTTPは合法なの ? An HTTP message can be parsed as a stream for incremental processing or forwarding downstream. However, senders and recipients cannot rely on incremental delivery of partial messages, since some implementations will buffer or delay message forwarding for the sake of network efficiency, security checks, or content transformations. 存在しない限り動く！ 存在したらタイムアウトとか ... RFC 9110 Section 7.6 訳: HTTPメッセージの送受信において、部分的なメッセージの逐次配送を前提とする ことはできない。なぜなら、効率化やセキュリティチェック、コンテンツ変換などのため にメッセージをバッファリングしたり、転送を遅延させるHTTP実装も存在するからであ る
14. インクリメンタル HTTPは合法なの ? • まあでも動く環境も多い ◦ 特に開発中の環境は単純でプロキシとかないし ... • 結果、実装しちゃって、デプロイしたあとで問題発覚 • どうなるかと言うと ...
20. Syntax: proxy_request_buffering on | off; Default: proxy_request_buffering on; Context: http, server, location This directive appeared in version 1.7.11. Enables or disables buffering of a client request body. When buffering is enabled, the entire request body is read from the client before sending the request to a proxied server. When buffering is disabled, the request body is sent to the proxied server immediately as it is received. In this case, the request cannot be passed to the next server if nginx already started sending the request body. from Nginx documentation
21. 現在の状況 : lose-lose • アプリはインクリメンタルな挙動を使いたい ◦ 設計が単純になるため
22. 現在の状況 : lose-lose • アプリはインクリメンタルな挙動を使いたい ◦ 設計が単純になるため • プロキシはインクリメンタルをデフォルトにしたくない ◦ セキュリティや効率上の理由 ▪ cf. Slowloris攻撃
23. 現在の状況 : lose-lose • アプリはインクリメンタルな挙動を使いたい ◦ 設計が単純になるため • プロキシはインクリメンタルをデフォルトにしたくない ◦ セキュリティや効率上の理由 ▪ cf. Slowloris攻撃 • 結果：インクリメンタルに依存するアプリをプロキシ経由で 使おうとするたびに問題が発生し、原因調査の上、アプリ の再設計かプロキシの設定検討が必要に
24. 問題の所在 • 保証外の使い方をする人が悪いのか ?
25. 問題の所在 • 保証外の使い方をする人が悪いのか ? ◦ 悪いと言ったところで問題は解決しない
26. 問題の所在 • 保証外の使い方をする人が悪いのか ? ◦ 悪いと言ったところで問題は解決しない ◦ 便利な使い方だからこそ、同じことをやる人が出現
27. 問題の所在 • 保証外の使い方をする人が悪いのか ? ◦ 悪いと言ったところで問題は解決しない ◦ 便利な使い方だからこそ、同じことをやる人が出現 • それなら、やりやすくすればいいのでは ?
28. 問題の所在 • 保証外の使い方をする人が悪いのか ? ◦ 悪いと言ったところで問題は解決しない ◦ 便利な使い方だからこそ、同じことをやる人が出現 • それなら、やりやすくすればいいのでは ? ◦ インクリメンタルに使いたいという要求と ◦ それに対する拒否応答を HTTPプロトコルの拡張として定めればいい
30. で、俺が産まれたってわけ (RFC 10036)
31. RFC 10036 • インクリメンタルな転送が必要な場合 : Incremental: ?1 というHTTPヘッダをつける
32. RFC 10036 • インクリメンタルな転送が必要な場合 : Incremental: ?1 というHTTPヘッダをつける • プロキシは、このヘッダを認識したにもかかわらず、インク リメンタルに転送ができない場合 : ◦ 501 Not Implemented - 永続的な拒否 ◦ 429 Too Many Requests - 一時的な拒否 応答を返す
33. 結果: win-win • Incremental拡張に対応したプロキシが増えていけば、 相 互運用性が改善 • インクリメンタルな挙動に依存するアプリを作りやすく ◦ 双方向通信も HTTPで • プロキシはヘッダをみて挙動を変えられるので、設定変更 が不要に
34. まとめ • リクエストをインクリメンタルにサーバに届けたい → Incremental: ?1 をリクエストにつける • レスポンスをインクリメンタルにクライアントに届けたい → Incremental: ?1 をレスポンスにつける • HTTP POSTで双方向通信 → Incremental: ?1 をリクエストレスポンス両方につける
35. まとめ • リクエストをインクリメンタルにサーバに届けたい → Incremental: ?1 をリクエストにつける • レスポンスをインクリメンタルにクライアントに届けたい → Incremental: ?1 をレスポンスにつける • HTTP POSTで双方向通信 → Incremental: ?1 をリクエストレスポンス両方につける • プロキシは Incrementalに対応して！
36. まとめ • リクエストをインクリメンタルにサーバに届けたい → Incremental: ?1 をリクエストにつける • レスポンスをインクリメンタルにクライアントに届けたい → Incremental: ?1 をレスポンスにつける • HTTP POSTで双方向通信 → Incremental: ?1 をリクエストレスポンス両方につける • プロキシは Incrementalに対応して！ 向通 方 双 も て く ゃな じ t e k c o S Web て ... っ れ そ 信できる！
37. まとめ I D T • リクエストをインクリメンタルにサーバに届けたい → Incremental: ?1 をリクエストにつける • レスポンスをインクリメンタルにクライアントに届けたい → Incremental: ?1 をレスポンスにつける • HTTP POSTで双方向通信 → Incremental: ?1 をリクエストレスポンス両方につける • プロキシは Incrementalに対応して！ 向通 方 双 も て く ゃな じ t e k c o S Web て ... っ れ そ 信できる！ W O T M T
38. W O T TM I D T 私たちが Perlを引退しても Perlの精神は永久に不滅です！！