Description

This PR fixes a bug where WebSocket connections fail when pass_host_header is set to false. The WebSocket proxy was not respecting this configuration setting, while the regular HTTP proxy does.

The fix ensures the WebSocket proxy respects the PassHostHeader configuration by:

• Adding passHostHeader parameter to newWebSocketReverseProxy()
• Applying setProxyUpstreamHostHeader() when PassHostHeader=false
• Ensuring consistent behavior between HTTP and WebSocket proxies

Motivation and Context

When pass_host_header=false is configured, regular HTTP requests correctly set the Host header to the upstream backend URL. However, WebSocket upgrade requests retain the original request host, causing failures when backend services validate the Host header (e.g., Google Cloud Run, Kubernetes ingress, strict reverse proxies).

This inconsistency breaks WebSocket functionality for deployments using:

• pass_host_header=false
• proxy_websockets=true
• Backends that validate the Host header

Fixes #3288

How Has This Been Tested?

Tested in production with:

• OAuth2-proxy version: master branch and implemented the proposed changes
• Backend: Google Cloud Run with websocket application (Cloud Run uses Host header to route traffic to the correct backend)
• Configuration: pass_host_header=false

Test results:

• Regular HTTP requests work correctly
• WebSocket connections successfully establish
• WebSocket connections remain stable
• Backend receives correct Host header for both HTTP and WebSocket requests

Checklist:

• My change requires a change to the documentation or CHANGELOG.
• I have updated the documentation/CHANGELOG accordingly.
• I have created a feature (non-master) branch for my PR.
• I have written tests for my code changes.