Reject non-GET WebSocket upgrade requests with 405 (RFC 6455)

[hahwul]

Description of the Change

Kemal::WebSocketHandler previously gated the WebSocket upgrade solely on a matching ws route and the presence of Upgrade / Connection headers. The HTTP method itself was never validated, so any method (POST, QUERY, …) carrying valid upgrade headers could complete the handshake. RFC 6455 §4.1 requires the opening handshake to be a GET request.

This PR adds a method guard in WebSocketHandler#call, placed after the existing “is this an upgrade request for a ws route?” check and before the Origin check:

• Non-GET upgrade requests are rejected with 405 Method Not Allowed, an Allow: GET header (required for 405 by RFC 9110 §10.2.1), and Connection: close — the same connection-smuggling protection already used by the 403 Origin rejection ([Security] Close connection after rejected WebSocket upgrade #767).
• Requests without upgrade headers are left untouched: they fall through to the next handler exactly as before, so an HTTP route that shares a path with a ws route continues to work.
• Both rejection paths (403 / 405) now share a single reject_websocket! helper driven by HTTP::Status. The helper also skips writing if an upstream handler (e.g. a before filter) has already closed the response.

Before / after, using the reproduction from #770:

curl -si -X QUERY localhost:3000/chat \
  -H 'Upgrade: websocket' -H 'Connection: Upgrade' \
  -H 'Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==' \
  -H 'Sec-WebSocket-Version: 13' \
  -H 'Origin: http://localhost:3000'
# before: HTTP/1.1 101 Switching Protocols
# after:  HTTP/1.1 405 Method Not Allowed
#         Allow: GET
#         Connection: close

Specs cover the full 405 response shape (status, Allow, Connection: close, Content-Type, body) for POST / QUERY / HEAD, confirm that the method check runs before the Origin check, and verify the unchanged fall-through for non-upgrade requests. A CHANGELOG entry is included.

Alternate Designs

• Fall through to the next handler instead of rejecting.
  RFC 9110 §7.8 allows a server to ignore Upgrade and process the request normally. Rejected: before this change a non-GET upgrade request never reached RouteHandler anyway (it was upgraded or returned 403), so falling through would be a larger behavior change. An explicit 405 also matches the wider ecosystem — gorilla/websocket and Node ws return 405, python-websockets returns 405 + Allow: GET, and Cowboy only upgrades GET.

• Route the rejection through custom error 405 handlers.
  Rejected for consistency: the 403 Origin rejection deliberately writes the response directly so the security-relevant shape (Connection: close) cannot be altered; the 405 path follows the same rule.

• Compute Allow dynamically from coexisting routes on the same path.
  Rejected as overkill: it would couple WebSocketHandler to RouteHandler internals. A static Allow: GET correctly describes the upgrade resource and matches python-websockets’ behavior.

Benefits

• RFC 6455 §4.1 conformance and parity with the broader WebSocket ecosystem.
• A clear, diagnosable 405 + Allow: GET instead of a protocol-violating 101 that can confuse intermediaries (or a misleading 403 that suggests an Origin problem).
• A slightly more robust rejection path: shared helper, reason phrases taken from HTTP::Status, and no write attempt on an already-closed response.

Possible Drawbacks

• Behavior change. Clients that (incorrectly) performed the handshake with a non-GET method previously received 101 (allowed origin) or 403, and now receive 405. This is documented in the CHANGELOG; such clients were already violating RFC 6455.
• A non-GET request that carries upgrade headers to a path shared by a ws route and an HTTP route is answered with 405 rather than reaching the HTTP route. This is not a regression — previously the request never reached the route either (it was upgraded or returned 403) — and requests without upgrade headers are unaffected.
• Allow: GET is static; it does not enumerate methods of HTTP routes that coexist on the same path (see Alternate Designs).

[sdogruyol]

Thanks a lot @hahwul 🙏

[hahwul]

@sdogruyol
Thanks for your kind words!