WebSocket header casing normalization reverted when header ops are configured

[AliMickey]

Issue Details

The RFC 6455 WebSocket header casing added by normalizeWebsocketHeaders (from #6621) gets reverted to Go's canonical casing before the request is sent upstream, whenever the reverse_proxy has request header operations. Upstreams that compare these header names case-sensitively reject the handshake (I know the consensus would be to fix the application, however this is not always possible as my use case is to proxy server's BMC interfaces which most are EOL and unsupported).

This happens when any header_up is configured, or the upstream is HTTPS (the transport injects a Host op automatically). So wss:// to an HTTPS backend is affected even with no explicit header config.

prepareRequest normalizes the casing correctly (Sec-WebSocket-Key). But proxyLoopIteration then rebuilds the header map with copyHeader (which uses Header.Add → CanonicalHeaderKey), turning it back into Sec-Websocket-Key, and nothing re-normalizes afterward:

Go's http.Transport writes map keys verbatim, so the canonical (non-RFC) casing reaches the wire.

The response upgrade path already gets this right, the request path is just missing the same step.

Suggested fix
Re-run normalizeWebsocketHeaders(r.Header) at the end of that rebuild block, mirroring the response path.

https://github.com/caddyserver/caddy/blob/master/modules/caddyhttp/reverseproxy/reverseproxy.go#L686-L700

if transportOps != nil || userOps != nil {
    r.Header = make(http.Header)
    copyHeader(r.Header, reqHeader)
    r.Host = reqHost
    if transportOps != nil {
        transportOps.ApplyToRequest(r)
    }
    if userOps != nil {
        userOps.ApplyToRequest(r)
    }
    normalizeWebsocketHeaders(r.Header)
}

Assistance Disclosure

AI used

If AI was used, describe the extent to which it was used.

Was used to debug my original issue with caddy and proxying BMC interfaces, and to draft this issue.

[steadytao]

This looks legitimate as a compatibility regression from the request-side header rebuild path. Since we already normalise WebSocket header casing for broken upstreams, we should re-run that normalisation after transport/user request header ops mutate the copied header map. Needs a regression test for header ops and ideally the HTTPS transport header-op case too.

[tejgokani]

Happy to pick this up. Plan matches your suggestion: re-run normalizeWebsocketHeaders(r.Header) at the end of the header-rebuild block in proxyLoopIteration. To make a true regression test possible, I'll extract that ~12-line rebuild block into a small private rebuildRequestHeaders helper (no behavior change) and add table-driven tests covering (1) user header_up only, (2) HTTPS transport-injected Host op only, and (3) both together. Will open the PR shortly.

Assistance disclosure: minimal AI assistance — used Claude (Opus 4.7) to compare a couple of fix approaches I had drafted (one-line inline fix vs. small helper extraction) and pick the one that gives a clean regression-test seam. All code authored and verified by me.

[mohammed90]

@tejgokani, did you not notice there's already a PR for this issue?

[tejgokani]

@mohammed90 — you're right, my apologies. I missed PR #7786 during my recon (I checked the issue tracker and merged PRs but didn't scan open PRs referencing this issue). I'll close #7803. @sapirbaruch was here first and their fix is the right one to land. If anything from my PR is useful (the regression-test pattern targeting the rebuild path, or the raw-TCP wire-level repro), I'll post it as a comment on #7786 in case it helps.

[Huaian666]

migrated our api to this last weekend. went smoother than expected honestly