Can someone on the CF team give the official answer as to the relationship between CPU time and websockets on DO? For example, if a websocket connection is sending some sort heartbeat request to a DO, and that DO is doing some CPU work to handle them (say 1ms per request), is that websocket connection getting dropped after 50 of those heartbeat requests?

oh so this allows a worker to connect to another websocket endpoint? (say a nonworker like wss://echo.websocket.org)

Yes

very interesting usecase

It allows you to connect to any web socket server

I would recommend cfw-easy-utils to make it easier

so many ideas in my head wow this opens up so many possibilties

like this makes it possible to setup a NoVNC proxy + auth without jumping thru 3 hoops

i have applied for the closed beta and was promised an update on the status in the queue in january but no message since then. so i am waiting for the beta to open to the public. is the plan for the public beta still q1?

hey, sorry for the missing follow-up. Yes, the team is hoping to open up the beta very soon

thanks! very soon being still in q1 tentatively?

Tentatively, yeah 🙂

thanks, so there is still hope 🤡

Excited to try out Durable Objects 😃

I had a bit of a tough time yesterday debugging this: 1. Worker receives request, calls a DO stub. 2. DO returns a 302 with a Location header containing a fully-qualified URL pointing to a different host. 3. Worker receives the response, but ignores the host of the Location and fetches from the DO again (ie, the stub's

fetch

is used, not the worker's global

fetch

). 4. Since the redirect was not intended for the DO, it barfs and returns an error. Thanks to Cloudflare following the standard fetch implementation (seriously, such a good design decision), I realized I could get around this by setting the

redirect

property on the

init

parameter to

manual

(instead of the default

follow

), but I wonder if it would be better to change the behavior of DO stub fetch to default to

manual

for fully-qualified 3xx Location headers that don't match the request host?

FWIW, this kind of issue is why I think it would make sense for Cloudflare to take DO routing magic out of special runtime stubs, and assign DOs their own URIs reachable through existing

fetch

. It would avoid issues like this, and obviate the need for the current awkward binding setup dance.

Hello! I am stuck with a bunch of workers that return

errors: { "code": 10013, "message": "workers.api.error.unknown" }

when I try to delete them. I had a suspicious issue before that, but I am not sure about the relation. I was working on a script to upload workers-chat-demo and was creating both namespaces in parallel queries. Sometimes it would fail (and that's how I guessed parallel namespace creation might be an issue), but not always. When it did not fail, the chat was deployed, and the worker served the front-end, but for some of that workers the durable object namespace was not bound. Now I try to clean everything up but cannot delete those worker scripts that were deployed without errors but did not work.

Hmm, I also get

500 Internal Server Error

when requesting bindings API endpoint for those scripts I cannot delete.

Thanks, that indeed was one of a few links google could offer me. Unfortunately, it did not help a lot, those cases look different. Also, my issue is not wrangler related, as I do not even use it.

yeah I believe it's best to ask @User about undeletable workers scripts

The problem is if durable objects exist in the same URL namespace as the public internet, the SSRF becomes possible -- if you get a URL from an untrusted third party, you can't safely fetch it without first verifying that it doesn't specify one of your internal addresses.

Actually, the same problem exists with regards to origin fetches today, since

fetch()

to your same zone bypassed cloudflare and other workers. We plan to fix that by requiring you to write something like

origin.fetch()

to explicitly go to origin, and then global

fetch()

will go to the public internet always (possibly looping back into your site's "front door").

the issue with redirects is an interesting one that I hadn't thought about, though.

to clarify, i'm not suggesting that DOs need to be internet-addressable, only that existing URL semantics can be used for addressing, such as by using the currently ignored hostname (ie,

fake-host

) to specify the DO from inside a worker.

Right. But if you use the same

fetch()

method to address durable objects and the public internet, and the difference is determined only by URL, then SSRF becomes an issue, even if they aren't publicly addressable. To be fair, basically all other cloud platforms have this problem... but I'm hoping Workers can avoid it. 🙂

interesting... but the threat model here requires fetching arbitrary URLs?

Right. But that's a common thing to want to do -- evidenced by SSRF being a common vulnerability.

heh, i guess

this.env[someRandomString].get(id).fetch(request)

is a more obvious smell then. 🙇

there's definitely some amount of opinion and design taste here... but I'm really interested to try the "always be explicit if you don't intend to fetch from the public internet" approach. If people generally get it and it solves SSRF, awesome. If people find it cumbersome, we can always try something else.