Configure access URL rewrite and redirection - CDN - Alibaba Cloud Documentation Center

If the path of a resource on the origin server changes, the resource is no longer accessible at its original path on CDN points of presence (POPs). If a client requests the resource using the original URL, CDN can rewrite the request URL and redirect the request to the destination path. This reduces origin fetch requests and improves client access performance.

Background

The HTTP 302 status code (302 Found) indicates that a resource has been temporarily moved. After you configure the access URL rewrite feature, CDN POPs return a 302 response that includes the new URL in the HTTP Location header. After the client receives the 302 response, it sends a new request to the specified URL.

By default, CDN POPs send a 302 status code after you configure an access URL rewrite rule. The 303 and 307 status codes are also supported. To change the status code, you can submit a ticket.

Status code	Meaning	Processing method	Use case
302	Found	The GET method does not change. Other methods may change to the GET method.	A webpage is temporarily unavailable for unforeseeable reasons. In this case, search engines do not update their links.
303	See Other	The GET method does not change. Other methods change to the GET method. The message body is lost.	Used for page redirection after a PUT or POST request is complete. This prevents the same operation from being triggered again if the page is refreshed.
307	Temporary Redirect	The method and message body do not change.	A webpage is temporarily unavailable for unforeseeable reasons. In this case, search engines do not update their links. This status code is preferred over the 302 status code when the site supports links or operations that use methods other than GET.

Important

You can configure a maximum of 50 rewrite rules for a single domain name. If you configure multiple rules, they are executed in the order that they are listed on the Rewrite Access URL page in the CDN console.

Differences between access URL rewrite and origin URL rewrite

Feature

Affected

Client experience

Use case

Rewrite access URLs

Affects the URL that the client accesses. It also changes the URL that the POP uses for origin fetch.

If the flag is set to redirect, the client uses the redirected URL to send a new request.
If the flag is set to break, the URL that the client sees is the same as the accessed URL and does not change.

Commonly used to migrate or map URLs from an old domain name to a new domain name, or to provide different URLs for mobile and PC clients.

Example: When a client accesses old.example.com/hello, the access URL is rewritten to new.example.com/hello.

Rewrite origin URLs

Affects the URL that the POP uses for origin fetch. The URL that the client accesses does not change.

The URL that the client sees is the same as the accessed URL and does not change.

Commonly used to hide the actual URL structure of the origin server to protect origin server information, or to use URL mapping to allow CDN POPs to fetch content from different origin directories.

Example: When a client accesses cdn.example.com/hello, the origin URL is rewritten to origin.example.com/source/hello.

Access URL rewriting

A client sends a request to a POP. The request URL is old.example.com/hello.
After the POP receives the request, it rewrites the request URL to new.example.com/hello based on the access URL rewrite rule. The POP then includes the new URL in the HTTP Location header of the 302 response.
After the client receives the 302 response, it sends a new request to the new URL.
The POP checks its cache. If the content for the rewritten URL is cached, the POP returns the content to the client. If the content is not cached, the POP sends a request to the origin server. The request URL is the rewritten URL, new.example.com/hello.
The origin server receives the request and returns the response to the POP.
The POP caches the response and returns it to the client.

Origin URL rewriting

A client sends a request to a POP. The request URL is cdn.example.com/files/hello.txt.
After the POP receives the request, it checks its cache. If the content for the request URL is cached, the POP returns the content to the client. If the content is not cached, the POP rewrites the origin URL to origin.example.com/secret/files/hello.txt based on the origin URL rewrite rule and sends a request to the origin server.
The origin server receives the request and returns the response to the POP.
The POP caches the response and returns it to the client.

Procedure

Log on to the CDN console.
In the left navigation pane, click Domain Names.
On the Domain Names page, find the target domain name and click Manage in the Actions column.
In the domain's navigation pane, click Cache.
Click the Access URL Rewrite tab.

Click Create and configure the parameters for the access URL rewrite rule.

Parameter	Description
Path to Be Rewritten	The path must start with a forward slash (`/`) and cannot contain the protocol or domain name. Perl Compatible Regular Expressions (PCRE) are supported. Example: `^/hello$`.
Target Path	If you set Flag to Break, the path must start with a forward slash (`/`) and cannot contain the protocol or domain name. If you set Flag to Redirect, the path can contain the protocol and domain name. PCRE is supported. For example, you can use `$1` and `$2` to capture strings in parentheses from the path to rewrite.
Flag	By default, Redirect and Break are supported. Redirect: If a request URL matches a rule, the request is redirected to the destination URL with a 302 status code. The Location header in the response that the POP returns to the client is the destination URL. The parameters in the original URL are not modified. After the current rule is executed, the request continues to be matched against the remaining rules. Break: If a request URL matches a rule, the request is rewritten to the destination URL. The parameters in the original URL are not modified. After the current rule is executed, the remaining rules are skipped. The Empty, enhance-break, and enhance_redirect flags are also supported. To use these flags, submit a ticket to have them configured in the backend. Empty: If you configure multiple rules and a request URL matches a rule, the request continues to be matched against the subsequent rules after the current rule is executed. enhance_break: Similar to Break, but modifies the entire URL, including parameters. enhance_redirect: Similar to Redirect, but modifies the entire URL, including parameters. Note Different flags use different rewrite methods. Whether the rewritten URL supports other domain names and protocols also varies: Empty, Break, and enhance_break directly rewrite the user request URL. They do not support rewriting to other domain names or protocols. For example, you cannot use these flags to change the protocol from HTTP to HTTPS. Redirect and enhance_redirect use 302 redirection to rewrite a URL. They support rewriting to other domain names and protocols: You can set the 302 Location address to the current accelerated domain name or another domain name. This lets you rewrite a URL that uses the `example.com` domain name to a new URL that uses the `aliyundoc.com` domain name. The 302 Location address supports other protocols. This lets you rewrite a URL that uses the HTTP protocol to a new URL that uses the HTTPS protocol.
Rule Condition	Rule conditions identify various parameters in a user request to determine whether a configuration applies to the request. Do not use: Do not use rule conditions. To add or edit rule conditions, manage them in the Rules Engine.
Enable NGINX variable computing	By default, this feature is disabled. If you enable this feature, you can use built-in NGINX variables in the destination URL. Example: Path to Rewrite: `^/test.jpg$` Destination Path: `/test.${arg_type}` After you enable this option, the value of `${nginx_var}` is calculated. `${arg_type}` specifies the value of the type parameter in the original URL. Note To configure this parameter, submit a ticket to have it configured in the backend.

Click OK.
After the rewrite rule is configured, it appears in a list where you can Modify or Delete it.

Configuration examples

Example 1

A client requests http://example.aliyundoc.com/hello. Because the request path is /hello, the CDN POP writes the new URL http://example.aliyundoc.com/index.html to the Location header of a 302 response and sends the response to the client. The client then sends a request to http://example.aliyundoc.com/index.html.

正则表达

Note

During a 302 redirection, if the Location header does not contain a protocol and domain name, the client uses the protocol and domain name from the original request by default.

Example 2

A client requests http://example.aliyundoc.com/hello. The request contains /hello and matches the regular expression ^/hello$. The CDN POP returns a 302 status code to the client and includes the destination URL https://test.aliyundoc.com/index.html in the Location header. After receiving the response, the client sends a new request to https://test.aliyundoc.com/index.html.

Example 3

A client requests http://www.example.com/cdn/url/http://image.example.com/image/cat.jpg. The request contains /cdn/url/http:// and matches the regular expression ^/cdn/url/http://(.*). The CDN POP returns a 302 status code to the client and includes the destination URL http://image.example.com/image/cat.jpg in the Location header. After receiving the response, the client sends a request to http://image.example.com/image/cat.jpg.