Topic: http
-
Using HTTP status codes correctly: the client's first branching point
Clients, caches and agents decide on the status code alone whether to retry, reload or give up: 201/204 for success with and without a body, 401 versus 403 for missing authentication versus missing permission, 409/412/428 for conflicts and preconditions, 429 and 503 with Retry-After for "later". A 200 with an error object misleads all of them.
-
Honor Retry-After as a lower bound
Schedule retries from either form of Retry-After while preserving the task deadline and avoiding premature repeated requests.
-
Backing off as a client: Retry-After, RateLimit headers and per-host budgets
How an agent should react to 429 and 503 responses and to advisory rate-limit headers: honour Retry-After exactly, otherwise back off exponentially with jitter, read the RateLimit and RateLimit-Policy fields where a server sends them to pace ahead of the limit, keep a budget per host and per key, and never retry a non-idempotent write without an idempotency key.
-
Response compression: where to do it and what to exclude
Compress text responses (HTML, JSON, Markdown) at the proxy or the application, skip already-compressed and streaming content, keep ETags honest across encodings, and set Vary: Accept-Encoding.
-
Distributed tracing at a glance: spans, parent IDs, and W3C Trace Context
A trace is a tree of spans, each with a trace ID, its own span ID, a parent span ID, timestamps, attributes, and a status. The W3C traceparent header carries the trace ID, parent ID, and a sampled flag across process boundaries, and a service that merely forwards both headers still keeps traces intact.
-
Custom 404 pages and soft 404s: serve the error page with the error status
A custom 404 page helps users only if it is served with status 404; a not-found page served with 200 is a soft 404 that crawlers keep fetching and search engines exclude. nginx's error_page can rewrite the status (error_page 404 =200 ...), which is exactly how soft 404s are created by accident; keep the status, make the page useful, and check with curl -I.
-
The Same-Origin Policy: what an origin is and what it isolates
An origin is the scheme, host and port of a URL. Script may read and modify same-origin documents, storage and responses; cross-origin reads are blocked by default, while cross-origin writes such as form submissions and embedding such as images and scripts are generally allowed. CORS relaxes reads; CSRF defences are still needed.
-
Using fetch with timeouts and AbortController
A fetch promise rejects only on network failure, not on HTTP error status, and it has no timeout by itself. Pass an AbortSignal combined from AbortSignal.timeout and a caller's controller, check response.ok, and tell TimeoutError, AbortError, network errors and HTTP errors apart in the catch.
-
Designing idempotent operations and safe retries
An operation is idempotent if executing it several times has the same effect as executing it once; RFC 9110 defines this for HTTP methods, and an Idempotency-Key header extends the property to POST. Store each key with a request fingerprint and the result, report conflicts with 409 and 422, and delete keys after a documented retention period.
-
Server-sent events versus WebSockets
Server-sent events stream text events from server to client over plain HTTP with automatic reconnection and last-event IDs; WebSockets provide a bidirectional binary-capable channel with its own protocol. Choose SSE for one-way updates and WebSockets when the client must send frequently.
-
Calling the TypeSafe API from an agent: request shape, errors, retries and version pinning
The documented contract an agent needs to call Jev without a chat layer: POST /v1/systemone with a Bearer key, a state, a model name and a map of typed questions; answers keyed like the questions plus a usage block; 401, 422, 429 and 529 with exponential backoff; aliases that move and versioned IDs that do not; SDK defaults for retries and the agent skill for coding agents.
-
The Link header and link relation types
RFC 8288 lets any HTTP response carry typed links in a Link header: <target>; rel="relation" plus optional anchor, hreflang, type, title and media parameters. Relation names come from the IANA registry (next, prev, canonical, alternate, describedby, preload) or are absolute URIs for private extensions. It is how non-HTML responses point to their neighbours and how 103 Early Hints tells a browser what to fetch early.
-
Web Push basics: subscriptions, VAPID keys and the push service
A browser subscribes with its vendor's push service and hands the page an endpoint plus keys; the application server POSTs encrypted messages to that endpoint with a TTL header and a VAPID JWT (ES256, aud = push service origin, exp at most 24 hours) whose public key was passed to PushManager.subscribe as applicationServerKey. A 201 means accepted, not delivered.
-
Sitemaps and canonical URLs: one piece of content, one address
Each piece of content should have exactly one canonical HTTPS address, declared on the page itself. Twin versions such as Markdown or JSON point to it via a Link header, parameters that do not change the content create no new addresses, and the sitemap lists only canonical addresses with truthful modification dates.
-
HEAD and OPTIONS: what they answer and what clients use them for
HEAD is GET without the body: same status and headers (Content-Length and Vary may be omitted), cacheable, used for link checking, size probes and freshness checks. OPTIONS asks which communication options a resource or the whole server (OPTIONS *) supports, is typically answered with Allow, is not cacheable, and carries CORS preflights with Access-Control-Request-Method.
-
URL shortener walk-through: key generation, redirect status and abuse controls
A design walk-through for a URL shortener: random base62 keys with collision retry, a redirect path that touches one cache and one store, 302 rather than 301 when targets must stay revocable and countable, creation-side abuse checks, and a list of what not to build first.
-
Collapsing redirect chains to single hops raises the share of crawler requests that end in a 200 on a large site
Hypothesis: on a site with tens of thousands of URLs and accumulated redirects, rewriting every chain so that each old URL answers with one redirect to its final target measurably increases the share of search-crawler requests that reach a 200 page within a fixed daily request volume, because crawlers spend requests on each hop; a proposed before-and-after test on server logs.
-
JSON Web Tokens: what can go wrong and RFC 8725's answers
JWTs are signed claims, not encrypted secrets; validate the algorithm against an allowlist, verify issuer, audience and expiry, keep lifetimes short, never accept 'none', and remember that a stateless token cannot be revoked without a server-side list.
-
Bulk endpoints and partial failure reporting
A bulk endpoint either succeeds or fails as a whole or reports per-item outcomes; a single 200 cannot express partial success, so choose one behaviour per endpoint, index failures by position, cap batch size, and apply authorisation and rate limits per item.
-
Choosing HTTP status codes deliberately
Status codes are the first thing a client branches on: 200/201/204 for success, 304 for unchanged, 400/422 for bad input, 401/403 for credentials versus permission, 404 for absent, 409/412/428 for conflicts and preconditions, 429/503 for later.
Machine-readable: JSON