Unify the WebSocket and HTTP pipelines

[raman-m]

Predecessor

• Proposal: merge the WebSocket and HTTP pipelines (plan only) #2407

Idea 💡

Proposal — merge the WebSocket and HTTP pipelines

Status: planning only. This draft intentionally contains no implementation, tests, or documentation changes yet. It captures the goal and a proposed plan for discussion before any code is written. Opened per @raman-m's suggestion on #2406 to start the follow-up; no rush expected until the next release cycle.

Goal

Remove the forked WebSocket pipeline and route WebSocket upgrade requests through the same Ocelot pipeline as ordinary HTTP requests. This is the larger follow-up discussed on #2406 (the #2403 IP-security fix), where the fork was the root cause of the bypass.

Why

A WebSocket request is an ordinary HTTP request until AcceptWebSocketAsync. Today app.MapWhen(IsWebSocketRequest, ConfigureWebSockets) forks it into a hand-maintained subset of middlewares, which is why WS upgrades miss most Ocelot features (auth, authz, rate limiting, claims, header transforms) and why each gap has to be patched in the forked pipeline separately.

Proposed approach

• Drop the MapWhen WS fork in OcelotPipelineExtensions.BuildOcelotPipeline.
• Make WebSocketsProxyMiddleware self-check IsWebSocketRequest and pass non-WS requests through, registering it as a normal pipeline stage after DownstreamUrlCreatorMiddleware so WS terminates there and HTTP continues to cache/requester.
• Preserve user overrides (WebSocketsMiddlewareType / WebSocketsMiddleware).
• Decide the fate of the now-unused public ConfigureWebSockets extension (keep / [Obsolete]).

Open questions for maintainers

1. Is this the shape you had in mind (one flat pipeline, checker in the proxy), or would you prefer a different structure?
2. Are there concerns with making the public ConfigureWebSockets '[Obsolete]'?
3. Expected behaviour changes to call out (e.g. custom MapWhenOcelotPipeline branches would begin to see WS upgrade traffic; browser WS clients can't send an Authorization header).
4. Are there any features which should remain explicitly unsupported for WS upgrades?