https://blog.yusukeikoma.com/ja/tags/http/Recent content in http on Ikoma's BlogHugoja-jpThu, 10 Sep 2026 11:23:25 +0900https://blog.yusukeikoma.com/ja/posts/websocket-origin-check-is-not-authentication/Thu, 10 Sep 2026 11:23:25 +0900https://blog.yusukeikoma.com/ja/posts/websocket-origin-check-is-not-authentication/WebSocket のハンドシェイクにある Origin ヘッダーは、ブラウザが付けるもので、それ以外のクライアントは好きな値を送れます。許可リストが守るのは、Cookie 認証のブラウザセッションが他のサイトから使われることで、接続してきた相手が誰かは証明しません。動くサーバー、実ブラウザでの攻撃、そこから導かれるハンドシェイクの規則を示します。https://blog.yusukeikoma.com/ja/posts/http2-timeout-stream-vs-connection/Tue, 08 Sep 2026 12:56:00 +0900https://blog.yusukeikoma.com/ja/posts/http2-timeout-stream-vs-connection/たくさんのリクエストを同時に流している1本の接続で、1つのリクエストの期限が来たとき、接続ごと閉じるべきか、そのリクエストだけを閉じるべきか。小さなNodeの実験では、HTTP/2のセッションを閉じると無関係な2本が失敗し、ストリームだけをキャンセルすると同じTCP接続のまま2本とも完了しました。ただし、TCPの1パケットの遅れは接続上の全ストリームを止めます。その場合に接続の生死を確かめる方法として、PINGを使った確認も試します。https://blog.yusukeikoma.com/ja/posts/resumable-streams-cursors-last-event-id-snapshots/Fri, 04 Sep 2026 19:26:37 +0900https://blog.yusukeikoma.com/ja/posts/resumable-streams-cursors-last-event-id-snapshots/再接続したクライアントが、状態を取りこぼさず、重複せず、履歴を読み直さずに追いつく方法を、「全部読み直す」から「上限つきのログとスナップショットのフォールバック」まで、版0から版4まで段階的に組み立てます。ブラウザの EventSource が再接続時と non-200 応答のときに実際に何をするか、スナップショットの順序のバグ、決定木も扱います。https://blog.yusukeikoma.com/ja/posts/exactly-once-delivery-idempotency-and-backoff/Fri, 28 Aug 2026 10:07:45 +0900https://blog.yusukeikoma.com/ja/posts/exactly-once-delivery-idempotency-and-backoff/リクエストがタイムアウトしたとき、クライアントはリクエストが失われたのか、確認応答だけが失われたのかを区別できません。だから「ちょうど1回」の配送は作れず、実際にできるのは「少なくとも1回の配送」と「重複を除く受け手」の組み合わせです。不安定なネットワークでの実験、正しく見えて89件を重複させるバグ、原子的な重複排除ストア、ジッターのシミュレーションで確かめます。