リクエスト ヘッダーとレスポンス

リージョン ID

REGION_ID は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r が App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。

詳しくは、リージョン ID をご覧ください。

サポートされている HTTP ヘッダーの詳細、App Engine でのリクエストとレスポンスに関する制限事項の詳細については、このリファレンス ページをご覧ください。App Engine がリクエストを受信して、レスポンスを送信する仕組みの詳細については、リクエストの処理方法をご覧ください。

リクエスト ヘッダー

受信した HTTP リクエストには、クライアントから送信された HTTP ヘッダーが含まれています。セキュリティ上の理由から、一部のヘッダーは、アプリケーションに到達する前に中間プロキシによってサニタイズ、削除または修正されます。

受信リクエストから削除されるヘッダー

クライアントがリクエストを送信すると、次のヘッダーが受信リクエストから削除されます。

  • X-Google-* パターンに一致する名前を含むヘッダー。この名前のパターンは Google で予約されています。

  • App Engine 固有のヘッダーと一致する名前を含むヘッダー。大文字と小文字を区別しない完全一致のみが削除されます。たとえば、X-Appengine-Country または X-AppEngine-Country という名前のヘッダーは削除されますが、X-Appengine-Cntry は削除されません。

また、次のヘッダーは、クライアントとサーバー間の HTTP データの転送に関連するため、受信リクエストから削除されます。

  • Accept-Encoding
  • Connection
  • Keep-Alive
  • Proxy-Authorization
  • TE
  • Trailer
  • Transfer-Encoding

たとえば、サーバーが Accept-Encoding リクエスト ヘッダーの値に応じて、gzip 圧縮されたレスポンスを自動的に送信する場合があります。アプリケーション自体は、クライアントがどのコンテンツ エンコードを受け付け可能かを認識している必要はありません。

App Engine 固有のヘッダー

アプリに対するサービスとして、App Engine は、以下のヘッダーをすべてのリクエストに追加します。

X-Appengine-Country
リクエスト送信元の国を表す ISO 3166-1 alpha-2 国コード。App Engine は、クライアントの IP アドレスからこのコードを決定します。国情報は WHOIS データベースから導出されるものではないことに注意してください。ある IP アドレスの国情報が WHOIS データベースには存在していても、X-Appengine-Country ヘッダーに国情報が含まれていないということもあります。アプリケーションが特別な国コード ZZ（不明な国）を処理できるようにしておく必要があります。
X-Appengine-Region
リクエスト送信元のリージョンの名前。この値は、X -Appengine-Country の国のコンテキストでのみ意味があります。たとえば、国が「US」でリージョンが「ca」の場合は、この「ca」はカナダではなく「カリフォルニア州」を意味します。有効なリージョン値の一覧については、ISO-3166-2 規格をご覧ください。
X-Appengine-City
リクエスト送信元の都市の名前。たとえば、リクエストの送信元がマウンテン ビューという都市の場合は、ヘッダー値が mountain view となります。このヘッダーに有効な値の正式な一覧はありません。
X-Appengine-CityLatLong
リクエスト送信元の都市の緯度と経度。米国のマウンテンビューからのリクエストの場合は、この文字列が「37.386051,-122.083851」のようになります。
X-Cloud-Trace-Context
Cloud Trace と Cloud Logging に使用されるリクエスト用の一意の ID。App Engine スタンダード環境上のアプリでは、いずれもトレースが自動で行われるため、このヘッダーを無効にしたり、トレースのサンプリング レートを選択したりすることはできません。
X-Forwarded-For: [CLIENT_IP(s)], [global forwarding rule IP]

クライアント リクエストがルーティングされた際に経由した IP アドレスからなるカンマ区切りリスト。このリストの最初の IP アドレスは、通常は、そのリクエストを作成したクライアントの IP アドレスです。それ以降の IP アドレスには、このリクエストがアプリケーション サーバーに到達するまでに経由した各プロキシ サーバーに関する情報が含まれます。次に例を示します。

X-Forwarded-For: clientIp, proxy1Ip, proxy2Ip
X-Forwarded-Proto [http | https]

クライアントでアプリケーションに接続するために使用されたプロトコルに基づいて、http または https が表示されます。

Google Cloud Load Balancer ですべての https 接続が終了され、http を介して App Engine インスタンスにトラフィックが転送されます。たとえば、ユーザーが https://PROJECT_ID.REGION_ID.r.appspot.com を介してサイトへのアクセスをリクエストする場合、X-Forwarded-Proto ヘッダーの値は https になります。

さらに、App Engine は内部で使用する以下のヘッダーを設定できます。

  • X-Appengine-Https
  • X-Appengine-User-IP
  • X-Appengine-Api-Ticket
  • X-Appengine-Request-Log-Id
  • X-Appengine-Default-Version-Hostname
  • X-Appengine-Timeout-Ms
App Engine のサービスが次のようなリクエスト ヘッダーを追加する場合があります。

  • cron サービスからのリクエストにより、次のヘッダーが追加されます。

    X-Appengine-Cron: true

    詳しくは、cron の URL を保護するをご覧ください。

  • 他の App Engine アプリケーションから送信されたリクエストには、リクエスト元のアプリが URL 取得サービスを使用している場合、リクエストを発行したアプリを識別するヘッダーが含まれています。

    X-Appengine-Inbound-Appid

リクエストのレスポンス

この HTTP ヘッダーに関するドキュメントは、受信 HTTP リクエストに対するレスポンスにのみ適用されます。レスポンスは、クライアントに返される前に変更されることがあります。

削除されるヘッダー

以下のヘッダーは無視され、レスポンスから削除されます。

  • Connection
  • Content-Encoding*
  • Content-Length
  • Date
  • Keep-Alive
  • Proxy-Authenticate
  • Server
  • Trailer
  • Transfer-Encoding
  • Upgrade

* App Engine がレスポンスを圧縮する場合には、再度追加されることがあります。

名前または値に非 ASCII 文字を含むヘッダーも削除されます。

追加または置換されるヘッダー

レスポンス内で、以下のヘッダーが追加または置換されます。

Cache-Control、Expires、Vary

これらのヘッダーでは、中間ウェブプロキシ（Google フロントエンド、インターネット サービス プロバイダなど）やブラウザに対するキャッシング ポリシーを指定します。アプリによってこれらのレスポンス ヘッダーが設定された場合、通常は変更されませんが、アプリによって Set-Cookie ヘッダーも設定された場合、またはそのレスポンスの対象のユーザーが管理者アカウントを使用してログインした場合は除きます。

アプリによって Set-Cookie レスポンス ヘッダーが設定された場合、Cache-Control ヘッダーは private に（まだ制限されていない場合）、Expires ヘッダーは現在の日付（まだ過去になっていない場合）に設定されます。一般的に、これでブラウザがレスポンスをキャッシュに保存できますが、中間プロキシ サーバーではキャッシュに保存できません。これはセキュリティ上の理由からです。仮にレスポンスが一般公開された状態でキャッシュに保存されたとすると、その後で別のユーザーが同じリソースをリクエストして、最初のユーザーの Cookie を取得できてしまう可能性があります。

アプリによって Cache-Control レスポンス ヘッダーが設定されていない場合、サーバーはこのヘッダーを private に設定して Vary: Accept-Encoding ヘッダーを追加することがあります。

Google フロントエンドでサポートされている Vary 値のリストなど、キャッシュ保存の詳細については、レスポンスのキャッシュ保存をご覧ください。

Content-Encoding

リクエスト ヘッダーとレスポンスの Content-Type に応じて、サーバーは前述のようにレスポンスの本文を自動的に圧縮する場合があります。この場合、サーバーは Content-Encoding: gzip ヘッダーを追加して本文が圧縮されていることを示します。詳細については、レスポンスの圧縮をご覧ください。

Content-Length または Transfer-Encoding

サーバーは、アプリケーションから返される Content-Length ヘッダーを常に無視します。Content-Length を本文の長さに設定するか（圧縮が適用される場合は圧縮後の長さ）、Content-Length を削除し、チャンク転送エンコードを使用します（Transfer-Encoding: chunked ヘッダーを追加します）。

Content-Type

このヘッダーを明示的に設定しない場合、http.ResponseWriter クラスはレスポンス本文の先頭からコンテンツ タイプを検出し、それに応じて Content-Type ヘッダーを設定します。

Date

現在の日時に設定します。

Server

Google Frontend に設定します。開発用サーバーは、この値を Development/x に設定します。x はバージョン番号です。

サイトの動的ページにアクセスするユーザーが管理者アカウントを使用してログインしている場合は、App Engine からのレスポンス ヘッダーにリクエストごとの統計情報が含まれます。

X-Appengine-Resource-Usage
リクエストで使用されるリソース（ミリ秒単位）。サーバー側の時間も含まれます。

リソースの使用統計情報を含むレスポンスはキャッシュできなくなります。

アプリケーションの構成に含まれるレスポンス ヘッダー

カスタム HTTP レスポンス ヘッダーを、アプリケーションの構成ファイル内の動的または静的パスの URL ごとに設定できます。詳しくは構成ドキュメントの http_headers セクションをご覧ください。