Configure URL rewrites and redirections - CDN - Alibaba Cloud Documentation Center

If the path of a resource on your origin server changes, the corresponding path on the CDN node also changes. When a user requests the original URL, the CDN node rewrites the URL and redirects the request to the destination path. This process reduces origin fetch requests and improves client access performance.

Background information

The HTTP 302 status code (302 Found) indicates that a resource has been temporarily moved. After you configure a URL rewrite rule, the CDN node includes the new URL in the HTTP Location header. When the client receives the 302 response, it requests the new URL.

By default, CDN nodes send a 302 status code after a URL rewrite rule is configured. Status codes 303 and 307 are also supported. To change the status code, you can submit a request by or submitting a ticket.

Code	Meaning	Handling method	Typical application scenario
302	Found	The GET method does not change. Other methods might change to the GET method.	The page is temporarily unavailable for unforeseen 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 operation from being triggered again if the page is refreshed.
307	Temporary Redirect	Neither the method nor the message body changes.	The page is temporarily unavailable for unforeseen reasons. In this case, search engines do not update their links. This status code is better than the 302 status code when the site supports links or operations for methods other than GET.

Important

A single domain name can have up to 50 rewrite rules. If multiple rules are configured, they are executed sequentially from top to bottom as they appear in the URL rewrite list in the CDN console.

Access URL Rewrite and Origin Path Rewrite differences

Feature

Affected object

Client experience

Application scenario

Rewrite access URLs

Affects the URL that the client accesses. It also changes the URL that the DCDN node uses for origin fetches.

If the execution rule is `redirect`, the client sends a new access request using the redirected URL.
If the execution rule is `break`, the URL that the client sees is the same as the actual access URL. There is no change.

Commonly used to migrate or map URLs from an old domain name to a new one. It is also used 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 Fetch Path

Affects the URL that the DCDN node uses for origin fetches. The URL that the client accesses does not change.

The URL that the client sees is the same as the actual access URL. There is no change.

Commonly used to hide the real URL structure of the origin server to protect its information. It is also used for URL mapping to make the DCDN node fetch content from different origin server folders.

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

Access URL Rewrite diagram

The client sends a request to a DCDN node. The request URL is old.example.com/hello.
After the DCDN node receives the request, it applies the URL rewrite rule. The DCDN node includes the new URL, new.example.com/hello, in the Location header of the 302 response that is sent to the client.
After the client receives the 302 response, it sends a request to the new URL.
The DCDN node checks its cache. If the cache contains the content for the rewritten URL, the node returns the content directly to the client. If not, the DCDN node sends a request to the origin server using the rewritten URL, new.example.com/hello.
The origin server receives the request and returns the response content to the DCDN node.
The DCDN node caches the response content and returns it to the client.

Origin Path Rewrite diagram

The client sends a request to a DCDN node. The request URL is cdn.example.com/files/hello.txt.
After the DCDN node receives the request, it checks its cache. If the cache contains the content for the request URL, the node returns the content directly to the client. If not, the DCDN node applies the origin fetch URL rewrite rule. It rewrites the origin fetch URL to origin.example.com/secret/files/hello.txt and sends a request to the origin server.
After the origin server receives the request, it returns the response content to the DCDN node.
The DCDN node caches the response content 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 rewriting access URLs.

Parameter	Description
Path to Be Rewritten	The path must start with a `/`. It cannot include the protocol header or domain name. PCRE regular expressions are supported, such as `^/hello$`. The content after a `#` in a URL is a client-side fragment identifier. Browsers do not send fragment identifiers to the server. Therefore, DCDN rewrite rules cannot match the path after the `#`. To configure a redirection for a URL that contains a `#` fragment, you must create a separate rewrite rule for each destination address that exactly matches the path before the `#`.
Target Path	If the execution rule is set to Break, the path must start with a `/`. It cannot include the protocol header or domain name. If the execution rule is set to Redirect, the path can include the protocol header and domain name. PCRE regular expressions are supported. For example, you can use `$1` and `$2` to capture strings in parentheses from the path to rewrite.
Flag	Redirect and Break are supported by default. Redirect: If a request URL matches a rule, the request is redirected to the destination URL with a 302 status code. The Location header that the CDN node returns to the client contains the destination URL. The parameters in the original URL are not modified. After this rule is executed, the system continues to match 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 this rule is executed, the system does not match any remaining rules. The empty, enhance_break, and enhance_redirect rules are also supported. To use these rules, you must submit a ticket to have them configured in the background. empty: If multiple rules are configured and a request URL matches a rule, the system continues to match subsequent rules after the current rule is executed. enhance_break: Similar to break, but it rewrites the entire URL, including parameters. enhance_redirect: Similar to redirect, but it rewrites the entire URL, including parameters. Note Different execution rules use different rewrite methods. They also differ in whether the rewritten URL can use other domain names or protocols: empty, Break, and enhance_break directly rewrite the user's request URL. They do not support rewriting to another domain name or protocol, such as from HTTP to HTTPS. Redirect and enhance_redirect use a 302 redirection to rewrite the URL. They support rewriting to other domain names and protocols: The 302 Location address can be set to a different domain name, not just the current accelerated domain name. For example, you can rewrite a URL from the `example.com` domain to the `aliyundoc.com` domain. The 302 Location address supports other protocols. For example, you can rewrite a URL from HTTP to HTTPS.
Rule Condition	A rule condition identifies various parameter information in a user request. This determines whether a configuration takes effect for that request. Important When you reference rule conditions, they are matched based on the priority of the associated rule conditions, not the configuration order of the feature itself. Do not use: Does not use a rule condition. To add or edit rule conditions, manage them in the Rules Engine.
Nginx Var	This option is unchecked by default. Check this option to use built-in NGINX variables in the destination URL. The following is a configuration example: Path to Rewrite: `^/test.jpg$` Destination Path: `/test.${arg_type}` If you enable NGINX variable calculation, the value of `${nginx_var}` is calculated. `${arg_type}` represents the value of the `type` parameter in the original URL. Note To use this parameter, you must submit a ticket to have it configured in the background.

Click OK.
After you configure the rewrite feature, you can Modify or Delete the rule from the rewrite list.

Configuration examples

Example 1

When a client requests http://example.aliyundoc.com/hello, the request path is /hello. The DCDN node includes the new URL http://example.aliyundoc.com/index.html in the Location header of the 302 response and returns the response to the client. The client then sends a request to http://example.aliyundoc.com/index.html.

For this rule, Path to Rewrite is set to ^/hello$, Destination Path is set to /index.html, and Execution Rule is set to redirect.

Note

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

Example 2

When a client requests http://example.aliyundoc.com/hello, the request path /hello matches the regular expression ^/hello$. The DCDN node returns a 302 response to the client. The response includes the destination URL https://test.aliyundoc.com/index.html in the Location header. After the client receives the response, it sends a request to https://test.aliyundoc.com/index.html.

Configuration rule: Set Path to Rewrite to ^/hello$, set Destination Path to https://test.aliyundoc.com/index.html, and set Execution Rule to redirect.

Example 3

When a client requests http://www.example.com/cdn/url/http://image.example.com/image/cat.jpg, the request path contains /cdn/url/http://, which matches the regular expression ^/cdn/url/http://(.*). The DCDN node returns a 302 response to the client. The response includes the destination URL http://image.example.com/image/cat.jpg in the Location header. After the client receives the response, it sends a request to http://image.example.com/image/cat.jpg.

For the configuration rule, set Destination Path to http://$1 and Execution Rule to redirect.

Example 4

When a client requests http://example.aliyundoc.com/stories/index.html#/voice/318, the #/voice/318 part of the URL is a client-side fragment identifier. The browser does not send this part to the server. The actual request path that the DCDN node receives is /stories/index.html. Therefore, when you configure the rewrite rule, set Path to Rewrite to ^/stories/index\.html$ to match the path before the #. Then, set Destination Path to the target URL and Execution Rule to Redirect.

To redirect multiple source URLs that have different # fragments to different destination URLs, you must configure a separate rewrite rule for each source path. This is because a server cannot distinguish between URLs based on the content that follows the # symbol.