coleplx

From nginx mailing list:

Hello!

As you probably know, F5 closed Moscow office in 2022, and I no longer work for F5 since then. Still, we’ve reached an agreement that I will maintain my role in nginx development as a volunteer. And for almost two years I was working on improving nginx and making it better for everyone, for free.

Unfortunately, some new non-technical management at F5 recently decided that they know better how to run open source projects. In particular, they decided to interfere with security policy nginx uses for years, ignoring both the policy and developers’ position.

That’s quite understandable: they own the project, and can do anything with it, including doing marketing-motivated actions, ignoring developers position and community. Still, this contradicts our agreement. And, more importantly, I no longer able to control which changes are made in nginx within F5, and no longer see nginx as a free and open source project developed and maintained for the public good.

As such, starting from today, I will no longer participate in nginx development as run by F5. Instead, I’m starting an alternative project, which is going to be run by developers, and not corporate entities:

http://freenginx.org/

The goal is to keep nginx development free from arbitrary corporate actions. Help and contributions are welcome. Hope it will be beneficial for everyone.

-- Maxim Dounin

Agreed. But I don't think that part is true. I asked about that on CF's discord and people started talking about it, but no official answer.... and most likely we won't get any, unfortunately.

According to Toby, the server's owner, Cloudflare turned off their proxy, letting all attack traffic hit the origin.

Given the server's public is mostly teenagers, I doubt TubNet will release any technical post. However, it would be nice to see Cloudflare's side here.

Ugh, HN removed the timing param in the post: https://youtu.be/FoI4GPWxRtA?t=467

That's interesting. I wonder how it interacts with the Cache API.

The Cache API has kinda poor cache hit ratio today if you serve users from multiple locations since the cache is per DC per location.

If the Worker runs close to the Origin, then we wouldn't have dozens of DCs to MISS our requests anymore. Unfortunately, we'd miss all the advantagens of caching assets, like lower TTFB.

I guess running two Workers, one close to the origin and other close to the client, could replicate a bit their Smart Cache Topology. Unfortunately, I don't think it's possible to route things like that (maybe with service bindings?), and I'm pretty sure we'd end up paying twice per uncached request, lol.

Cool feature for non-cacheable content anyway