オリジンサーバー上のリソースが再配置された場合、Dynamic Content Delivery Network (DCDN) の POP (Point of Presence) は、古いリクエスト URL をリライトし、新しいパスにリダイレクトします。これにより、オリジンサーバーへのリクエストが削減され、アクセスパフォーマンスが向上します。
参考：本機能がルールエンジンからルール条件を参照する場合、実行順序は本機能自体の設定の優先順位ではなく、ルールエンジンで設定されたルール条件の優先順位に従います。
背景情報
HTTP ステータスコード 302 (Found) は、リクエストされたリソースが一時的に再配置されたことを示します。URI リライトルールが設定されている場合、DCDN の POP は HTTP 302 レスポンスの Location ヘッダーに新しい URI を追加します。その後、クライアントは新しい URI にリクエストを送信します。
デフォルトのステータスコード 302 に加えて、POP はステータスコード 303 と 307 もサポートしています。リダイレクトのステータスコードを変更したい場合は、チケットを送信してください。
HTTP ステータスコード | 説明 | 処理方法 | シナリオ |
302 | Found | GET リクエストは変更されません。他のメソッドを使用するリクエストは、GET リクエストに変更される場合があります。 | Web ページが不明な理由で一時的にアクセスできなくなっています。検索エンジンは Web ページの URL を更新しません。 |
303 | See Other | GET リクエストは変更されません。他のメソッドを使用するリクエストは GET リクエストに変更されます。メッセージボディは破棄されます。 | このステータスコードは、ページの再読み込みによって引き起こされるリダイレクトの繰り返しを防ぐため、PUT および POST リクエストのリダイレクトに使用されます。 |
307 | Temporary Redirect | リクエストメソッドとメッセージボディの両方が変更されません。 | Web ページが不明な理由で一時的にアクセスできなくなっています。検索エンジンは Web ページの URL を更新しません。Web サイトが GET 以外のリクエストメソッドをサポートしている場合、ステータスコード 302 の代わりに 307 が返されます。 |
1 つのドメイン名に対して最大 50 個の URI リライトルールを作成できます。複数の URI リライトルールを設定した場合、ルールは、DCDN コンソールに表示されている順序に従って、上から順に適用されます。
シナリオ
オリジンサーバー上のリソースが別のディレクトリに移動された場合、POP 上のキャッシュされた URL はそれに応じて更新されます。クライアントが元の URL にリクエストを送信すると、DCDN はリクエストをリライトして新しい URL にリダイレクトします。たとえば、画像ファイルが /download/ ディレクトリから /image/ ディレクトリに移動された場合などです。
操作手順
- DCDNコンソールにログインします。
- 左側のナビゲーションペインで ドメイン名 をクリックします。
ドメイン名 ページで、対象のドメイン名を見つけ、設定 をクリックします。
- ドメイン名の左側のナビゲーションウィンドウで、[キャッシング] をクリックします。
アクセス URL の書き換え タブをクリックします。
追加 をクリックし、要件に応じてリライトルールを設定します。
パラメーター
説明
[書き換え対象の URI]
パスはスラッシュ (
/) で始まり、プロトコルとドメイン名を除外する必要があります。PCRE (Perl 互換正規表現) がサポートされています。例：
^/hello$。
[ターゲット URI]
リライトルールでフラグを [中断] に設定した場合、パスはスラッシュ (
/) で始まり、プロトコルとドメイン名を除外する必要があります。リライトルールでフラグを [リダイレクト] に設定した場合、パスにプロトコルとドメイン名を含めることができます。PCRE がサポートされています。たとえば、
$1や$2は、書き換え対象の URI 内の括弧でキャプチャされた文字列を参照するために使用されます。
[実行ルール]
有効な値：[リダイレクト]、[中断]。
[リダイレクト]：リクエストの URI がルールに一致する場合、POP はステータスコード 302 を返し、Location ヘッダーで指定された URI にリクエストをリダイレクトします。元の URI のパラメーターは変更されません。このルールが実行されると、クライアントにリダイレクトレスポンスが送信され、後続のルールの評価は行われません。
[中断]：リクエストの URI がルールに一致する場合、POP はリクエストをターゲット URI にリライトします。元の URI のパラメーターは変更されません。現在のルールが実行された後、残りのルールはスキップされます。
OK をクリックします。
ルールを作成した後、[URLリライト] タブでそのルールを [変更] または [削除] できます。
設定例
例1
クライアントが http://example.aliyundoc.com/hello をリクエストすると、リクエストパスは /hello になります。POP は、302 レスポンスの Location ヘッダーに新しい URL http://example.aliyundoc.com/index.html を含めてクライアントに返します。その後、クライアントは http://example.aliyundoc.com/index.html にリクエストを送信します。
このルールでは、[書き換え対象の URI] を ^/hello$ に、[ターゲット URI] を /index.html に、[フラグ] を [リダイレクト] に設定します。
302 リダイレクト中、Location ヘッダーにプロトコルとドメイン名が含まれていない場合、クライアントはデフォルトで元のリクエストのプロトコルとドメイン名を使用します。
例2
クライアントが http://example.aliyundoc.com/hello をリクエストすると、リクエストパス /hello は正規表現 ^/hello$ に一致します。POP はクライアントに 302 レスポンスを返します。レスポンスには、Location ヘッダーにターゲット URL https://test.aliyundoc.com/index.html が含まれます。クライアントがレスポンスを受信した後、https://test.aliyundoc.com/index.html にリクエストを送信します。
このルールでは、[書き換え対象の URI] を ^/hello$ に、[ターゲット URI] を https://test.aliyundoc.com/index.html に、[フラグ] を [リダイレクト] に設定します。
例3
クライアントが http://www.example.com/cdn/url/http://image.example.com/image/cat.jpg をリクエストすると、リクエストパスには /cdn/url/http:// が含まれ、正規表現 ^/cdn/url/http://(.*) に一致します。POP はクライアントに 302 レスポンスを返します。レスポンスには、Location ヘッダーにターゲット URL http://image.example.com/image/cat.jpg が含まれます。クライアントがレスポンスを受信した後、http://image.example.com/image/cat.jpg にリクエストを送信します。
このルールでは、[書き換え対象の URI] を ^/cdn/url/http://(.*) に、[ターゲット URI] を http://$1 に、[フラグ] を [リダイレクト] に設定します。
例4
クライアントが http://example.aliyundoc.com/stories/index.html#/voice/318 をリクエストすると、URL の #/voice/318 の部分はクライアントサイドのフラグメント識別子です。ブラウザはこの部分をサーバーに送信しません。POP が受信する実際のリクエストパスは /stories/index.html です。したがって、リライトルールを設定する際には、[書き換え対象の URI] を ^/stories/index\.html$ に設定して # の前のパスに一致させます。次に、[ターゲット URI] をターゲット URL に設定し、[フラグ] を [リダイレクト] に設定します。
異なる # フラグメントを持つ複数のソース URL を異なるターゲット URL にリダイレクトするには、ソースパスごとに個別のリライトルールを設定する必要があります。これは、サーバーが # 記号に続くコンテンツに基づいて URL を区別できないためです。
例5
サブディレクトリのホームページを設定する：クライアントがサブディレクトリ名にアクセスしたときにサブディレクトリのデフォルトのホームページファイルを返すことは、Web サイトの一般的な要件です。URI リライトを使用すると、オリジンサーバーを変更することなく DCDN 側でこの機能を実装できます。たとえば、ホームページファイルが https://www.example.com/cdn/index.html の場合、設定が有効になると、https://www.example.com/cdn または https://www.example.com/cdn/ へのクライアントリクエストはホームページファイルを返します。
ルールを設定する前に、オリジンサーバー上のサブディレクトリのホームページファイルにアクセスできることを確認してください。たとえば、https://www.example.com/cdn/index.html が期待どおりに返されることを確認します。
クライアントからのリクエストパスは、スラッシュ (/) で終わる場合と終わらない場合があります。したがって、両方のケースに一致させるには、次の 2 つのルールを設定する必要があります。
ルール 1：[書き換え対象の URI] を
^/(.+)/$に、[ターゲット URI] を/$1/index.htmlに、[フラグ] を [中断] に設定します。ルール 2：[書き換え対象の URI] を
^/([^.?#]+)$に、[ターゲット URI] を/$1/index.htmlに、[フラグ] を [中断] に設定します。
設定が有効になった後、https://www.example.com/cdn などのサブディレクトリに直接アクセスします。サブディレクトリのホームページファイルが期待どおりに返された場合、設定は成功です。