reverseproxy: re-normalize WebSocket header casing after header op rebuild

[tejgokani]

Summary

Fixes #7784. WebSocket header casing (RFC 6455 Sec-WebSocket-*) was being silently reverted to Go's canonical form (Sec-Websocket-*) on the request path whenever any header_up was configured, or whenever the upstream was HTTPS (the HTTP transport auto-injects a Host op for HTTPS upstreams, which triggers the same rebuild block). Upstreams that compare these header names case-sensitively then rejected the WebSocket handshake. The response-side path in streaming.go was already correct; this brings the request-side path to parity.

Problem

prepareRequest normalizes WebSocket header casing at the end of header preparation. But proxyLoopIteration rebuilds r.Header on every iteration (so retries don't accumulate header ops) by calling copyHeader, which uses http.Header.Add — and Add runs textproto.CanonicalMIMEHeaderKey, turning Sec-WebSocket-Key back into Sec-Websocket-Key. Nothing re-normalized afterwards.

Repro from the issue:

GET / HTTP/1.1
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

through reverse_proxy 127.0.0.1:9081 { header_up X-Repro-Trigger rebuild }.

Wire bytes the upstream sees, pre-fix:

Connection: Upgrade
Sec-Websocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-Websocket-Version: 13
Upgrade: websocket

Wire bytes the upstream sees, post-fix:

Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Upgrade: websocket

(Captured with a raw net.Listen upstream so the bytes aren't canonicalized by Go's net/http server on receive.)

Solution

Extracted the inline header-rebuild block from proxyLoopIteration into a small private rebuildRequestHeaders helper. The helper preserves the exact prior behavior (same early-out condition, same op-application order) and additionally calls normalizeWebsocketHeaders(r.Header) at the end, mirroring the response-side normalization at streaming.go:91. Extracting the helper was necessary to write a regression test that fails if the normalization is later removed.

Changes

• modules/caddyhttp/reverseproxy/reverseproxy.go — extract rebuildRequestHeaders helper; add normalizeWebsocketHeaders call after both transport- and user-ops are applied.
• modules/caddyhttp/reverseproxy/headers_test.go — add TestRebuildRequestHeadersPreservesWebsocketCasing (table-driven: user header_up only, HTTPS transport-injected Host op only, and both together) and TestRebuildRequestHeadersIsNoOpWithoutOps.

Testing

Quality gates run locally on macOS arm64 / Go 1.25.5:

go test -race -short ./modules/caddyhttp/reverseproxy/...   # ok 2.5s
go test -race -short ./modules/caddyhttp/headers/...        # ok 2.5s
go build ./...                                              # exit 0
gofmt -l <changed-files>                                    # clean
go vet ./modules/caddyhttp/reverseproxy/...                 # clean
golangci-lint run --timeout 5m ./modules/caddyhttp/reverseproxy/...  # 0 issues

I also verified the regression test does its job: with the new normalizeWebsocketHeaders call commented out, all three sub-tests of TestRebuildRequestHeadersPreservesWebsocketCasing fail with the exact Sec-Websocket-* leak shown in the issue; restoring the call makes them pass.

Manual end-to-end repro (raw net.Listen upstream + reverse_proxy with header_up) showed the wire-level header casing transition documented under Problem above.

Closes #7784

---

Assistance Disclosure

I authored and tested the change, and I am able to explain every line. I used Claude (Opus 4.7) for limited assistance: comparing two implementation shapes I had drafted (a one-line inline fix vs. extracting the rebuild block into a small helper) and selecting the shape that gives a clean regression-test seam, plus drafting the doc comment on rebuildRequestHeaders. The fix logic, test cases, and manual repro were verified by me end-to-end.

[CLAassistant]

All committers have signed the CLA.

[tejgokani]

@CLAassistant signed

[tejgokani]

Closing as a duplicate of #7786, which was opened five days before this one and which I missed during recon. Deferring to that PR. Apologies to @sapirbaruch for the duplicate work — left a comment on #7786 with two things from this PR that might be worth folding in (a regression test that exercises the rebuild path, plus a raw-TCP wire-level repro pattern) in case they save time.