Live data from Hacker News

Code Everywhere: Why We Built Cloudflare Workers

blog.cloudflare.com

21–28 of 28 posts

Re: Code Everywhere: Why We Built Cloudflare Workers

#22
post #20

How does this deal with proxy loops? As an example, I would assume worker is making requests with the internal view of the site, but can not have an internal view of other sites or security problems would ensue.. So what happens when two of my sites have service workers fetching something from each other on each request?

As you guessed, when your worker makes a subrequest to your own zone, it goes directly to your origin server, but when you subrequest to some other domain, it goes in "the front door", and that other domain's scripts apply.

If a request bounces back such that the same worker script would need to run twice as a result of a single original request, then it fails with an error. There's nothing else we can do here: we can't let the request loop, but we also can't let it skip your script after it's bounced through a third-party script.

Re: Code Everywhere: Why We Built Cloudflare Workers

#23
post #22
post #20

How does this deal with proxy loops? As an example, I would assume worker is making requests with the internal view of the site, but can not have an internal view of other sites or security problems would ensue.. So what happens when two of my sites have service workers fetching something from each other on each request?

As you guessed, when your worker makes a subrequest to your own zone, it goes directly to your origin server, but when you subrequest to some other domain, it goes in "the front door", and that other domain's scripts apply. If a request bounces back such that the same worker script would need to run twice as a result of a single original request, then it fails with an error. There's nothing else we can do here: we ca…

To clarify, yesterday you mentioned that subrequests go through the regular caching subsystem.

Does this hold true even for subrequests to your own zone, where you say here that they go directly to the origin server?

Re: Code Everywhere: Why We Built Cloudflare Workers

#24
post #7

Earlier quoted context omitted.

What is ESI in this context? Edge Server Infrastructure?

Edge Side Includes. Imagine putting some sort of template syntax in a file, that file is cached, and when it's called from cache it grabs a file from the remote server based on the template syntax.

Notably, implementing ESI directly at Cloudflare's edge enables them to cache page fragments, rather than fully constructed pages.

That could do wonders both for the size of caches and for cache hit-rates

Re: Code Everywhere: Why We Built Cloudflare Workers

#25

It would be amazing if those workers supported WebSockets. Running game servers in them would be tempting, as long as they don't charge exorbitant prices for bandwidth.

WebSocket support is planned (not sure if it will be in v1).

The issue with game servers is that you probably need to make sure all the players in the same game instance hit the same worker. There won't be any way to do that with workers in v1. But, this is definitely something we've thought about, and as a big gamer myself I would like to see it happen someday. I have some particular ideas for a different kind of worker (not a Service Worker) that serves this use case. But it's probably a year out.

Re: Code Everywhere: Why We Built Cloudflare Workers

#26
post #6

> the most peered network on the planet That's a bold claim. I'd expect Akamai, Google and Amazon to be peered at more locations, maybe even more. Or have they become that big?

Yes. We are that big. https://bgp.he.net/report/exchanges#_participants

But this only counts IX peers I guess? Google, Amazon, Facebook will peer privately with most ISPs.

Re: Code Everywhere: Why We Built Cloudflare Workers

#27
post #22

Earlier quoted context omitted.

As you guessed, when your worker makes a subrequest to your own zone, it goes directly to your origin server, but when you subrequest to some other domain, it goes in "the front door", and that other domain's scripts apply. If a request bounces back such that the same worker script would need to run twice as a result of a single original request, then it fails with an error. There's nothing else we can do here: we ca…

To clarify, yesterday you mentioned that subrequests go through the regular caching subsystem. Does this hold true even for subrequests to your own zone, where you say here that they go directly to the origin server?

Yes. I meant that those requests don't loop back into the Worker again -- I didn't mean that they skip cache.
Post reply on HN