docs
Edgecast Console

Upgrading to Edgecast Applications Version 7

The Edgecast Applications platform consists of the following products:
  • Edgecast Performance improves your site’s performance and speeds up your development lifecycle.
  • Edgecast Security provides robust, multi-layered Web Application and API Protection.
  • Edgecast Sites provides optimal performance and development efficiency to your headless Jamstack applications.
Upgrading to Edgecast Applications to version 7 involves the following steps:
  1. Layer0 (Version 4 and Earlier): Rename layer0.config.js and Edgecast packages.
  2. Upgrade Node.js to version 18.x or 20.x and update your application accordingly.
  3. Create an Edgecast account.
  4. Create an organization, properties, and environments.
  5. Upgrade Edgecast packages.
  6. Update your CDN-as-code configuration to reflect changes introduced in version 7.
  7. Image Optimization
  8. Real User Monitoring (RUM) Token
  9. Build your Edgecast properties.
  10. Deploy to Edgecast
  11. Configure your Firewall
  12. Update your DNS

Step 1: Rename layer0 Components

This section only applies to Edgecast Applications version 4 and earlier. Proceed to the Upgrade Node.js step if you are using a later version.
Edgecast Applications now uses Edgecast branding for our CLI, packages, and a configuration file. Additionally, our service will no longer modify duplicate query string parameters.
Perform the following steps for each of your properties:
  1. Rename layer0.config.js to edgio.config.js.
    Edgecast Applications version 5+ ignores the layer0.config.js configuration file.
  2. Rename all references to Edgecast packages from @layer0 to @edgio.
    • package.json: In addition to renaming the Edgecast packages, you should also set their version to ^7.0.0.
      For example, the following excerpt from a package.json file references several @layer0 packages:
      JSONpackage.json version 4 and earlier
      1...
      2  "dependencies": {
      3    "@layer0/rum": "4.18.1",
      4  },
      5  "devDependencies": {
      6    "@layer0/cli": "4.18.1",
      7    "@layer0/core": "4.18.1",
      8    "@layer0/devtools": "4.18.1",
      9...
      You should update all of these references as shown below.
      JSONpackage.json version 7
      1...
      2  "dependencies": {
      3    "@edgio/rum": "^7.0.0",
      4  },
      5  "devDependencies": {
      6    "@edgio/cli": "^7.0.0",
      7    "@edgio/core": "^7.0.0",
      8    "@edgio/devtools": "^7.0.0",
      9...
    There may be additional @layer0/* dependencies listed in your site’s package.json file that are not listed above. Update those dependencies to @edgio/*. After which, there should be no remaining @layer0/* references in the file.
    • Import Statements: Rename Edgecast packages within each import statement from @layer0 to @edgio. You can find these import statements within various files, such as routes.ts, sw/service-worker.js, and your Next and Nuxt configuration files.
      For example, the following excerpt from a routes.ts file imports various @layer0 packages:
      JavaScriptroutes.ts version 4 and earlier
      1import {isProductionBuild} from '@layer0/core/environment';
      2import {Router} from '@layer0/core/router';
      3import {nextRoutes} from '@layer0/next';
      4...
      You should update all of these import statements as shown below.
      JavaScriptroutes.ts version 7
      1import {isProductionBuild} from '@edgio/core/environment';
      2import {Router} from '@edgio/core/router';
      3import {nextRoutes} from '@edgio/next';
      4...
    • edgio.config.js: If you are using an Edgecast connector, then you should also rename the connector defined in the connector property.
      For example, you should update connector: '@layer0/next' to connector: '@edgio/next'.
    • Next app: Rename all Edgecast references within your next.config.js from @layer0 to @edgio.
      For example, the following excerpt from a next.config.js file contains several @layer0 references:
      JavaScriptnext.config.js version 4 and earlier
      1const { withServiceWorker } = require('@layer0/next/sw')
      2const withLayer0 = require('@layer0/next/withLayer0')
      3module.exports = withLayer0(
      4...
      You should update all of these references as shown below.
      JavaScriptnext.config.js version 7
      1const withEdgio = require('@edgio/next/withEdgio')
      2module.exports = withEdgio(
      3...
      Version 7 no longer requires the withServiceWorker function to be explicitly defined within the next.config.js file and therefore it may be safely removed.
  3. Install the dependencies defined in the previous step.
    Bash
    1npm install
    This should generate an updated dependency tree in your package-lock.json or yarn.lock file. Be sure to commit these changes.
  4. Update all references to the Edgecast CLI within your package.json scripts from 0 | layer0 to either edg or edgio.
  5. Exclude build artifacts from being tracked in version control by updating your .gitignore file to:
    Bash.gitignore
    1...
    2# Edgecast generated build directory
    3.edgecast

Step 2: Upgrade Node.js

Edgecast Applications version 7.4.0+ runs your apps in Node.js v18 or v20. Therefore, we strongly recommend that you use Node.js v18.x or 20.x when developing your web application.
Learn how to use nvm to install Node.js.
Once you are using Node.js v18 or v20, update your application code to be compatible with your updated version of Node.js.
If package.json or .npmrc explicitly sets the Node.js engine version to 14.x, then you will need to update it to 18.x or 20.x.
Additionally, check your CI/CD environment for Node.js version settings. If your workflow targets Node.js 14.x, then you will need to update your files and settings to target Node.js 18.x or 20.x.

Step 3: Create an Edgecast Account

Although you already have an existing account through app.layer0.co, you will need to sign up for a new account through app.edgecast.io using the same email address, Google account, or Github account.

Step 4: Create an Organization, Properties, and Environments

Create an organization, properties, and environments by either:
To migrate your existing team, sites, and environments
  1. From the Edgecast Console, create and then copy an application key (aka API key).
    1. Click your profile icon and then select My Account.
    2. From the Application Keys section, click Edit.
    3. Click Create an API Key.
    4. In the Name option, assign a name for this key.
    5. Create Create token.
    6. Copy the token by clicking the
      Copy to clipboard icon
      icon.
    7. Click Close.
  2. From app.layer0.co, navigate to the desired team.
  3. Click Settings.
  4. Find the Edgio v7 migration section and then click Copy team and sites to Edgio v7 Console.
  5. In the Edgio console API key option, paste the API key created in step 1.
  6. Click Copy team to v7. This migration process may take up to a minute.
  7. From the Edgecast Console, verify that your organization along with its properties and environments were successfully migrated.
    Proceed to Step 5: Upgrade Edgecast Packages.

Create an Organization

If the property being migrated belongs to a Layer0 team space, then you will need to recreate it within app.edgecast.io.
  1. From the Edgecast Console, click on the
    Menu
    icon next to your name and then click on Create an Organization.
    Space menu
  2. In the Organization Name option, assign a name to your organization (e.g., my-company) and then click Create an Organization.
    Add an Organization
  3. Invite the desired team members. Learn more.
If you are an enterprise customer, contact your account manager or our sales department at 1 (866) 200 - 5463 to upgrade your newly created organization.

Create a Property

Create and then initialize your property.
  1. From the Edgecast Console, determine where you will create a property.
    • Private Space: By default, the Edgecast Console loads your private space. Access to a property created in your private space is restricted to your account. Proceed to the next step.
    • Organization: Load the desired organization by clicking the
      Menu
      icon that appears next to your name and then selecting the desired organization.
      Organization Selection
  2. Click New Property.
  3. From under the Host Property on Edgecast, click Create Property.
  4. In the Property Name option, assign a unique name to this property.
  5. Verify that the Create using CLI option is selected.
  6. Click Create Property.
  7. A quick start page will display a npx command that:
    • Installs the latest version of the Edgecast CLI.
      By default, Edgecast CLI v5.1+ collects usage and error reporting information to help improve our products. However, it omits personally identifiable information. Learn how to opt-out.
    • Initializes your property.
    Run this command from your project’s root directory. Upon running the above command:
    1. The Edgecast CLI will require that you log in to the Edgecast if it does not detect an active Edgecast session.
    2. You will need to authorize the CLI by granting it a token through which it may deploy your property to Edgecast.
    The CLI should automatically configure your property according to the detected framework. It will create a default and a production environment. Although production traffic can be served through either environment, we recommend that you use the production environment to serve production traffic. Cloud Function requests to the production environment are prioritized over other environments when heavy traffic is experienced.
    If you are not using a supported framework, then you will be prompted to provide additional information. Learn more.

Create Environments

As mentioned in the previous step, Edgecast automatically creates a default and a production environment upon initializing a property. If you require additional environment(s), then you should create them now.
Learn how to create an environment.

Step 5: Upgrade Edgecast Packages

Update all Edgecast packages to version 7 using the CLI.
Bash
1edgio use ^7.0.0
If you are upgrading from version 4 and earlier, then you should have already upgraded to version 7. In which case, the above step will indicate that your packages are up to date.

Step 6: Update your CDN-as-Code Configuration

Updating your CDN-as-code configuration to be compatible with version 7 involves:

edgio.config.js Settings

Update each property’s edgio.config.js as indicated below.
  • backends: The backends property has been replaced with the origins property. We recommend that you define them on a per environment basis through the environments property.
    For example, we will assume that your backends property is configured as follows:
    JavaScriptedgio.config.js version 6 and earlier
    1backends: {
    2  origin: {
    3    // The domain name or IP address of the origin server
    4    domainOrIp: "origin.mysite.com",
    5

    6    // When provided, the following value will be sent as the host header when connecting to the origin.
    7    // If omitted, the host header from the browser will be forwarded to the origin.
    8    hostHeader: "www.mysite.com",
    9

    10    // Uncomment the following line if TLS is not set up properly on the origin domain and you want to ignore TLS errors
    11    // disableCheckCert: true,
    12

    13    // Overrides the default ports (80 for http and 443 for https) and instead use a specific port
    14    // when connecting to the origin
    15    // port: 1337,
    16  },
    17}
    The equivalent configuration in version 7 is shown below.
    JavaScriptedgio.config.js version 7
    1...
    2environments: {
    3  // Serve production traffic through the production environment.
    4  production: {
    5    origins: [
    6      {
    7        // the key in backends
    8        name: 'origin',
    9

    10        // from hostHeader
    11        override_host_header: 'www.mysite.com',
    12

    13        // Version 7 introduces the ability to load balance across multiple origin hosts.
    14        // Previous versions only supported a single host per origin.
    15        hosts: [
    16          {
    17            scheme: 'https',
    18            location: [
    19              {
    20                // from domainOrIp
    21                hostname: 'origin.mysite.com',
    22

    23                // from port
    24                port: 443,
    25              },
    26            ],
    27          },
    28        ],
    29

    30        // In version 7, you may enable Server Name Indication (SNI) and define a SNI hint.
    31        // This configuration is essential when using multiple domains, since it allows us to
    32        // present to the browser a certificate with the correct name during the TLS handshake.
    33

    34        tls_verify: {
    35          use_sni: true,
    36          sni_hint_and_strict_san_check: 'www.mysite.com',
    37        },
    38

    39        // In version 7, the location of the shield (formerly referred to as the “global” PoP) is
    40        // configured in edgio.config.js instead of the Edgecast Console
    41        // Previous versions only supported a single shield in a single region.
    42

    43        // If your Edgecast cloud region is US East, use:
    44        shields: {us_east: 'DCD'},
    45

    46        // If your Edgecast cloud region is US West, instead use:
    47        // shields: { us_west: 'SAC'},
    48

    49        // Uncomment the following lines to define a configuration equivalent to disableCheckCert: true
    50        // tls_verify: {
    51        //   allow_self_signed_certs: true,
    52        // },
    53      },
    54    ],
    55  },
    56},
  • Hostnames: In Edgecast Applications version 6 and earlier, custom domains are defined on a per environment basis within the Edgecast Console. In version 7, if you are using CDN-as-code, we recommend that you define them on a per environment basis through the environments property. The following excerpt of a sample configuration demonstrates how to define hostnames for both the production and the default environment.
    JavaScriptedgio.config.js version 7
    1environments: {
    2  // Each key is the name of an environment in the Edgecast Console
    3  production: {
    4    hostnames: [
    5      {
    6        hostname: "www.mysite.com",
    7      },
    8      {
    9        hostname: "eu.mysite.com",
    10      },
    11    ],
    12    // Origin configurations can also be defined within an environment-specific configuration.
    13    origins: [
    14      {
    15        ...
    16      }
    17    ],
    18  },
    19  default: {
    20    hostnames: [
    21      {
    22        hostname: "staging.www.mysite.com",
    23      },
    24      {
    25        hostname: "staging.eu.mysite.com",
    26      },
    27    ],
    28  },
    29},
  • includeNodeModules: If you previously set includeNodeModules: true, then you should define it within a serverless property:
    JavaScriptedgio.config.js version 7
    1serverless: {
    2  includeNodeModules: true,
    3},
  • includeFiles: If you previously set includeFiles, then you should define it within a serverless property:
    JavaScriptedgio.config.js version 6 and earlier
    1includeFiles: {
    2  'lang/**/*': true,
    3  ‘public/**/*’: true
    4}
    JavaScriptedgio.config.js version 7
    1serverless: {
    2  include: ['lang/**/*', 'public/**/*'];
    3}
    Versions 6 and earlier supports mapping an input path to a different output path. Version 7 does not support this capability. For example, the following configuration is unsupported:
    JavaScriptedgio.config.js version 6 and earlier
    1includeFiles: {
    2  'lang/**/*': 'another/dir/in/layer0/lambda',
    3},

Routes

Edgecast Applications version 7 introduces a new JSON syntax for defining the set of features that will be applied to a route.
For example, the following route sets a CDN caching policy:
JavaScriptedgio.config.js version 7
1new Router().get('/', {
2  caching: {
3    max_age: '1d', // cache for 1 day at the edge
4  },
5});
The equivalent route in version 6 and earlier is:
JavaScriptedgio.config.js version 6 and earlier
1new Router().get('/', ({cache}) => {
2  cache({edge: {maxAgeSeconds: 60 * 60 * 24}});
3});
In order to ease the transition to version 7, we provide limited support for legacy syntax. However, the following syntax is unsupported:
  • fallback(): The fallback() method, which is unsupported in version 7, executes when no other route is matched. If you are trying to proxy a request to a legacy origin, then you may do so by mapping the desired hostname to an origin configuration through the default_origin_name property.
    JavaScriptedgio.config.js version 7
    1environments: {
    2  // Each key is the name of an environment in the Edgecast Console
    3  production: {
    4    hostnames: [
    5      {
    6        hostname: "www.mysite.com",
    7      },
    8      {
    9        hostname: "random.mysite.com",
    10        default_origin_name: "legacy",
    11      },
    12    ],
    13    // Origin configurations can also be defined within an environment-specific configuration.
    14    origins: [
    15      {
    16        name: 'legacy',
    17        ...
    18      }
    19    ],
    20  },
    21  default: {
    22    hostnames: [
    23      {
    24        hostname: "staging.www.mysite.com",
    25      },
    26      {
    27        hostname: "staging.eu.mysite.com",
    28        default_origin_name: "legacy",
    29      },
    30    ],
    31    origins: [
    32      {
    33        name: 'legacy',
    34        ...
    35      }
    36    ],
    37  },
    38},
    You may also manually assign an origin configuration within a route through set_origin. If you want this route to act as a catch-all, then we recommend that you position it above your other routes.
    JavaScript
    1router.get('/', {
    2  origin: {
    3    set_origin: 'myorigin',
    4  },
    5});
  • destination(): The destination() method is unsupported in version 7. However, you may assign an origin to requests through set_origin and redirect requests through url_redirect. Additionally, you may use Experimentation to distribute traffic to different destinations.
  • ResponseWriter Methods: The following ResponseWriter methods are not fully supported in version 7:
    • updateResponseCookie
    • removeResponseCookie
    • addUpstreamResponseCookie
    • removeUpstreamResponseCookie
    • setUpstreamResponseHeader
    • updateUpstreamResponseHeader

Cache Key Customization

Customize the cache key through cache_key instead of CustomCacheKey. However, if you require additional flexiblity when defining the cache key, then you may use cache_key_rewrite instead.
There are some subtle differences in our device classification implementation.
Method (Version 6 and Earlier)Variable (Version 7)
addIsBotUse %{wurfl_vcap_is_robot} instead. This variable returns true | false instead of 0 | 1.
addVendorUse %{wurfl_vcap_is_ios} and %{wurfl_vcap_is_android} instead. This variable returns true | false instead of apple | android | generic.
addBrowserUse %{wurfl_cap_mobile_browser} instead.
addDeviceUse %{wurfl_vcap_is_smartphone} and %{wurfl_cap_is_tablet} instead. These variables return true | false instead of 0 | 1.

Matching Behavior

Edgecast Applications version 6 and earlier returns an immediate response upon encountering one of the following methods:
  • proxy
  • renderWithApp
  • serveStatic
  • dir
  • static
  • send
  • compute
  • redirect
  • appShell
  • serviceWorker
  • render
In version 7, all routes that match the request are executed. This may cause unexpected behavior when multiple routes provide conflicting instructions.
We will now examine how the following routes are handled by different versions of Edgecast Applications.
JavaScriptroutes.js
1new Router()
2  .get(‘/’, ({ proxy }) => proxy(‘web’))
3  .get(‘/:path*’, ({ proxy }) => proxy(‘legacy’))
Version 6 and earlier will serve requests to / from the web origin. The second route will not take effect because the request satisfied the first proxy method. Version 7, on the other hand, matches both routes for requests to /. The first route sets the origin to web, while the second route immediately overrides the first route and sets the origin to legacy. As a result, all requests will be sent to the legacy origin.
Therefore, the origin in which routes are defined is important. We recommend placing routes with general criteria before routes with more detailed criteria.
For example, reversing the order of the routes ensures that requests to / are served from the web origin.
JavaScriptroutes.js
1new Router()
2  .get(‘/:path*’, ({ proxy }) => proxy(‘legacy’))
3  .get(‘/’, ({ proxy }) => proxy(‘web’))

Redirects

There are a variety of methods through which you may set up redirects. One method involves uploading CSV file(s) from within the Edgecast Console. The format for this CSV file does not vary by version of Edgecast Applications. This means that you may safely import CSV files exported from a previous version of Edgecast Applications.

Geolocation

Edgecast Applications version 6 and earlier adds the following geo-location request headers to all requests sent to the origin:
  • x-0-geo-city
  • x-0-geo-country-code
  • x-0-geo-latitude
  • x-0-geo-longitude
  • x-0-geo-postal-code
In version 7, geolocation headers are not included by default. However, you may define them through HTTP variables as demonstrated below.
JavaScriptroutes.js
1new Router().match('/:path', {
2  headers: {
3    set_request_headers: {
4      'x-0-geo-country-code': '%{geo_country}',
5      'x-0-geo-city': '%{geo_city}',
6      'x-0-geo-latitude': '%{geo_latitude}',
7      'x-0-geo-longitude': '%{geo_longitude}',
8      'x-0-geo-postal-code': '%{geo_postal_code}',
9    },
10  },
11});

Device Classification

Edgecast Applications version 6 and earlier adds the following device classification headers to all requests sent to the origin:
  • x-0-device
  • x-0-device-is-bot
  • x-0-vendor
  • x-0-browser
In version 7, device classification headers are not included by default. However, you may define them through HTTP variables as demonstrated below.
Header (Version 6 and Earlier)Variable (Version 7)
x-0-device-is-botUse %{wurfl_vcap_is_robot} instead. This variable returns true | false instead of 0 | 1.
x-0-vendorUse %{wurfl_vcap_is_ios} and %{wurfl_vcap_is_android} instead. These variables return true | false instead of apple | android | generic.
x-0-browserUse %{wurfl_cap_mobile_browser} instead.
x-0-deviceUse %{wurfl_vcap_is_smartphone} and %{wurfl_cap_is_tablet} instead. These variables return true | false instead of smartphone | tablet | mobile | desktop.
Example:
JavaScriptroutes.js
1new Router().match('/:path', {
2  headers: {
3    set_request_headers: {
4      'x-0-device-is-bot': '%{wurfl_vcap_is_robot}',
5      'x-0-geo-city': '%{geo_city}',
6      'x-0-geo-latitude': '%{geo_latitude}',
7      'x-0-geo-longitude': '%{geo_longitude}',
8      'x-0-geo-postal-code': '%{geo_postal_code}',
9    },
10  },
11});

Response Headers

Edgecast Applications version 6 and adds the following headers with each response:
Header (Version 6 and Earlier)Header (Version 7)
x-0-caching-statusView additional information about the cache policy applied to the requested content through debug cache response headers. Information on how to enable debug cache response headers is provided below.
x-0-componentsNo equivalent header.
x-0-statusx-edg-status
x-0-tx-edg-t
x-0-versionx-edg-version
To enable debug cache response headers
  1. Add a route that enables debug cache response headers. A sample route is provided below.
    JavaScriptroutes.js
    1new Router().match('/:path', {
    2  headers: {
    3    debug_header: true,
    4  },
    5});
  2. Send the following header with each request: x-ec-debug:x-ec-cache,x-ec-cache-remote,x-ec-check-cacheable,x-ec-cache-key,x-ec-cache-state
    Learn more.

Step 7: Image Optimization

If you currently optimize images through opt.moovweb.net, then you should perform the following steps to update to the latest version:
  1. Enable the Optimize Images feature (optimize_images) for the desired set of images.
  2. Update all opt.moovweb.net URLs to point directly to the image. Apply the same set of query string parameters, with the exception of img, to each new URL.
    Example: Convert the following sample URL from: https://opt.moovweb.net?quality=30&width=100&img=https://edgio-community-examples-v7-image-optimization-live.glb.edgio.link/images/demo.jpg
    To this:
    https://edgio-community-examples-v7-image-optimization-live.glb.edgio.link/images/demo.jpg?quality=30&width=100
View:

Step 8: Real User Monitoring (RUM) Token

If you are tracking Core Web Vitals through RUM, then you will need to update the initEdgioRum script to use your version 7 token. Your version 7 token is provided on the Core Web Vitals page.
HTML
1<script defer>
2  function initEdgioRum() {
3    new Edgio.Metrics({
4      token: 'ab1234c5-d6ef-789a-12c0-bb48102c2023', //version 7 token
5    }).collect();
6  }
7</script>
8<script
9  src="https://rum.edgio.net/latest.js"
10  defer
11  onload="initEdgioRum()"></script>

Step 9: Build your Edgecast Properties

Build each of your Edgecast properties by running the following command in its root directory:
Bash
1edgio build
If you encounter a build issue as a result of upgrading Node.js, then you should perform one or more of the following troubleshooting steps:
  1. Check whether you have defined a different Node.js or npm version in either a npm config file (.npmrc) or within package.json. If so, update it to the correct version and then run edgio build to rebuild your Edgecast property.
    Run node --version to check the Node.js version that you are currently using. This command should return 16.x.x (e.g., 16.18.0). Use this version information when updating .npmrc or package.json.
  2. Clear node_modules and rebundle your project by running the following command:
    Bash
    1npm ci
    Run edgio build to rebuild your Edgecast property.
  3. Regenerate a new dependency tree by running the following command:
    Bash
    1npm i --package-lock-only
    Run edgio build to rebuild your Edgecast property.

Step 10: Deploy to Edgecast

Once you have successfully built your property, run the following command to deploy your configuration to the default environment:
Bash
1edgio deploy
2

3// Alternatively, you may explicitly specify the default environment.
4// edgio deploy --environment=default
Once it has successfully deployed, run the following command to deploy your configuration to the production environment:
Bash
1edgio deploy --environment=production

Step 11: Configure your Firewall

Edgecast Applications version 7 uses a different set of IP blocks than previous versions. This means that you need to update your firewall to allow:
  • API Domain: You must allow traffic from the following domain: api.edgecast.app. If you plan on deploying to a development or CI/CD environment, then you will also need to allow this domain for the firewall for those environments.
  • IP Blocks: You must allow traffic from Edgecast IP blocks if you plan on using origin configuration(s) (aka backends).
View our IP blocks by clicking Instructions from the Origins page.
Learn more about firewall setup.

Step 12: Update your DNS

If you are an enterprise customer and have not already reached out to your account manager to upgrade your organization, please do so before serving traffic through Edgecast Applications version 7. You may contact our sales department at 1 (866) 200 - 5463.
Once you are ready to serve traffic through Edgecast, you will need to update the DNS for each of your hostname(s). Specifically, version 7 requires a CNAME record that points to a service domain that is either specific to your property’s:
Although version 6 supports both A and CNAME records, version 7 only supports CNAME records.

Migration Complete

Congratulations on successfully migrating Edgecast to version 7!

Additional Considerations

Review the following changes and revise your configuration as needed:

Cache-manifest.js File

If you detect 404 Not Found requests for cache-manifest.js after upgrading to version 7, verify that:
  • You have upgraded the @edgio/prefetch library to version 7.
  • Your application no longer references the @layer0/prefetch library.

JWT Access Control End-of-Life

Edgecast Applications version 6 does not support JWT access control. Previous versions allowed you to configure on a per route basis whether requests would be allowed or denied according to a JWT token.

Permalink Indexing

Edgecast Applications version 5.1+ automatically adds the x-robots-tag: noindex, nofollow header all responses being served from edge links and permalinks. This prevents search engines from indexing those links. By default, this header will not be added to any responses served from a custom domain. Prior to version 5.1, the .noIndexPermalink() function was an opt-in solution to achieve the same effect.
As a result, the .noIndexPermalink() router function is now deprecated and serves no purpose. We recommend that you remove this function from your routes.[js|ts] file.
However, if you want to override this default behavior and allow search engines to index all permalinks, you can pass the option indexPermalink set to true to the Router constructor:
JavaScript
1new Router({indexPermalink: true});

GraphQL Caching End-of-Life

Edgecast ended support for caching of GraphQL operations. If your Edgecast router (routes.[js|ts]) contains usage of .graphqlOperation(...), you should remove it. Otherwise, your application will fail to build.

Duplicate Query String Parameters

Edgecast Applications will no longer modify the request’s query string when it detects a duplicate query string parameter.
For example, we will examine how both versions of Edgecast handle the following request:
https://sports.example.com/index.html?id=123&type=Sports&type=Basketball
Edgecast Applications version 4 will modify the duplicate query string parameters as shown below.
https://sports.example.com/index.html?id=123&type=Sports%5B0%5D&type%5B1%5D=Basketball
Edgecast Applications version 7, on the other hand, will not modify the query string as shown below.
https://sports.example.com/index.html?id=123&type=Sports&type=Basketball
Review your code to see whether it generates duplicate query string parameters. If it does, update it to handle multiple query string parameters with the same name.

Log Data

Edgecast Applications version 7 introduces Real-Time Log Delivery (RTLD). RTLD allows you to define the set of data that will be logged and where log data will be sent (e.g., your web server, AWS S3, or Azure Block Blob). It consists of various modules that allow you to deliver log data for CDN, WAF, Rate Limiting, Bot Manager, and Cloud Functions.
Key information:
  • RTLD CDN is the module that replaces access logs (version 6). Access logs are mapped to RTLD CDN log fields below.
  • RTLD Cloud Functions logs requests processed by Cloud Functions. This includes Edgecast Sites requests. Use this module to deliver Server Logs, including Deep Request Inspection, to the desired destination.
  • RTLD CDN allows you to log request headers, response headers, and cookies. This makes it very flexible with regards to the set of data that can be logged.
  • A blank RTLD CDN (Version 7) cell indicates that, by default, the corresponding access log cannot be mapped to a RTLD CDN log field, a request header, a response header, or a cookie. However, you may still be able to log that data by setting a response header within your code and then logging that response header.
Access Logs (Version 6)RTLD CDN (Version 7)More Information
acreq_hdr_accept_encodingLog the Accept-Encoding request header.
asnclient_asn
beVersion 7 does not expose the backend configuration name.
bipThe proxy_ip log field returns an IP address that may identify an Origin Shield server or a web server associated with your origin configuration.
bkVersion 7 introduced Experimentation as a replacement for Traffic Splitting and A/B Testing. Log the cookie_x_edg_experiments cookie.
bldreq_hdr_x_edg_versionLog the x-edg-version request header. The first value reported by this response header is the deployment version.
botVersion 7 introduced sophisticated bot detection through Bot Manager Standard and Advanced. Manage log data for Bot Manager events through RTLD Bot.
brThe user_agent log field returns the client’s user agent. Define logic within your destination (e.g., Splunk) to translate this value to a browser name.
ccclient_country_code
ceresp_hdr_content_encodingLog the Content-Encoding response header.
ckhThe x-ec-cache-key debug cache header returns the cache key. Learn how to include this header in the response. After which, you may log this header.
clvAn approximation to this field may be achieved through the cache_status and proxy_type log fields.
codestatus_code
cscache_statusThe cache_status field does not indicate the reason why the response was not cached.
ctresp_content_typeLog the Content-Type response header.
cvVersion 7 does not expose the Edgecast edge compiler version.
cyclient_city
doneVersion 7 does not return request completion status.
dsVersion 7 introduced Experimentation as a replacement for Traffic Splitting and A/B Testing. Experiment and bucket information is passed within the x-edg-experiments-info upstream request header. Expose this information by passing this info back to the client as a cookie or a response header and then logging that custom response header or cookie.
dvVersion 7 returns device type information through feature variables (i.e., %{wurfl_vcap_is_full_desktop}, %{wurfl_vcap_is_smartphone}, %{wurfl_cap_is_tablet}, and %{wurfl_cap_is_wireless_device}). Expose the device type by passing the desired feature variables as a cookie or a response header and then logging that custom response header or cookie.
eidresp_hdr_x_edg_versionLog the x-edg-version response header. The last value returned by this header is the environment ID.
erVersion 7 does not indicate when a custom response is sent as a result of the send method.
evresp_hdr_x_edg_versionLog the x-edg-version response header. The second value reported by this header is the environment version.
h2client_protocolValid values are: HTTP_1_0, HTTP_1_1, and HTTP_2_0
hhhost
hridExpose the request ID by passing the %{http_x_ec_uuid} feature variable as a cookie or a response header and then logging that custom response header or cookie.
icresp_x_ec_check_cacheableThe x-ec-check-cacheable debug cache header indicates cache eligibility. Learn how to include this header in the response. After which, you may log this header.
ipclient_ip
loclient_geo_longitude
lpVersion 7 does not indicate whether a page was served due to Incremental Static (Re)Generation.
ltclient_geo_latitude
metmethod
pcExpose the postal code by passing the %{geo_postal_code} feature variable as a response header or cookie and then logging that custom response header or cookie.
preresp_x_edg_pLog the x-edg-p response header.
prlVersion 7 has not yet introduced support for static prerendering.
prodVersion 7 does not indicate whether a request was directed to the production environment. However, the last value reported by the x-edg-version response header is the environment’s system-defined ID.
pshVersion 7 does not support HTTP/2 server push.
rfrreferer
riduuid
s_rqVersion 7 does not return the request’s file size. However, you may log the request payload size through the Content-Length request header. Learn how to log headers and cookies.
s_rsfile_size
scclient_region
secManage threat log data for v7 Security through RTLD WAF, RTLD Rate Limiting, and RTLD Bot.
shThe proxy_type log field returns MIDGRESS whenever we proxy requests within our network. In addition to Origin Shield requests, this may include peering requests.
sslschemeValid values are: http and https
stlcache_statusThe cache_status log field indicates cache status. The cache status codes that correspond to stale responses are TCP_EXPIRED_HIT and TCP_EXPIRED_MISS.
tVersion 7 reports time measurements through a variety of log fields (i.e., background_fill_wait_time, read_time, prewrite_time, write_time, and total_time) and the x-edg-t response header.
timestamptimestamp
uauser_agent
urlpath
uvLog the Vary response header sent to the client. However, this header does not affect how we split the cache in v7. Version 7 solely uses the cache key to determine how to split the cache.
vVersion 7 does not expose the Edgecast version.
vnVersion 7 provides device information through a variety of feature variables, such as %{wurfl_vcap_is_android}, %{wurfl_vcap_is_ios}, and %{wurfl_cap_device_os}. Expose device information by passing the desired feature variables as a cookie or a response header and then logging that custom response header or cookie. Learn how to log headers and cookies.
wafEdgecast passes security status through the waf_prod_action, waf_audit_alert, waf_prod_alert, and rl_alert log fields. Manage all other threat log data through RTLD WAF, RTLD Rate Limiting, and RTLD Bot.
wafvManage threat log data for v7 Security through RTLD WAF, RTLD Rate Limiting, and RTLD Bot.
xffreq_x_forwarded_forLog the x-forwarded-for request header.
xmrresp_x_edg_mrLog the x-edg-mr response header.
xmsresp_x_edg_statusLog the x-edg-status response header which returns status codes for the Cloud load balancer and the Cloud worker.
xmtresp_x_edg_tLog the x-edg-t response header.
xutVersion 7 does not support the x-0-user-t response header.
zipVersion 7 does not indicate whether the response was compressed. However, you may log the Content-Encoding response header. This header indicates the type of compression applied to the response payload. Learn how to log headers and cookies.

Incremental Static Regeneration (ISR)

Edgecast Applications version 7 no longer supports generic Incremental Static Regeneration (ISR) through the means of the serveStatic(...) router method. If you are using ISR with a Next.js or Nuxt application, your application will continue to work as expected.

Default Caching Policy

By default, Edgecast Applications version 7:
  • Honors cache instructions provided by an origin server.
  • Caches eligible requests after a POP receives 2 requests for the same content. The following content types are exempt from this policy and are eligible for caching after a single request:
    • text/html
    • text/css
    • text/xml
    • application/json
    • application/javascript
    • application/xml
Edgecast Applications version 7 uses the caching feature to add caching to a route.

Compression

Edgecast Applications version 7 has stricter requirements for edge server compression.
  • Compression must be explicitly enabled for each desired content type through the compress_content_types feature.
  • Compression requires a cached version of the requested content.
  • The requested content must be greater than 128 bytes and less than 3 MB.
In addition to Brotli and Gzip compression, Edgecast Applications version 7 supports deflate and bzip2 compression. Additionally, version 7 supports transcoding compressed content when the user agent (e.g., a web browser) requests a compression method that has not been previously cached.
Learn how compression works.

HTTP/3

Edgecast Applications version 7 introduces support for communicating with clients through HTTP/3. This requires signalling HTTP/3 support to the client through the alt-svc response header.
Learn how to enable HTTP/3.