Note di Matteo

Idempotency Is Easy Until the Second Request Is Different. Deep dive nell'implementazione di idempotency nelle API HTTP.

FastCGI: 30 Years Old and Still the Better Protocol for Reverse Proxies. Andrew Ayer di SSLMate spiega in occasione del 30° anniversario di FastCGI come il protocollo sia per certi versi (e almeno in teoria) migliore di HTTP per la comunicazione tra reverse proxy e backend.

FastCGI is very usable today, and has been in production use at SSLMate for over 10 years. That said, using a vintage technology has some downsides. It was never updated to support WebSockets. The tooling is not as good. For example, curl has no way to make requests to a FastCGI server. It supports FTP, Gopher, and even SMTP (however that works), but not FastCGI. When I benchmarked Go's FastCGI server behind a variety of reverse proxies, some workloads had worse throughput compared to HTTP/1.1 or HTTP/2. I don't think that's inherent to the protocol, but a reflection that FastCGI code paths have not been optimized as much as HTTP.

In Chrome dall'ottobre 2026:

One year from now, with the release of Chrome 154 in October 2026, we will change the default settings of Chrome to enable “Always Use Secure Connections”. This means Chrome will ask for the user's permission before the first access to any public site without HTTPS.

Aggiungere una CDN o in generale avvicinare l'edge all'utente finale non sembra avere impatto in sulla latenza in presenza di una origin dinamica (rispetto a connettersi direttamente alla origin).

Mi sarei aspettato che fasi delicate come handshake TCP/TLS beneficiassero della vicinanza dell'edge e che la connessione CDN-origin fosse di qualità migliore, e invece:

Non una prova definitiva ovviamente.

Non c'è differenza nell'utilizzo della CPU tra algoritmi di controllo della congestione in QUIC secondo l'analisi di CDN77 (DataCamp):

Both BBRv1 and BBRv2 are much more computationally complex than Cubic. Cubic is de facto event-based, where each dropped packet manipulates the congestion window (CWND) by a scaling constant, meaning the algorithm has minimal bookkeeping. On the other hand, both BBRv1 and BBRv2 maintain a state machine, which is much more computationally expensive.

BBRv2 maintains more parameters than BBRv1, which adds to the computational complexity.

Nevertheless, we have not seen any measurable difference in CPU usage between Cubic, BBRv1, and BBRv2. We can conclude that the overhead of BBRv1 and BBRv2 is negligible.

Cache-Control for Civilians è un classico must-read (ancora attuale e ancora aggiornato) per chi vuole imparare una volta per tutti gli header per gestire la cache HTTP.

Ho trovato questa recente iniziativa, HTTP/1.1 must die, secondo cui il rischio di HTTP smuggling è troppo alto e quindi bisognerebbe migrare verso HTTP/2 per gli upstream nei reverse proxy.

Per contesto (dal paper):

HTTP/1.1 has a fatal, highly-exploitable flaw - the boundaries between individual HTTP requests are very weak. Requests are simply concatenated on the underlying TCP/TLS socket with no delimiters, and there are multiple ways to specify their length. This means attackers can create extreme ambiguity about where one request ends and the next request starts.

HTTP/2 non soffre di questo problema:

HTTP/2 is not perfect - it's significantly more complex than HTTP/1, and can be painful to implement. However, upstream HTTP/2+ makes desync vulnerabilities vastly less likely. This is because HTTP/2 is a binary protocol, much like TCP and TLS, with zero ambiguity about the length of each message.

E il problema si può presentare anche se il client usa HTTP/2, proprio per via dei reverse proxy:

Servers and CDNs often claim to support HTTP/2, but actually downgrade incoming HTTP/2 requests to HTTP/1.1 for transmission to the back-end system, thereby losing most of the security benefits.

Come risolvere:

First, ensure your origin server supports HTTP/2. Most modern servers do, so this shouldn't be a problem.

Next, toggle upstream HTTP/2 on your proxies. I've confirmed this is possible on the following vendors: HAProxy, F5 Big-IP, Google Cloud, Imperva, Apache (experimental), and Cloudflare (but they use HTTP/1 internally).

Unfortunately, the following vendors have not yet added support for upstream HTTP/2: nginx, Akamai, CloudFront, Fastly.