Edge Security Acceleration:Modify response headers

How response header modification works

When a client requests resources, the request reaches ESA first. If the request does not hit the cache of the ESA POP, ESA initiates a request to the origin server to obtain data. After the origin server returns data, the ESA POP modifies the original responses based on your configured rules, such as adding, replacing, or deleting specific fields. The ESA POP then returns the complete resources containing response headers to the client to implement cross-origin resource sharing (CORS) and optimize cache policies.

Scenarios

• Inform clients of the type of content returned by ESA: For example, you can add the Content-Type: text/html response header to inform clients that content returned by ESA is in the HTML format and perform related rendering.

• Implement CORS: If a client requests resources on a website that is added to ESA, you can configure the Access-Control-Allow-Origin header in the response message sent by ESA to enable CORS.

• Specify custom response behavior: You can add or modify custom headers to implement specific features or track responses. For example, you can adjust the response content and format returned to clients based on your needs.

Before you begin

If you create multiple response header modification rules, the rules are executed from top to bottom in the list. If multiple rules modify the same response header, the most recent rule overwrites rules created earlier. Take note that the execution results of rules may not meet your expectations. Example:

• Rule 1: Add the cache-control: max-age=3600 response header.

• Rule 2: Add the cache-control: no-cache response header.

If you have Rule 1 and Rule 2 at the same time, Rule 2 takes precedence over Rule 1. This means that the returned content is not cached.

Modify a response header

The rules take effect according to the priorities.

1. In the ESA console, choose Websites and click the name of the website you want to manage.

2. In the left-side navigation pane, choose Rules > Transform Rules.

3. Click the Modify Response Header tab. Click Create Rule, and fill in the Rule Name.

4. In the If Requests Match... area, specify the conditions for matching incoming requests. For more information about how to configure a rule, see Rules.

5. In the Modify Request Header area, select a value from the Operation drop-down list, and fill in the Request Header Name and Request Header Value.

   The following list describes the operations and related header names and values:

   Add

   • Type: static

     • Description

       • Adds a specific response header to the response message returned to clients.

       • The newly added header will overwrite the existing header in the client's request when a client request includes a header that has the name as one you provide.

     • Example

       Adding a response header whose name is x-code and value is key1. Example values:

       • Response Header Name : x-code

       • Response Header Value :key1

   • Type: dynamic

     • Description

       • The response header can be set to an expression. For more information, see Work with rules.

     • Example

       Adding a response header whose name is Client-Ip-Geo-Location and value is ip.geoip.country. Example values:

       • Response Header Name: Client-Ip-Geo-Location

       • Response Header Value: ip.geoip.country

       Client-Ip-Geo-Location is a custom header used to record the country or region of the geographic location of the client IP address.

   Change

   • Type: static

     • Description

       • Changes the value of a response header.

       • The change is invalid when a client request doesn't include a header that matches the name you provide.

     • Example

       Changing the value of a response header whose name is x-code to key2. Example values:

       • Response Header Name: x-code

       • Response Header Value: key2

   • Type: dynamic

     • Description

       • The response header can be set to an expression. For more information, see Work with rules.

     • Example

       Changing the value of a response header whose name is Client-Ip-Geo-Location to ip.geoip.country. Example values:

       • Response Header Name: Client-Ip-Geo-Location

       • Response Header Value: ip.geoip.country

       The value of the Client-Ip-Geo-Location header contained in the original response is changed to the country or region of the geographic location of the client IP address.

   Delete

   • Description

     Removes all response headers that match the value in the Response Header Value column from the response message returned to clients, regardless of how many such response headers exist.

   • Example

     To remove a response header whose name is x-code, enter x-code in the Response Header Name column.

   • Note

     • You cannot specify a response header name that starts with ali- or Ali-.

     • You can specify one or more values for a response header. Separate the values with commas (,).

     • The configuration effect for the delete operation is the same in static and dynamic modes.

     • You can only change the name of a header that exists in the original response.

6. Click OK.

Response headers

The following list describes the response headers:

• Custom

  • You can create a custom response header based on your needs. You need to specify the name of the response header based on the following rules:

    • The name can contain letters, hyphens (-), and digits.

    • The name must be 1 to 100 characters in length.

  • Example: Test-Header

• Cache-Control

  • The cache rule that requests and responses follow.

  • Example: no-cache

• Content-Disposition

  • The default file name that is used when the retrieved content is saved as a file on the client.

  • Example: examplefile.txt

• Content-Type

  • The media type of the resource that is returned to clients.

  • Example: text/plain

• Pragma

  • Pragma is an HTTP/1.0 general-type header that is used to carry cache control directives in server responses.

  • Example: no-cache

• Access-Control-Allow-Origin

  • Specifies which source can access resources. This is part of the CORS mechanism, which allows servers to declare whether their resources can be accessed by a specified source domain name. The value of this response header supports the following types:

    • Wildcard character (*): You can use the wildcard character to allow access to resources from any source. This approach is very permissive and is suitable for resources that are publicly accessible without authentication or authorization. However, you must use the wildcard character with caution in production environments because it may introduce security risks, such as cross-site request forgery (CSRF) attacks.

    • A specified source: You can specify a source domain name, indicating that only this particular source is allowed to access the resources. Example: http://example.com or https://api.example.com. Requests must come from the specified source. Otherwise, they will be rejected.

  • Examples:

    • *

    • http://www.alibabacloud.com

• Access-Control-Allow-Methods

  • The request methods that you can use in cross-origin requests. You can specify one or more request methods. Separate request methods with commas (,).

  • Example: POST,GET

• Access-Control-Allow-Headers

  • The header fields that you can use in cross-origin requests.

  • Example: X-Custom-Header

• Access-Control-Expose-Headers

  • The headers that can be exposed as part of the response.

  • Example: Content-Length

• Access-Control-Allow-Credentials

  • Specifies whether browsers can expose responses to the frontend page.

    • true: Browsers can expose responses to the frontend page.

    • Other values: Browsers cannot expose responses to the frontend page.

  • Example: true

• Access-Control-Max-Age

  • The period during which the results of a preflight request can be cached. Unit: seconds.

  • Example: 600