reverseproxy: re-apply WebSocket header normalization after header ops

[sapirbaruch]

Fixes #7784.

When transport or headers ops are configured on a reverse proxy handler, proxyLoopIteration rebuilds r.Header from scratch using copyHeader. Because copyHeader uses http.Header.Add internally, Go's CanonicalHeaderKey canonicalizes the header names — this lowercases the second word in Sec-WebSocket-*, so Sec-WebSocket-Key becomes Sec-Websocket-Key.

normalizeWebsocketHeaders is already called in prepareRequest to fix this exact problem, but the subsequent header rebuild in the retry loop undoes it. Adding the same call after the rebuild keeps the headers in RFC 6455-compliant form (Sec-WebSocket-* with uppercase S) regardless of whether header ops are configured.

The call is cheap and safe for non-WebSocket requests: normalizeWebsocketHeaders iterates a five-element map and only mutates headers that actually exist, so it's effectively a no-op when there are no Sec-WebSocket-* headers present.

---

AI assistance disclosure: This PR was developed with the assistance of an AI tool (Claude), per the project's contribution guidelines.

[CLAassistant]

All committers have signed the CLA.

[mholt]

Can you the human please sign the CLA please @sapirbaruch ?

[mholt]

Also would your LLM be able to add a test?

[mholt]

My last question before we merge it, that I just considered, is should we have Go fix CanonicalHeaderKey instead of us hacking around it? If the canonical form is WebSocket maybe it shouldn't be changing it to Websocket.

[sapirbaruch]

The Go team explicitly closed this as won't-fix back in 2016 (golang/go#18495). Brad Fitzpatrick's response:

RFC 6455 can't mandate the case of headers, since HTTP/1 says that they're case insensitive. And in HTTP/2 there is no case on the wire. I don't want to complicate Go and encourage buggy libraries from assuming case.

So CanonicalHeaderKey will never special-case WebSocket headers — the normalization has to live in Caddy. The normalizeWebsocketHeaders helper (introduced in #6621) is the right layer for this, and the fix just makes sure it's called after the header rebuild in the retry loop, not only before it.

[WeidiDeng]

AI disclosure is required.

[mholt]

Thanks for the reminder @WeidiDeng . Yes, the PR is missing our standard assistance disclosure. It's required even if not using AI, but I can tell this one is, and I think in my head since I could tell I forgot to check for the disclosure.

[tejgokani]

@sapirbaruch — apologies for the duplicate (#7803). I missed your PR when scanning. Closing mine now.

If useful, two things from my work that might be worth folding in:

1. A regression test that exercises the rebuild path itself. Your unit tests on normalizeWebsocketHeaders directly are clean, but they don't fail if the new call at the rebuild site is later removed. A test that goes through the rebuild block (via a small helper extraction or via proxyLoopIteration setup) catches that. Happy to share the diff; the gist is a table-driven test with three cases — user header_up only, the HTTPS transport-injected Host op only, and both together — that constructs a Handler{}, calls into the rebuild path, and asserts the RFC 6455 casing reaches r.Header. I verified it fails without the fix and passes with it.

2. A raw-net.Listen upstream for wire-level evidence. Go's net/http server canonicalizes incoming header keys on receive, so an application-layer upstream hides the bug even when it's present on the wire. A ~30-line raw TCP upstream that prints the literal request bytes shows the difference clearly:

PRE-FIX:   Sec-Websocket-Key: dGhlIHNhbXBsZSBub25jZQ==
POST-FIX:  Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

Useful for the PR body / future regression debugging.

Totally fine to skip either of these — just offering in case they save you time. Thanks for the citation on golang/go#18495, that was the right context I was missing.

---

Assistance disclosure: minimal AI assistance — used Claude (Opus 4.7) to compare implementation shapes and draft this comment. Authored and verified by me.

[steadytao]

I added the rebuild-path regression test locally since this PR has gone stale. The updated test exercises the actual header rebuild path for user header ops, the transport-injected Host op case and both together. It fails if the post-rebuild normalizeWebsocketHeaders call is removed so it should cover the regression Tej pointed out.