2 posts tagged with "http"

RFC conformance can sound abstract until you run a real production stack.

Your service is not only interacting with one client. It is sitting behind load balancers, reverse proxies, CDNs, API gateways, browsers, mobile clients, and internal automation tools. A cookie that works in Chrome but breaks in Safari, a cache header that your CDN interprets differently than you intended, an authorization header that your proxy strips because it does not match the expected format — these are real incidents that happen because of small protocol deviations.

Fiber v3 addresses this with specific improvements to cookie handling, context behavior, response semantics, and connection management, each tied to concrete RFCs. This post walks through what changed and why it matters operationally.

In many backend teams, outbound HTTP calls are still treated like helper code. They live in random utility functions, each call has slightly different timeout behavior, and when incidents happen no one is fully sure which upstream policy is actually active.

That works while a service has two dependencies. It starts to hurt when a service has ten. Timeout drift, inconsistent retry behavior, missing correlation headers, and ad-hoc error mapping become real operational problems. When your on-call engineer cannot tell which upstream policy is in effect during an incident, the outbound client is the root cause even when the upstream itself is fine.

The v3 client package addresses this by treating outbound HTTP as a first-class concern. You define client behavior once, override it where needed, and keep request policy visible in one place.