sanic: Can no longer async stream fragmented message through 21.9 websockets

In the legacy Webscokets implementation you could async stream a fragmented response through the websocket using an AsyncIterator. This seems to not be supported anymore in the 21.9 sanic implementation of websockets as the websocket.send() now only accepts str or bytes. Iterables seem to have a not implemented placeholder in the source (sanic.server.websockets.impl.WebsocketImplProtocol.send()). Is this a feature that will be added in the future?

Example:


websocket.send(async_response_stream_iterator())

async def async_response_stream_iterator():

    yield b"binary data fragment 1"
    yield b"binary data fragment 2"

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 19 (17 by maintainers)

Most upvoted comments

Sorry I’m late to the party on this one, I must’ve missed it in my inbox.

During the development of the new Websockets backend before the release Sanic 21.9, I spoke briefly to the the websockets developer @aaugustin about specifically this issue, that is, a single message, over multiple fragments as described by @tylersalminen . Short story, is that is very difficult to do using the new websockets sans-io interface, and not supported by the sans-io interface (as far as I am aware).

It is not as simple as an iterator generating multiple messages to send, that pattern is easily implemented at the handler level as shown by others in this thread.

The new Sanic Websockets backend has no inter-message state. It communicates data to send directly to the websockets sans-io api layer, which does its own state management. Its probably possible to manipulate the api to get fragement-level sends working, but as I said, I don’t think that is a supported usage pattern.

@aaugustin Is it correct what I said above? Do you have any further insights on this feature?

ashleysommer on Jan 10, 2022

I would have a hard time giving a good use case.

I have anecdotal evidence that sending fragmented messages is rare. It took several years I introduced compression in websockets until someone noticed that I misunderstood the spec and that browsers would reject fragmented, compressed messages generated by websockets. Compression was enabled by default. This shows that almost no one uses fragmentation.

“We don’t support fragmentation, sorry” is a defensible position. I think the amount of time I spent supporting fragmentation in websockets is out of proportion of the usefulness of this “feature” in the real world.

aaugustin on Jan 16, 2022

Exactly. That is the question: should we support this or not. It was never an official feature. I of course hate adding breaking changes. But the real question is whether we should add the complexity to support this or not.

ahopkins on Dec 29, 2021