【Dev Tools】HTTPヘッダーとは？中身のデータの確認方法（Headers）

【Dev Tool】リクエストヘッダーとは？中身のデータの確認方法（Request Headers）

Chromeなどの開発ツールのnetworkパネルで確認できるHeadersの内容について。

目次

1. Headersとは？
2. ヘッダーの種類
3. General
   1. Referrer policyとは？
   2. オリジンとは？
   3. オリジンとドメインとの違い
4. Response Headers
5. Request Headers
6. Query string parametersとは？
7. Request Payloadとは？

Headersとは？

ブラウザとサーバー間でデータのやりとりをするファイルの冒頭に記述されている補足情報のこと

通信の流れ

ブラウザ

　↓　HTTPリクエスト（ファイル）

サーバー
　
　↓　HTTPレスポンス（ファイル）

ブラウザ

それぞれのファイルにヘッダーがあり、HTTPリクエストヘッダ、HTTPレスポンスヘッダと呼ぶ。

開発ツールではどちらも確認できる。

ヘッダーの種類

項目	名称	内容
General	一般ヘッダ	リクエストとレスポンスのどちらもに共通するヘッダ
Response Headers	レスポンスヘッダ	HTTPレスポンスのヘッダ
Request Headers	リクエストヘッダ	HTTPリクエストのヘッダ

1. General

リクエストしたURLやメソッド、HTTPステータス、IPアドレス、リファラのポリシーが記載されている。

なお、各項目を〇〇ヘッダと呼ぶ。
例：　GeneralヘッダのRequest URLヘッダ

Referrer policyとは？

Referer（リファラ）とは現在のページへのリンク元の情報。
情報追跡にも使用されるため、情報をどこまで含めるかを設定している。

項目	内容
no-referrer	リファラー情報を送らない（Referer ヘッダー全体を省略）
no-referrer-when-downgrade	デフォルト。プロトコルのセキュリティ水準が同一 (HTTP→HTTP, HTTPS→HTTPS) か改善される場合 (HTTP→HTTPS) は送信する。低下する場合 (HTTPS→HTTP) は送信しない
origin	文書のオリジンのみをリファラーとして送信（同一ドメイン内のリンク情報など）
origin-when-cross-origin	同一オリジン間でリクエストを行う場合は送信する。その他の場合はオリジンのみ送信
same-origin	同じオリジンにはリファラーを送信
strict-origin	プロトコルのセキュリティ水準が同じである場合 (HTTPS→HTTPS) にのみ、文書のオリジンをリファラーとして送信
strict-origin-when-cross-origin	同じオリジン間でプロトコルのセキュリティレベルが同じ場合 (HTTPS→HTTPS) はオリジンを送信。安全性の劣る送信先 (HTTPS→HTTP) は送信しない。
unsafe-url	どんな場合もリファラヘッダを送信

オリジンとは？

大元のサイトのこと。例えば、 https://example.com/page.htmlにあるファイルのオリジンは https://example.com/となる。

同一オリジンとは、https://example.com/配下など同一サイトとなる場合。

オリジンとドメインとの違い

ほぼ同じと考えていい。オリジンの方が情報量が多い。

ドメイン： www.google.com
オリジン：　https://www.google.com/(:443)

ドメインのみでなく、スキーム（https://）やポート番号(:443)が入る。

なお、httpの場合のポート番号は:80。

2. Response Headers

サーバーからブラウザに帰ってきたファイルのヘッダ情報。

Access-Control-Allow-Credentials

リクエストの資格情報モード (Request.credentials) が include である場合に、レスポンスをフロントエンドのJavaScriptコードに公開するかどうかをブラウザーに指示する。

booleanで指定。資格情報を必要としない場合はfalseにする。（Access-Control-Allow-Credentialsヘッダが完全に省略される）

・資格情報とは？
Cookie、認証ヘッダー、または TLS クライアント証明書のこと。

Access-Control-Allow-Origin

通信を許可するオリジン。

Cache-Control

キャッシュをどう扱うかの指示。レスポンスとリクエストのいずれにも含まれる。（それぞれで使えるプロパティが異なる）

プロパティ	レスポンス	リクエスト	内容
max-age=	✔︎	✔︎	リソースが新しいとみなされる最長の時間
s-maxage=	✔︎	-	max-age または Expires ヘッダーを上書き
max-stale[=]	-	✔︎	クライアントが古くなったレスポンスを受け入れる
min-fresh=	-	✔︎	少なくとも指定された秒数の間は新しいままのレスポンスを要求
no-cache	✔︎	✔︎	レスポンスをどのキャッシュにも格納するが、格納されたレスポンスは使用する前に常に元のサーバーとの検証を通さなければならない。（キャッシュに保存されないようにする効果はない）
no-store	✔︎	✔︎	レスポンスがどのキャッシュにも保存されないようにする
no-transform	✔︎	✔︎	中間キャッシュやプロキシが、レスポンスの本文、 Content-Encoding, Content-Range, Content-Type を変更できない
only-if-cached	-	✔︎	クライアントによって設定される。レスポンスのためにネットワークを使用しない
must-revalidate	✔︎	-	一度リソースが古くなると、元のサーバーでの検証が成功しない限り、古くなったキャッシュを使用しない
public	✔︎	-	レスポンスをどのキャッシュにも格納することができる
private	✔︎	-	ブラウザーのキャッシュにのみ格納できる
proxy-revalidate	✔︎	-	共有キャッシュ (プロキシなど) にのみ適用。プライベートキャッシュは無視

Connection

現在のトランザクションが完了したあとも、ネットワーク接続を開いたままにするかどうかを設定する。

Connection: keep-alive

後続のリクエストで再利用する。ほとんどの場合 Keep-Alive が設定されるが必須ではない。

Content-Encoding

圧縮している場合にどのメディアで圧縮しているかを返す。

複数の場合は適用された順序を示す。

Content-Encoding: gzip, identity

値	内容
gzip	Lempel-Ziv coding (LZ77) を使用し、32ビットの CRC が付いた形式
deflate	zlib 構造 (RFC 1950 で定義) の deflate 圧縮アルゴリズム
identity	圧縮・変更なし
br	Brotli アルゴリズム

Content-Length

受信者に送信されるエンティティ本文の長さ。単位はバイト長

例: Content-Length: 2161

Content-Typ

リソースのメディア種別。

例：Content-Type: application/json; charset=utf-8

値	内容
media-type	MIME タイプ
charset	標準の文字エンコーディング

Date

メッセージが発信された日時

例：　Wed, 17 Feb 2021 03:27:36 GMT

GMTはGreenwich Mean Timeの略。世界標準時、グリニッジ標準時と呼ばれる。グリニッジはイギリス ロンドン南東部の地名。（なのでイギリスの時間）

Sever

レスポンスを作成したサーバー

例：　Server: nginx

Set-Cookie

サーバーからユーザーエージェントへクッキーを送信する。ユーザーエージェントがサーバーに送り返すこともできる。

例

Set-Cookie: SOC=XyfApMCo5sMAANQhVFAAAAAA; path=/; expires=Fri, 17-Feb-23 03:27:36 GMT; domain=socdm.com; secure; SameSite=None

3. Request Headers

ブラウザからサーバーに要求したファイルのヘッダ情報。

Accept

クライアントが理解できるコンテンツタイプを MIME タイプで伝える。

例： Accept: */*

値	内容	例
*/*	すべての MIME タイプ	/
<MIME_type>/<MIME_subtype>	単一の詳細な MIME タイプ	text/html
<MIME_type>/*	サブタイプの指定がないMIMEタイプ	image/*

Accept-Encoding

ブラウザが理解できる圧縮アルゴリズムの種類。レスポンス側のContent-Encodingと対になる。

例： Accept-Encoding: gzip, deflate, br

値	内容
gzip	Lempel-Ziv coding (LZ77) を使用し、32ビットの CRC が付いた形式
deflate	zlib 構造 (RFC 1950 で定義) の deflate 圧縮アルゴリズム
identity	圧縮・変更なし
br	Brotli アルゴリズム

Accept-Language

ブラウザが理解できる言語。

例: Accept-Language: ja,en-US;q=0.9,en;q=0.8

・;q=とは？ (q 値の重みづけ)

順序付けのための任意の値。weightと呼ばれる相対的な品質質を使用

上記例だと、ja > en-US > en　になる。

Connection

現在のトランザクションが完了したあとも、ネットワーク接続を開いたままにするかどうかを設定する。

Connection: keep-alive

後続のリクエストで再利用する。ほとんどの場合 Keep-Alive が設定されるが必須ではない。

Content-Typ

リソースのメディア種別。

例：Content-Type: application/json; charset=utf-8

値	内容
media-type	MIME タイプ
charset	標準の文字エンコーディング

MIMEタイプの指定方法

<MIME_type>/<MIME_subtype>

Cookie

過去にサーバーがSet-Cookieヘッダーで送信（レスポンス）し、ブラウザに保存されたHTTPクッキー

HOST

サーバーのホスト名とポート番号。

ポート番号が指定されなかった場合は、要求されたサービスの既定のポート（HTTPSなら443、 HTTPなら80）とみなす。

例: Host: d.socdm.com

User-Agent

どのデバイスやブラウザで閲覧しているかの情報。

サーバーやネットワークピアがアプリケーション、オペレーティングシステム、ベンダーや、リクエストしているユーザーエージェントのバージョン等を識別できるようにする特性文字列。

構文

User-Agent: <product> / <product-version> <comment>

項目	内容
product	製品の識別子（または名前や開発コードネーム）
product-version	バージョン
comment	補足情報

User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Mobile Safari/537.36

4. Query string parametersとは？

Headersの中にQuery string parametersも含まれている。

Query string parametersとは、クエリ文字列（URLパラメーター）と呼び、サーバーに情報を送るためにURLの末尾につけ足す文字列（変数）のこと。

URLの?以降の内容。

▼例
https://d.socdm.com/adsv/v1?posall=SSPLOC&id=80215&sdktype=0&hb=true&t=json3&transactionid=6eba653d-e3a9-441e-94e1-ba78b734afa5&sizes=300x250&currency=JPY&pbver=4.25.0&sdkname=prebidjs&adapterver=1.0.1&imark=1&tp=https%3A%2F%2Fcookpad.com%2F

?プロパティ名1=値1&プロパティ名2=値2&,,,,のようになっている情報を見やすく表示している。

5. Request Payloadとは？

Headersの中にRequest Payloadも含まれている。これはPOSTまたはPUTリクエストによって送信されるデータのこと。