URL 書き換え
Azure Front Door は URL 書き換えをサポートしており、配信元にルーティングされる要求パスを変更できます。 この強力な機能により、URL や指定したヘッダーを書き換えるタイミングを決定する条件を定義できます。 これらの条件は、要求と応答に存在する情報に基づいています。
URL 書き換えを使用することで、エンドユーザーのデバイスの種類や要求するファイルの種類などの要因に基づいて、エンド ユーザーを異なる配信元にリダイレクトできます。 URL 書き換えアクションはルール セット内で簡単に構成できるため、ルーティング動作をきめ細かく制御できます。
ソース パターン
ソース パターンは、置換する最初の要求の URL パスを表します。 現在、ソース パターンはプレフィックス ベースの照合方法を使用しています。 すべての URL パスを一致させるために、ソース パターンの値としてスラッシュ (/) を指定できます。
URL 書き換えアクションのコンテキストでは、ルート構成の照合するパターンの後のパスのみがソース パターンとして考慮されます。 たとえば、このルール セットでは、受信 URL の形式が contoso.com/pattern-to-match/source-pattern の場合、/source-pattern のみ書き換えるソース パターンとみなされます。 URL 書き換えが適用されると、発信 URL 形式は contoso.com/pattern-to-match/destination になります。
URL の /pattern-to-match セグメントを削除する必要がある場合は、ルート構成の配信元グループの配信元パス を / に設定できます。
宛先
配信先パスは、ソース パターンを置き換えるパスを表します。 たとえば、要求 URL パスが contoso.com/foo/1.jpg で、ソース パターンが /foo/ で、宛先が /bar/ と指定する場合、コンテンツは配信元の contoso.com/bar/1.jpg から提供されます。
一致しないパスを保持する
[一致しないパスを保持する] を指定すると、ソース パターンの後に残っているパスの処理補法を制御できます。 [一致しないパスを保持する] を [はい] に設定することで、残りのパスが新しいパスに追加されます。 一方、[いいえ] (既定) に設定すると、ソース パターンの後の残りのパスが削除されます。
[一致しないパスを保持する] の動作を示す例は次のとおりです。
| 一致しないパスを保持する | ソース パターン | 到着地 | 着信要求 | 配信元から提供されるコンテンツ |
|---|---|---|---|---|
| はい | / | /foo/ | contoso.com/sub/1.jpg | /foo/sub/1.jpg |
| はい | /sub/ | /foo/ | contoso.com/sub/image/1.jpg | /foo/image/1.jpg |
| いいえ | /sub/ | /foo/2.jpg | contoso.com/sub/image/1.jpg | /foo/2.jpg |
重要
Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、Azure Front Door (クラシック) の廃止に関するページを参照してください。
転送ルーティングの種類の規則を構成するときにカスタム転送パスを設定すると、Azure Front Door (クラシック) で URL の書き換えがサポートされます。 既定では、スラッシュ (/*) のみが定義されている場合、Front Door により、転送された要求で受信 URL パスが複製されます。 転送された要求で使用されるホスト ヘッダーは、選択されたバックエンドの構成に基づきます。 詳細については、バックエンド ホスト ヘッダーのドキュメントを参照してください。
URL 書き換えの重要な側面は、ワイルドカードに一致するカスタム転送パスを使用する場合、受信パスの一致する部分を転送パスにコピーする機能にあります。 次の表は、カスタム転送パスの /fwd/ を使用する場合の受信要求および対応する転送パスの例を示しています。 a/b/c で示されるセクションは、ワイルドカードの一致を置き換える部分を表します。
| 受信 URL パス | 一致パス | カスタム転送パス | 転送パス |
|---|---|---|---|
| /foo/a/b/c | /foo/* | /fwd/ | /fwd/a/b/c |
URL 書き換えの例
次のフロントエンド ホストとパスの組み合わせが構成されているルーティング規則を考えてみましょう。
| Hosts | パス |
|---|---|
| www.contoso.com | /* |
| /foo | |
| /foo/* | |
| /foo/bar/* |
次の表は、受信要求とそれに対応する代表的な一致ルートの例を示しています。 また、カスタム転送パスとその結果提供される転送パスの例も示しています。
たとえば、表の 2 行目について考えてみましょう。 受信要求が www.contoso.com/sub で、カスタム転送パスが / に設定されている場合、転送パスは /sub になります。 しかし、カスタム転送パスが /fwd/ に設定されている場合、転送パスは /fwd/sub になります。 パス内の太字で表示された部分は、ワイルドカード一致に含まれる部分を示しています。
| 着信要求 | 代表的な一致パス | / | /fwd/ | /foo/ | /foo/bar/ |
|---|---|---|---|---|---|
| www.contoso.com/ | /* | / | /fwd/ | /foo/ | /foo/bar/ |
| www.contoso.com/sub | /* | /sub | /fwd/sub | /foo/sub | /foo/bar/sub |
| www.contoso.com/a/b/c | /* | /a/b/c | /fwd/a/b/c | /foo/a/b/c | /foo/bar/a/b/c |
| www.contoso.com/foo | /foo | / | /fwd/ | /foo/ | /foo/bar/ |
| www.contoso.com/foo/ | /foo/* | / | /fwd/ | /foo/ | /foo/bar/ |
| www.contoso.com/foo/bar | /foo/* | /bar | /fwd/bar | /foo/bar | /foo/bar/bar |
Note
Azure Front Door (クラシック) では、静的パスから別の静的パスへの URL 書き換えのみがサポートされます。 一致しないパスの保持は、Azure Front Door Standard および Premium でサポートされます。 詳細については、一致しないパスの保持に関する説明を参照してください。
オプション設定
[Cache Configuration] (キャッシュ構成) - 無効になっているか、または指定されていない場合、このルーティング規則と一致する要求から、キャッシュされたコンテンツを使用しようとするのではなく、代わりに常にバックエンドからフェッチされます。 詳細については、「Azure Front Door でのキャッシュ」を参照してください。
次のステップ
- Azure Front Door プロファイルを作成する方法について学習します。
- Azure Front Door のルール セットの詳細を確認します
- Azure Front Door のルーティング アーキテクチャについて確認します。