Channels: Error: Django can only handle ASGI/HTTP connections, not websocket.

Created on 12 Mar 2020  路  5Comments  路  Source: django/channels

my setup:

Django==3.0.3
channels==2.4.0
channels-redis==2.4.2
daphne==2.4.1

run command:

daphne myproduct.asgi:application

I got 500 server error when I connenct websocket .

log:

127.0.0.1:54023 - - [12/Mar/2020:16:51:21] "WSCONNECTING /ws/robot" - -
2020-03-12 16:51:22,104 ERROR    Exception inside application: Django can only handle ASGI/HTTP connections, not websocket.
  File "/Users/xx/project/xx/venv/lib/python3.7/site-packages/daphne/cli.py", line 30, in asgi
    await self.app(scope, receive, send)
  File "/Users/xx/project/xx/venv/lib/python3.7/site-packages/django/core/handlers/asgi.py", line 146, in __call__
    % scope['type']
  Django can only handle ASGI/HTTP connections, not websocket.
127.0.0.1:54023 - - [12/Mar/2020:16:51:22] "WSDISCONNECT /ws/robot" - -
documentation enhancement

Most helpful comment

Hi @jack-michaud. Yes. Currently this is the case. It's a difference between ASGI v2 and v3.

Progress for this should be made in #1421 by @jaydenwindle. At that point we should be able to accept a single callable (the ASGI v3 version that Django's new code implements) and the idea above should hold. 馃

Goal now is a channels update to use ASGI 3 (allowing fallback for existing apps) throughout.
I have stuff for the next version of DRF top of my list, and then it's Channels after that. If you fancy lending a hand, that would be super.

All 5 comments

Django's ASGI handler does not support web sockets.

You're still going to need to use Channel's ProtocolTypeRouter as per the tutorial here.
You'll need to point daphne to (e.g.) myproduct.routing:application.

The thing you can do with Django 3.0. is route http traffic to Django's ASGIHander, rather than have Channels use its own. (Adding that to the docs would be a good example.)

Was experiencing this, I modified django's default asgi.py to what it says in the docs (using from channels.routing import get_default_application instead of django's django.core.asgi.get_asgi_application) and it worked fine.

I also tried to use django's asgi application in the protocol router but I think there may be an interface difference.

Channels' HTTP asgi handler: https://github.com/django/channels/blob/master/channels/http.py#L179
Django's asgi handler: https://github.com/django/django/blob/master/django/core/handlers/asgi.py#L136

As a result, I don't think you _can_ use Django's ASGIHandler.
Channels' works fine for me though.

Hi @jack-michaud. Yes. Currently this is the case. It's a difference between ASGI v2 and v3.

Progress for this should be made in #1421 by @jaydenwindle. At that point we should be able to accept a single callable (the ASGI v3 version that Django's new code implements) and the idea above should hold. 馃

Goal now is a channels update to use ASGI 3 (allowing fallback for existing apps) throughout.
I have stuff for the next version of DRF top of my list, and then it's Channels after that. If you fancy lending a hand, that would be super.

For those tracking this, it looks like work continues in #1479 and #1480.

Make sure you have DEBUG = True in development

Was this page helpful?
0 / 5 - 0 ratings