Cloudfront経由でHTTPヘッダーの追加変化を確認してみた

AWSのCDN(cloudfront)を使用すると、cloudfront前後でHTTPヘッダーが書換えられたり(変化)・追加されたりします。

ALB経由時でHTTPヘッダーの変化確認方法と同様に、cloudfront前後で具体的にどういう変化が起きているのか検証し確認していましました。

環境・前提条件

User → Cloudfront → EC2

  • AWS cloudfront
  • ALBのバックエンドにEC2(Linux+apache+php)サーバーを構築しHTTPヘッダーを出力するページ(test.php)用意
  • User側のブラウザツールとしてPostmanを使用

環境を作り、cloudfront前後でHTTPヘッダーがどう変化・付与されるか確認してみました。

結論、Cloudfrontを経由するとHTTPリクエストヘッダーに追加されるヘッダー一覧

  • HTTP Request(※普通はしないけど不正チェックしていました)
  • X-Amz-Cf-Id (追加)
  • Via (追加)
  • X-Forwarded-For (追加)
  • Upgrade-Insecure-Requests (追加)
  • CloudFront-Is-Mobile-Viewer (追加)
  • CloudFront-Is-Tablet-Viewer (追加)
  • CloudFront-Is-SmartTV-Viewer (追加)
  • CloudFront-Is-Desktop-Viewer (追加)
  • CloudFront-Viewer-Country (追加)
  • CloudFront-Forwarded-Proto (追加)

※通常はこんな事をする人はいないと思いますが、HTTP Requestの書き換え・チェックを確認するために、cloudfrontをブラウザのProxy設定として設定し、HTTP Requestをカスタマイズしてリクエストしてみました。

HTTP Request以外は、cloudfrontを経由するとこで通常付与されるヘッダー情報になります。

以下、今回の結論を導いた検証結果情報になります。

Cloudfront前のHTTPリクエストヘッダー

Cloudfront前のリクエストヘッダーをまともに調査しようとすると、UserとCloudfrontの間にパケットキャプチャーを仕掛けなければならなくなるので、近しくなる情報としまして、まず「Userが直接EC2に接続しに行った場合のHTTPリクエストヘッダー」を調査しました。

Userが以下の設定でcloudfrontにアクセスしに行ったときの、EC2が受け取ったHTTPリクエストヘッダーの出力に相当します。

EC2側の出力としましては、

HTTP Request Headers

HTTP RequestGET /test.php HTTP/1.1
User-AgentPostmanRuntime/7.26.5
Accept*/*
Cache-Controlno-cache
Postman-Tokencccb6f74-a896-4cdd-a761-1664b3e5eb3f
Hostec2-***.ap-northeast-1.compute.amazonaws.com
Accept-Encodinggzip, deflate, br
Connectionkeep-alive

HTTP Response Headers

Upgradeh2,h2c
ConnectionUpgrade
X-Powered-ByPHP/5.4.16

実際に、Userが以下の設定でcloudfrontにアクセスしに行った場合のHTTPレスポンスヘッダーには、もっとヘッダー情報が追加されます。キャッシュヒットしたかキャッシュミスしたかの情報がわかる「x-cache」ヘッダーもあります。

追加されるHTTPレスポンスヘッダーについて詳しくは以下のリンクを参照してください。

Cloudfront後のHTTPリクエストヘッダー

こちらは、実際にCloudfrontからEC2が受け取ったHTTPリクエストヘッダーです。

Userが以下の設定でCloudfrontにアクセスしに行ったときの、EC2が受け取ったHTTPリクエストヘッダーの出力です。

EC2側の出力としましては、

HTTP Request Headers

※下の表は、画像のデータとは異なり、chimeでつなげた場合のHTTPリクエストヘッダーになります。異なる情報ですみません。

HTTP RequestGET /test.php HTTP/1.1
Hostcf.****.***
User-AgentMozilla/5.0 (Windows NT 10.0; Win64; x64)
X-Amz-Cf-IdZshae0Mv*****
ConnectionKeep-Alive
Via1.1 06f682****.cloudfront.net (CloudFront)
X-Forwarded-For18*.**.**.**
Accept-Languageja
Accepttext/html,application/xhtml+xml,application/xml;q=0.9
Accept-Encodinggzip, deflate
Upgrade-Insecure-Requests1
CloudFront-Is-Mobile-Viewerfalse
CloudFront-Is-Tablet-Viewerfalse
CloudFront-Is-SmartTV-Viewerfalse
CloudFront-Is-Desktop-Viewertrue
CloudFront-Viewer-CountryJP
CloudFront-Forwarded-Protohttp

HTTP Response Headers

Upgradeh2,h2c
ConnectionUpgrade
X-Powered-ByPHP/5.4.16

HTTP Requestヘッダーテスト。イレギュラー的にProxyとしてcloudfront URL設定した場合

ALBはProxyサーバーのロードバランサーとして機能するかどうか確認した時と同様に、イレギュラーなHTTP Requestヘッダーをcloudfrontが受け付けた時の挙動を確認しました。

■ パターン1

  • UserのProxy設定に「cloudfront DNS名」を設定
  • UserのURL Requestは「適当なURLのhttp://a.b.c/test.php

cloudfrontの出力画面としましては、エラーとなりました。

■ パターン2

  • UserのProxy設定に「cloudfront DNS名」を設定
  • UserのURL Requestは「URLのhttp://<cloudfront DNS名>/test.php

cloudfrontの出力画面としましては、正常となりました。

つまり、cloudfrontはHTTP Requestヘッダーをチェックしています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です