Early Data (0-RTT) Advanced expands the capabilities of Early Data (0-RTT) by adding support for URLs with query string parameters. For security reasons, basic Early Data disallows query string parameters, but these can be manually allowed by using this advanced behavior.

📘

Soon this advanced behavior will also allow you to support Early Data with other HTTP methods besides GET.

Before you begin

• Make sure you understand the potential security risks when enabling this behavior. You should make the necessary backend changes to prevent replay attacks when accepting 0-RTT requests at the origin. Learn more about Caveats and known issues.
• This behavior is optional and requires an additional module added to your contract. To enable it, contact your Akamai representative.
• The base Early Data (0-RTT) behavior should be present in the property in order to use the Early Data (0-RTT) Advanced behavior.

How it works

The behavior works in the same way as its base version, Early Data (0-RTT).

Features and options

Implementation

Add the Early Data (0-RTT) Advanced behavior to your property.

In contrast to the base Early Data (0-RTT) behavior, of which you can only have one instance, you can add multiple instances of the Early Data (0-RTT) Advanced behavior in your property. The behavior allows matching criteria — for example, request path, file extension, request headers and other client request attributes — to selectively enable Early Data query parameter support for specific (API) paths/endpoints or clients.

Caveats and known issues

Consider the following points when adding the Early Data behavior to your property:

• Early Data and Enforce mTLS settings. Early Data (0-RTT) Advanced isn’t compatible with the Enforce mTLS settings behavior. Remove either of these behaviors from the rule tree, as your property can't include both.
• Reduced forward security. Early Data is encrypted with keys derived from a session key. If an attacker gets access to this key, they could decrypt the early data.
• Replay attacks. An attacker could capture packets containing early data and replay them against the server. This is why the base Early Data (0-RTT) behavior limits support to GET requests without query parameters only, as these are most likely to be idempotent and don’t change permanent state. With this advanced behavior, you can manually allow more types of requests. However, make sure your backend APIs and endpoints can deal with duplicate and replayed requests, especially when processing sensitive operations. For example, payments, authentication tokens, and state changes. Akamai can’t do this for you.
• HTTP 425 Too Early Response. As per the RFC8470 standard, any request that originates from Early Data and goes forward to the origin server will include the Early-Data: 1 HTTP request header. Seeing this header, the origin server can respond with a 425 Too Early status code, which indicates the client should resend the request after completion of the TLS handshake.