Modify outbound response headers by configuring rules for origin fetch-Edge Security Acceleration(ESA)-阿里云帮助中心

Outbound response headers from Edge Security Acceleration (ESA) nodes are part of the HTTP response headers sent to clients. By configuring outbound response headers in ESA, you can control the headers that are returned with resources. ESA lets you add, modify, and delete outbound response header rules to meet specific business requirements.

Function Introduction

When a client requests a resource, the request first reaches ESA. If the request misses the cache on the ESA node, an origin request is sent to the origin server to retrieve the data. After the origin server returns the data, the ESA node modifies the original response based on your configured response header rules, such as adding, replacing, or deleting specific fields. The node then returns the complete resource, including the response headers, to the client to satisfy business requirements for cross-domain access control and cache policy optimization.

Scenarios

Informing the client of the ESA response file's resource type: for example, you can add the response header Content-Type: text/html to inform the client that the ESA response file is in HTML format, which allows the client to render it accordingly.
Enable cross-origin resource access: When a user requests a resource from a domain name on ESA, you can enable cross-origin access by configuring the Access-Control-Allow-Origin response header in the response from ESA. For more information, see Configure cross-origin resource sharing.
Customize response behavior: You can add or modify custom headers to adjust the content and format of responses received by the client. This lets you enable specific features or tracking based on your business needs.

Notes

If multiple rules are configured, they are executed in the order they are listed, from top to bottom. If multiple rules specify the same response header name, a later rule overwrites an earlier one. This behavior may lead to unexpected results.

Example 1

The original response includes the header test:123.
A rule adds the header test:321.

If the response matches the rule, the original header test:123 is overwritten by test:321.

Example 2

The original response includes the header test:123.
A rule adds the header test:321, followed by another rule that deletes the header test.

If the response matches the rules, the original header test:123 is deleted.

Procedure

After you add a rule, ESA matches and executes rules sequentially based on the rule execution priority each time a user requests a resource.

In the ESA console, go to Websites. In the Website column, click the target site.
In the navigation pane on the left, choose Rules > Transform Rules.
Select the Modify Response Header tab, click the ESA to Client item, and then click Create Rule.
Click Create Rule. In the If requests match... section, set the matching criteria for user requests. For more information, see Rule expression syntax.

In the Modify Response Header section, select an Operation, enter a Response Header Name and Response Header Value, and then click OK.

Action	Mode	Description	Example
Add	Static	Adds the specified response header to the response from the origin server. If a header with the same name already exists, the new header overwrites it.	To add a response header named `x-code` with the value `key1`, set Header Name to `x-code` and Header Value to `key1`.
Add	Dynamic	The response header value can be a rule expression.	To add a response header named `Client-Ip-Geo-Location` with the dynamic value `ip.geoip.country` that records the client's IP country or region, set Header Name to `Client-Ip-Geo-Location` and Header Value to `ip.geoip.country`.
Modify	Static	Changes the value of a specified response header in the response from the origin server.	To change the value of the response header `x-code` to `key2`, set Header Name to `x-code` and Header Value to `key2`.
Modify	Dynamic	The response header value can be a rule expression.	To change the value of the response header `Client-Ip-Geo-Location` to the dynamic value `ip.geoip.country`, set Header Name to `Client-Ip-Geo-Location` and Header Value to `ip.geoip.country`.
Delete	—	Deletes all instances of the header that match the specified header name from the response from the origin server. The delete operation is the same for static and dynamic modes.	To delete the response header `x-code`, set Header Name to `x-code`.

Note

You cannot configure a header name that starts with ali-swift, ali-esa-inner, x-swift, or x-site (case-insensitive).
You can specify multiple values in the Header Value field. Separate the values with a comma (,).
The Modify action changes an existing response header and takes effect only if a header with the specified name exists in the original response.

Configuration example

Note

If you use OSS as the origin server and configure CORS in both the OSS and ESA consoles, the ESA configuration overwrites the OSS CORS settings.

Apply to all requests

Use case

Allow all requests from your site (example.com) to access resources from any origin.

Steps

In the ESA console, select Websites. In the Website column, click the target site.
In the navigation pane on the left, choose Rules > Transform Rules. On the Transform Rules page, click the Modify Response Header tab. Set Response Header Position to ESA to Client, and then click the Create Rule button.
On the Create Response Header Modification Rule page, configure the parameters as follows:
1. Rule Name: Enter a custom rule name, such as rule-cors-for-all.
2. If requests match...: Select All Requests.
3. Then execute...: Configure the following parameters:
  - Type: Select Static.
  - Operation: Select Add.
  - Response Header Name: Enter Access-Control-Allow-Origin.
  - Response Header Value: Enter *.

Result

For any cross-origin request, ESA adds the Access-Control-Allow-Origin: * header to the response, allowing the browser to display the cross-origin resource.

Apply to specific requests

Use case

Allow cross-origin access when the origin header matches a subdomain of example.com over HTTP or HTTPS. For example:

origin:http://www.example.com
origin:https://www.example.com
origin:http://image.example.com
origin:https://image.example.com

The CORS response header value must match the origin header in the request.

Configuration steps

In the ESA console, select Websites. In the Website column, click the target site.
In the navigation pane on the left, choose Rules > Transform Rules. On the Transform Rules page, click the Modify Response Header tab. Set Response Header Position to ESA to Client, and then click the Create Rule button.
On the Create Response Header Modification Rule page, configure the parameters as follows:
1. Rule Name: Enter a custom rule name, such as rule-cors-origin.
2. If requests match...: For this example, set the condition to Header Value of origin matches regex ^https?://(?:[a-zA-Z0-9](?:[a-zA-Z0-9\-]*[a-zA-Z0-9])?\.)+example\.com$.
  
  You can also directly edit the expression as follows: (http.request.headers["origin"] matches "^https?://(?:[a-zA-Z0-9](?:[a-zA-Z0-9\-]*[a-zA-Z0-9])?\.)+example\.com$")
  
  Note
  If your plan does not support matching with regular expressions, use the is in operator and list the allowed origin header values.
  
  You can also directly edit the expression as follows: (http.request.headers["origin"] in {"http://www.example.com" "https://www.example.com" "http://image.example.com" "https://image.example.com"})
3. Then execute...: Configure the following parameters:
  - Type: Select Dynamic.
  - Operation: Select Add.
  - Response Header Name: Enter Access-Control-Allow-Origin.
  - Response Header Value: Enter http.request.headers["origin"].

Result

When the origin header in a cross-origin request matches the rule, ESA adds the Access-Control-Allow-Origin header with the value from the client's Origin header. The browser then processes the response and displays the cross-origin resource.

Response header parameter description

Response Header Parameter	Description	Example
Custom	Supports adding custom response headers. Custom header names must meet these requirements: Contain only letters, hyphens `-`, and digits. Be 1 to 100 characters long.	Test-Header
Cache-Control	Specifies the caching mechanism that client requests and responses must follow.	no-cache
Content-Disposition	Specifies the default filename provided when the client saves the requested content as a file.	examplefile.txt
Content-Type	Specifies the content type of the response object.	text/plain
Pragma	Pragma is a general header defined in HTTP/1.0. It defines how clients should cache files in server responses.	no-cache
Access-Control-Allow-Origin	Specifies which origins can access the resource. It is part of the cross-origin resource sharing (`CORS`, `Cross-Origin Resource Sharing`) mechanism, which allows a server to specify whether its resources can be accessed by a specified origin. The value of this response header supports the following types: Wildcard ``: Allows any origin to access the resource. This is very permissive and suitable for public resources that require no authentication. However, use caution in production environments because it can introduce security risks, such as cross-site request forgery attacks. Single specified origin*: Specify a particular origin domain to allow only that origin to access the resource. For example, `http://example.com` or `https://api.example.com`. Requests from other origins will be denied.	* http://www.aliyun.com
Access-Control-Allow-Methods	Specifies allowed cross-origin request methods. Separate multiple methods with commas `,`.	POST,GET
Access-Control-Allow-Headers	Specifies allowed cross-origin request headers.	X-Custom-Header
Access-Control-Expose-Headers	Specifies custom headers that the client can access.	Content-Length
Access-Control-Allow-Credentials	Indicates whether the response to the request can be exposed to the page. true: Exposure is allowed. Any other value: Exposure is not allowed.	true
Access-Control-Max-Age	Specifies how long, in seconds, the client can cache the result of a preflight request for a specific resource.	600

Function Introduction

Scenarios

Notes

Procedure

Configuration example

Apply to all requests

Use case

Steps

Result

Apply to specific requests

Use case

Configuration steps

Result

Response header parameter description

Related documentation