http on Ikoma's Bloghttps://blog.yusukeikoma.com/tags/http/Recent content in http on Ikoma's BlogHugoen-usThu, 10 Sep 2026 11:23:25 +0900A WebSocket Origin Check Blocks Other Websites, Not Other Clientshttps://blog.yusukeikoma.com/posts/websocket-origin-check-is-not-authentication/Thu, 10 Sep 2026 11:23:25 +0900https://blog.yusukeikoma.com/posts/websocket-origin-check-is-not-authentication/The Origin header on a WebSocket handshake is set by browsers and can be set to anything by every other client. So an allow-list protects a cookie-authenticated browser session from other sites, and it proves nothing about who is connecting. A runnable server, a real headless-browser attack, and the handshake rule that follows.Cancel the Stream, Not the Connection, When One HTTP/2 Request Times Outhttps://blog.yusukeikoma.com/posts/http2-timeout-stream-vs-connection/Tue, 08 Sep 2026 12:56:00 +0900https://blog.yusukeikoma.com/posts/http2-timeout-stream-vs-connection/A request deadline fired on a connection that carries many requests at once. Do you close the connection, or only the request? In a small Node lab, closing the HTTP/2 session failed two innocent requests, while cancelling only the stream let them finish on the same TCP connection. The same lab shows the one case where cancelling is not enough: a lost packet stalls every stream on a TCP connection, and a connection-level PING is the right way to tell.Resuming an Event Stream with a Cursor, a Bounded Log and a Snapshothttps://blog.yusukeikoma.com/posts/resumable-streams-cursors-last-event-id-snapshots/Fri, 04 Sep 2026 19:26:37 +0900https://blog.yusukeikoma.com/posts/resumable-streams-cursors-last-event-id-snapshots/How a client catches up after a reconnect without losing state, without duplicates, and without re-reading history. Built in steps (versions 0 to 4), from “read everything again” to a bounded log with a snapshot fallback, with what a real browser’s EventSource does on reconnect and on a non-200 response, a snapshot-ordering bug, and a decision tree.Retries Duplicate Your Writes, and Exactly-Once Won't Save Youhttps://blog.yusukeikoma.com/posts/exactly-once-delivery-idempotency-and-backoff/Fri, 28 Aug 2026 10:07:45 +0900https://blog.yusukeikoma.com/posts/exactly-once-delivery-idempotency-and-backoff/When a request times out, the client cannot tell whether the request or only its acknowledgement was lost. This is why exactly-once delivery cannot be built, and why effectively-once processing is at-least-once delivery plus a receiver that deduplicates. A runnable experiment with a flaky network, the bug that still duplicates 89 of 200 requests, an atomic dedupe store, and a jitter simulation.