What is the difference between an end-to-end HTTP field and a hop-by-hop one, how does the Connection header field designate the hop-by-hop set, and what goes wrong if a proxy forwards them unchanged?

## Two scopes for one message An HTTP message may pass through caches, reverse proxies, load balancers and gateways. Each hop is a separate connection with its own capabilities: one may be HTTP/1.1 with keep-alive and gzip transfer coding, the next HTTP/2 over TLS. So fields split by scope. **End-to-end fields** belong to the message and its representation, and must be relayed unchanged (with a few defined exceptions, such as caches adding `Age` or `Via`). `Content-Type`, `ETag`, `Cache-Control`, `Authorization`, `Location` are all end-to-end: dropping or rewriting them changes what the far end sees. **Hop-by-hop, or connection-specific, fields** describe the connection currently in use. They are consumed by the recipient of that connection and must not be forwarded. The classic set is `Connection`, `Keep-Alive`, `Transfer-Encoding`, `TE`, `Trailer`, `Upgrade`, `Proxy-Authenticate` and `Proxy-Authorization`. ## How Connection designates the set `Connection` does double duty. It carries connection options (`close`, and historically `keep-alive`), and it *names other fields* that are connection-specific for this message. `Connection: keep-alive, X-Route-Hint` means both `Keep-Alive` and `X-Route-Hint` are scoped to this hop. A conforming intermediary must remove every field named in `Connection`, then remove `Connection` itself, before forwarding. That is the extension mechanism for hop scope: it lets a client and its immediate peer agree on a private field without the risk of it leaking onward. It is also why blindly copying all inbound fields to an upstream request — a very common shortcut in hand-written proxies and API gateways — is wrong. ## What breaks when they are forwarded 1. **Framing corruption.** `Transfer-Encoding` describes how the body is encoded on *this* connection. If a proxy buffers a chunked request and forwards it with `Content-Length` while also copying the original `Transfer-Encoding: chunked`, the upstream sees both fields and the two ends can disagree about the message boundary. That is a request-smuggling primitive, and it is one of the most common ways a homegrown proxy becomes exploitable. 2. **Broken upgrades.** `Upgrade` plus `Connection: upgrade` negotiates a protocol switch on one connection, typically WebSocket. Relaying it to a peer that never agreed leaves one side expecting frames and the other expecting HTTP. Conversely, a proxy that strips `Upgrade` without deliberately proxying the tunnel breaks WebSocket entirely — which is why proxy configurations for WebSocket explicitly re-add these two fields for that route rather than passing everything. 3. **Wrong connection parameters.** A forwarded `Keep-Alive: timeout=5` advertises the previous hop's idle timeout to a peer with different settings, producing races where one side closes a connection the other is about to reuse. 4. **Credential leakage across trust boundaries.** `Proxy-Authorization` is for the proxy, not the origin. Forwarding it hands proxy credentials to an upstream that has no business seeing them. ## Modern versions HTTP/2 and HTTP/3 remove the concept from the wire: connection-specific fields are forbidden, and a message carrying `Connection`, `Keep-Alive`, `Transfer-Encoding`, `Upgrade` or `Proxy-Connection` must be treated as malformed. The single carve-out is `TE`, permitted only with the exact value `trailers`. Connection management moved into the framing layer (SETTINGS, GOAWAY, stream priorities), and protocol upgrade is handled by extended CONNECT rather than the `Upgrade` field. This makes translation the interesting case. A gateway terminating HTTP/2 and forwarding to an HTTP/1.1 back end must *generate* appropriate hop fields for the upstream connection and must refuse any smuggled `transfer-encoding` or `connection` field that arrived over HTTP/2. A gateway going the other way must strip them. Getting this wrong is the h2-downgrade smuggling family. ## Operationally When a header "disappears" between the client and the application, the checklist is: is it named in `Connection`? Is it in the fixed hop-by-hop set? Is a proxy configured with an explicit allow-list? Reverse proxies typically drop hop-by-hop fields silently and by design, which is exactly the confusion that produces the interview question. The design lesson: any field you invent for your own infrastructure must be either genuinely end-to-end, or explicitly declared hop-scoped and stripped at the boundary — never accidentally relayed because the proxy copies everything it receives.