Hi, this is a question on how to interpret the asgi specs of django channels:
https://channels.readthedocs.io/en/latest/asgi.html If this is the wrong place to discuss it, then please point me to the right place. I used some free time to learn the language "go" and tried to write a protocol servers in go. This works quite well, thanks for the asgi specs and daphne as an example. Most parts already work. But I do not understand how to handle incoming websocket connections. https://channels.readthedocs.io/en/latest/asgi.html#connection If I understand the specs right, then the protocol server should not respond to an incoming websocket connection right away but keep the http-connection open with no response at all. But it should send a connection message to the channel layer, wait for the responding Send/Close/Accept message and handle the websocket-request accordingly. But there are some cases which I do not understand: What should happen if the python application does not send a Send/Close/Accept at all? Should the websocket-handshake stay in an incomplete state? It seems, that the reconnecting-websocket javascript library[1], that is used by the django channels examples[2], closes and reconnects an websocket handshake, if there is no response after one second. [1] https://github.com/joewalnes/reconnecting-websocket [2] https://github.com/andrewgodwin/channels-examples The specs says, that the Send/Close/Accept message has a "close" and a "accept" flag. What should the protocol server do while the connection is waiting for acceptance and * accept AND close are both set to true? * neither accept nor close (nor byte nor text) is set to true? When I compare the "stable" specs with the "latest" specs I see, that the "accept" flag has not been there in the "stable" version. I do not understand way it was introduced. If I understand the Send/Close/Accept message correctly it should be possible to remove the "accept" flag by merge it with the "close" flag into one "close/reject" flag. * If this flag is set while the connection is waiting for acceptance, then the websocket connection is rejected. * If the flag is set to true while the connection is established, then the connection should be closed. * If it is set to false while the connection is waiting for acceptance, then the connection is accepted * If it is set to false while the connection is established, then it is kept open. The specs say, that close can be a positive integer specifying the response code. What should the protocol server do while the connection is waiting for acceptance when it receives an Send/Close/Accept message like this one: {"close": 1006} At this moment the websocket handshake was not finished, so the usual way to "close" it would be not to open it at all. The protocol server can just send an http 403 response. So should the "close" value be ignored? Is there a way for the python application to specify the http status code? I think this is not possible because the specs allow the protocol server to open the websocket connection before the Send/Close/Accept message was received and buffer all incoming messages. In this case it is not possible for the protocol server to send an http status code to the client. Maybe the specs should be more strict and say that it is not allowed for the protocol server to finish the websocket handshake before the first Send/Close/Accept message was received. In this case the close-value of the first Send/Close/Accept message could be interpreted as an http response code. Best regards, Oskar -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/26bf7c7e-bc74-618f-818a-bd7b6538caf2%40oshahn.de. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
