Solve incompatibility with uvicorn before releasing 17.0

[aaugustin]

Don't make a release until Kludex/uvicorn#3035 is sorted out.

[aaugustin]

I checked Sanic; it isn't affected because it uses its own HTTP parser and serializer.

Details

Parsing

No fix needed in Sanic. Confirmed from two independent passes: sanic_request_to_ws_request() calls http11.Request(...) (the constructor) with already-decoded strings, never http11.Request.parse() — the classmethod where the ASCII→Latin-1 change actually lives. ServerProtocol.accept() only consumes the resulting Headers object at the string level. websockets 17.0's decoding change is scoped entirely to a code path Sanic never invokes.

One thing the agent's grep turned up that I hadn't checked: Sanic's own decoding is inconsistent across transports, independent of websockets:

• HTTP/1.1 (http1.py:201): head.decode(errors="surrogateescape") → UTF-8 (default) + surrogateescape
• ASGI (asgi.py:138-139) and HTTP/3 (http3.py:343): explicit ASCII + surrogateescape

This predates and is unrelated to the websockets 17.0 change — it doesn't matter to the WS handshake since accept() only reads structurally-ASCII fields (Sec-WebSocket-Key/Version/Protocol) — but it's a latent inconsistency if you ever wanted HTTP/1.1 requests with non-ASCII header bytes to behave identically to ASGI/HTTP3-served ones. Also worth noting: no test in tests/test_websockets.py or tests/test_ws_handlers.py covers non-ASCII websocket handshake headers at all, so this whole area is currently untested either way.

Serialization

Sanic serializes the handshake response itself too, in websocket_protocol.py:141-153:

first_line = (f"HTTP/1.1 {resp.status_code} {resp.reason_phrase}\r\n").encode()
rbody = bytearray(first_line)
rbody += ("".join([f"{k}: {v}\r\n" for k, v in resp.headers.items()])).encode()

Both .encode() calls take no encoding argument, so they're hardcoded to UTF-8, unconditionally, regardless of websockets version. Sanic never calls resp.serialize() — I confirmed that's the only place resp (the http11.Response from ws_proto.accept()) is touched; there's no .serialize() call anywhere in the file

[aaugustin]

Fixed now.