[Triage] Rejecting WebSocket does not conform to the ASGI spec

[vytas7]

Type

Bug Report

Description

According to the ASGI spec, when a close event is sent before the WebSocket is accepted, the server must close the connection with an HTTP 403 error code (Forbidden).

Gunicorn does not conform to this part of spec; instead it replies with an HTTP 200 OK, and then abruptly cuts the connection.

This works correctly in all other ASGI servers exercised in Falcon's integration tests: Daphne, Granian, Hypercorn, and Uvicorn.

Steps to Reproduce (for bugs)

1. Create a simple app file called reject.py:

async def app(scope, receive, send):
    if scope['type'] == 'websocket':
        while True:
            event = await receive()
            print('<==', event)
            if event['type'] == 'websocket.connect':
                await send({'type': 'websocket.close'})
                break

2. Run it with gunicorn 26.2.0 (see below).
3. Connect to ws://localhost:8000/ using a browser or other WebSocket client. The browser or client reports an HTTP 200 together with unclean shutdown. When using any other conformant server, the browser or client will report an HTTP 403 instead.

Configuration

gunicorn --access-logfile - --log-level debug --worker-class asgi reject:app

Logs / Error Output

Nothing of interest. The request doesn't even show up in the log.

[2026-09-06 18:37:38 +0200] [105750] [DEBUG] 1 workers
[2026-09-06 18:37:38 +0200] [105750] [INFO] Control socket listening at /run/user/1000/gunicorn.ctl
<== {'type': 'websocket.connect'}
[2026-09-06 18:37:54 +0200] [105751] [DEBUG] WebSocket close handshake timeout

Gunicorn Version

gunicorn (version 26.2.0)

Python Version

Python 3.12.3

Worker Class

asgi (beta)

Operating System

Ubuntu 24.04.4 LTS

Additional Context

No response

Checklist

• I have searched existing discussions and issues for duplicates
• I have checked the documentation and FAQ

[vytas7]

A correction, that 200 may have been invented by Firefox's inspector.

It looks like Gunicorn just sends a bare \x88\x02\x03\xe8 over the socket in this case, there was no status line of any kind.