search

encode / httpx

A next generation HTTP client for Python. 🦋
https://www.python-httpx.org/
BSD 3-Clause "New" or "Revised" License
12.68k stars 810 forks source link

WebSockets support. #304

Open jlaine opened 4 years ago

jlaine commented 4 years ago

Currently httpx is squarely focused on HTTP's traditional request / response paradigm, and there are well-established packages for WebSocket support such as websockets. In an HTTP/1.1-only world, this split of responsabilities makes perfect sense as HTTP requests / WebSockets work independently.

However, with HTTP/2 already widely deployed and HTTP/3 standardisation well under way I'm not sure the model holds up:

Using the sans-IO wsproto combined with httpx's connection management we could provide WebSocket support spanning HTTP/1.1, HTTP/2 and HTTP/3. What are your thoughts on this?

One caveat: providing WebSocket support would only make sense using the AsyncClient interface.

tomchristie commented 4 years ago

So my assumption here would be "no", but that it's possible we'll want to expose just enough API in order to allow a websocket implementation to use httpx for handshaking the connection, and sharing the connection pool.

So, to the extent that we might allow it to be possible, I'd expect that to be in the form of a third party package, that has httpx as a dependency.

I'm not sure exactly what API that'd imply that we'd need to support, but it's feasible that we might end up wanting to expose some low-level connection API specifically for supporting this kind of use case. The most sensible tack onto thrashing out what we'd need there would be a proof-of-concept implementation that'd help us concretely indentify how much API we'd need to make that possible.

Does all that make sense, or am I off on the wrong track here?

jlaine commented 4 years ago

What you are saying does make sense, I haven't quite made up my own mind on this.

Pros of a third-party package handling the websockets:

Cons:

tomchristie commented 4 years ago

Interesting points, yeah. I guess I'd be open to reassessing this as we go.

We'd need to identify what the API would look like, both at the top user-facing level, and at whatever new lower-level cutoffs we'd need to be introducing.

sethmlarson commented 4 years ago

I'm in favor of adding websockets definitely, would be a good feature to work towards in a v2? Still so much to do to get a v1 released.

Thanks for bringing this up @jlaine! I've not had to deal with websockets so I didn't even think they'd be at home in a library like HTTPX. :)

tomchristie commented 4 years ago

I'm in favor of adding websockets definitely, would be a good feature to work towards in a v2? Still so much to do to get a v1 released.

Probably not a bad call, yeah.

jlaine commented 4 years ago

I'm in favor of adding websockets definitely, would be a good feature to work towards in a v2? Still so much to do to get a v1 released.

I'll see if I can find time to put together a minimal PR supporting HTTP/1.1 and HTTP/2 to scope out what this entails. Obviously if there are more pressing needs for v1 there is zero pressure to merge it.

@aaugustin just pinging you so you're in the loop : this is not a hostile move against websockets, and your insights would be most welcome

aaugustin commented 4 years ago

I'm currently working on refactoring websockets to provide a sans-I/O layer. If it's ready within a reasonable timeframe, perhaps you could use it. It will handle correctly a few things that wsproto doesn't, if the comments I'm seeing in wsproto's source code are correct.

One of my issues with sans-I/O is the prohibition async / await, making it impossible to provide a high-level API. For this reason, I'm not sure that sans-I/O as currently specified is the best approach. This makes me hesitate on a bunch of API design questions...

Building an API that httpx will consume (either strict sans-I/O or something else) would be a great step forwards. Perhaps we can cooperate on this?

Also I would really like websockets to work over HTTP/2 and HTTP/3.

I'm quite happy with my implementation of a subset of HTTP/1.1 — I'm not kidding, even though it's home-grown, I honestly think it's all right. It may be possible to achieve HTTP/2 in the same way but it will be partial e.g. it will be impossible to multiplex websockets and HTTP on the same connection. Given what I've seen of aioquic, I don't think it's reasonable to do HTTP/3 that way.

So I'm interested in working with third-party packages that handle HTTP/2 and HTTP/3 to figure out what that entails.

ClericPy commented 4 years ago

As for me, httpx is not only the next generation HTTP client for requests but also aiohttp.

So expecting a new choice to take the place of aiohttp's websocket. https://github.com/ftobia/aiohttp-websockets-example/blob/master/client.py

Best wishes to the author, this lib is a great help for me.

PS: aiohttp is good enough, except some frequently changing api protocol (like variable names), which raised a backward incompatibility error by a new version.

aaugustin commented 4 years ago

FYI I started implementing a Sans-I/O layer for websockets: https://github.com/aaugustin/websockets/issues/466

It may not be obvious from the first commits because I have to untangle a lot of stuff from asyncio before I can get anything done :-)

sethmlarson commented 4 years ago

@aaugustin That's awesome news! :) Thanks for updating this thread. It'd be interesting to see how an upgrade from h11 into the websockets state-machine might look. Something to definitely write up a POC for that little exchange.

(Also, congrats on the Tidelift sponsorship!)

aaugustin commented 4 years ago

So, here's how I think the bridge could work.

Since we're talking about httpx, I'm focusing on the client side here, but the same logic would apply on the server side.

In addition to the regular APIs that receive and send bytes, websockets should provide an API to receive and send already parsed HTTP headers. This API will support bolting websockets on top of any HTTP/1.1 implementation.

In addition to:

from websockets import ClientConnection

ws = ClientConnection()
bytes_to_send = ws.connect()
...
ws.receive_data(bytes_received)

I need to provide something like:

from websockets import ClientConnection

ws = ClientConnection()
request = ws.build_handshake_request()
# here request is (path, headers) tuple
bytes_to_send = serialize(request)  # <-- you can do this with any library you want
...
response = parse(bytes_received)  # <-- you can do this with any library you want
# here response is a (status_code, reason_phrase, headers) tuple
ws.receive_handshake_response()

The latter happens under the hood anyway so it's clearly doable.

It's "just" a matter of naming things :-) — which I care deeply about.

WebSocket over HTTP/2 requires a different handshake, so websockets will need another APIs to support it. I have no idea about WebSocket over HTTP/3.

jlaine commented 4 years ago

WebSockets over HTTP/3 haven't been officially specified, but it is extremely likely it will work like for HTTP/2 (RFC 8441), namely using a :protocol pseudo-header. This is what I have assumed for the aioquic demo client + server, and I believe @pgjones did the same for hypercorn.

tomchristie commented 4 years ago

I'd like us to treat this as out-of-scope at this point in time.

Yes I think we'll want to provide enough API to make this do-able at some point in the not too distant future, but being able to do that while still aiming for a sqaured away API stable 1.0 release isn't something we're able to do just yet.

smurfix commented 4 years ago

I'd recommend to keep this open and add a "deferred" label.

cpitclaudel commented 4 years ago

It might also be worth tweaking the AsyncClient documentation; currently, it says:

Async is a concurrency model that is far more efficient than multi-threading, and can provide significant performance benefits and enable the use of long-lived network connections such as WebSockets.

and indeed httpx pops up as one of the first results on Google for python websockets ^^

tomchristie commented 3 years ago

So, I've been thinking a bit about how we might support websockets and other upgrade protocols from httpx.

This is more of a rough idea, than a formal plan at the moment, but essentially what we'll want is for the httpcore layer to support another method in addition to the existing .request(). So that we have...

.request(<request>) -> <response> .upgrade(<request>, <protocol string>) -> <response>, <socket stream>

Which will return an object implementing our (currently internal only) SocketStream API

Once we're happy that we've got the low-level httpcore API for that thrashed out, we'd expose it higher up into httpx with something like this...

# Using a `client` instance here, but we might also support a plain `httpx.upgrade(...)` function.
# Both sync + async variants can be provided here.
with client.upgrade(url, "websocket") as connection:
    # Expose the fundamental response info...
    connection.url, connection.headers, ...
    # Also expose the SocketStream primitives...
    connection.read(...), connection.write(), ...

With HTTP/2, the socket stream would actually wrap up an AsyncSocketStream/SyncSocketStream together with the stream ID, and handle the data framing transparently.

Protocol libraries wouldn't typically expose this interface themselves, but rather would expose whatever API is appropriate for their own cases, using httpx in their implementation to establish the initial connection. They might provide a mechanism for passing an existing http.Client/httpx.AsyncClient instance to their library for users who want to eg. share WebSockets over the same connections as their HTTP requests are being handled.

Nice stuff this would give us...

We don't necessarily want to rush trying to get this done, but @aaugustin's work on https://github.com/aaugustin/websockets/issues/466 has gotten me back to thinking about it, and it feels like quite an exciting prospect.

Does this seem like a reasonable way forward here?...

/cc @pgjones @florimondmanca @jlaine @aaugustin @sethmlarson

aaugustin commented 3 years ago

The Sans I/O layer in websockets is (AFAIK) feature complete with full test coverage.

However, websockets doesn't uses it yet and I haven't written the documentation yet.

If you have a preference between:

I can priorize my efforts accordingly.

Also, I don't expect you to use the HTTP/1.1 implementation in websockets, only the handshake implementation (which contains the extensions negotiation logic, and you don't want to rewrite that). You will want to work with request / response abstractions serialized / parsed by httpx rather than websockets. At some point, making this possible was a design goal. I don't swear it is possible right now :-) We can investigate together the cleanest way to achieve this.

pgjones commented 3 years ago

In my view supporting sending requests over the same connection as the WebSocket for HTTP/2 is a key feature. As an isolated connection may as well start with the HTTP/1-Handshake and avoid the HTTP/2 extra complexity.

I've not followed the httpcore/httpx structure so I can't comment on the details, sorry.

I'll also make the case for wsproto, which supports WebSockets, HTTP/1-Handshakes, and HTTP/2-Handshakes. It also works very happily with h11, and h2. It is also now typed and I would say stable - indeed we've been discussing a 1.0 release.

aaugustin commented 3 years ago

wsproto is perfectly fine as well :-)

tomchristie commented 3 years ago

Thanks folks - not going to act on any of this just yet since it's clearly a post 1.0 issue.

In the first pass of this we'd simply be exposing a completely agnostic connection upgrade API, which would allow third party packages to build whatever websocket implementations they want, piggybacking on top of httpx HTTP/1.1 and HTTP/2 connections.

We could potentially also consider built-in websocket support at that point, but let's talk about that a little way down the road.

tomchristie commented 3 years ago

So my initial take on this is that we'd want to first expose a connection upgrade API, and then built websockets support over that, so something like...

def request(...) -> ...  #  Our standard request/response interface at the Transport API level.
def connect(...) -> Connection  # New method at the Transport API level, exposing raw connection capabilities.

Then at the client level, have websocket support, that uses connect under the hood.

async with client.websocket(...) as ws:
    await ws.send(...)
    message = await ws.receive()

There's a couple of potential awkwardnesses about that tho...

So, after a bit more thinking, I reckon we should instead aim to provide a Transport-level interface specifically for websockets.

def request(...) -> ...  #  Our standard request/response interface at the Transport API level.
def websocket(...) -> WebSocket  # New method at the Transport API level, exposing websocket capabilities.

This wouldn't preclude us possibly also adding a raw "just give me the connection" level abstraction too at some other point, in order to provide for low-level CONNECT, Upgrade and HTTP/2 bi-directional streaming support. But we could treat that as a lower priority, depending on if we're actually seeing any demand/use-cases for exposing those capabilities.

def request(...) -> ...  #  Our standard request/response interface at the Transport API level.
def websocket(...) -> WebSocket  # New method at the Transport API level, exposing websocket capabilities.
def connect(...) -> Connection  # New method at the Transport API level, exposing raw CONNECT/Upgrade/HTTP2 data streaming capabilities.

The information returned from the low-level websocket method would need to be all the standard response code/headers stuff, plus an interface that just exposes something like send_event(), receive_event() and close().

There's also the question of what the API ought to look like at the httpx level. One thing that tends to be a bit fiddly here is that websockets can return either bytes or str frames, but we'd still like our users to be able to access the data in a nice type-checked fashion. Rather than expose multiple kinds of send/receive methods, we might be able to do with just these, by...

  1. Having a form like ws.send(text=...) to distinguish on sending.
  2. Having a form like msg = ws.receive(); print(msg.text) to distinguish on receiving. The .text property could strictly return str, and could raise an error if the received data frame was actually in the unexpected binary mode.
  3. For convenience we probably want a json argument in both case. We could default to handling JSON over text frames. Optionally we might include a flag on the client.websocket() method setting the expected mode to either text or binary, and using that for the JSON framing, plus erroring out if the incorrect style is sent/received anytime.
def send(*, text: str = None, content: bytes = None, json: typing.Any = None)
def receive()  # Returns an object with `.text`, `.content`, `.json`, `.payload [str|bytes]`
def close()

We can transparently deal with ping/pong frames during any .send()/receive(), and context managed async transports could also send background pings.

We might well also want .iter_bytes(), .iter_text(), and .iter_json() methods, for convenience.

I'm aware this is all in a bit of a "jotting down" style, please do feel free to let me know if I'm not being clear enough about anything here.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

tomchristie commented 2 years ago

We've actually got some neat stuff we can do around this now, but it needs documenting. Going to keep this open to track that.

See the stream extension in the httpcore docs for a rough outline.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

mvoitko commented 2 years ago

Still relevant

A5rocks commented 1 year ago

Hello! I was looking at using the stream extension from httpcore for websockets. Unfortunately, it appears I cannot get a connection that then gets upgraded.

Just crossposting my discussion since I haven't gotten a response yet and I suspect I am simply approaching this wrong: https://github.com/encode/httpcore/discussions/572.

dimaqq commented 1 year ago

I wonder what's the state of the art this year.

I was about to write a small "api server/balancer" with ~httpx~starlette server to receive requests and httpx client to forward these requests to backends, the latter being selected based on application logic.

But... it turns out I would need to support a single, pesky websocket endpoint, it too would be basically "connected" to one of the backends. I wonder how I could hack this together. 🤔

Kludex commented 1 year ago

This is about to be merged in httpcore: https://github.com/encode/httpcore/pull/581

tomchristie commented 1 year ago

Okay, so since the latest release of httpcore it's now possible to use Upgrade requests with httpx.

This means we're able to read/write directly to upgraded network streams. We can combine this with the wsproto package in order to handle WebSocket connections (over upgraded HTTP/1.1).

import httpx
import wsproto
import os
import base64

url = "http://127.0.0.1:8765/"
headers = {
    b"Connection": b"Upgrade",
    b"Upgrade": b"WebSocket",
    b"Sec-WebSocket-Key": base64.b64encode(os.urandom(16)),
    b"Sec-WebSocket-Version": b"13"
}
with httpx.stream("GET", url, headers=headers) as response:
    if response.status_code != 101:
        raise Exception("Failed to upgrade to websockets", response)

    # Get the raw network stream.
    network_steam = response.extensions["network_stream"]

    # Write a WebSocket text frame to the stream.
    ws_connection = wsproto.Connection(wsproto.ConnectionType.CLIENT)
    message = wsproto.events.TextMessage("hello, world!")
    outgoing_data = ws_connection.send(message)
    network_steam.write(outgoing_data)

    # Wait for a response.
    incoming_data = network_steam.read(max_bytes=4096)
    ws_connection.receive_data(incoming_data)
    for event in ws_connection.events():
        if isinstance(event, wsproto.events.TextMessage):
            print("Got data:", event.data)

    # Write a WebSocket close to the stream.
    message = wsproto.events.CloseConnection(code=1000)
    outgoing_data = ws_connection.send(message)
    network_steam.write(outgoing_data)

(I tested this client against the websockets example server given here... https://websockets.readthedocs.io/en/stable/)

This gives us enough that someone could now write an httpx-websockets package, similar to @florimondmanca's https-sse package.

I assume the API would mirror the sse package a little, and look something like this...

import httpx
from httpx_websockets import connect_websockets

with httpx.Client() as client:
    with connect_websockets(client, "ws://localhost/sse") as websockets:
        outgoing = "hello, world"
        websockets.send(outgoing)
        incoming = websockets.receive()
        print(incoming)

With both sync and async variants.

If anyone's keen on taking a go at that I'd gladly collaborate on it as needed.

tomchristie commented 1 year ago

Aside: WebSockets over HTTP/2 would require https://github.com/encode/httpcore/issues/592. Not really clear to me how valuable that'd be, but linking to it here for context.

aaugustin commented 1 year ago

FWIW websockets provides a Sans-I/O layer too. It used to be more feature-complete; wsproto caught up in the recent years; I don't know how the two libraries compare these days.

Based on the docs, I believe websockets' handling of failure scenarios is more robust i.e. it tells you when things have gone wrong and you should just close the TCP connection (even if you're the client).

aaugustin commented 1 year ago

One thing that websockets is missing — and that I had in mind when I wrote the Sans-I/O layer — is the ability to handshake over HTTP/2. I believe you have that :-) I'd be interested in figuring out the graft.

tomchristie commented 1 year ago

FWIW websockets provides a Sans-I/O layer too.

Neato. Step zero would be to ping up a little example similar to the wsproto based one above, to demo using the websockets Sans-IO API together with httpx for the networking. We could figure out where we wanted to go from there.

One thing that websockets is missing — and that I had in mind when I wrote the Sans-I/O layer — is the ability to handshake over HTTP/2.

I'd suppose the benefits of using httpx here are that it would mean you'd be able to support asyncio, trio, and threaded versions, add that you'd be able to lean on all the same auth, SSL config, network timeout behaviours etc. that httpx provides. No doubt you've got websockets already super well covered, but it'd be neat to have a unified http and websockets client.

We could feasibly add websockets-over-http/2 as well, yes, although it'd need a bit more work, see above.

frankie567 commented 1 year ago

I started to work on this, following what you recommended, @tomchristie: https://github.com/frankie567/httpx-ws

The main pain point for me was to actually implement an ASGITransport able to handle WebSockets using the network_stream approach. Other than that, the API in itself was quite straightforward to bootstrap.

It's still very experimental, but it's a start 😊

aaugustin commented 1 year ago

Here's one way to do it with websockets.

A pretty big difference with the example with wsproto above — I'm actually executing the opening handshake logic, meaning that extensions, subprotocols, etc. are negotiated. In practice, this means that compression works.

Also, lots of small things could be cleaner: for example, httpx insists on having a http:// url while websockets wants a ws:// url.

import httpx

# ClientConnection is renamed to ClientProtocol in websockets 11.0.
# Sorry, I grew unhappy with my inital attempt at naming things!
# I'm using the future-proof name here.
from websockets.client import ClientConnection as ClientProtocol
from websockets.connection import State
from websockets.datastructures import Headers
from websockets.frames import Opcode
from websockets.http11 import Response
from websockets.uri import parse_uri

def connect_to_websocket(url):

    # Force the connection state to OPEN instead of CONNNECTING because
    # we're handling the opening handshake outside of websockets.
    protocol = ClientProtocol(
        parse_uri(url.replace("http://", "ws://")),
        state=State.OPEN,
    )

    # Start WebSocket opening handshake.
    request = protocol.connect()

    with httpx.stream("GET", url, headers=request.headers) as response:

        # Get the raw network stream.
        network_steam = response.extensions["network_stream"]

        # Convert httpx response to websockets response.
        response = Response(
            response.status_code,
            response.reason_phrase,
            Headers(response.headers),
        )

        # Complete WebSocket opening handshake.
        protocol.process_response(response)

        # Write a WebSocket text frame to the stream.
        protocol.send_text("hello, world!".encode())
        for outgoing_data in protocol.data_to_send():
            network_steam.write(outgoing_data)

        # Wait for a response.
        incoming_data = network_steam.read(max_bytes=4096)
        protocol.receive_data(incoming_data)
        for frame in protocol.events_received():
            if frame.opcode is Opcode.TEXT:
                print("Got data:", frame.data.decode())

        # Write a WebSocket close to the stream.
        protocol.send_close()
        for outgoing_data in protocol.data_to_send():
            network_steam.write(outgoing_data)

if __name__ == "__main__":
    connect_to_websocket("http://127.0.0.1:8765/")
aaugustin commented 1 year ago

Re. asyncio / trio / threads, actually websockets isn't all that well covered:

tomchristie commented 1 year ago

for example, httpx insists on having a http:// url while websockets wants a ws:// url.

Would someone like to raise an issue so we can resolve that?

There's a very minor change needed in httpcore.

We do already handle the correct default port mapping for ws and wss, and httpx will send ws URLs to the transport layer, so it's just the one fix pointed to above that's needed.

@aaugustin - Thanks for your example above! I've reworked that to provide a basic API example...

import contextlib

import httpx

from websockets.client import ClientConnection as ClientProtocol
from websockets.connection import State
from websockets.datastructures import Headers
from websockets.frames import Opcode
from websockets.http11 import Response
from websockets.uri import parse_uri

class ConnectionClosed(Exception):
    pass

class WebsocketConnection:
    def __init__(self, protocol, network_steam):
        self._protocol = protocol
        self._network_stream = network_steam
        self._events = []

    async def send(self, data):
        self._protocol.send_text("hello, world!".encode())
        for outgoing_data in self._protocol.data_to_send():
            await self._network_stream.write(outgoing_data)

    async def recv(self):
        while True:
            if not self._events:
                incoming_data = await self._network_stream.read(max_bytes=4096)
                self._protocol.receive_data(incoming_data)
                self._events = self._protocol.events_received()
            for event in self._events:
                if event.opcode is Opcode.TEXT:
                    return event.data.decode()
                elif event.opcode is Opcode.CLOSE:
                    raise ConnectionClosed()

@contextlib.asynccontextmanager
async def connect(url):
    protocol = ClientProtocol(
        parse_uri(url.replace("http://", "ws://")),
        state=State.OPEN,
    )

    # Start WebSocket opening handshake.
    request = protocol.connect()

    async with httpx.AsyncClient() as client:
        async with client.stream("GET", url, headers=request.headers) as response:
            # Get the raw network stream.
            network_steam = response.extensions["network_stream"]

            # Convert httpx response to websockets response.
            response = Response(
                response.status_code,
                response.reason_phrase,
                Headers(response.headers),
            )

            # Complete WebSocket opening handshake.
            protocol.process_response(response)

            yield WebsocketConnection(protocol, network_steam)

You can then use that with asyncio...

import asyncio

async def hello(uri):
    async with connect(uri) as websocket:
        await websocket.send("Hello world!")
        print(await websocket.recv())

asyncio.run(hello("http://localhost:8765"))

Or with trio...

import trio

async def hello(uri):
    async with connect(uri) as websocket:
        await websocket.send("Hello world!")
        print(await websocket.recv())

trio.run(hello, "http://localhost:8765")

To implement the equivalent threaded version, drop the async/await calls everywhere, and use contextlib.contextmanager and httpx.Client.

@frankie567

I started to work on this, following what you recommended, @tomchristie: https://github.com/frankie567/httpx-ws

That's looking pretty neat. It occurs to me that a neater API would be to make the client instance optional, so that you've got the basic case covered...

with connect_ws(client, "http://localhost:8000/ws") as ws:
    message = ws.receive_text()
    print(message)
    ws.send_text("Hello!")

and if you want shared connection pooling, then...

with httpx.Client() as client:
    with connect_ws("http://localhost:8000/ws", client) as ws:
        message = ws.receive_text()
        print(message)
        ws.send_text("Hello!")
wholmen commented 1 year ago

Is there a plan to get this built into AsyncClient?

I'm struggling a bit to write end-to-end tests where I want to listen to websockets in the background while i post data to fastapi.

I will try to work with your examples, but this really is a lot of code that would be nice to have as a method on AsyncClient like Starlette has on it's TestClient

frankie567 commented 1 year ago

@wholmen You can try the library I've just created: https://github.com/frankie567/httpx-ws

In particular, here is how you could set up a test client to test a FastAPI app: https://frankie567.github.io/httpx-ws/usage/asgi/

tomchristie commented 1 year ago

So I suppose we should add this and https://github.com/florimondmanca/httpx-sse to the https://www.python-httpx.org/third_party_packages/ docs?

They're such important use cases that I'd probably suggest something like prominent "Websockets" and "Server Sent Events" headings above the existing "Plugins"?

ll2pakll commented 1 year ago

I needed a behavior where I could connect to the websocket and listen to messages from the server indefinitely, until I needed to disconnect, while making sure that every time a message came the program would perform the action I wanted. In this implementation, it didn't work so the recv method would save first message and wouldn't listen to anything after that, but would endlessly return the message. Chat-GPT made some changes to the method and now it works the way I need it to. If you put it in a loop, it will work as long as you need. I'm sharing, maybe it will be useful for someone:

    async def recv(self):
        while True:
            incoming_data = await self._network_stream.read(max_bytes=4096)
            self._protocol.receive_data(incoming_data)
            self._events = self._protocol.events_received()
            for event in self._events:
                if event.opcode is Opcode.TEXT:
                    return event.data.decode()
                elif event.opcode is Opcode.CLOSE:
                    raise ConnectionClosed()

async def hello(url):
    async with connect(url) as websocket:
        while True:
            # Send a message to the server
            await websocket.send("Hello world")
            # Receive a message from the server
            message = await websocket.recv()
            # Print the message
            print(message)
tomchristie commented 1 year ago

@ll2pakll Thanks for the prompt. I can see the error there now, although the Chat-CPT version isn't quite right either. (Might block reading from the network while there's pending events that could be returned.)

Here's an updated ws_proto based implementation that'll work with either asyncio or trio... https://gist.github.com/tomchristie/3293d5b118b5646ce79cc074976744b0

SubeCraft commented 5 months ago

Not websocket support so ?