Application Gateway は、トラフィックをリダイレクトするために使用できます。 一般的なリダイレクト メカニズムがあり、あるリスナーで受信したトラフィックを別のリスナーまたは外部サイトにリダイレクトできます。 これにより、アプリケーションの構成が簡単になり、リソースの使用が最適化され、グローバルなリダイレクトやパスに基づくリダイレクトなどの新しいリダイレクト シナリオがサポートされるようになります。
多くの Web アプリケーションの一般的なリダイレクト シナリオは、アプリケーションとそのユーザー間のすべての通信が暗号化されたパスを介して行われるように、HTTP から HTTPS への自動リダイレクトをサポートすることです。 これまでは、HTTP で受信した要求を HTTPS にリダイレクトすることが唯一の目的である専用のバックエンド プールの作成といった手法が使われていました。 Application Gateway ではリダイレクトがサポートされているため、ルーティング規則に新しいリダイレクト構成を追加し、HTTPS プロトコルを使用する別のリスナーをターゲット リスナーとして指定するだけでこれを実現できます。 HTTP から HTTPS へのリダイレクトの詳細については、 Azure portal を使用した HTTP から HTTPS へのリダイレクトを使用した Application Gateway の作成に関するページを参照してください。
リダイレクトの種類
リダイレクトの種類では、クライアントがリダイレクトの目的を理解するための応答の状態コードが設定されます。 次の種類のリダイレクトがサポートされています。
- 301 (永続的に移動) :ターゲット リソースに新しい永続的な URI が割り当てられていることを示します。 このリソースへの今後の参照によって、囲まれた URI のいずれかが使用されます。 状態コード 301 は HTTP から HTTPS へのリダイレクトに使用します。
- 302 (検出) :ターゲット リソースが一時的に別の URI に存在することを示します。 リダイレクトは場合によっては変更される可能性があるため、クライアントは今後の要求のために有効な要求 URI を引き続き使用する必要があります。
- 303 (その他を参照): ターゲット リソースがユーザー エージェントを別のリソースにリダイレクトしていることを示します。これは、[場所] ヘッダー フィールドの URI で示されます。
- 307 (一時的なリダイレクト) :ターゲット リソースが一時的に別の URI に存在することを示します。 ユーザー エージェントからその URI への自動リダイレクトを行う場合、要求メソッドを変更することはできません。 リダイレクトは時間が経つにつれて変更される可能性があるため、クライアントは今後の要求のために元の有効な要求 URI を引き続き使用する必要があります。
リダイレクト機能
リスナーのリダイレクト
あるリスナーから別のリスナーにリダイレクトします。 リスナーのリダイレクトは、一般に、HTTP から HTTPS へのリダイレクトを有効にする場合に使用されます。
マルチサイト ターゲット リスナーを使用してリダイレクトを構成する場合は、ソース リスナーの一部として定義されているすべてのホスト名 (ワイルドカード文字の有無にかかわらず) も宛先リスナーの一部である必要があります。 これにより、HTTP から HTTPS へのリダイレクトを構成しているときに、宛先リスナーにホスト名がないことが原因でトラフィックが削除されることがなくなります。
パスに基づくリダイレクト
この種類のリダイレクトでは、特定のサイト領域でのみリダイレクトが有効になります。たとえば、
/cart/*で示されるショッピング カート領域の HTTPS 要求に HTTP をリダイレクトする場合などです。外部サイトへのリダイレクト
この変更により、お客様は、リダイレクト先のターゲット リスナーまたは外部サイトを指定する新しいリダイレクト構成オブジェクトを作成する必要があります。 構成要素は、リダイレクトされる URL に URI パスとクエリ文字列を追加できるオプションもサポートしています。 リダイレクトの種類を選択することもできます。 このリダイレクト構成は、作成されると、新しいルールによってソース リスナーに関連付けられます。 基本的なルールを使うと、リダイレクト構成はソース リスナーに関連付けられて、グローバル リダイレクトになります。 パスベース ルールを使用する場合、リダイレクトの構成は URL パス マップで定義されます。 したがって、サイトの特定のパス領域にのみ適用されます。