All Products
Search
Document Center

CDN:Rewrite access URLs

Last Updated:Jul 15, 2024

If the directory of a resource on the origin server changes, the directory of the resource on points of presence (POPs) also changes. If the request URL to the resource does not change, POPs need to rewrite the request URL and redirect the request to the destination path. This reduces the number of origin requests and improves client access performance.

Background information

The HTTP status code 302, also known as the Found message, indicates that the requested resource has temporarily relocated. After you configure the access URL rewrite feature, POPs add the new URL of the resource to the Location header in the response that is returned together with an HTTP 302 status code. After the client receives the response, the client sends a request to the new URL.

After you create an access URL rewrite rule, the POPs return the HTTP status code 302 to the client by default if the requested resource has relocated. You can also set the HTTP status code to 303 or 307. To change the HTTP status code, submit a ticket.

HTTP status code

Description

Solution

Scenario

302

Found

GET requests remain unchanged. Requests that use other methods may be changed to GET requests.

A web page is temporarily inaccessible due to unknown reasons. In this case, search engines do not update the URL to the web page.

303

See Other

GET requests remain unchanged. Requests that use other methods are changed to GET requests. The message body is dropped.

Web pages are redirected after PUT or POST requests are processed to prevent frequent requests that are initiated by a page refresh.

307

Temporary Redirect

Both the request method and message body remain unchanged.

A web page is temporarily inaccessible due to unknown reasons. In this case, search engines do not update the URL to the web page. If the website supports requests that use methods other than GET, the HTTP 307 status code is returned instead of the HTTP 302 status code.

Important

You can create up to 50 rewrite rules for a domain name. If you create multiple access rewrite rules, the rules are applied in descending order in which they are listed in the Alibaba Cloud CDN console.

Differences between access URL rewrite and origin URL rewrite

Feature

Description

Result

Scenario

Rewrite access URLs

The URL that is accessed by clients is rewritten, and the origin URL also changes.

The URL seen by clients changes and is different from the actually accessed URL.

This feature is commonly used to map the URL of the old domain name to a new domain name or provide different URLs for mobile devices and PCs.

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

Rewrite origin URLs

The origin URL is rewritten, and the access URL remains unchanged.

The URL seen by clients remains unchanged and is the same as the actually accessed URL.

This feature is commonly used to hide the actual URLs of origin servers to protect information about origin servers. You can also use this feature to map URLs to allow POPs to retrieve content from different origin directories.

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

Rewrite an access URL

image
  1. A client initiates a request to a POP. The request URL is old.example.com/hello.

  2. After the POP receives the request, the POP adds the new URL to the HTTP Location header in the response that is returned together with an HTTP 302 status code, and rewrites the request URL to new.example.com/hello based on access URL rewrite rules.

  3. After the client receives the response and the HTTP 302 status code, the client initiates a request to the new URL.

  4. The POP checks the cache. If the content that corresponds to the rewritten URL exists in the cache, the POP returns the content to the client. If not, the POP initiates a request to the origin server. The request URL is new.example.com/hello, which is rewritten.

  5. The origin server receives the request and returns the requested content to the POP.

  6. The POP caches the requested content and returns the requested content to the client.

Rewrite an origin URL

image
  1. A client initiates a request to a POP. The request URL is cdn.example.com/files/hello.txt.

  2. After the POP receives the request, the POP checks the cache. If the content that corresponds to the rewritten URL exists in the cache, the POP returns the content to the client. If not, the POP rewrites the origin URL to origin.example.com/secret/files/hello.txt based on origin URL rewrite rules.

  3. The origin server receives the request and returns the requested content to the POP.

  4. The POP caches the requested content and returns the requested content to the client.

Procedure

  1. Log on to the Alibaba Cloud CDN console.

  2. In the left-side navigation pane, click Domain Names.

  3. On the Domain Names page, find the domain name that you want to manage and click Manage in the Actions column.

  4. In the left-side navigation tree of the domain name, click Cache.

  5. Click the Access URL Rewrite tab.

  6. Click Create, and configure the parameters based on your business requirements.

    重写

    Parameter

    Description

    Path to Be Rewritten

    Enter a URL that starts with a forward slash (/). The URL cannot contain http:// or domain names. You can use Perl Compatible Regular Expressions (PCRE) to specify the URL. Example: ^/hello$.

    Target Path

    Enter a URL that starts with a forward slash (/). The URL cannot contain http:// or domain names. Example: /index.html.

    Flag

    • By default, Redirect and Break are supported.

      • Redirect: If the URL in a request matches a rule, Alibaba Cloud CDN returns the HTTP 302 status code and the request is redirected to the actual URL. The value of the Location header in the response message that is returned by the POP to the client is the actual URL. Parameters in the original URL are not modified. After the current rule is executed, the request is matched against other rules.

      • Break: If the URL in a request matches a rule, the requested URL is overwritten by the actual URL. Parameters in the original URL are not modified. After the current rule is executed, other rules are skipped.

    • Empty, enhance-break, and enhance_redirect are also supported. To use these rules, submit a ticket.

      • Empty: If multiple rules are configured and the URL in a request matches a rule, the request is matched against other rules after the current rule is executed.

      • enhance_break: enhance_break is similar to Break, but modifies the URL, including parameters.

      • enhance_redirect: enhance_redirect is similar to Redirect, but modifies the URL, including parameters.

    Note

    Different rules use different rewrite methods, and whether the rewritten URL supports other domain names and other protocols also varies.

    • Empty, Break, and enhance_break rewrite the URL in a request, but cannot modify the domain name or protocol in the URL. For example, the rules cannot modify the protocol from HTTP to HTTPS.

    • Redirect and enhance_redirect use 302 redirection to rewrite a URL, and can modify the domain name or protocol in the URL.

      • You can set the Location header to the current domain name or another domain name. This way, the original URL uses the example.com domain name, and the rewritten URL uses the aliyundoc.com domain name.

      • The Location header in 302 redirection responses supports different protocols. This way, the original URL uses the HTTP protocol, and the rewritten URL uses the HTTPS protocol.

    Rule Condition

    Rule conditions can identify parameters in a request to determine whether a configuration applies to the request.

    • Do not use conditions

    • Select the configured rule conditions in Rules Engine. For more information, see Rules engine.

    Enable NGINX variable computing

    By default, the check box is not selected. If you select this check box, you can use NGINX built-in variables in the destination URL. Sample configurations:

    • Path to Be Rewritten: ^/test.jpg$

    • Target Path: /test.${arg_type}

    • After you enable NGINX variable calculation, the value of ${nginx_var} is calculated. ${arg_type} indicates the value of the type parameter in the original URL.

    Note

    To configure this parameter, submit a ticket.

  7. Click OK.

    After a rewrite rule is created, the rule is displayed on the Access URL Rewrite tab. You can modify or delete the rule.

Sample configurations

The following figure shows how to use a regular expression to configure an access URL rewrite rule.正则表达

The value of Path to Be Rewritten is a regular expression ^/hello$, which is an expression used to match a specific string pattern. The following list describes the regular expression:

  • ^: matches a string from the beginning of the string.

  • /hello: matches the string "/hello".

  • $: matches a string to the end of the string.

This regular expression matches only the string "/hello". Examples:

  • "/hello" can be matched.

  • "/hello/" cannot be matched because the string contains an extra character "/" at the end.

  • "hello" cannot be matched because "/" is missing from the beginning of the string.

  • "/hello world" cannot be matched because the string contains extra characters after "/hello".

When a client requests http://example.aliyundoc.com/hello, which contains the string /hello, the POP writes a new URL http://example.aliyundoc.com/index.html to the Location header and returns the Location header together with an HTTP 302 status code to the client. The client initiates a request to http://example.aliyundoc.com/index.html.