An HTTP message generally contains:
These messages all consist of a beginning line, one or multiple headers, a blank line indicating the end of headers, and an optional message body.
HTTP headers divide into common header, request header, response header, and entity header. Each header consists of a domain name, colon (":"), and domain value, such as
If you use the HTTP header configuration feature provided by ECDN, when an end user requests a business resource, you can add a custom header in the returned response message to implement cross-origin access.
- As the HTTP header configuration is for a specified domain name, once the configuration takes effect, the configured header will be added to the response messages of user requests for any resource under this domain name.
- HTTP header configuration affects only response of the client (such as browser) rather than ECDN node's caching behaviors.
ECDN allows you to configure the following headers:
Content-Disposition is used to activate download in the browser and set the default filename of the downloaded resource. When the server sends a file to the client browser, if it is in a type supported by the browser, such as .txt or .jpg, it will be directly opened in the browser by default. If you want to ask the user to save the file, you can configure the
Content-Disposition field to override the browser's default behavior. The common configuration is
Content-Language specifies the code of the language used by the webpage. Common configurations are as follows:
Cross-origin access refers to a scenario where a resource under a domain name, such as
www.abc.com, initiates a request to another resource under another domain name, such as
www.def.com. As the resource domain names are different, cross-origin access will occur. Using different protocols or ports can cause cross-origin access. You need to add configuration related to cross-origin access in the response header to make the first resource get the desired data.
Access-Control-Allow-Origin is used to solve the problem of cross-origin permissions of resources. Its value specifies the origins that can access the resource. You can also set the wildcard
\* to allow all origins to access the resource. Common configurations are as follows:
Pay attention to the following limits when configuring
\*or specify a URI.
Access-Control-Allow-Methods is used to specify the HTTP request methods allowed for cross-origin access. Multiple methods can be set as follows:
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Max-Age specifies the validity period of a preflight request.
For a non-simple cross-origin request, before the formal communication, an HTTP query request called "preflight request" needs to be made to check whether the cross-origin request is secure and acceptable. The following requests are considered as non-simple cross-origin requests:
POSTor is initiated by using
POSTwith a data type other than
text/plain, such as
Access-Control-Max-Age is measured in seconds. Here, the configuration sample
Access-Control-Max-Age: 1728000 indicates that no more preflight requests will be sent for the cross-domain access to this resource within 1,728,000 seconds (20 days).
Access-Control-Expose-Headers specifies which headers can be accessed when a cross-region request is initiated. By default, the following six types of headers can be exposed to the client:
If you want the client to access other header information, you can set as follows (separate multiple headers with
Access-Control-Expose-Headers: Content-Length, QCloud-DSA-MyCustom-HeaderY
Then, the server will allow requests to contain the
ECDN allows you to add custom headers as needed.
The following fields cannot be added currently:
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