All Products
Search
Document Center

CDN:Modify incoming response headers

Last Updated:Jun 20, 2026

When the cache on a CDN/ point of presence (POP) expires or a cache miss occurs, the CDN/ POP requests the latest content from the origin server. The content and HTTP headers returned by the origin server are called origin response headers. You can modify these headers on your origin server to define a cache policy, configure Cross-Origin Resource Sharing (CORS), and more. This allows you to optimize website loading speed, enhance content security, control resource accessibility, and improve the user experience.

Background

HTTP response headers are components of an HTTP response that carry specific parameters to the client.

When content requested by an end user is not cached on a CDN node, the CDN performs an origin fetch, and the origin server sends a response. You can modify the HTTP headers in this inbound response. For example, you can rewrite the value of the Content-Type header before it is passed to the client to ensure proper parsing. If the origin server returns an incorrect Content-Type value, the client may fail to parse the content correctly. You can resolve this issue by rewriting the header on the CDN.

Note
  • An inbound response is the HTTP message that an origin server sends to a CDN node. Modifying inbound response headers only affects the HTTP message sent from the origin server to the CDN node; it does not affect responses the CDN node serves to the end user.

  • You cannot modify inbound response headers for wildcard domains.

Use cases

Here are common use cases and examples:

  • Incorrect content type: If the content type (Content-Type) returned by the origin server does not match the actual content, the client may be unable to parse it correctly. For example, an HTML file may be incorrectly marked as plain text. You can resolve this issue by configuring the origin response header.

    Example: Change Content-Type: text/plain to Content-Type: text/html.

  • Cache policy control: If you need fine-grained control over the CDN caching policy, you can adjust the Cache-Control or Expires fields in the origin server's response headers. This helps optimize the content update frequency and cache hit rate.

    Example: Change Cache-Control: max-age=3600 to Cache-Control: max-age=86400 to extend the cache expiration time. For more information about the default cache rules of CDN, see Alibaba Cloud CDN Default Cache Rules and Priorities.

  • Cross-Origin Resource Sharing (CORS): If you want to allow web applications from other domains to access resources hosted on the CDN, you must configure the Access-Control-Allow-Origin header and other related CORS headers on the origin server. These settings ensure that when a browser performs a cross-origin request, the CDN can provide the appropriate response headers to the client to prevent CORS errors. For more information about cross-origin access issues, see Configure Cross-Origin Resource Sharing.

    Examples:

    • Access-Control-Allow-Origin: *: Allows cross-origin resource requests from all domains.

    • Access-Control-Allow-Methods: GET, POST, OPTIONS: Specifies the HTTP methods that are allowed for cross-origin requests.

  • Compressed transfer: If the origin server supports compressed transfer but has not enabled it, or if the compression algorithm used is not the most efficient, you can set the Accept-Encoding in the back-to-origin response header to instruct the origin server to use the optimal compression method.

    Example: Change Accept-Encoding: gzip, deflate to Accept-Encoding: br to prioritize Brotli compression. For more information, see Brotli Compression.

  • Redirection: When your origin server needs to redirect a user to another URL, you can set the correct redirection headers in the origin response header. For more information, see Configure 301/302 redirect following.

    Example: Location: https://www.example.com/new-page.html: Notifies the CDN and the user's browser of the new resource location for 301 or 302 redirection.

  • Custom origin behavior: You may need to add custom headers to the response to implement specific functions or for tracking purposes.

Notes

  • Multiple configurations are executed from top to bottom in the order they appear in the configuration list. The effects are cumulative. If multiple configurations modify the same header, the last one takes precedence. In the following example, Configuration 2 is the one that takes effect:

    • Configuration 1: Add the HTTP response header: cache-control: max-age=3600

    • Configuration 2: Add the HTTP response header: cache-control: no-cache

  • When rule conditions are applied, matching is determined by the priority of the conditions, not the order of the configurations.

Procedure

  1. Log on to the CDN console.

  2. In the left navigation pane, click Domain Names.

  3. On the Domain Names page, find the target domain name and click Manage in the Actions column.

  4. In the domain's navigation pane, click Origin Fetch.

  5. Click the Modify Incoming Response Header tab.

  6. Click Customize.

  7. Modify the ingress response header settings.

    Important

    If multiple operations apply to the same origin response header parameter, the operations are executed based on the following priority: Replace > Add > Change and Delete. For example, if both an add and a delete operation are configured for the same parameter, the add operation is executed before the delete operation.

    Add response header

    Parameter

    Example

    Description

    Operation

    add

    Adds the specified response header to the origin response.

    Response Header

    Custom Response Header

    Select Custom Response Header or a preset response header parameter.

    Header Name

    x-code

    Specifies the name of the custom response header.

    Header Value

    key1

    Enter one or more header values, separated by commas (,).

    key1,key2

    Allow Duplicates

    Allow

    • Yes: Allows you to add duplicate response headers. For example, x-code:key1 and x-code:key2.

    • No: If a header with the same name already exists, the new value overwrites the existing one. For example, if you add x-code:key1 and then x-code:key2, the final header is x-code:key2.

    Rule Condition

    Do not use

    A rule condition allows a rule to be applied only when a request meets specific criteria.

    • Do not use: Disables conditional rules.

    • You can add or edit conditional rules in the Rules engine.

    Delete response header

    Parameter

    Example

    Description

    Operation

    delete

    Removes all response headers that have the specified name, including duplicates.

    Response Header

    Custom Response Header

    Select Custom Response Header or a preset response header parameter.

    Header Name

    x-code

    Specifies the name of the custom response header to delete.

    Rule Condition

    Do not use

    A rule condition allows a rule to be applied only when a request meets specific criteria.

    • Do not use: Disables conditional rules.

    • You can add or edit conditional rules in the Rules engine.

    Modify response header

    Parameter

    Example

    Description

    Operation

    modify

    Modifies the header. This operation is not allowed if duplicate headers with the same name exist.

    Response Header

    Custom Response Header

    Select Custom Response Header or a preset response header parameter.

    Header Name

    x-code

    Specifies the name of the custom response header to modify.

    Change Value To

    key1,key3

    Specifies the new value for the header. To configure multiple values, separate them with commas (,).

    Rule Condition

    A rule condition allows a rule to be applied only when a request meets specific criteria.

    • Do not use: Disables conditional rules.

    • You can add or edit conditional rules in the Rules engine.

    Replace response header

    Parameter

    Example

    Description

    Operation

    replace

    Replaces the header value. This operation is not allowed if duplicate headers with the same name exist.

    Response Header

    Custom Response Header

    Select Custom Response Header or a preset response header parameter.

    Header Name

    x-code

    Specifies the name of the custom response header whose value you want to replace.

    Find

    key

    A regular expression that matches the part of the header value to replace.

    Replace With

    abc

    The value that replaces the matched text.

    Match

    Match All

    • Match All: Replaces all occurrences that match the regular expression. For example, if the header is x-code:key1,key2,key3 and you use a regular expression to replace the matched value key with abc, the result is x-code:abc1,abc2,abc3.

    • Match the First Only: Replaces only the first occurrence that matches the regular expression. For example, if the header is x-code:key1,key2,key3 and you use a regular expression to replace the matched value key with abc, the result is x-code:abc1,key2,key3.

    Rule Condition

    -

    A rule condition specifies the criteria that a user request must meet for this configuration to apply.

    • Do not use: No rule condition is used.

    • To add or edit rule conditions, go to the rule engine page.

  8. Click OK.

Default response headers

Alibaba Cloud CDN sets four response headers by default: Cache-Control, Content-Type, Expires, and Last-Modified. These essential HTTP protocol headers control caching, define content types, set expiration times, and record the last modified time of resources.

Header

Description

Example

Cache-Control

Controls the caching behavior and duration of a resource. It provides caching directives for POPs and client browsers, specifying when to cache content, for how long, and when it becomes stale. This header takes precedence over the legacy Expires header.

  • Cache-Control: no-cache forces validation with the origin before using a cached resource.

  • Cache-Control: max-age=3600 specifies that the resource is fresh for 3600 seconds (1 hour) and can be served from the cache without an origin fetch.

Content-Type

Specifies the media type of a resource. This header helps the client browser interpret and render the data correctly. The CDN also uses this header to process and transfer content.

  • Content-Type: text/html indicates that the content is in HTML format.

  • Content-Type: image/jpeg indicates that the resource is a JPEG image.

Expires

Specifies the date and time when the resource expires. The CDN uses this header to determine if the resource is still valid. If expired, the CDN performs an origin fetch to retrieve an updated version. The Expires header is a legacy mechanism. In HTTP/1.1, the Cache-Control header provides more fine-grained control, and the use of Expires has declined.

Expires: Thu, 01 Dec 2023 16:00:00 GMT indicates that the content expires after the specified GMT time.

Last-Modified

Indicates the time when the resource was last modified. The CDN and client browsers use this response header to determine if a cached resource is still up-to-date.

Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT indicates the resource's last modified time, which is used for cache validation.

Configuration examples

Example 1: Set a response MIME type

Use case

Set a specific MIME type for a response.

Note

MIME types include the following main categories:

  • Text: Includes text files (such as .txt and .csv) and HTML files (such as .html, .htm, and .shtml).

  • Image: Includes common image files (such as .jpg, .png, and .gif).

  • Audio: Includes audio files (such as .mp3 and .wav).

  • Video: Includes video files (such as .mp4 and .avi).

  • Application: Includes application files (such as .pdf, .doc, and .xls).

Configuration

  • Response header operation: Add

  • Header name: Content-Type

  • Header value: text/html

    Set Allow Duplicates to Do not allow and Rule Condition to Do not use, then click OK.

Result: The POP adds the Content-Type: text/html header to the response from the origin server. If you configure this header again, the new value overwrites the existing one.

Example 2: Delete a response header

Use case

Deleting a response header.

Configuration

  • Response header operation: Delete

  • Header name: Content-Type

    Set Allow Duplicates to Do not allow and Rule Condition to Do not use, then click OK.

Result: The POP removes the Content-Type header from the response before returning it to the client.

Note

If you apply the configurations from both Example 1 and Example 2, the system first adds and then deletes the Content-Type: text/html response header. As a result, the client receives the response without a specified MIME type.

FAQ

Missing CORS response header

If you configure a back-to-origin response header, such as Access-Control-Allow-Origin, in Alibaba Cloud CDN but still encounter CORS errors and cannot find the header in the final response, the issue may be caused by one of the following reasons:

Possible causes

  1. Incorrect or pending configuration: The configuration may be incorrect or has not yet taken effect, preventing the CDN from returning the expected CORS response header.

  2. Stale CDN cache: A POP may have cached an old response and continues to serve outdated headers despite the new configuration.

  3. Origin server issues: A conflict can occur if your origin server returns CORS headers that are inconsistent with the CDN configuration. In this case, you must align the settings on both.

  4. Stale browser cache: The browser may have cached an old response, preventing it from making a new request to fetch the updated headers.

Solutions

  1. Verify the configuration: Confirm that your CDN configuration is set up correctly and has taken effect, especially the settings for CORS-related response headers.

  2. Clear the CDN cache: Use the CDN's refresh feature to purge cached content, and then access the resource again. For more information, see purge and prefetch resources.

  3. Check the origin server settings: Ensure the origin server does not return CORS response headers that conflict with the CDN configuration. Align the CORS settings on both the origin server and the CDN.

  4. Clear the browser cache: Clear your browser cache or use a private window to test. This ensures that the browser fetches the latest response headers.

  5. Contact technical support: If the issue persists after trying the preceding steps, the problem may be with the CDN service. Contact Alibaba Cloud CDN technical support or submit a ticket for assistance.

Verify CORS response headers

ECS instance

Verify that the web server or application on your ECS instance correctly sets the Access-Control-Allow-Origin and other CORS-related response headers. To verify your configuration:

  1. Log on to the ECS console and connect to your ECS instance.

  2. Check the CORS configuration of your web server.

    Configuring CORS response headers depends on the web server or application you use. Common web servers include Apache and Nginx.

    Apache

    In the .htaccess file or a server configuration file, such as httpd.conf or vhosts.conf, look for settings similar to the following:

    Header set Access-Control-Allow-Origin "*"

    Or, for a specific domain:

    Header set Access-Control-Allow-Origin "http://example.com"

    Ensure these settings are correct.

    Nginx

    In the Nginx configuration file, typically /etc/nginx/nginx.conf or /etc/nginx/sites-available/default, find the server block related to your application and check for the following settings:

    location / {
    	add_header 'Access-Control-Allow-Origin' '*';
    }

    Or, for a specific domain:

    location / {
    	add_header 'Access-Control-Allow-Origin' 'http://example.com';
    }

    Ensure these settings are correct.

  3. Restart the web server.

    After modifying the configuration file, restart the web server to apply the changes. For example, use the following commands to restart Apache or Nginx.

    • For Apache:

      sudo service apache2 restart
    • For Nginx:

      sudo service nginx restart
  4. Verify the response headers in your browser.

    Use the Network tab in your browser's DevTools to check the resource's response headers. Verify that the Access-Control-Allow-Origin header is present. If it is not, the configuration might not have taken effect, or a cached response from a CDN is being served.

OSS

OSS supports CORS. Use the OSS console to verify that response headers such as Access-Control-Allow-Origin are correctly set. Follow these steps:

  1. Log on to the OSS console.

  2. In the left-side navigation pane, click Buckets. On the Buckets page, find and click the desired bucket.

  3. In the left navigation pane, choose Content Security > CORS.

  4. In the list of CORS rules, verify that the Access-Control-Allow-Origin setting exists and has the correct value.

    • To allow access from any origin, set Access-Control-Allow-Origin to *.

    • To allow access only from specific origins, set Access-Control-Allow-Origin to the specific origin URL, such as https://yourdomain.com.

  5. Check other related CORS headers.

    In addition to Access-Control-Allow-Origin, verify that the following CORS-related headers are also configured correctly:

    • Access-Control-Allow-Methods: Specifies the allowed HTTP methods, such as GET, POST, PUT, and DELETE.

    • Access-Control-Allow-Headers: Specifies the allowed custom request headers if the request includes non-standard headers.

    • Access-Control-Max-Age: Specifies the maximum time in seconds that the results of a preflight request (OPTIONS) can be cached.

  6. Save and test.

    If any settings are incorrect, update them and save the changes. Note that the changes may take some time to take effect.

For more information about configuring CORS in OSS, see CORS.

If the issue persists, contact Alibaba Cloud CDN technical support or submit a ticket.

Fixing garbled characters

Garbled characters on a CDN-accelerated page are typically caused by the origin server's Content-Type response header not specifying a character encoding. To resolve this issue, follow these steps:

  1. Log in to the Domain Names console and find the target domain name.

  2. In the left navigation pane of the domain details page, click Origin Fetch. Use the "Modify Outgoing Response Header" feature to add a response header rule for the file path, setting Content-Type to text/plain; charset=utf-8.

  3. Go to the refresh and prefetch page and refresh the path's cached resources to apply the new rule.

Note

To ensure this file is not cached (preventing future update delays), go to Cache and set the cache expiration time to 0 seconds for its path, such as /llms.txt.

Precise Content-Type configuration

If you globally set the Content-Type to video/mp4 for an entire domain name, it affects all resource types under that domain, such as image, CSS, and JS files. To avoid affecting other files, we recommend that you use the following methods for precise configuration:

  1. Match by path: In a Modify Ingress Response Header rule, use the rule conditions in the Origin Fetch to apply the rule only to video paths, such as paths that contain /vod-cd20e3/ or have the .mp4 suffix.

  2. Using conditional statements: The CDN console supports setting response headers based on the request suffix or Header conditions, allowing you to return Content-Type: video/mp4 only for .mp4 files.

This way, you can modify the Content-Type for video files only, without affecting other resource types such as images.

Video response header

You can use the modify outbound response header feature in Cache to configure the Content-Disposition response header to control video download or preview behavior:

  • Setting the value to attachment; filename='video.mp4' prompts the user to download the resource.

  • Setting the value to inline previews the resource directly in the browser.

If the configuration does not take effect, check the following:

  1. Rules Engine matching conditions: Ensure the rule's match condition targets the URI path (for example, it contains /video-origin/20260414) and not just the query string. The Rules Engine uses path information from a user request to determine whether to apply the configuration.

  2. Cache Issues: If the CDN has already cached the video file, it may still be serving the old response header. Go to the Refresh and Prefetch page and refresh the cache for the path to apply the new configuration.

JS file served as text/html

Cause:

This issue occurs when the origin server first returns a JS file with the Content-Type response header incorrectly set to text/html. When the CDN caches this incorrect type, the browser attempts to parse the file as text/html on the first request, which can cause rendering or script execution errors. Subsequent requests succeed because either the origin server has corrected the Content-Type or the CDN performs an origin fetch and retrieves the correct type.

Solution:

  1. In the CDN console, configure a rule for inbound response headers to forcibly set the Content-Type for JS files to application/javascript.

  2. After configuring the rule, go to the Refresh and Prefetch page and refresh the JS file to apply the new rule immediately.

JS file settings

Yes. In the "Modify Inbound Response Header" settings, you can set the Content-Type for JS files to application/javascript. This setting does not affect other file types.

To do this, configure a rule condition to match the .js suffix. This ensures that the MIME type is set correctly for JS files without affecting other resource types, such as CSS and images.

Response header modification and file status

No. The modify response header feature corrects or enforces a specific MIME type. This resolves caching issues caused when the origin returns an incorrect type. You cannot use this feature to detect missing files on the CDN or verify their synchronization status.

To troubleshoot missing files or synchronization issues, use the following methods:

  • Use the refresh and prefetch feature in the CDN console to manually refresh the target file. This action triggers an origin fetch to verify the file's existence.

  • Check that the file is accessible on your origin.

  • Review your CDN logs for a successful origin fetch status code.