A microcache keeps reusable responses for a short freshness lifetime, often a few seconds. Requests for the same selected representation can reuse a fresh entry during that window. The response might lag a new origin update, but it is not HTTP-stale merely because it came from a cache. Expiration, permission to serve stale content, and concurrent cache filling are separate policies. ...
A validator lets a recipient ask whether its stored representation still matches the selected one. A successful conditional GET can return 304 without retransmitting the body. Freshness is a separate decision: it determines when a stored response can be reused without that request. An ETag does not itself specify a cache lifetime, and a 304 is not a replacement body. ...
HTTP/3 runs QUIC over UDP:443, and the reason to care is what a lost packet costs. On a TCP connection every stream shares one byte stream, so a dropped segment blocks delivery of everything behind it until the retransmission arrives. QUIC gives each stream its own loss recovery, so the same drop blocks only the streams whose data was in that packet. ...
Server Name Indication (SNI) sends the hostname during the TLS handshake, so one IP address can serve many different certificates and sites. Before SNI, the math was brutal: one certificate per IP, one IP per site, and IPv4 addresses spent like water. Name-based virtual hosting worked for plaintext HTTP but broke for TLS, because the server had to choose a certificate before the encrypted request revealed which site the client wanted. SNI resolves the paradox by moving the hostname earlier — into the handshake itself, ahead of encryption. ...
HTTP/2 changes HTTP transport framing and multiplexing; gzip and Brotli encode representation data. Enabling HTTP/2 does not automatically compress response bodies, and enabling gzip does not prove that a client negotiated HTTP/2. HTTP/2 header compression is another mechanism again. A reliable check records the negotiated protocol, response Content-Encoding, transferred body size, and the bytes obtained after decoding. ...
An nginx redirect and an internal rewrite change different parts of the request flow. A redirect returns a status and Location for the client to consider, potentially causing a new request. An internal rewrite changes nginx’s current URI while processing the existing request. Choosing between them determines whether the client sees a new address, whether location selection runs again, and how the final handler receives path and query data. ...
An nginx location selects configuration for a request within the chosen server. For the flat prefix and regex locations tested here, an exact match finishes the search; otherwise nginx remembers the longest matching prefix and can then choose the first matching regex. If no applicable regex wins, the remembered prefix supplies the configuration. This is a selection process, not simply the first block encountered in the file. ...
nginx request limiting uses a leaky-bucket method to account for excess requests against a configured rate. The burst allowance determines how much excess can be accepted, while nodelay and delay affect when accepted excess proceeds. These are admission and scheduling decisions. They do not make every request above the nominal rate fail, nor do they measure concurrent application work. ...