Azureのリバースプロキシ/CDNなどのサービスである「Azure Front Door」で、配信元のサーバ/サイトからクライアントへコンテンツが正しく送られない場合がある。その原因の1つである、配信元へ送出される「Host」ヘッダの設定方法や設定上の注意点などを説明する。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
対象:Azure Front Door Standard/Premium
リバースプロキシやCDN(コンテンツ配信ネットワーク)、WAF(Webアプリケーションファイアウォール)などが利用できるAzureのサービス「Azure Front Door」で、そのプロファイルに配信元(Origin)のサーバ/サイトを割り当てたとき、以下のようなトラブルが生じることがある。
こうしたトラブルの原因の1つとして、Azure Front Doorから配信元に送られるHTTPリクエスト内の「Host」ヘッダが適切でない可能性が考えられる。本Tech TIPSでは、この「Host」ヘッダを変更する方法について説明する。
対象はAzure Front Door Standard/Premiumとし、以前のAzure Front doorクラシックは扱わない。また、Azure CLIやBicepによる設定は、原稿執筆時点ではプレビュー中で、正式版ではないことをご了承いただきたい。
Azure Front DoorがクライアントからのHTTPリクエストを受信後、配信元(origin)に中継するHTTPリクエストには、宛先のホスト名を表す「Host」ヘッダ(ホストヘッダ)が含まれる。このHostヘッダに含まれるホスト名は、Azure Front Doorの配信元の設定で変更できる。
そのため、クライアントからリクエストされたホスト名の場合もあれば、配信元のホスト名の場合もあるし、あるいは全く別のホスト名も指定できる(希望通りの動作をするかどうかは別として)。
以下の画面は、配信元としてAzure App Service(Web App)のWebサーバを設定したAzure Front DoorのエンドポイントをWebブラウザでアクセスしたところだ。ここでは、クライアントからのアクセス先ホスト名(=Azure Front Doorエンドポイントに設定されたカスタムドメイン)ではなく、配信元(=Azure App Service)のオリジナルのホスト名が送信されている。
このHostヘッダに設定すべきホスト名は、配信元のサーバやサイトなどによって全く異なる。例えば配信元の実体がバーチャルドメイン方式のレンタルサーバの場合、配信元サーバのホスト名を正しく指定しないと別のバーチャルホストが応答したり、共通名(Common Name)の不一致によるSSLサーバ証明書のエラーが生じたりする恐れがある。
逆に配信元のオリジナルのホスト名を設定すると、例えば上記の画面にあるサーバ変数「HTTP_HOST」を元に生成される各種URLが、本来のAzure Front Doorエンドポイントではなく、配信元サーバを指すようになる。結果としてコンテンツが表示されなくなったり、隠しておきたい内部ホスト名が漏えいしたりする。
そのため、措定すべきホスト名は十分に考慮する必要がある。その上で、以下の手順でホスト名を変更していただきたい。
AzureポータルでFront Doorから配信元へ送るHostヘッダの内容を変更する手順は以下の通りだ。クライアントからリクエストされるホスト名を設定したい場合は、設定欄の[配信元のホストヘッダー]を空欄にすること。
Copyright© Digital Advantage Corp. All Rights Reserved.