2018/9/20 Release Notes: ECDSA, PEM, better garbage collection

Hi all,

Many people don’t realize this, but we update Workers every single week. Historically we haven’t been telling people what changed in every release, but we’ve decided to start posting release notes starting this week. This is somewhat of an experiment; we may change the format in future weeks.

This week:

New features:

  • V8 has been updated to version 7.0.
  • The WebCrypto API now supports ECSDA import, signing, and verification.
  • The WebCrypto API now supports PKCS#8 and SPKI import for RSASSA-PKCS1-v1_5 and ECDSA key imports. These are the formats commonly encoded in PEM files, e.g. by the openssl command-line tools. (Previously, only JWK was supported.)
  • You can now use the Cache API to manipulate the main cache (which normal fetch() calls go through) in addition to privately-namespaced caches, via the caches.default object. (This diverges from the standard, which offers no way to manipulate the main cache.)
  • Added new convenience helpers for Unannounced Feature S. (Stay tuned.)

Bug fixes:

  • We discovered that garbage collection was not correctly collecting objects when a reference cycle existed where at least one leg of the cycle was between two native-code objects. For example, a FetchEvent object contains a native reference to a Request object. Scripts which created a reference in the opposite direction – for example, by writing event.request.event = event – would leak memory, and would eventually go over their memory limit and be killed. This has been fixed.
  • Improved error messages produced when saving an invalid script that uses Unannounced Features W or C. (Stay tuned.)
  • Internal stability fixes.

Any chance to get more insight into the magical land of workers? :slight_smile: Is that some custom built or Node.js based?

One thing it’s not is Node.js based! Workers have 1/12th the memory overhead of a Node process, and something like 1/200th the cold-start time.

Hi @sandro,

The Workers runtime is an all-new C++ server runtime built on V8. It does not use Node.js, because Node is not designed for strong sandboxing and multiple tenants. In order to allow every domain’s Worker code to run at every one of our 154-and-growing locations, we needed to create an environment where we can start up a worker instantaneously and run potentially tens of thousands of workers per machine.

I blogged about this a while back here: https://blog.Cloudflare.com/introducing-Cloudflare-workers/


So you basically built a custom Node.js-alike runtime on V8?

Thanks for the link, I’ll check it out :+1:

You mention that we can purge the cache by URL but not how, so, how?

Hi @thomas4,

You mention that we can purge the cache by URL but not how, so, how?

You can paste any URL into the cache purge UI in the Cloudflare Dashboard, or use the “Purge Files by URL” API: Cloudflare API Documentation

Ah, perfect! Glad this is available on all tiers as well :+1: