When an end user requests a business resource, you can add a custom header in the returned response message to implement cross-origin resource sharing.
Response header configuration is of the domain name dimension, therefore, once the configuration takes effect, it will be synced to the response message of each resource under the domain name. Response header configuration only makes changes to the client (browser) response but not to the CDN node cache.
Log in to the CDN Console, select Domain Management on the left sidebar, and click Manage on the right of a domain name to enter its configuration page. Open the Advanced Configuration tab to find the Response Header Configuration setting, which is disabled by default. You can click Add Rule to add HTTP response header rules.
|Set||Changes the value of a specified response header parameter.
If the target header does not exist, it will be added after the change operation.
If the header parameter already exists, all the duplicates will be changed and merged into one header. For example, after the rule "Set -
|Delete||Deletes a specified response header parameter.|
- Some headers cannot be set or deleted in a self-service manner. For the detailed list, see Notes.
- Up to 10 HTTP response header rules can be configured.
- Rule priority can be adjusted. Rules at the bottom of the list have higher priority. If a header parameter is configured with multiple rules, the bottom rule will take effect as rules are executed from bottom to top.
|Access-Control-Allow-Origin||Cross-origin resource sharing (CORS) header, which specifies the domain allowed to access resources. If a source request host is configured as a header parameter value, it will be filled in to the response header. You can also set it as
|Access-Control-Allow-Methods||Specifies the CORS HTTP request method and supports multiple methods at the same time:
|Access-Control-Max-Age||Specifies the validity period (in seconds) of a preflight request.
For a non-simple CORS request, an HTTP query request, namely the preflight request, is needed before the official communication to check whether the CORS request is secure to be accepted. A CORS request is non-simple if it is:
Not a GET, HEAD, or POST request, or it is a POST request but its request data type is
For example, if a custom request header is
|Access-Control-Expose-Headers||Specifies which headers can be exposed to clients as a part of responses.
By default, these 6 headers can be exposed to clients:
If you want to make other headers accessible to clients, you can separate multiple headers with
|Content-Disposition||Activates download in the browser and sets the default filename of the downloaded resource.
When a server sends files to a client browser, with the file types such as TXT and JPG supported by the browser, the files will be directly opened in the browser by default. If you want the user to save the files, you can configure the
|Content-Language||Specifies the language code used on the page. The common configuration is as follows:
|Custom||Supports custom header and key-value pair settings.
A custom header parameter supports 1-100 characters of uppercase and lowercase letters, digits, and hyphens (-).
The parameter value supports 1-1000 characters excluding Chinese characters.
|Match Mode||Origin Value||Description|
|Full match||*||If it is set to
|Second-level wildcard domain name match||
If there are special ports, you need to enter the relevant information in the list. You must specify the port as arbitrary port match is not supported.
The headers below are not supported and will not take effect if configured:
Date Expires Content-Type Content-Encoding Content-Length Transfer-Encoding Cache-Control If-Modified-Since Last-Modified Connection Content-Range ETag Accept-Ranges Age Authentication-Info Proxy-Authenticate Retry-After Set-Cookie Vary WWW-Authenticate Content-Location Content-MD5 Content-Range Meter Allow Error