Protocols

Tech / 16 Sep 2026 / 6 min read

TCP TIME-WAIT Preserves Closed Connection State

A TCP endpoint can finish an application’s close operation while the protocol still retains state for that connection. After an active close completes its FIN exchange, the endpoint normally enters TIME-WAIT instead of discarding the connection record immediately. That retained state has two jobs. It leaves the endpoint able to acknowledge a retransmitted final FIN, and it separates a closed connection from a later incarnation that could use the same local and remote addresses and ports.

TCP Networking

Software Engineering / 16 Sep 2026 / 7 min read

If-Range Prevents Mixed-Representation Resumes

A resumed HTTP transfer can corrupt a local result without any malformed bytes if the resource changes between requests. The first response may supply bytes from one representation while a later range response supplies offsets from another. If-Range exists to bind the resumed range to the representation that produced the stored prefix. This is a representation-identity problem rather than a transport-framing problem. Byte offsets only have stable meaning relative to a particular representation. A syntactically valid 206 Partial Content response can still be unusable for recombination when its bytes belong to a different version.

Software Engineering HTTP

Software Engineering / 16 Sep 2026 / 8 min read

HTTP 425 Keeps Replay-Sensitive Requests Out of TLS Early Data

TLS 1.3 can carry application data before a resumed handshake completes, which means an HTTP request can reach server processing earlier than the connection has its final handshake state. That latency optimization changes a security property: early data can be replayed, so a request that is safe to execute once can become unsafe when the same bytes are accepted more than once. HTTP status 425 Too Early marks the boundary between transport acceptance and application acceptance. A server can accept TLS early data at the connection layer yet decline to process a particular HTTP request from that data. The client can then retry after the handshake completes, where the early-data replay condition no longer applies.

Software Engineering HTTP

Software Engineering / 15 Sep 2026 / 7 min read

TCP Half-Close Separates the Two Stream Directions

A TCP peer can reach end-of-stream on incoming data while its outgoing stream remains usable. The event is directional: a FIN closes one side’s sending direction after previously queued bytes, but it does not require the opposite direction to close at the same instant. That property is easy to hide behind APIs that expose a connection as one object with a single close operation. At the protocol boundary, however, TCP carries two byte streams in opposite directions. A half-close makes the distinction visible and gives application protocols a useful signal: one participant can state that its request body is complete while still accepting a response.

Software Engineering Networking

Software Engineering / 15 Sep 2026 / 8 min read

Expect 100-Continue Defers Request Body Transfer

An HTTP/1.1 client can send request headers containing Expect: 100-continue and hold back the request body while the server evaluates those headers. The server can answer with 100 Continue, allowing body transfer to proceed, or send a final response when it can reject the request without receiving the payload. This splits one request into a metadata decision boundary followed, conditionally, by body transmission. The mechanism matters most when a request body is costly to transmit and the server can make a useful decision from request metadata alone. Authentication failure, an unsupported method, or another header-visible rejection can terminate the exchange before those bytes cross the connection. The same split also creates a timing dependency: a client cannot wait forever for an interim response, and servers and intermediaries must preserve the protocol semantics closely enough for progress.

Software Engineering HTTP

Python / 01 Sep 2026 / 5 min read

Python Protocols and Structural Subtyping for Flexible APIs

Python code often depends on behavior rather than a specific class hierarchy. A function may only need an object with a send() method, a read() method, or a pair of repository operations. typing.Protocol lets type checkers describe those behavioral requirements directly. A class satisfies a protocol by having compatible members; it does not need to inherit from the protocol. This is structural subtyping: “if it has the required shape, it can be used here.”

Python Typing