Http | Techlist.io

cloudflareAug 13, 20262 min readCurated summary

Total eclipse of the Internet: traffic impacts in Iceland, Spain, and Portugal

The August 12, 2025 total solar eclipse caused a measurable, temporary decline in Internet activity across Europe. Cloudflare Radar data shows that HTTP traffic dropped most sharply when the eclipse reached maximum obscuration, especially in countries along the path of totality. Traffic generally returned to normal within minutes as people resumed using their devices. ## Traffic Drops Matched Eclipse Timing - Cloudflare analyzed HTTP requests in five-minute intervals across affected countries. - Traffic reductions aligned closely with each location’s moment of maximum eclipse. - The strongest declines occurred in Iceland, Ireland, the UK, France, Spain, and Portugal. - Countries with only shallow partial eclipses, including Sweden, Denmark, Poland, and Switzerland, saw little or no decline. - Regions experiencing deep eclipses recorded traffic drops of roughly 15% to 30%. - Traffic typically rebounded shortly after maximum obscuration. ## Eclipse Depth Predicted Internet Activity - Researchers compared each country’s peak solar obscuration with its average traffic change during the surrounding 15-minute window. - The results showed a clear downward relationship: greater obscuration generally produced larger traffic declines. - Local factors such as population density, cloud cover, and time of day caused some variation, but the precise timing supported the eclipse as the primary cause. - Solar obscuration was calculated geometrically using the apparent sizes and positions of the sun and moon, measuring how much of the sun’s disk was covered every five minutes. ## Iceland, Spain, and Portugal Saw the Largest Declines - Country-level traffic changes ranged from a 9.3% increase to a 46.7% decrease. - Iceland, Spain, and Portugal experienced the most dramatic reductions. - Norway and Sweden saw slight increases above normal levels. - Denmark experienced the smallest overall change, while Poland quickly returned to baseline. - Eclipse-day traffic was compared with the median traffic from the three previous Wednesdays, using matching times of day to reduce the effect of unusual weekly patterns. ## Physical Events Reshape Digital Behavior - The findings show that Internet traffic reflects where people direct their attention. - The eclipse reduced online activity because people temporarily stopped using their devices to observe it, not because of technical network problems. - Traffic normalized quickly afterward, demonstrating how a shared real-world event can create a continent-wide but short-lived shift in digital behavior. - Cloudflare Radar can be used to study similar changes during major global events.

Read original

Http Data Visualization Cloudflare Radar Statistical Analysis+2

cloudflareJul 1, 20263 min readCurated summary

Announcing the Monetization Gateway: charge for any resource behind Cloudflare via x402

Cloudflare is introducing the Monetization Gateway, which will let customers charge for web pages, datasets, APIs, and MCP tools protected by Cloudflare. It combines payment rules, access control, metering, and payment verification at the edge, initially using stablecoins through the x402 protocol. The goal is to make low-cost, usage-based payments practical for AI agents without requiring sellers to build billing infrastructure or onboard every buyer. ## The Web’s Shift Toward Usage-Based Payments - The traditional web monetized human attention through advertising, subscriptions, and e-commerce. - AI agents consume resources without viewing ads or maintaining subscriptions, creating a need for pricing based on actual usage. - Potential models include: - Charging a few cents per search. - Combining a base fee with usage charges, such as per megabyte uploaded. - Charging only when an outcome succeeds, such as a resolved support escalation. - Agents may generate thousands of requests and micropayments, making per-request, per-token, or outcome-based pricing more appropriate than monthly or per-seat plans. - Existing usage billing has generally required API keys, known customers, extensive accounting systems, and costly payment infrastructure. - Stablecoins such as USDC and Open USD can support sub-cent payments with low fees and settlement times under a second. ## Cloudflare’s Role in Usage-Based Billing - Cloudflare can use its position as a proxy between buyers and sellers to combine payment verification with the request path. - Metering, payment exchange, and settlement can occur away from the customer’s origin. - Customers retain control over: - Pricing. - Access rules. - Revenue. - Sellers will not need to onboard each buyer or build a complete billing system; they can define rules that determine when agents must pay. ## How x402 Payments Work - x402 uses HTTP’s `402 Payment Required` status code to add payments directly to ordinary web requests. - The flow is: - A client requests a protected resource. - The server returns a 402 response containing the price, accepted asset, and payment destination. - The client pays and retries the request with proof of payment. - A facilitator verifies the payment. - The server returns the requested resource. - There are no checkout redirects or separate payment APIs. - Payments settle peer-to-peer directly into the seller’s wallet. - x402 is well suited to machine payments because: - It supports very small transactions. - Buyers do not need an account with the seller. - The payment itself acts as the access credential. - Stablecoins offer fast settlement, low fees, and no chargebacks. ## Monetization Gateway Capabilities - Customers will define payment policies through a dedicated rules API using expressions similar to other Cloudflare rules. - The system will apply to traffic such as tokens, APIs, MCP tool calls, and datasets. - Enforcement will run across Cloudflare’s network in more than 330 cities, allowing payment handshakes to occur near buyers while reducing latency and protecting origins. - Planned functionality includes charging for specific REST methods and routes, such as requiring $0.01 for each `GET` or `POST` request to `/api/premium/*`. - The gateway is also intended to support variable pricing for tasks with different costs. Cloudflare’s approach is to make micropayments a native part of HTTP access, enabling businesses to charge agents directly for the resources they consume without constructing their own payment and accounting systems.

Read original

Http AI Agents Model Context Protocol Cloudflare+4

cloudflareJun 22, 20263 min readCurated summary

How we found a bug in the hyper HTTP library

The Images binding’s migration to a local Unix-socket architecture exposed a rare race condition in Rust’s `hyper` HTTP library. Under slow-reader conditions, large image responses were truncated even though they returned `200 OK` and a full `Content-Length`, causing downstream processing or image decoding to fail. After six weeks of investigation, the issue was traced to premature socket shutdown and fixed with four lines of code. ## Images Bindings and the Request Path - Cloudflare’s Images service runs on Workers and uses `hyper` to manage HTTP connections. - The Images binding lets Workers send image data directly to the service, chain transformations, and receive the processed result as a stream. - The response path involved: - The Images service generating the complete encoded image. - `hyper` buffering the response. - Data moving through socket buffers managed by the kernel. - A client or intermediary reading the response. - If the reader was fast, `hyper` could flush the entire response and safely shut down the socket. - If the reader was slower, the socket’s outbound buffer filled, requiring `hyper` to pause and resume writing. ## Moving from FL to Local Unix Sockets - Initially, binding traffic passed through Cloudflare’s FL intermediary service. - In December 2025, the Images team replaced FL with an internal binding running on the same machine. - Unix sockets removed network and FL-processing overhead, including routing and DNS work. - The redesign improved performance and allowed the Images team to release binding changes independently. - The bug appeared within days of the rollout. ## Successful Responses with Truncated Bodies - The first report involved nested image-processing pipelines: - An inner Images binding composited large JPEG and PNG inputs from R2. - An outer URL-based pipeline resized, compressed, and transcoded the result. - The inner pipeline returned `200 OK` and a `Content-Length` for several megabytes, but delivered only a fraction of the body. - One response contained roughly 200 KB instead of the expected 3.3 MB. - The outer pipeline reported an end-of-file error because the body ended before the declared message length. - Depending on the image format, clients saw partially rendered images or completely broken images. ## Reproducing and Isolating the Race - Engineers recreated the nested setup, then removed layers until the failure occurred with the binding alone. - Batch testing produced failures reliably—for example, 19 of 25 requests in one run. - The amount of data received, approximately 200 KB, closely matched the production socket-buffer size. - This indicated that the failure was related to backpressure and socket-buffer exhaustion rather than the customer’s specific configuration. - Investigation eventually identified a race in `hyper` where the connection could be shut down before buffered response data had finished flushing. The incident demonstrates that HTTP success status codes do not guarantee complete response bodies when connection handling is incorrect. Systems streaming large payloads over sockets should test slow-reader and backpressure scenarios, and libraries should only close connections after all buffered data has been written.

Read original

Http Cloudflare Workers Rust Race Condition+2

cloudflareApr 17, 20264 min readCurated summary

Shared Dictionaries: compression that keeps up with the agentic web

Shared dictionaries address a growing web-performance problem: pages are getting heavier, being rebuilt more frequently, and fetched repeatedly by agents. Instead of retransmitting entire assets after every deployment, servers can compress new versions against files already cached by the browser and send only the differences. The approach could dramatically reduce bandwidth and CPU use, though adoption depends on browser support, security safeguards, and complex server-side implementation. ## The Problem: More Shipping Means Less Caching - Web pages have become 6–9% heavier annually due to frameworks, interactivity, and media. - Agentic crawlers and other automated tools increasingly request full pages; they accounted for nearly 10% of Cloudflare requests in March 2026, up about 60% year over year. - AI-assisted development leads to more frequent deployments and experiments. - Small code changes can cause bundlers to re-chunk assets and generate new filenames, forcing clients to download entire bundles again. - Conventional compression reduces the size of each response but cannot exploit the fact that the client already has most of the previous version. - Frequent deployments therefore create substantial redundant bandwidth and CPU usage. ## How Shared Dictionaries Work - A compression dictionary is shared knowledge between the client and server. - The server compresses a new response using content the client already possesses as a reference. - The client uses that same reference to reconstruct the complete file. - Brotli includes a built-in dictionary of common web patterns, while Zstandard can generate custom dictionaries from representative content. - Gzip lacks a prebuilt or custom dictionary and discovers patterns only during compression. ## Delta Compression for Versioned Assets - Shared dictionaries use the previously cached resource as the compression dictionary. - The initial response includes a `Use-As-Dictionary` header, telling the browser to retain the resource for future compression. - On a later request, the browser sends an `Available-Dictionary` header identifying what it has cached. - The server sends only the differences between the old and new versions. - A 500 KB JavaScript bundle with a one-line change could become only a few kilobytes on the wire. - The technique is especially useful for versioned JavaScript bundles, CSS, framework updates, and other incrementally changing assets. - Each release can use the immediately preceding version as its dictionary, allowing savings to continue across many deployments. - Custom and dynamic dictionaries for non-static content remain an area for future development. ## Lessons from SDCH - Google introduced Shared Dictionary Compression for HTTP (SDCH) in Chrome in 2008. - Although early adopters reported significant performance improvements, SDCH had serious security and architectural issues. - Compression side-channel attacks such as CRIME and BREACH demonstrated that attackers could infer secrets by injecting content and observing compressed response sizes. - SDCH also conflicted with the Same-Origin Policy and CORS because of its cross-origin dictionary model. - Its specification did not adequately define interactions with APIs such as the Cache API. - Chrome removed SDCH in 2017 after adoption failed to materialize. ## The Modern Standard and Remaining Challenges - RFC 9842, Compression Dictionary Transport, addresses major SDCH shortcomings. - Dictionaries are restricted to responses from the same origin, reducing conditions that enabled earlier side-channel attacks. - Chrome and Edge support the standard, while Firefox is working toward support. - Implementing the system requires servers to: - Generate or select dictionaries. - Advertise them with correct headers. - Detect `Available-Dictionary` requests. - Delta-compress responses dynamically. - Fall back cleanly for clients without dictionary support. - Cache behavior becomes more complicated because responses vary by both content encoding and dictionary availability. Cloudflare plans to offer a beta of its shared compression dictionary support on April 30, 2026. The technology is promising for frequently deployed applications and agent-heavy traffic, but broad benefits will depend on cross-browser adoption and careful handling of security and caching complexity.

Read original

Http Web Performance Delta Compression Shared Compression+4