Release notes

The Monitoring section now includes a table that summarizes each of the options available to help you gain insight about the performance of your EdgeWorkers functions. This overview can help you, for example, decide if you want to deliver JavaScript logs via Enhanced debug headers or a DataStream 2 stream.

You’ll also find the following improvements to the built-in EdgeWorkers Reports.

If validation fails when activating an EdgeWorker version, details about the error are now provided in the UI.

When creating the first version of a new EdgeWorker ID, you can now see the default configuration options when you open the bundle.json file in the Code bundle editor.

Flexible composition lets you create and deploy multiple EdgeWorkers for the same website. You can enable dynamic reactivation when you activate a parent EdgeWorker by disabling the auto pin option.

By default, the initial revision created when you activate the parent EdgeWorker is pinned. Pinning prevents dynamic reactivation.

The getHeaders() method for the Response Object is now available to return a JavaScript object that contains all HTTP response headers as properties. You can use the getHeaders() method on the onOrigin Response and onClient Response event handlers.

The EdgeWorkers event handlers now support the OPTIONS HTTP method. To use the OPTIONS method you need to add the PMUSER_EW_ENABLE_OPTIONS variable to your rule and set the value to true. The name of the variable must be UPPERCASE.

The request object now supports the clientIp property. You can use it to get the original client IP address that can be either IPv4 or IPv6.

Now when you deliver JavaScript logs to an external endpoint using a DataStream 2 stream you can use the EdgeWorkers Management application to override the default log level.

Flexible composition is now available to use without having to join the Beta program.

The EdgeWorkers CLI now supports flexible composition via the following new commands:

• list-revision-activations
• activation-revision
• download-revision
• get-revision-bom
• get-revision
• list-revisions
• compare-revisions
• pin-revision
• unpin-revision

You can now use a DataStream 2 stream to deliver JavaScript logs to an external endpoint. You can also set the log-levels for the logs sent via DataStream 2.

For more information, go to the Use DataStream 2 to deliver JavaScript logs tutorial.

You can now import a specific Revision ID, instead of the active version, of a child into a parent EdgeWorker. If the owner of the child EdgeWorker continues to activate new versions of the child your dependency tree will not import these changes. This lets you freeze the dependency tree for a particular child if that tree is triggering unneeded revisions. To learn more see, Import a static revision.

You can now use subWorkers to make HTTP requests to EdgeWorkers on different properties or different accounts.

subWorkers let you divide the work and responsibilities for large projects amongst different teams. Each team can own a separate EdgeWorker, deploy it on different schedules, and use their preferred tool chains. You can also use subWorkers to share the results of computation across accounts and use Akamai optimizations to cache or accelerate a sub-request.

You can now configure an EdgeWorkers function to execute via an ESI (Edge Side Includes) fragment request on the enhanced TLS network.

To execute EdgeWorkers from an ESI fragment, add the PMUSER_ENABLE_EW_ESI_FRAG user-defined variable to your rule and set it to true. The name of the variable must be UPPERCASE.

All EdgeWorkers PMUSER_BYPASS variables are now evaluated at the stage that corresponds to the event handler. For example, PMUSER_BYPASS_EW_CLTREQ_EVENT is now evaluated in onClientRequest. Previously the PMUSER_BYPASS variables were all evaluated at the content-policy metadata stage regardless of the event handler invoking the request.

📘

This change occurred on January 31, 2024. You should review any rules created before this date that use the PMUSER_BYPASS variable to see if you need to make any adjustments.

You can now specify the severity of the logging messages included in the JavaScript logs. For more information go the log built-in module.

You no longer need to contact your Akamai representative to opt-in to this feature.

Standard TLS, used to serve non PCI compliant traffic over HTTPS via an edgesuite.net edge hostname, is supported as a delivery method for EdgeWorkers.

Flexible composition lets different development teams within an organization work separately to create and deploy multiple EdgeWorkers for the same website.

Now, two or more EdgeWorkers can handle a single request. You can create and deploy code bundles that include dependencies defined in the bundle.json file. To learn more and for instructions on how to get started, go to the Flexible composition section in this Guide or check out the EdgeWorkers APIs, also available in beta.

The getHeaders() method for the Request Object now supports all EdgeWorkers event handlers.

A built-in watermarking module is now available to use in your EdgeWorkers functions. You can use it to watermark Over-The-Top (OTT) content delivered in an Adaptive Bitrate (ABR) format. This watermarking solution currently doesn’t support interoperability with partial object caching. Please reach out to your account team if you require partial object caching.

You can now view EdgeWorkers error reports in the mPulse **App Error List **and App Error Summary dashboards. These reports include data about EdgeWorkers errors generated due to JavaScript errors. You can also find additional information in the form of a JavaScript stack trace. To learn more, go to the Integrate mPulse reports section in this guide.

The built-in crypto module now supports the sign() method that you can use to generate digital signatures.