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