Which headers does httputil.ReverseProxy remove before sending a request upstream?

## The rule the proxy is implementing Some HTTP header fields describe the message; others describe the single TCP connection the message travelled on. The second kind belongs to one hop only. A proxy that copies them onward is telling the next hop something about a connection it is not part of, and the results range from harmless to genuinely broken — a forwarded `Transfer-Encoding` next to a re-framed body is the classic smuggling shape. `httputil.ReverseProxy` handles this for you and does not ask. ## What is removed The fixed set the package strips is: `Connection`, `Proxy-Connection`, `Keep-Alive`, `Proxy-Authenticate`, `Proxy-Authorization`, `Te`, `Trailer`, `Transfer-Encoding`, `Upgrade`. On top of that, the `Connection` header may itself *name* further headers as hop-by-hop, as a comma-separated token list. A request carrying `Connection: X-Internal-Token` is asking that `X-Internal-Token` not be forwarded, and the proxy honours it by deleting that header too — on both the request and the response. This is the part candidates usually miss: it is not a fixed blacklist, it is a fixed list plus whatever the message declares. The same removal runs over the upstream's response headers before they are copied to the `http.ResponseWriter`, so a `Connection` or `Keep-Alive` that governed the proxy-to-upstream connection does not leak out to the browser. ## Where in the pipeline it happens The removal runs **after** your `Director` or `Rewrite` hook, over the outbound header map. That ordering has a visible consequence: anything hop-by-hop you set inside the hook is thrown away moments later. Setting `Connection: close` in a Director to try to stop the proxy from reusing the upstream connection does nothing at all — connection behaviour towards the upstream is a property of the round tripper, not a header you inject. End-to-end headers you set in the same hook, such as a tenant or trace identifier, survive untouched. ## The two things put back Stripping the whole set unconditionally would break two legitimate cases, so the proxy restores them. **Trailers.** If the inbound request's `Te` field contained the `trailers` token, the proxy re-sets `Te: trailers` on the outbound request. Without it, an upstream that would have sent trailing headers has been told, by the proxy's own scrubbing, that the client cannot accept them. **Protocol upgrades.** The proxy reads the inbound `Upgrade` token before stripping. If there was one, it puts `Connection: Upgrade` and `Upgrade: <token>` back on the outbound request. That is what allows an upgrade handshake to traverse a `ReverseProxy` at all: the upstream must see the upgrade request to answer `101 Switching Protocols`, at which point the proxy stops being an HTTP relay and splices the two connections together. ## Diagnosing it The symptom is almost always "a header I set is not arriving" or "a header I did not expect is arriving". Put the proxy's view and the upstream's view side by side: log the outbound header map at the end of your hook, and log what the upstream handler actually received. If a name is present in the first and absent in the second, check whether it is on the hop-by-hop list or named in `Connection`. If it survived and you wished it had not — a stale `X-Internal-*` from a caller, say — the fix is a `Header.Del` in your hook, because the proxy only strips what the protocol calls per-connection, not what your organisation considers internal. ## Why this is the proxy's job and not yours Once you have seen the list, the temptation is to reproduce it in a hook. Don't. The package applies it after your hook, on both directions, and handles the upgrade and trailer exceptions in the right order. Your hook's job is the routing and the end-to-end headers your services agreed on.