The Query String Caching feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It determines how the CDN evaluates query parameters when generating cache keys, allowing you to cache each query string variant separately, ignore specific parameters, or build cache keys using only selected values. These configurations provide granular control over caching behavior for dynamic endpoints, APIs, and personalized content.

For configuration details, caching modes, and examples, refer to the main documentation: Learn more in the .

The Redirect Handle From Origin feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It allows the CDN to process selected 3xx redirect responses returned by your origin and apply custom request or response headers. This provides consistent redirect behavior for dynamic workloads and ensures greater control over how clients receive redirected responses.

For configuration details, supported redirect codes, and examples, refer to the main documentation: Learn more in the .

The Shared Cache feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It determines whether CDN edge nodes use an isolated cache namespace for your account (Default) or a shared cache namespace across multiple accounts that use the same Domain Cache Key (Share). When shared mode is enabled, identical content is cached once and reused across participating accounts, improving efficiency and reducing redundant origin requests.

For configuration details, cache modes, and examples, refer to the main documentation: Learn more in the .

The Error Status Code Cache Expiration feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It allows you to define custom cache durations for specific HTTP error codes so the CDN can temporarily store repeated error responses, reducing unnecessary load on the origin. Each status code can have its own TTL, and caching can be enabled or disabled per code based on your requirements.

For configuration details, supported behaviors, and examples, refer to the main documentation: Learn more in the .

The Advanced Origin Settings feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It allows you to define rule-based origin routing for specific URLs, extensions, or directories, enabling precise control over how dynamic traffic is forwarded to different origins. You can override protocols, ports, host headers, and assign priorities to create complex multi-origin routing behaviors.

For configuration details, match types, and examples, refer to the main Advanced Origin Settings documentation: Learn more in the .

The Origin Response Timeout feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It defines the maximum time the CDN waits for the origin to return an HTTP(S) response. When the origin exceeds this duration, the CDN stops waiting and returns a 504 Gateway Timeout, ensuring predictable behavior for dynamic workloads and preventing long wait times caused by slow or overloaded origins.

For configuration details, timeout behavior, and examples, refer to the main documentation: Learn more in the .

The Enable Gzip from Origin feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It instructs the CDN to include Accept-Encoding: gzip when requesting eligible text-based content from your origin. If the origin supports gzip, the CDN stores the compressed response; otherwise, it stores the uncompressed version. This reduces bandwidth usage on the origin → CDN path and improves overall delivery efficiency for dynamic workloads.

For configuration details, supported MIME types, and examples, refer to the main documentation: Learn more in the .

The Origin SNI Request feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It ensures the CDN includes the correct Server Name Indication (SNI) during the TLS handshake when forwarding dynamic HTTPS requests to your origin. This enables the origin server to select the appropriate SSL certificate and prevents certificate mismatch issues in multi-domain environments.

For configuration details, expected behavior, and examples, refer to the main documentation: Learn more in the .

The HSTS Protection feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It adds the Strict-Transport-Security header to HTTPS responses, instructing browsers to use HTTPS exclusively for a defined period. You can configure max-age, subdomain enforcement, and optional preload parameters to strengthen browser-side security for dynamic applications. This feature does not alter caching behavior, redirect rules, or origin routing.

For configuration details, header parameters, and examples, refer to the main documentation: Learn more in the .

The Edge Cache Expiration feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It defines how the CDN caches objects at the edge and how long cached responses remain valid before refreshing from the origin. You can configure cache modes that rely on Panel-defined TTL values, defer to origin headers, or disable caching entirely for dynamic workloads.

For configuration details, cache modes, and examples, refer to the main documentation: Learn more in the.

The X-CDN Header feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. When enabled, CDN edge servers include the X-CDN header in origin requests, allowing your origin to identify and log CDN-proxied traffic. This header is inserted only on the origin-facing request path and does not modify viewer responses, caching behavior, or delivery logic.

For configuration details, header behavior, and examples, refer to the main documentation: Learn more in the X-CDN Header documentation.

The Browser Cache Rule feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It controls browser-side caching by defining cache duration, cache modes, and rule priorities for different URL patterns, directories, or file types. These rules determine how browsers store and revalidate dynamic content, independent of CDN edge caching behavior.

For configuration details, rule types, and examples, refer to the main documentation: Learn more in the Browser Cache Rule documentation.

The Stale Cache feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It allows CDN edge servers to deliver the last cached version of an object when the origin fails to respond or returns specific error codes. You can define which origin conditions—such as timeouts, invalid headers, or 5xx errors—trigger stale delivery. This improves availability for dynamic workloads during short-term origin instability.

For configuration details, supported triggers, and examples, refer to the main documentation: Learn more in the Stale Cache documentation.

The Rewrite Origin URLs feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It rewrites incoming request paths based on defined match rules, allowing you to adjust backend routing for APIs, directory changes, or custom origin mappings. You can configure match modes, origin and target URIs, and rule priority to control how dynamic requests are transformed before reaching the origin.

For configuration details, supported match modes, and examples, refer to the main documentation: Learn more in the Rewrite Origin URLs documentation.

The ETag Verification feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It compares the ETag value returned by the origin with the ETag of the cached object and refreshes the cache when a mismatch occurs. This ensures the CDN serves the most up-to-date version of dynamic content and prevents stale objects from being delivered to end users.

For configuration details, validation behavior, and examples, refer to the main documentation: Learn more in the ETag Verification documentation.

The Mobile Device Cache feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It allows CDN edge servers to create separate cache entries based on the client’s device type, ensuring that mobile, tablet, and desktop users receive the correct version of dynamic content without cache conflicts.

When enabled, the CDN also forwards device metadata to the origin using the X-DEVICE and X-MOBILE request headers. This enables device-aware logic at the origin while preserving cache integrity at the edge.

Cache behavior, device classification logic, and forwarded headers remain consistent across Static Content Delivery and Dynamic Content Acceleration.

For configuration steps, device categories, forwarded headers, and usage examples, refer to the main documentation: Learn more in the .

The Disallow Cookie-Based Cache feature allows you to bypass CDN caching for requests that include defined cookie key–value pairs. This ensures that personalized or session-based content is always fetched from the origin instead of being served from cache.

Use this feature to prevent incorrect caching of dynamic responses while maintaining optimal cache efficiency for all other traffic.

How Disallow Cookie-Based Cache Works

When the feature is enabled:

The Cookie Base Cache feature allows you to include selected cookies in the CDN cache key for Dynamic Content Acceleration resources. This ensures that different user sessions or states receive the correct cached response without disabling caching entirely.

How Cookie Base Cache Works

When Cookie Base Cache is enabled:

The Origin Host Header feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It allows CDN edge servers to overwrite the Host header in origin requests with a custom domain you specify. This is essential for virtual hosting environments, multi-tenant systems, and origins that rely on hostname-based routing or validation. Viewer-facing responses and cache behavior remain unchanged.

For configuration details, header behavior, and examples, refer to the main documentation: Learn more in the .

The Custom Header feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It enables CDN edge servers to add, modify, or remove HTTP headers for both origin requests and CDN responses. You can define multiple rule types—such as adding origin request headers, adding or removing CDN response headers, or applying raw header directives—to customize how headers are processed during dynamic delivery.

For configuration details, rule types, and examples, refer to the main documentation: Learn more in the .

The CORS Header feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It allows CDN edge servers to set or override the access-control-allow-origin header for HTML responses when you want to explicitly control which origins may access your resources. By default, the CDN forwards CORS headers returned by your origin; enabling this feature instructs the CDN to generate or override the header instead, using either a wildcard or a defined allow list.

For configuration details, allowed domain behavior, and examples, refer to the main documentation: Learn more in the CORS Header documentation.

MNUID Cookie Base Cache generates separate cached versions of content based on the MNUID cookie value for Dynamic Content Acceleration resources.

This feature enables session-aware caching while maintaining control over cache lifetime through configurable expiry settings.

How MNUID Cookie Base Cache Works

When MNUID Cookie Base Cache is enabled:

• Medianova CDN checks incoming requests for the MNUID cookie.

• The value of the MNUID cookie is included in the cache key.

• Requests with different MNUID values are cached as separate variants.

• Cached responses remain valid for the duration defined in Cookie Expiry Time.

• After the expiry time elapses, the cached content is refreshed from the origin.

This mechanism allows session-aware caching while maintaining control over cache lifetime.

Configure MNUID Cookie Base Cache

You can manage MNUID Cookie Base Cache using the .

• Each unique MNUID value creates a separate cache entry.

• Cache variation is based on the cookie value, not just its presence.

• Cookie Expiry Time controls cache validity independently of origin headers.

Common Use Cases

• Cache dynamic pages per authenticated user session

• Improve performance for logged-in users while maintaining correctness

• Control cache lifetime for session-based personalization

• Reduce origin load for frequently accessed user-specific content

The Header Base Cache feature allows you to include selected HTTP request headers in the CDN cache key for Dynamic Content Acceleration resources.

This enables the CDN to create separate cached objects for different header combinations, ensuring correct delivery of dynamic or personalized content without disabling caching.

How Header Base Cache Works

When Header Base Cache is enabled:

• The CDN inspects incoming requests for the configured HTTP header keys.

• The specified headers and their values are included in the cache key.

• Requests with different header values are cached as separate variants.

This approach allows safe caching of responses that vary based on request headers such as language, device hints, or custom application headers.

Configure Header Base Cache

You can configure this feature from the .

• Each unique header value creates a separate cache entry.

• Header matching is based on the header name; values are evaluated dynamically.

• This feature affects cache key generation, not cache bypass behavior.

Common Use Cases

• Cache responses per language using Accept-Language

• Separate cache entries for feature flags or tenant identifiers

• Cache dynamic HTML or JSON responses that vary by request metadata

The Header Value Base Cache feature allows you to explicitly allow or deny caching when a request contains a specific HTTP header value. This provides precise control over caching behavior for Dynamic Content Acceleration resources where certain header values determine whether content should be cached.

How Header Value Base Cache Works

When Header Value Base Cache is enabled:

The X-Frame Options feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It adds the X-Frame-Options header to viewer responses to control how your content can be embedded inside iframes. You can restrict framing to the same origin or specify allowed domains when selective embedding is required. This helps mitigate clickjacking risks and enforces browser-level framing policies for dynamic applications.

For configuration details, header values, and examples, refer to the main documentation: Learn more in the .

The X-XSS Protection feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It adds the X-XSS-Protection header to viewer responses to enable built-in browser filtering mechanisms on browsers that still support the header. This option is primarily intended for legacy environments and does not alter origin requests, caching behavior, or modern browser security posture.

For configuration details, header behavior, and examples, refer to the main documentation: Learn more in the .

The X-Content-Type-Options feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It adds the X-Content-Type-Options: nosniff header to viewer responses, instructing browsers not to infer MIME types and to strictly follow the Content-Type sent by the origin. This helps reduce exposure to injection or XSS risks, particularly for script and stylesheet responses. The feature does not modify origin requests or affect CDN caching behavior.

For configuration details, header usage, and examples, refer to the main documentation: Learn more in the .

The Purge feature for Dynamic Content Acceleration works the same way as for Static Content Delivery. It allows you to instantly invalidate cached content across all Medianova CDN cache layers, ensuring that users always receive the most recent version of your dynamic assets.

Purge operations remove outdated or modified files from CDN cache and trigger fresh retrieval from your origin upon the next request. This guarantees consistency and fast propagation across all edge and shield locations.

For detailed usage steps, behavior, and best practices, please visit the main Purge documentation below:

Learn all about Purge

The Compression feature for Dynamic Content Acceleration operates the same way as in Static Content Delivery. It enables CDN edge servers to deliver compressed responses using Gzip or Brotli based on the client’s Accept-Encoding header, improving performance and reducing bandwidth consumption for dynamic workloads. Compression settings, supported MIME types, and behavior remain identical across Static and Dynamic delivery modes.

For configuration steps, supported encodings, and detailed behavior, refer to the main documentation: Learn more in the Compression documentation.

The Prefetch feature for Dynamic Content Acceleration functions the same way as for Static Content Delivery. It allows you to fetch and cache specific files from your origin in advance, ensuring faster delivery and reduced latency across Medianova’s global CDN.

Prefetch proactively loads the requested file into CDN cache layers before the first user request — helping you minimize time-to-first-byte (TTFB) for large or frequently accessed content.

For full configuration steps, best practices, and behavior details, please visit the main Prefetch documentation below:

Learn all about Prefetch

Page Rules for Dynamic Content Acceleration operate the same way as in Static Content Delivery. They allow you to apply rule-based caching and optimization logic for specific URL paths and file extensions. This enables fine-grained control over performance behavior for dynamic applications, APIs and mixed static–dynamic workloads.

Use Page Rules when you need to override the default caching logic, apply custom TTLs, control headers, or modify delivery behavior for selected routes.

For full configuration steps and available rule types, refer to the main Page Rules documentation:

Learn more: Page Rules Documentation

Dynamic Page Cache Behavior

Dynamic Content Acceleration accounts include an additional setting under Page Rules: Dynamic Page Cache.

This setting controls whether HTML, JSON and other dynamic text-based responses can be cached using the TTL defined in a Page Rule.

How Dynamic Page Cache Works

When to Enable Dynamic Page Cache

Enable this option if your application can safely serve cached HTML/JSON responses for the specified duration — for example:

• Landing pages with infrequent updates

• API responses that are cache-friendly

• Server-rendered pages that do not change per user

Leave it disabled for:

• Personalized pages

• User-specific HTML

• Sensitive JSON or rapidly changing dynamic data

Supported Rule Components

Dynamic Content Acceleration supports the same rule components as Static Content Delivery:

• File Path Match (directory, wildcard, regex)

• File Extensions

• Cache Type and TTL

All rule logic is evaluated in the same manner as Static Content Delivery.

Example Use Case

Scenario: A customer wants to cache HTML responses under /blog/ for 30 seconds but does not want to cache dashboard or personalized pages.

Configuration:

• File Path: /blog/

• File Extension: html

• Cache Type: Edge

Result: HTML pages under /blog/ are cached for 30 seconds. Other dynamic pages remain uncached.

Notes

• Page Rules override the global Caching tab for matching requests.

• Dynamic Page Cache applies only if the rule includes a TTL.

• When disabled, dynamic responses always result in an origin fetch.

Streaming Content Caching

Streaming Content Caching resources use a fixed set of 4 predefined page rules instead of dynamic, user-created rules. Unlike other resource types, you cannot add or remove page rules — the rules come pre-configured to match standard streaming content patterns (HLS, DASH and Smooth Streaming). However, you can customize per-rule settings to control how each content type is delivered.

The 4 Default Page Rules

• Rules 1–3 are manifest rules — they match playlist and index files that players fetch first to discover available streams.

• Rule 4 is a segment rule — it matches the actual media chunks (video/audio fragments) that are downloaded during playback.

Editing a Page Rule

Click the three-dot menu (⋮) on any rule to open the Update a Page Rule dialog.

The dialog contains:

• File Name and File Extensions — these are read-only and show the predefined matching criteria for the rule.

• Settings section — use the "Select a setting" dropdown to choose a setting, then click Add a setting to include it in the rule.

Note: All settings you add or remove from the settings section will only be visually added or removed on the interface side. Settings that you do not see in the interface will still be processed with their necessary default values.

Click Update to save your changes.

Default vs Custom Setting Mode

Each setting added to a page rule has a type selector with two options:

Available Settings

The following settings can be configured per page rule via the "Select a setting" dropdown:

Example: Custom CORS for DASH Manifests

Scenario: CORS is enabled globally with Default type across all rules, but .mpd (DASH manifest) requests need to allow a specific set of origins that differ from the global configuration.

Configuration:

1. Open the Page Rules tab for your Streaming Content Caching resource.

2. Click ⋮ on Rule ID 2 (.mpd) and select Edit.

3. Add the CORS setting from the dropdown.

Result: .mpd requests return CORS headers with the custom domain list. All other rules (.m3u8, Manifest, Fragment.*) continue using the global CORS configuration from the Headers tab.

Notes

• The 4 predefined rules cannot be added, removed, or reordered.

• File Name and File Extension matching criteria are fixed and cannot be modified.

• When a setting is not explicitly added to a rule, it uses its default behavior from the main configuration.