Skip to content

Updated websocket consumers for ASGI v2.3. #2002

Merged
carltongibson merged 1 commit intodjango:mainfrom
kristjanvalur:kristjan/close
Apr 3, 2024
Merged

Updated websocket consumers for ASGI v2.3. #2002
carltongibson merged 1 commit intodjango:mainfrom
kristjanvalur:kristjan/close

Conversation

@kristjanvalur
Copy link
Contributor

This PR adds the "headers" field for websocket.accept messages and the "reason" field for websocket.close, which
were added in ASGI spec versions 2.1 and 2.3 respectively.

@carltongibson carltongibson changed the title support asgi spec 2.3 for websockets Updated websocket consumers for ASGI v2.3. Apr 9, 2023
Copy link
Member

@carltongibson carltongibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @kristjanvalur — thanks for this. Looks right.

Can you make the tests pass? (Missing a django_db marker from the looks of it.)

Refs https://asgi.readthedocs.io/en/latest/specs/www.html#websocket

@kristjanvalur
Copy link
Contributor Author

I've updated, could you re-run the workflow?

@kristjanvalur
Copy link
Contributor Author

Oops, sorry about that, everything should now pass, including the linting.

@kristjanvalur
Copy link
Contributor Author

Would be great to have this merged at some point.

@kristjanvalur
Copy link
Contributor Author

I did the fixes with github.dev, could not test them, but I´m crossing my fingers.

Closes the WebSocket from the server end
"""
message = {"type": "websocket.close"}
if code is not None and code is not True:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my curiosity, why is there a check for the "code not being True"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, hard questions! I think this is a compatibility check. It's been a while, but IIRC, there was a case where a "True" value was being passed to close... I need to look.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, this is not my code. Phew. So, your guess is as good as mine. Maybe in the distant past, someone would call close(True) for whatever reason and this is trying to allow for that? Nothing in the library or unit tests which is doing that, though.

Comment on lines +93 to +94
if reason:
message["reason"] = reason
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if those conditionals are needed, but should be fine.

Copy link
Contributor Author

@kristjanvalur kristjanvalur Jun 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is to not pollute the response with an empty "reason" which is optional in any case.

Copy link
Member

@carltongibson carltongibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this @kristjanvalur 🎁

@carltongibson carltongibson merged commit de88e03 into django:main Apr 3, 2024
@kristjanvalur kristjanvalur deleted the kristjan/close branch April 3, 2024 13:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

3 participants