URL 書き換え

[アーティクル]
02/14/2023

Azure Front Door では、配信元にルーティングされる要求のパスを変更するために URL 書き換えがサポートされます。また、URL 書き換えでは、条件を追加することで、特定の条件が満たされた場合にのみ、URL または指定したヘッダーが書き換えられるようにすることもできます。これらの条件は、要求と応答の情報に基づいています。

この機能を使用すると、シナリオ、デバイスの種類、または要求されたファイルの種類に基づいて、さまざまな配信元にユーザーをリダイレクトできます。

URL 書き換えの設定は、ルールセットの構成で確認できます。

ソースパターン

ソースパターンとは、置換するソース要求の URL パスです。現在、ソースパターンではプレフィックスに基づく一致が使用されます。すべての URL パスを一致させるには、ソースパターン値としてスラッシュ (/) を使用します。

URL 書き換えのソースパターンでは、ルート構成の "照合対象のパターン" の後のパスのみが考慮されます。たとえば、<Frontend-domain>/<route-patterns-to-match-path>/<Rule-URL-Rewrite-Source-pattern> という受信 URL 形式がある場合、/<Rule-URL-Rewrite-Source-pattern> のみがルールエンジンによって書き換えられるソースパターンと見なされます。したがって、ソースパターンの一致を使用した URL 書き換えルールがある場合、送信 URL の形式は <Frontend-domain>/<route-patterns-to-match-path>/<Rule-URL-Rewrite-destination> になります。

URL パスの /<route-patterns-to-match-path セグメントを削除する必要があるシナリオの場合は、ルート構成の元のグループの元のパスを / に設定します。

到着地

書き換えに使用する宛先パスを定義できます。宛先のパスは、ソースパターンを上書きします。

一致しないパスを保持する

[一致しないパスを保持する] を指定すると、ソースパターンの後に残っているパスを新しいパスに追加できます。

たとえば、 [一致しないパスを保持する] を [はい] に設定したとします。

着信要求が www.contoso.com/sub/1.jpg の場合、ソースパターンは / に設定され、宛先は /foo/ に設定されて、コンテンツは配信元の /foo/sub/1.jpg から取得されます。
着信要求が www.contoso.com/sub/image/1.jpg の場合、ソースパターンは /sub/ に設定され、宛先は /foo/ に設定されて、コンテンツは配信元の /foo/image/1.jpg から取得されます。

たとえば、 [一致しないパスを保持する] を [いいえ] に設定したとします。

着信要求が www.contoso.com/sub/image/1.jpg の場合、ソースパターンは /sub/ に設定され、宛先は /foo/2.jpg に設定されて、wwww.contoso.com/sub/ でどのパスが後続していてもコンテンツは配信元の /foo/2.jpg から取得されます。

バックエンドに転送する要求を作成するときに、オプションのカスタム転送パスを構成して使用すると、Azure Front Door (クラシック) で URL 書き換えがサポートされます。既定では、カスタム転送パスが指定されていない場合、Front Door により、転送された要求で使用される URL に受信 URL パスがコピーされます。転送された要求で使用されるホストヘッダーは、選択されたバックエンド用に構成されています。その機能と構成方法については、「バックエンドホストヘッダー」をご覧ください。

URL 書き換えの堅牢な部分としては、カスタム転送パスによって、転送されたパスに、ワイルドカードパスと一致する受信パスの任意の部分がコピーされることです。

たとえば、一致パスが /foo/* で、カスタム転送パス用に /fwd/ が構成されている場合、ワイルドカード以降のすべてのパスのセグメントは、次の図にオレンジ色で示されている転送パスにコピーされます。この例では、受信 URL パスが /foo/a/b/c の場合、転送パスは /fwd/a/b/c になります。次の図に緑色で示されているワイルドカードは、a/b/c パスのセグメントによって置き換えられます。

Azure Front Door での URL パスの書き換えの図