##【Dev Tool】リクエストヘッダーとは？中身のデータの確認方法（Request Headers）
Chromeなどの開発ツールのnetworkパネルで確認できるHeadersの内容について。
##目次
- Headersとは？
- ヘッダーの種類
-
General
4. Referrer policyとは？
5. オリジンとは？
6. オリジンとドメインとの違い - Response Headers
- Request Headers
- Query string parametersとは？
- 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_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の?以降の内容。
?プロパティ名1=値1&プロパティ名2=値2&,,,,のようになっている情報を見やすく表示している。
##5. Request Payloadとは？ Headersの中にRequest Payloadも含まれている。これは**POSTまたはPUTリクエストによって送信されるデータ**のこと。
