Add this behavior to support secure HTTP/3 connections between requesting clients and the ​Akamai​ edge.

How it works

HTTP/3 retains the HTTP/1.1 and HTTP/2 concepts, but it moves away from the traditional transmission control protocol (TCP) transport layer. Instead, HTTP/3 uses the IETF QUIC protocol that handles streams by itself. This supports improved performance and a faster connection setup.

Before you begin

HTTP/3 requires a secure (HTTPS) connection between the requesting client and the ​Akamai​ edge network. To get this you can:

• Create a Domain Validation (DV), Organization Validation (OV), or a third-party certificate and assign it to a property hostname.
• Use the ​Akamai​ shared certificate in a property hostname.

📘

You need TLS 1.3 support

Your certificate needs to have transport layer security (TLS) 1.3 enabled in its deployment settings. If you create a new DV or OV certificate and use Standard or Enhanced TLS with ​Akamai​'s Certificate Provisioning System (CPS), or you use the ​Akamai​ Shared Certificate, this is automatically enabled.

You can verify your certificate

To ensure TLS 1.3 is enabled in your certificate, you can take a look at it in CPS:

1. In ​Akamai​ ​Control Center​, select ☰ > CDN > Certificates.

2. Locate the applicable certificate. In the Actions column, select … > View and Edit Certificate.

3. Return to the landing page.

👍

If you’re limited on the number of certificates you can create, and this certificate isn’t active in a property hostname, select … > Delete to remove the certificate.

4. Click … > View and Edit Deployment settings for the certificate.

5. In the SNI Advanced Configuration panel, click Edit.

6. In the TLS Protocol Versions options, ensure that either of the following options is selected:

   • Enable all TLS versions.

   • Disable specific TLS versions. If you enable this, select each version you want left out, but ensure that TLS 1.3 is deselected.

7. If you made a change here, click Submit. If you didn't need to change anything, click Cancel.

Implementation

Add the behavior and set the Enable slider to On. You can add it to these rules in your property:

🚧

You can only have one instance of the HTTP/3 behavior in your property.

• The Default Rule. All requests processed by this property will support HTTP/3 for transfer.
• A custom rule. You can add it in a custom rule, but you need to use specific match criteria:

Customize the max-age in the Alt-Svc header

When you include the HTTP/3 behavior, an Alternative Services (Alt-Svc) header is automatically generated for requests. The header presets a max-age (ma) of 93600 seconds. You can change it by adding the Alt-Svc Header behavior to a rule in your property.

Caveats and known issues

Consider the following points when adding HTTP/3:

• Keep HTTP/2. If you want to accept HTTP/2 requests, the HTTP/2 behavior needs to be in your property. HTTP/3 does not replace HTTP/2.

• HTTP/3 supports connection reuse. This lets a client reuse an open connection for any domain included in your certificate, even if that domain points to a different origin. For example, if the certificate is valid for both example1.com and example2.com, the client can reuse an existing connection to example1.com to fetch example2.com/images.html. While most browsers perform a DNS query to ensure both domains resolve to the same IP address, some clients skip this step. If the domains have different configurations, this may lead to several problems and inconsistencies:

  • Enhanced TLS and Standard TLS concerns. Requests intended for Enhanced TLS might arrive on a Standard TLS server, bypassing stricter compliance guarantees, and vice-versa.
  • HTTP/3 not working for content domains. If you only use HTTP/1 or HTTP/2 connections for your site’s base domain (example.com), HTTP/3 might not work for any subdomains (images.example.com), even if you specifically enable this behavior for them. The reused connection to the HTTP/2-only domain doesn’t send the Alt-Svc response header to the client, which prevents the HTTP/3 discovery.

  To guarantee your connections remain secure and HTTP/3 behavior works properly, use separate certificates for your base and sub domains so that clients can open new, independent TLS connections.

  📘

  As a best practice, you shouldn’t use the same domain across multiple certificates, regardless if you’re using HTTP/3. This same issue can occur with HTTP/2 Support, because it uses connection reuse, too.

  Alternatively, if you want to keep using the same certificate for multiple domains, make sure they share common settings. For example, enable HTTP/3 for all hostnames in your certificate, including base domains.

• HTTP/3 traffic in other domains in the certificate. If a requesting client doesn’t respect Alt-Svc headers and tries HTTP/3 without the HTTP/3 behavior, an HTTP/3 connection will still be opened if the certificate used in the request has QUIC enabled. This will change after beta when HTTP/3 connections will only be possible for domains if the HTTP/3 behavior is enabled in your property.

• Adaptive Acceleration's Automatic Server Push isn't supported with HTTP/3. Chromium-based browsers have dropped support for the Server Push functionality that's used by the Adaptive Acceleration feature in your ​Akamai​ property. If the connecting protocol is HTTP/3, Adaptive Acceleration will automatically preload the resources (.css, and .js) rather than pushing them. So, there's nothing you need to do. However, when you add the HTTP/3 behavior to your Ion property and you're using Adaptive Acceleration, you'll see a warning message that discusses this. Alternatively, you can use Early Hints to manually send preload and preconnect hints to the browser.

• Zero round trip time (0-RTT) connection resumption is supported. Early Data (0-RTT) connection resumption is supported through a separate behavior. If you want to use 0-RTT data with HTTP/3, you need to add at least the Early Data (0-RTT) behavior and optionally also the Early Data (0-RTT) Advanced behavior.

• The QUIC Support behavior isn’t supported. If you have both the QUIC Support behavior and HTTP/3 in your property, you’ll see a warning message. QUIC Support enables the legacy Google QUIC protocol that Google has deprecated in place of the IETF QUIC protocol that HTTP/3 uses. You can't use both in the same property. The QUIC Support behavior will be deprecated soon.