A .pfx (PKCS#12) file contains your public certificate, private key, and intermediate certificates bundled together. This guide explains how to extract the certificate (.crt) and private key (.key) using a simple Bash script with OpenSSL.

Prerequisites

Before you begin:

• A valid .pfx file provided by the customer.

• The password for the .pfx file.

• OpenSSL installed on your local machine.

• (Optional) Rename the file for clarity using this format: &#xNAN;domain.pfx — for example: medianova_com.pfx.

#!/bin/bash
# Usage: ./extract-cert.sh <pfx-password>

# 1. Extract encrypted private key
openssl pkcs12 -in domain.pfx -nocerts -out encrypted-domain.key -passin pass:$1 -passout pass:$1

# 2. Decrypt the private key
openssl rsa -in encrypted-domain.key -out domain.key -passin pass:$1

# 3. Extract public certificate
openssl pkcs12 -in domain.pfx -clcerts -nokeys -out domain.crt -passin pass:$1

# 4. Verify that the certificate and key match
first=$(openssl x509 -in domain.crt -modulus -noout | openssl md5)
second=$(openssl rsa -in domain.key -modulus -noout | openssl md5)

if [[ "$first" == "$second" ]]; then
    echo "✅ Certificate and Key match."
else
    echo "❌ Mismatch between certificate and key."
fi

This procedure automates the extraction of certificate and key files from .pfx bundles. You can now use the generated .crt and .key files to upload your own SSL certificate in the Medianova Control Panel.

Settings control the actions Medianova CDN takes once a request matches the URL pattern defined in a page rule.

The table below outlines all settings available in Page Rules from the Medianova Control Panel.

Cache Type

Use the Cache Type setting to control CDN caching.

Select Edge to specify how long the CDN may cache responses.

Select Origin to instruct the CDN to determine the maximum cache duration from origin response headers cache-control or expires .

Select Dynamic to disallow the CDN to cache responses for matching URLs.

CORS

The CORS setting controls the cross-origin resource sharing (CORS) header access-control-allow-origin in responses served by Medianova CDN edge servers.

Custom Header

Set the Custom Header Type to Default to have the CDN inherit the parent settings, as configured in the Headers tab in the Medianova Panel.

Set the Custom Header Type to Custom to disable parent setting inheritance and customize the headers. Configure the CDN to manipulate headers in requests to origin, or to manipulate headers in responses the CDN sends to clients/browsers.

Downloadable Query String Header

Use the Downloadable Query String Header setting to trigger browsers to download a file instead of displaying it.

In the page rule, toggle the setting on and specify a Downloadable Query String Header Key and a Downloadable Query String Header Value. For example, set the key to download and the value to yes to trigger a browser to download the file when it loads a URL with query string ?download=yes (and the URL matches on File Path and File Extension as configured in the page rule).

The CDN will send the content-disposition response header with in its value the attachment attribute and the path to the file. For example, content-disposition: attachment; filename="manual.pdf"

Exact Match

Turn on Exact Match to disable recursive directory processing. For example, if the page rule has File Path /dir/ and Exact Match is enabled, only URLs for files in that exact directory will match, while with Exact Match off (default) the page rule would also take action for files in subdirectories like /dir/subdir/ .

Hotlink Protection

If Hotlink Protection is turned on in the parent setting in the Security tab, a new page rule will inherit its status and configuration. The Update a Page Rule screen then shows the Hotlink Protection toggle in the active state and the Hotlink Protection Type is set to Default.

Change the Hotlink Protection Type to Custom to and confgure the Hotlink Protections that must apply to matching URLs.

Options Request

Turn on Options Request to have the CDN send edge-generated responses to requests with the OPTION method in case the origin does not respond to OPTION requests.

Query String Caching

While a new page rule inherits the parent setting for Query String Caching (as configured in the Caching tab in the Medianova Control Panel), you can customize the CDN query string caching behavior for matching URLs.

Query String Caching in Page Rules has four options:

Range Based Caching

Page Rules allows you to enable/disable Range Based Caching for matching URLs, regardless of the parent setting for Range Based Caching

(as configured in the Caching tab in the Medianova Control Panel).

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 Origin SNI Request documentation.

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 Edge Cache Expiration 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 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 Query String Caching 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 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 Error Status Code Cache Expiration documentation.

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 Shared Cache 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 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 CDN inspects incoming requests for the configured cookie key–value pairs.

• If any defined pair matches, the request bypasses the cache.

• The response is fetched directly from the origin and is not stored in the CDN cache.

This behavior applies consistently across all requests for the selected CDN Resource.

Configure Disallow Cookie-Based Cache

You can configure this feature from the .

• Cache bypass is triggered if any defined cookie rule matches.

• Cookie matching is exact; both key and value must match.

• This feature affects cache eligibility only and does not modify headers or routing logic.

Troubleshooting

Issue: Responses are still cached. Cause: The incoming cookie value does not exactly match the configured key-value pair. Fix: Capture the request cookies from the client and confirm the exact key and value.

Issue: Cache hit ratio drops unexpectedly. Cause: Too many cookie pairs are configured, or a widely present cookie is included. Fix: Remove non-essential cookies and keep only cookies that must bypass cache.

Issue: Configuration does not take effect. Cause: Changes were not saved. Fix: Confirm you selected Submit and re-check the setting state in the Caching tab.

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 CDN inspects incoming requests for the configured Cookie Key values.

• The specified cookies are included as part of the cache key.

• Requests with different cookie values are cached separately.

This allows dynamic and personalized content to be cached safely without serving incorrect responses across users.

Configure Cookie Base Cache

You can configure this feature from the .

• Each unique cookie value creates a separate cache entry.

• Cookie matching is based on the cookie name only; values are evaluated dynamically.

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

Common Use Cases

• Cache dynamic pages per user role or session type

• Serve different cached responses for logged-in vs logged-out users

• Safely cache HTML or JSON responses that depend on cookie state

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:

• Medianova CDN inspects incoming requests for the configured Header and Value.

• If the request matches the defined rule:

  • Allow — the response is eligible for caching.

This mechanism allows cache decisions to be enforced conditionally, rather than only by cache key variation.

Configure Header Value Base Cache

You can configure this feature from the .

• Only one header value-based rule can be active at a time.

• Header matching is exact; both header name and value must match.

• This feature controls cache eligibility, not cache key variation.

Common Use Cases

• Prevent caching when a request contains a debug or preview header

• Allow caching only when a specific feature-flag header is present

• Enforce cache bypass for internal or authenticated traffic

• Control caching behavior based on application-specific headers

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.

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

Comprehensive CDN documentation and API references, with integration, troubleshooting, and developer guides across all Medianova services.

Learn how to integrate and optimize your workflows with our detailed API documentation.

Introduction

Medianova is a global provider of Content Delivery Network (CDN) and cloud security services designed to accelerate and secure digital experiences. With over 50 data centers across 21 countries, it helps businesses deliver fast, reliable websites, applications, and APIs while ensuring high performance and robust security.

Key Services and Concepts

1. CDN (Content Delivery Network) A CDN optimizes content delivery by distributing it across multiple servers around the world. Medianova's CDN service ensures that content such as images, stylesheets, and scripts are delivered efficiently by caching static assets at strategically located servers. This minimizes latency and improves page load times for users.

2. Static CDN The Static CDN service is specifically designed to optimize the delivery of static content. By caching assets globally, it ensures that users receive content from the nearest server, drastically reducing load times and enhancing performance. Integration is simple, with users needing only to update asset URLs and configure settings via the Medianova platform.

3. Dynamic Content Caching Dynamic content, generated per user request, can be resource-intensive. Medianova's microcaching system allows for caching dynamic content (e.g., API responses or web pages) for brief periods, thus reducing server load and improving page speeds. This helps reduce bandwidth costs while enhancing the user experience.

4. Live Streaming Medianova provides high-quality live streaming with adaptive streaming technology. This ensures optimal video quality across devices, from desktop to mobile, while maintaining seamless playback. The platform integrates with major social media platforms for broader reach. Security features, including encryption and access controls, ensure that content is protected and accessible only to authorized users.

5. Private CDN For organizations requiring greater control, the Private CDN offers flexible, secure, and high-performance content delivery. It provides businesses with tailored solutions that allow enhanced security and content distribution management.

6. Image Optimization Medianova offers real-time image optimization. This feature allows on-the-fly image transformations such as resizing, cropping, and watermarking through simple URL calls. It also supports responsive images, ensuring that content is tailored for different devices and screen sizes, contributing to faster load times and better user experiences.

7. Stook - Cloud Object Storage Stook is Medianova's cloud object storage solution that enables businesses to store, manage, and retrieve data quickly and reliably. It is S3-compatible and eliminates the traditional barriers of egress and transaction fees, making it a cost-effective choice for scalable storage needs.

8. SSL Encryption Secure Socket Layer (SSL) ensures encrypted communication between a server and a client. Websites with SSL certificates are considered secure, and this encryption is critical for e-commerce platforms, where security is a primary concern for users.

9. Medianova WAF (Web Application Firewall) Medianova's WAF actively monitors all incoming web traffic to detect and block malicious patterns before they can affect web assets. With predefined Managed Rules, enabling these rules offers immediate protection against various security threats.

10. DDoS Protection Medianova's DDoS protection system is always active, offering continuous defense against common attack types, such as DNS Query Floods, SlowLoris, and HTTP floods. It includes several mitigation strategies, including rate limiting, IP blocking, and geoblocking, ensuring minimal disruption to services during attacks.

Conclusion

Medianova combines advanced caching, acceleration, and security features to help businesses create fast, reliable, and secure digital solutions. With global infrastructure, robust security, and easy integration, Medianova empowers businesses to deliver superior user experiences while ensuring high performance and protection against a wide range of threats.

A Distributed Denial of Service (DDoS) attack is a malicious attempt to disrupt normal traffic by overwhelming a target system or network with excessive requests. Medianova’s DDoS Protection automatically detects and mitigates these attacks without requiring any manual activation. From rate limiting to IP and Geo blocking, Medianova ensures uninterrupted availability even under heavy attack conditions.

How Medianova DDoS Protection Works

Medianova integrates several protection layers designed to stop attacks before they impact your services.

Always-On Defense

Your DDoS protection is active by default. There is no need for additional setup — your web assets are continuously monitored and protected against common attack types such as:

• DNS Query Floods

• Slowloris Attacks

• HTTPS GET / POST Floods

Anycast DNS Infrastructure

Medianova’s global distributes thousands of requests across multiple servers. This prevents traffic overload on a single endpoint and mitigates large-scale network floods.

IP and Origin Protection

You can reduce the risk of DDoS threats by concealing your origin IP before an attack begins. Medianova provides an extra layer of protection through Secure Cloud, limiting exposure of your origin infrastructure and filtering harmful traffic before it reaches your servers.

Warning: Exposing your origin IP directly allows attackers to bypass DDoS mitigation layers.

Rate Limiting and Geo Blocking

Edge-level rate limiting and Geo-based filtering restrict malicious or excessive traffic patterns. This ensures that legitimate users maintain access while harmful requests are dropped early in the network path.

WAF Integration

When combined with Medianova’s , DDoS Protection forms a complete multi-layer defense system. This integration protects not only against volumetric attacks but also against application-layer threats, such as bot floods or malicious payloads targeting web applications.

Best Practices

• Conceal your origin IP using Secure Cloud or Origin Shield.

• Combine DDoS Protection with WAF for enhanced multi-layer defense.

• Keep critical DNS zones under to distribute load globally.

Medianova DDoS Protection delivers continuous and intelligent protection against both volumetric and application-layer attacks. By combining global Anycast DNS distribution, adaptive rate limiting, and origin shielding, Medianova ensures your online services remain fast, secure, and always available.

WAF is Medianova’s intelligent web security layer that protects your applications from malicious traffic, bots, and exploits. With real-time filtering, custom rule control, and built-in analytics, it helps you prevent attacks before they reach your origin servers.

Why Choose WAF?

Medianova WAF combines ease of use, robust protection, and edge-level performance to keep your web applications secure. Unlike standard firewalls, WAF protects against both network and application-layer attacks.

• Edge-level protection – All traffic is filtered at Medianova’s global CDN edge before it reaches your origin.

• Managed Rules – Constantly updated rulesets by Medianova’s Security Team, including OWASP Top 10 protections.

• Custom Rules – Define your own rules to block, allow, or log specific requests.

Key Features

• OWASP Top 10 Protection – Shields against SQL Injection, XSS, and other common web vulnerabilities.

• Custom Rule Engine – Create granular policies based on IP, URI, headers, or user agents.

• Monitoring Mode – Observe how rules behave before full activation.

Use Cases

• Web Application Security – Protect public websites and portals from injection and XSS attacks.

• API Protection – Filter and control requests to your backend APIs.

• E-commerce Security – Prevent data breaches, bot abuse, and checkout exploitation attempts.

Built for Modern Web Security

Medianova WAF delivers enterprise-grade web protection that’s easy to deploy and manage through the . It helps you stay secure without adding complexity — protecting your applications from the edge, in real time.

Free SSL certificates provide an easy and cost-effective way to secure your CDN Resources without purchasing a commercial SSL. Medianova integrates Let’s Encrypt to automatically issue and renew these certificates through the SSL Management interface.

Hotlink Protection restricts access to your CDN Resource by verifying the Referer header in each HTTP request. When enabled, it ensures that only requests originating from your allowed domains can retrieve content from your CDN. Requests coming from unauthorized sources — such as external websites directly embedding your files — are blocked or redirected automatically.

Why Use Hotlink Protection?

Hotlink Protection helps you:

• Protect bandwidth – Prevent others from using your CDN capacity to serve their own content.

• Secure digital assets – Stop unauthorized sharing or embedding of your hosted media.

• Reduce server load – Block high-traffic external sites from consuming resources.

• Maintain brand control – Ensure your content appears only on trusted domains.

• Prevent abuse – Stop third-party sites from monetizing your media.

How Hotlink Protection Works

Hotlink Protection checks the Referer field of every HTTP request. If the Referer does not match your whitelisted domain list, the CDN automatically denies or redirects the request.

Geoblocking allows you to control which countries can access your content through the Medianova Control Panel. By enabling this feature, you can restrict or allow requests based on the visitor’s geographic origin, helping you comply with regional policies and protect your digital assets.

Why Use Geoblocking?

Use Geoblocking to manage access and enforce content distribution policies efficiently:

• Compliance and licensing – Restrict access to regions where content rights do not apply.

• Dynamic pricing models – Apply different pricing or service availability by country.

• Security enhancement – Block known high-risk regions or malicious traffic.

How to Configure Geoblocking

IP Restriction (Access Control List – ACL) allows you to manage which IP addresses can access your CDN Resource. You can choose between two modes: Whitelist or Blacklist, to define how access is granted or denied.

• Whitelist Mode: Only the IP addresses you specify are allowed to access your resource. All other IPs are denied.

• Blacklist Mode: The IP addresses you specify are denied access. All other IPs are allowed.

Why Use IP Restriction?

Use IP Restriction to:

• Protect internal or staging environments from unauthorized access.

• Restrict API access to trusted partners or corporate networks.

• Block known malicious IP ranges or suspicious activity.

• Ensure compliance with internal security policies.

Key Features

• Whitelist Mode – Only the IP addresses you specify are allowed to access the resource. All other traffic is blocked.

• Blacklist Mode – The IP addresses you specify are denied access, while all other IPs are permitted.

• Edge-Level Enforcement – Filtering occurs at the CDN edge, ensuring zero impact on origin performance.

Medianova’s IP Restriction system provides a simple yet powerful way to enforce access control at the CDN level. By validating requests before they reach your infrastructure, it prevents unauthorized access and improves overall performance stability. Combined with other Security features such as Rate Limiting, WAF, and Hotlink Protection, it forms a robust multi-layer defense mechanism.

Static Content Delivery accelerates websites and applications by distributing static assets—such as images, CSS, and JavaScript files—across Medianova’s globally distributed CDN network. By caching content at the edge, end-users receive data from the nearest server, reducing latency and improving overall page load performance.

Why Use Static CDN?

Medianova’s Static CDN provides an optimized way to serve static assets with speed, security, and scalability:

• Reduced Latency – Serve content from the nearest CDN edge location.

• Improved Page Load Times – Accelerate rendering of images, scripts, and styles.

• Lower Origin Load – Cache content at the edge to minimize backend requests.

Key Features

• Edge Caching – Automatically stores and serves static content at geographically distributed edge nodes.

• Custom Domain Support – Use your own domain (CNAME) for branded content delivery.

• SSL/TLS Encryption – Secure asset delivery with HTTPS support.

Built for Performance

Medianova’s Static CDN combines global edge coverage, intelligent caching, and secure HTTPS delivery to optimize the delivery of static assets. Whether hosting media, websites, or web applications, this service ensures users experience faster load times and consistent performance anywhere in the world.

Origin Response Timeout defines the maximum time the CDN waits for an HTTP(S) response from your origin server. If the origin does not respond within the configured duration, the CDN returns a 504 Gateway Timeout.

Adjusting this timeout helps maintain predictable performance and prevents long wait times caused by slow origin responses.

You can manage Origin Response Timeout using the Medianova Control Panel or API.

In the Medianova Control Panel, go to CDN Resources, select your resource, and navigate to Origin Settings.

Configure Origin Response Timeout

Follow the steps below to set the timeout duration.

Timeout Behavior

• The CDN waits for the origin to respond for the configured duration.

• If the timeout is reached, the CDN returns 504 Gateway Timeout to the client.

• Lower values improve failover speed; higher values allow slow origins more time to respond.

Recommended Settings

• 5–30 seconds: Fast origins or latency-sensitive applications

• 30–120 seconds: Moderate response times or variable workloads

• 120–300 seconds: Heavy processing at the origin (reports, large queries, image generation)

Troubleshooting

Issue: Clients receive 504 responses. Cause: Origin cannot respond within the configured timeout. Fix: Increase the timeout value or optimize origin performance.

Issue: Requests feel slow before failing. Cause: Timeout value is set too high. Fix: Reduce the timeout to a more suitable duration.

Edge Cache Expiration controls whether CDN edge servers cache an object and how long the cached content remains valid before it must be refreshed from the origin.

It defines the caching behavior applied at the edge, including modes that disable caching entirely or defer expiration settings to the origin.

You can manage Edge Cache Expiration in the Medianova Control Panel or via API.

Configure Edge Cache Expiration

Use this workflow to define how the CDN determines cache duration and applies expiration rules on edge servers.

• A value of 0 disables caching for both Edge and Origin modes.

• Dynamic mode always bypasses caching on edge servers.

• These settings do not impact browser caching; use for client-side caching behavior.

Best Practices

• Apply long TTL values for static assets such as images, fonts, CSS, and JavaScript.

• Use shorter TTL values for frequently updated or dynamic endpoints.

• Monitor edge cache hit ratios to optimize performance and origin load.

Error Status Code Cache Expiration defines how long selected HTTP error responses (such as 404 or 500) stay valid in the CDN cache. This reduces repeated requests to the origin when the same error occurs frequently.

You can manage Error Status Code Cache Expiration in the Medianova Control Panel or via API.

Select a CDN resource in the CDN section, and navigate to the Caching tab.

Configure Error Status Code Cache Expiration

Add an Error Status Code Definition

Define a cache duration for specific HTTP error codes.

Edit an Error Status Code Definition

Modify the cache time or status code.

Delete an Error Status Code Definition

Remove a cache rule so that future error responses bypass CDN cache.

Behaviour

• Cached error responses remain valid until the configured cache time expires.

• Deleting a definition does not immediately remove already cached error objects; existing cached content remains until expiration.

• Setting a low cache duration minimizes the risk of serving error responses for extended periods.

FAQ

Does removing a definition purge already cached error responses? No. Existing cached content remains until it expires.

Can I cache multiple error codes with different durations? Yes. Each status code can have its own cache time.

What happens if I set the cache time to zero? A value of zero disables caching for that error status code.

ETag Verification ensures that cached objects remain consistent with the latest version served by the origin. When enabled, the CDN evaluates the ETag header returned by the origin and refreshes the cached object when a mismatch is detected. This prevents outdated or stale content from being delivered to end users.

You can manage ETag Verification in the Medianova Control Panel or via API.

Select a CDN resource in the CDN section, and navigate to the Caching tab.

Configure ETag Verification

Enable or disable ETag validation to ensure cached content remains synchronized with the origin.

Behaviour

• When enabled, the CDN compares the origin’s ETag header with the cached object to determine whether a refresh is required.

• When disabled, cached objects are served without ETag-based validation.

• ETag validation improves consistency but may result in more origin requests depending on header behavior.

FAQ

Does ETag Verification guarantee that the CDN always serves the latest version? Yes. When enabled, the CDN validates the cached object using the ETag header and refreshes it if the origin indicates a change.

Does enabling ETag Verification increase origin traffic? It can. Validation requires comparing ETag values, which may trigger additional revalidation requests depending on origin behavior.

What happens if the origin does not send an ETag header? The CDN cannot perform ETag-based validation. Normal cache expiration and revalidation rules apply.

Range Based Caching allows the CDN to cache and deliver content in byte-range segments rather than requiring the entire file to be fetched or cached. This improves performance for large files such as videos, archives, or software downloads by serving only the requested portions.

You can manage Range Based Caching in the Medianova Control Panel or via API.

Select a CDN resource in the CDN section, and navigate to the Caching tab.

Configure Range Based Caching

Behaviour

• The CDN caches content in fixed-size byte segments defined by Segment Size.

• Requests for ranges within the same segment are served directly from cache.

• Useful for video playback, downloads, and large binary files where clients request only parts of a resource.

FAQ

Does Range Based Caching improve video streaming performance? Yes. It prevents the CDN from fetching the entire file when only a portion is requested, improving responsiveness.

What happens if I change the Segment Size? New segment size applies only to future cached segments. Existing segments remain until evicted.

Is this feature required for byte-range requests to work? Byte-range requests work regardless, but enabling Range Based Caching ensures partial responses can come from cache instead of the origin.

The Robots.txt File feature determines whether search engines receive a robots.txt file from the CDN and which source the file is taken from. This allows you to enable crawling for all files or defer crawling rules to your origin.

You can manage Robots.txt File settings in the Medianova Control Panel or via API.

Log in to the Medianova Control Panel, select a CDN resource in the CDN section, and navigate to the Caching tab.

Configure Robots.txt File

Choose how the CDN should provide the robots.txt file for the selected resource.

• Enabled mode always serves MN CDN’s default robots.txt content. Customers cannot upload or configure a custom robots.txt file through the Panel.

• Origin mode delegates full control to your origin server.

• Changes propagate immediately but may take a short time to be reflected across all PoPs.

FAQ

Does Medianova allow uploading a custom robots.txt file? No. In Enabled mode, the CDN serves a predefined robots.txt file that allows all crawling. To use a custom file, select Origin mode and host the file on your origin.

What happens if my origin has no robots.txt file but I choose Origin mode? The CDN will return 404 Not Found, and search engines will proceed as if no robots.txt file exists.

Does robots.txt affect CDN caching? No. It only controls search engine bot behavior and does not interact with cache rules.

The Custom Header feature allows you to add, modify, or remove HTTP headers for both origin requests and CDN responses. This configuration enables fine-grained control over how headers are passed, overwritten, or stripped at different stages of the delivery flow.

When Custom Header is enabled, you can define multiple header actions, each with a specific key–value pair and rule type. All rules are executed by CDN edge servers for the selected CDN Resource.

You can configure Custom Header in the Medianova Control Panel or via API

Configure Custom Header

Best Practices

• Header keys and values must follow valid HTTP header formatting rules.

• If the same header is modified by multiple rules, CDN edge behavior follows the order of applied rules.

• Removing headers may affect origin authentication, CORS behavior, or cache control logic.

The X-CDN Header feature adds an X-CDN header to requests that are forwarded from the CDN to your origin. This allows your origin to identify that the request is coming through Medianova CDN, which can be useful for logging, routing decisions, and origin-side analytics.

How X-CDN Header Works

You can configure X-CDN Header in the or via

When the X-CDN Header toggle is enabled:

• The CDN adds the X-CDN header to the origin request during the fetch operation.

• Your origin receives every request with this header included.

• The header allows your origin to distinguish CDN-proxied traffic from direct client traffic.

This feature is passive and does not alter cache decisions, TTL behavior, Page Rules, or viewer-facing responses.

Use Cases

Origin-side analytics

Log whether a request came through the CDN layer by checking for the X-CDN header.

Conditional behavior at the origin

Apply specific logic (e.g., rate limits, routing decisions, request tagging) based on the presence of this header.

Debugging origin fetches

Verify that requests are reaching your origin through the CDN, especially when diagnosing caching or routing flows.

Notes

• The header is inserted only on the origin request.

• It is not visible to clients and does not appear in viewer-facing responses.

• Header values may differ based on internal CDN configuration.

• Enabling the header does not change caching rules, request normalization, or delivery performance.

The Origin Host Header feature allows you to define a custom domain to be sent in the Host header of requests forwarded to your origin. Many origin servers rely on the Host header for routing, virtual hosting, or tenant identification. When this option is enabled and a domain is provided, the CDN replaces the default host value with the one you specify.

The feature does not modify viewer-facing responses and does not affect caching behavior.

How Origin Host Header Works

You can configure X-CDN Header in the or via

When the feature is active:

• The CDN overwrites the Host header in the origin request with the domain you provide.

• The domain must be entered without http:// or https://.

The purpose of this feature is to ensure compatibility with origins that require a specific hostname, especially in environments where multiple sites share the same origin infrastructure.

Use Cases

Virtual hosting environments

Ensure the correct site is selected when multiple hostnames share the same origin.

Multi-tenant systems

Send a tenant-specific domain in the Host header for proper routing.

Origin behavior validation

Match the exact hostname your origin expects for SSL/SNI evaluation or application routing logic (when applicable to host header usage).

Notes

• Enter only the domain name (e.g., subdomain.example.com).

• Do not include URL schemes such as http:// or https://.

• This feature modifies only the origin-bound request

The X-Frame Options feature adds the X-Frame-Options HTTP response header to prevent unauthorized framing of your website. This header is commonly used to mitigate clickjacking attacks by restricting how and where your content can be embedded inside an <iframe>.

When enabled, the CDN includes the header in responses according to the configuration you provide.

How X-Frame Options Works

You can configure X-CDN Header in the or via

When the feature is active:

• The CDN adds an X-Frame-Options header to viewer responses.

• If no domain is configured, the CDN sets:

  which allows framing only from the same domain.

• If one or more domains are provided, the CDN applies:

Use Cases

Prevent clickjacking

Block external sites from embedding your pages to protect users from UI redress attacks.

Allow trusted partners

Permit framing only from specific domains that require embedded content (e.g., partner dashboards, internal tools).

Enforce controlled embedding behavior

Define clear, browser-enforced restrictions on how your content is presented in external applications.

Notes

• ALLOW-FROM is not supported by all browsers. Modern security policies often prefer CSP frame-ancestors.

• X-Frame-Options does not affect API endpoints or non-HTML content.

• If multiple allowed domains are configured, behavior may vary by browser due to varying support levels.

The X-Content-Type-Options feature adds the X-Content-Type-Options header to viewer responses. This header instructs compatible browsers not to perform MIME sniffing and to rely strictly on the Content-Type declared by the server. Disabling MIME sniffing helps reduce exposure to certain injection and cross-site scripting (XSS) vectors.

How X-Content-Type-Options Works

You can configure X-CDN Header in the or via

When enabled:

• The CDN adds the following header to viewer-facing responses:

• Browsers that support this header will not attempt to infer content types and will instead enforce the value provided by the origin.

• MIME sniffing is disabled for resources such as scripts, stylesheets, and other content types that could be misinterpreted.

Use Cases

Prevent MIME sniffing

Ensure the browser does not guess content types, avoiding scenarios where a file may be interpreted as executable code.

Improve XSS resilience

Reduce attack surfaces where incorrect content-type interpretation could lead to script execution.

Enforce strict content handling

Guarantee consistent behavior across browsers by ensuring content is processed exactly as declared.

Notes

• The header is applied only to viewer responses, not to origin-bound requests.

• Modern browsers widely support nosniff, but legacy browsers may behave inconsistently.

• Enabling this header does not alter your CDN caching logic.

The X-XSS Protection feature adds the X-XSS-Protection header to viewer responses. This header instructs compatible browsers to enable their built-in XSS filtering mechanisms. While most modern browsers now ignore this header, the setting can still provide protection for legacy browsers that rely on it.

The feature does not modify origin requests or affect CDN caching behavior.

How X-XSS Protection Works

You can configure X-CDN Header in the or via

When enabled:

• The CDN adds the following header to viewer-facing responses:

• Browsers that still support the header will block pages that trigger reflected XSS heuristics.

• If disabled, the CDN does not include the header, and browsers revert to their default behavior.

This feature is primarily relevant for environments that depend on legacy browser compatibility.

Use Cases

Legacy browser support

Provide reflected-XSS filtering for older browsers that still honor the header.

Controlled security posture

Ensure consistent browser behavior across mixed device environments or corporate networks with outdated browser fleets.

Notes

• Modern browsers (Chrome, Edge, Safari) ignore X-XSS-Protection and instead rely on CSP (Content-Security-Policy) for XSS mitigation.

• This feature affects only viewer responses, not origin requests.

• Enabling the header does not prevent stored or DOM-based XSS attacks.

Page Rules trigger one or more actions on an incoming request to Medianova CDN whenever a defined URL pattern is matched.

Page Rules are available in the Medianova Panel for any CDN resource in the Page Rules tab.

Available settings for Page Rules include Cache Type, Custom Header, Geoblocking and more.

Availability

Page Rules can be configured foror CDN resources of type Small, Dynamic, Large & VOD.

The default number of allowed page rules depends on the package as shown below.

Priority Order Matters

Only one Page Rule will trigger per URL, that is the the matching page rule with the highest priority.

In the Medianova Panel, Page Rules are sorted top-to-bottom from highest priority to lowest priority. For this reason, we recommend ordering your rules from most specific to least specific.

Rate Limiting helps you maintain stable application performance by controlling how many requests a client can make in a given time frame. It protects against excessive API calls, brute-force attempts, and high-frequency requests that can degrade origin performance or service quality.

With Medianova’s edge-level implementation, rate limits are applied directly at the CDN layer — before the traffic reaches your origin servers — ensuring both reliability and efficiency.

Rate Limiting is available for Dynamic CDN Resources and can be configured per domain, path, or file extension through the .

IP Restriction enables you to define which IP addresses can access your CDN Resources by using either whitelist or blacklist rules. When configured, access control is enforced at the CDN edge, ensuring that unauthorized requests are blocked before they reach your origin server.

You can enable IP Restriction for each CDN Resource in the .

WAF (Web Application Firewall) enhances your website’s security by inspecting and filtering incoming HTTP/HTTPS traffic. You can enable it for any Dynamic CDN Resource, select the protection mode, and create Custom Rules to detect and block malicious requests.

Medianova CDN Configuration Basics document is designed to help you understand and implement the fundamental configurations necessary to leverage the full potential of Medianova's Content Delivery Network (CDN). Whether you are a web developer, content creator, or IT professional, this guide will walk you through essential concepts and steps to optimize content delivery, enhance performance, and improve user experience.

Creating a Medianova CDN Resource

To get started with Medianova CDN, follow these steps:

Rewrite Origin URLs enables you to transform incoming paths before they are forwarded to origin servers. You can configure Match Mode, Origin URI, Target URI, and Priority to adjust how paths are rewritten for directory changes, API restructuring, or backend routing needs.

You can manage Rewrite Origin URLs using the or .

In the Medianova Control Panel, go to CDN Resources, select your resource, and navigate to Origin Settings

Query String Caching defines how URLs containing query parameters are interpreted by the CDN cache. You can cache each query string variant separately, ignore selected query strings, or build the cache key using only specific parameters.

You can manage Query String Caching in the or via .

Log in to the Medianova Control Panel, select a CDN resource in the CDN section, and navigate to the Query String Caching section under the Caching tab.

Configure Query String Caching

Enable Gzip From Origin allows the CDN to request text-based files from your origin using the Accept-Encoding: gzip header.

If the origin supports gzip, the CDN stores the compressed version in cache; otherwise, it stores the uncompressed response.

Stale Cache allows CDN edge servers to deliver the last cached version of an object when the origin becomes temporarily unavailable. This includes conditions such as 500–504 errors, invalid headers, timeouts, forbidden responses, or an Updating status. Enabling Stale Cache helps maintain availability and ensures continuity of service during short-term origin instability.

You can manage Stale Cache in the or via .

Log in to the Medianova Control Panel, select a CDN resource in the CDN section, and navigate to the Stale Cache.

Configure Stale Cache

Mobile Device Cache allows the CDN to generate different cache entries based on the detected device type. This ensures that each device category receives appropriately formatted content without cache conflicts.

The feature also forwards device information to your origin using the X-DEVICE and X-MOBILE headers.

You can manage Mobile Device Cache in the

Log in to the , select a CDN resource in the CDN section, and navigate to the Caching tab.

Cross-origin resource sharing (CORS) is a browser security mechanism that determines whether a web page can load resources from a different origin. While browsers allow cross-origin images, CSS files, scripts, iframes, and videos without restrictions, other request types — such as Ajax calls and web fonts — are blocked by default under the same-origin policy.

CORS defines how browsers and servers evaluate cross-origin requests. Medianova CDN can send the access-control-allow-origin header in HTML responses to enable controlled cross-origin access.

By default, Medianova CDN forwards any CORS-related headers sent by your origin. You only need to enable CORS Header if you want CDN edges to set or override this header.

HTTP Strict Transport Security (HSTS) instructs browsers to connect to your domain only over HTTPS for a defined period of time. When enabled, the CDN adds the Strict-Transport-Security header to HTTPS responses, preventing protocol downgrade attacks and reducing the risk of session or cookie interception.

HSTS can also extend enforcement to subdomains and optionally request inclusion in browser preload lists.

How HSTS Protection Works

Gzip and Brotli compression reduces file sizes by up to 80% for common content types like HTML, CSS and JavaScript, leading to faster load times and improved user experience. This not only enhances website performance and improves SEO / Core Web Vitals, but also decreases bandwidth usage, saving CDN costs and ensuring efficient content delivery.

Compression at the Edge

Gzip compression happens at Medianova Midcache servers, which is then passed on to the Edge servers. Both the Midcache and Edge servers may cache the Gzip compressed content for faster delivery of next responses. Edge servers perform Brotli compression on-the-fly when requested by the client.

Prefetch allows you to pull specific files from your origin into the CDN cache before any user requests them. Use this feature to eliminate cache misses, reduce origin load, and ensure fast delivery to the first users.

You can initiate Prefetch via the or .

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 Advanced Origin Settings documentation.

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 Origin Response Timeout documentation.