Warning - HTTP

Warning
=======

**メモ:** `Warning` ヘッダーはまもなく非推奨になる予定です。詳しくは Warning (https://github.com/httpwg/http-core/issues/139) や Warning: header & stale-while-revalidate (https://github.com/whatwg/fetch/issues/913) をご覧ください。

**`Warning`** は HTTP の一般ヘッダーで、可能性のある問題についてメッセージのステータスによる情報を含みます。一つのレスポンスに複数の `Warning` ヘッダーが含まれる可能性があります。

`Warning` ヘッダーフィールドは一般的にあらゆるメッセージに適用できますが、一部の警告コードはキャッシュ専用であり、レスポンスメッセージのみに適用することができます。

|  |  |
| --- | --- |
| ヘッダー種別 | 一般ヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]
```

ディレクティブ
-------

<warn-code>

3 桁の警告番号です。最初の桁は、検証後にレスポンスを格納する際に `Warning` を削除する必要があるかどうかを示します。

* `1xx` の警告コードは、新鮮さやレスポンスの検証ステータスを表し、キャッシュされる際に削除されます。
* `2xx` の警告コードは、検証によって修正されない表現のいくつかの側面を説明しており、レスポンス全体が送信されない限り、検証後もキャッシュによって削除されないことを表します。

<warn-agent>

`Warning` ヘッダーを追加するサーバーやソフトウェアの名前または仮名です (エージェントが不明な場合は "-" になることがあります)。

<warn-text>

エラーを説明する助言のテキストです。

<warn-date>

任意。複数の `Warning` ヘッダーが送信される場合は、 `Date` ヘッダーと一致する日付を入れてください。

警告コード
-----

HTTP Warn Codes registry at iana.org では、警告コードの名前空間を定義しています。

| コード | テキスト | 説明 |
| --- | --- | --- |
| 110 | Response is Stale | キャッシュによって提供されたレスポンスが古くなっている (有効期限が切れている)。 |
| 111 | Revalidation Failed | サーバーへ到達できなかったため、レスポンスの検証をしようとして失敗した。 |
| 112 | Disconnected Operation | キャッシュがネットワークの他の部分から切断された。 |
| 113 | Heuristic Expiration | キャッシュが 24 時間より長い保持時間を選択しており、かつレスポンスの時間が 24 時間よりも長い場合。 |
| 199 | Miscellaneous Warning | 任意で特定されていない警告 |
| 214 | Transformation Applied | コンテンツのエンコーディング、メディア種別など、表現方法の変換を行った場合にプロキシが追加します。 |
| 299 | Miscellaneous Persistent Warning | 199 と同様だが、永続的な警告を含む場合 |

例
-
```

Warning: 110 anderson/1.3.37 "Response is stale"

Date: Wed, 21 Oct 2015 07:28:00 GMT
Warning: 112 - "cache down" "Wed, 21 Oct 2015 07:28:00 GMT"
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7234, セクション 5.5: Warning | Hypertext Transfer Protocol (HTTP/1.1): Caching |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Date`
* HTTP response status codes


Sec-Fetch-User - HTTP

Sec-Fetch-User
==============

**`Sec-Fetch-User`** はフェッチメタデータリクエストヘッダーで、これはユーザーアクティベーションによって開始されたリクエストに 対してのみ送られ、その値は常に `?1` です。

サーバーはこのヘッダーを使用して、文書や iframe などからのナビゲーションリクエストがユーザーによって発信されたかどうかを識別できます。

|  |  |
| --- | --- |
| ヘッダー種別 | フェッチメタデータリクエストヘッダー |
| 禁止ヘッダー名 | はい（`Sec-` 接頭辞） |
| CORS セーフリストリクエストヘッダー | いいえ |

構文
--

```http
Sec-Fetch-User: ?1
```

ディレクティブ
-------

値は常に `?1` です。リクエストがユーザーによるアクティベーション以外で発生した場合、 仕様ではヘッダーを完全に除外するようにブラウザーに要求されています。

例
-

ユーザーが同じオリジンの別のページへのページリンクをクリックした場合、結果として生じるリクエストには以下のヘッダーが入ります。

```http
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
```

仕様書
---

| Specification |
| --- |
| Fetch Metadata Request Headers # sec-fetch-user-header |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* 関連ヘッダー
    + `Sec-Fetch-Dest` (en-US)
    + `Sec-Fetch-Mode` (en-US)
    + `Sec-Fetch-Site` (en-US)
* Protect your resources from web attacks with Fetch Metadata (web.dev)
* Fetch Metadata Request Headers playground (secmetadata.appspot.com)


Date - HTTP

Date
====

**`Date`** は HTTP の一般ヘッダーで、メッセージが発信された日時が含まれています。

**警告:** `Date` は fetch 仕様書において禁止ヘッダー名に挙げられています。 - そのため、このコードは `Date` ヘッダーを送信しません。

```js
fetch("https://httpbin.org/get", {
  headers: {
    Date: new Date().toUTCString(),
  },
});
```

|  |  |
| --- | --- |
| ヘッダー種別 | 一般ヘッダー |
| 禁止ヘッダー名 | はい |

構文
--

```http
Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

ディレクティブ
-------

`<day-name>`

"Mon"、"Tue"、"Wed"、"Thu"、"Fri"、"Sat"、"Sun" のいずれか (大文字小文字を区別)。

`<day>`

2 桁の日番号。例えば "04" または "23"。

`<month>`

"Jan"、"Feb"、"Mar"、"Apr"、"May"、"Jun"、"Jul"、"Aug"、"Sep"、 "Oct"、"Nov"、"Dec" のいずれか (大文字と小文字を区別)。

`<year>`

4 桁の年の数字。たとえば "1990" または "2016"。

`<hour>`

2 桁の時の数字。たとえば "09" または "23"。

`<minute>`

2 桁の分の数字。たとえば "04" または "59"。

`<second>`

2 桁の秒の数字。たとえば "04" または "59"。

GMT

グリニッジ標準時。HTTP の日付は常に GMT で表され、決して現地時間で表されることはありません。

例
-
```

Date: Wed, 21 Oct 2015 07:28:00 GMT
```

```js
new Date().toUTCString();
// "Mon, 09 Mar 2020 08:13:24 GMT"
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7231, セクション 7.1.1.2: Date | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Age`


Device-Memory - HTTP

Device-Memory
=============

**安全なコンテキスト用:** この機能は一部またはすべての対応しているブラウザーにおいて、安全なコンテキスト (HTTPS) でのみ利用できます。

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

**`Device-Memory`** ヘッダーは、クライアントヒントのヘッダーのように機能する Device Memory API のヘッダーで、クライアントデバイスの RAM の概算量を表します。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | ? |

**メモ:** クライアントヒントには、安全なオリジン（TLS 経由）でのみアクセスできます。 サーバーは、`Accept-CH` および `Accept-CH-Lifetime` のレスポンスヘッダーを送信することによって、クライアントから `Device-Memory` ヘッダーを受信することを選択する必要があります。

構文
--

デバイス RAM の量は、フィンガープリント変数として使用できるため、ヘッダーでの値は、誤用の可能性を減らすために意図的に粗くなっています。 ヘッダーは次の値を取ります: `0.25`、`0.5`、`1`、`2`、`4`、`8`。
```

Device-Memory: <number>
```

例
-

サーバーはまず、レスポンスヘッダーとして `Device-Memory` を含む `Accept-CH` と `Accept-CH-Lifetime` を送信することによって、`Device-Memory` ヘッダーを受信するように選択する必要があります。
```

Accept-CH: Device-Memory
Accept-CH-Lifetime: 86400
```

次に、後続のリクエストでクライアントは、次のように `Device-Memory` ヘッダーを送り返す場合があります。
```

Device-Memory: 1
```

仕様書
---

| Specification |
| --- |
| Device Memory # iana-device-memory |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* Device Memory API
* `Accept-CH`
* `Accept-CH-Lifetime`
* `Vary`
* `Navigator.deviceMemory`


Proxy-Authorization - HTTP

Proxy-Authorization
===================

HTTP **`Proxy-Authorization`** リクエストヘッダーは、プロキシサーバーに対してユーザーエージェントを認証するための認証情報を保持し、ふつうはサーバーが `407` `Proxy Authentication Required` ステータスと `Proxy-Authenticate` ヘッダーを返した後に使われます。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Proxy-Authorization: <type> <credentials>
```

ディレクティブ
-------

<type>

認証方式。一般的には "Basic" です。認証方式の IANA レジストリも参照してください。

<credentials>

"Basic" 認証方式を使用している場合、認証情報は次のように構築されます。

* コロンで結合したユーザー名とパスワード (`aladdin:opensesame`)。
* 結果の文字列は Base64 でエンコードされます (`YWxhZGRpbjpvcGVuc2VzYW1l`)。

**メモ:** Base64 エンコードは暗号化でもハッシュでもありません。この方法の安全性はクリアテキストで認証情報を送るのと同等です (Base64 は可逆エンコーディングです)。 Basic 認証は HTTPS との組み合わせで使用することをお勧めします。

例
-
```

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7235, セクション 4.4: Proxy-Authorization | HTTP/1.1: Authentication |
| RFC 7617 | The 'Basic' HTTP Authentication Scheme |

関連情報
----

* HTTP 認証
* `Proxy-Authenticate`
* `WWW-Authenticate`
* `Authorization`
* `401`, `403`, `407`


Referer - HTTP

Referer
=======

**`Referer`** リクエストヘッダーには、現在リクエストされているページへのリンク先を持った直前のウェブページのアドレスが含まれています。 `Referer` ヘッダーにより、サーバーは人々がどこから訪問しに来たかを識別し、分析、ログ、キャッシュの最適化などに利用することができます。

**警告:** このヘッダーには無害な用途が多数ありますが、ユーザーのセキュリティとプライバシーに望ましくない結果をもたらす可能性もあります。 詳細情報と緩和策については Referer header: privacy and security concerns を参照してください。

なお、 referer は実際には "referrer" という単語のスペルミスです。詳しくは Wikipedia の HTTP リファラを参照してください。

次のような場合は、ブラウザーは `Referer` ヘッダーを送信しません。

* 参照していたリソースがローカルの "file" または "data" の URI の場合
* 安全ではない HTTP リクエストが使用されており、それを参照しているページが安全なプロトコル (HTTPS) で受信された場合

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | はい |

構文
--
```

Referer: <url>
```

ディレクティブ
-------

<url>

現在リクエスト中のページにつながるリンクがある直前のページの、絶対または相対アドレスです。 URL フラグメント (つまり "#section") およびユーザー情報 ("https://username:password@example.com/foo/bar/" の "username:password" の部分) は含まれません。リファラーポリシーによっては、オリジン、パス、クエリ文字列が含まれる場合があります。

例
-
```

Referer: https://developer.mozilla.org/ja/docs/Web/JavaScript
Referer: https://example.com/page?q=123
Referer: https://example.com/
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7231, セクション 5.5.2: Referer | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* HTTP リファラ - Wikipedia
* `Referrer-Policy`


Accept - HTTP

Accept
======

HTTP の **`Accept`** リクエストヘッダーは、クライアントが理解できるコンテンツタイプを MIME タイプで伝えます。 コンテンツネゴシエーションを使用して、サーバーは提案のうちの一つを選択し、それを使用してクライアントに `Content-Type` レスポンスヘッダーで選択を伝えます。ブラウザーはリクエストを行う場面に応じて適切な値をこのヘッダーに設定します。 CSS スタイルシートを取得するときは、画像、動画、スクリプトを取得するときとは異なる値をリクエストで設定します。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | いいえ |
| CORS セーフリストリクエストヘッダー |
 はい、ただし、値に *CORS-unsafe リクエストヘッダーバイト*、
 0x00-0x1F (0x09 (HT) を除く)、`"():<>?@[\]{}`、0x7F
 (DEL) を含むことができないという追加の制限があります。
  |

構文
--
```

Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*

// 重み値の構文によって重みづけされた複数の種別
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*;q=0.8
```

ディレクティブ
-------

`<MIME_type>/<MIME_subtype>`

単一の詳細な MIME タイプ、例えば `text/html` です。

`<MIME_type>/*`

MIME タイプですが、サブタイプがありません。 `image/*` は `image/png`, `image/svg`, `image/gif` 及びその他の画像タイプに一致します。

`*/*`

すべての MIME タイプ

`;q=` (Q 値の重み)

*重み*と呼ばれる、相対的な品質値を使用して表現される優先順位の順序で配置された値です。

例
-
```

Accept: text/html

Accept: image/*

// 全般的な既定値
Accept: */*

// ナビゲーション時のリクエストの既定値
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7231, セクション 5.3.2: Accept | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* HTTP コンテンツネゴシエーション
* コンテンツネゴシエーションの結果を伴うヘッダー: `Content-Type`
* 他の同様のヘッダー: `TE` (en-US), `Accept-Encoding`, `Accept-Charset`, `Accept-Language`


Permissions-Policy - HTTP

Permissions-Policy
==================

HTTP の **`Permissions-Policy`** ヘッダーは、自身のフレームおよび文書内の `<iframe>` 要素で、ブラウザーの機能を使用することを許可または拒否する仕組みを提供します。

詳しくは、権限ポリシーの記事を参照してください。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | はい |

構文
--
```

Permissions-Policy: <directive> <allowlist>
```

`<directive>`

`allowlist` に適用される権限ポリシーディレクティブです。許可されているディレクティブ名の一覧は、以下のディレクティブを参照してください。

`<allowlist>`

許可リストは、以下の値のうち 1 つ以上を取るオリジンの空白区切りのリストです。

* `*`: この機能は、この文書と、含まれるすべての閲覧コンテキスト (iframe) でオリジンに関係なく許可されます。
* `()`: (空の許可リスト): この機能は最上位および含まれる閲覧コンテキストで無効になります。
* `self`: この機能は、この文書と、含まれるすべての閲覧コンテキスト (iframe) のうち、同じオリジンのものに許可されます。
* `src`: (iframe の `allow` 属性のみ) この iframe に読み込まれた文書が iframe の src 属性の URL と同じオリジンから来ている限り、この機能はこの iframe で許可されます。

**メモ:** `src` のオリジンは iframe の `allow` 属性の中でのみ使用され、これが*既定の* `allowlist` の値です。
* <origin>: この機能は特定のオリジン (例えば、 `https://example.com`) で許可されます。オリジンは空白で区切ってください。ただし、 `<iframe>` の `allow` 属性には引き継がれないことに注意してください。

`*` の値 (すべてのオリジンで有効) または `()` (すべてのオリジンで無効) は単独でのみ使用できますが、 `self` と `src` は一つ以上のオリジンと一緒に使用することができます。

機能はそれぞれ、既定の許可リストを持つよう定義されています。

**メモ:** ディレクティブにはデフォルトの allowlist があり、 `Permissions-Policy` HTTP ヘッダーでは常に `*`, `self` または `none` になります。これらは個々のディレクティブのリファレンスページで指定されています。 `<iframe>` の `allow` 属性では、デフォルトの動作は常に `src` です。

ブラウザーがサポートしている場合、許可リストで複数の異なるサブドメインを明示的に指定する代わりに許可ポリシーのオリジンにワイルドカードを含めることができます。

そのため以下のような指定は

```http
("https://example.com" "https://a.example.com" "https://b.example.com" "https://c.example.com")
```

このように書き換えることができます。

```http
("https://example.com" "https://*.example.com")
```

>
> **Note:** `"https://*.example.com"` は `"https://example.com"` とは別のオリジンになります。
>
>
>

ディレクティブ
-------

`accelerometer`

現在の文書が、端末の加速度に関する情報を、 `Accelerometer` インターフェイスを通じて収集することを許可するかどうかを制御します。

`ambient-light-sensor`

現在の文書が、端末の周囲の環境における光量についての情報を、 `AmbientLightSensor` インターフェイスを通じて収集することを許可するかどうかを制御します。

`autoplay`

現在の文書で `HTMLMediaElement` インターフェイスがメディアの自動再生をリクエストすることを無効にするかどうかを制御します。このポリシーが有効であり、ユーザーによる操作がなかった場合、 `HTMLMediaElement.play()` が返す `Promise` が `DOMException` で拒否されます。 `<audio>` および `<video>` 要素の `autoplay` 属性は無視されます。

`battery`

Battery Status API の使用を許可するかどうかを制御します。このポリシーが無効になっている場合、 `Navigator.getBattery()` が返す `Promise` は `NotAllowedError` の `DOMException` で拒否されます。

`camera`

現在の文書が動画入力機器を使用することを許可するかどうかを制御します。このポリシーが無効であれば、 `getUserMedia()` が返す `Promise` は `NotAllowedError` の `DOMException` で拒否されます。

`display-capture`

現在の文書が `getDisplayMedia()` メソッドを使用して画面の内容をキャプチャすることを許可するかどうかを制御します。このポリシーが無効であれば、表示内容をキャプチャする許可がない場合、 `getDisplayMedia()` から返却されるプロミスが `NotAllowedError` で拒否されます。

`document-domain`

現在の文書が `document.domain` を設定することを許可するかどうかを制御します。このポリシーが無効な場合、 `document.domain` を設定しようとすると失敗し、 `SecurityError` の `DOMException` が発生します。

`encrypted-media`

現在の文書が Encrypted Media Extensions (en-US) API (EME) を使用することを許可するかどうかを制御します。このポリシーが無効であれば、 `Navigator.requestMediaKeySystemAccess()` (en-US) から返却された `Promise` が `DOMException` で拒否されます。

`execution-while-not-rendered` (en-US)

表示されないフレーム内 (例えば iframe が `hidden` または `display: none` の場合) でタスクを実行するかどうかを制御します。

`execution-while-out-of-viewport` (en-US)

ビューポートの見える範囲外にあるフレーム内のタスクを実行するかどうかを制御します。

`fullscreen`

現在の文書が `Element.requestFullscreen()` を使用することを許可するかどうかを制御します。このポリシーが無効であれば、返却された `Promise` が `TypeError` で拒否されます。

`gamepad` (en-US)

 現在の文書が Gamepad API を使用することを許可するかどうかを制御します。
 このポリシーが無効であれば、 `Navigator.getGamepads()` の呼び出しで `SecurityError` の `DOMException` が発生するようになり、 `gamepadconnected` および `gamepaddisconnected` イベントは発生しなくなります。

`geolocation`

現在の文書が `Geolocation` インターフェイスを使用することを許可するかどうかを制御します。このポリシーが無効であれば、 `getCurrentPosition()` および `watchPosition()` を呼び出すと、関数のコールバックが呼び出され、 `PositionError` コードが `PERMISSION_DENIED` になります。

`gyroscope` (en-US)

現在の文書が `Gyroscope` インターフェイスを通じて、端末の方向に関する情報を収集することを許可するかどうかを制御します。

`layout-animations` (en-US)

現在の文書がレイアウトアニメーションを表示することを許可するかどうかを制御します。

`legacy-image-formats` (en-US)

現在の文書が古い形式の画像を表示することを許可するかどうかを制御します。

`magnetometer` (en-US)

現在の文書が `Magnetometer` インターフェイスを通じて、端末の方向に関する情報を収集することを許可するかどうかを制御します。

`microphone`

現在の文書がオーディオ入力端末を使用することを許可するかどうかを制御します。このポリシーが無効であれば、 `MediaDevices.getUserMedia()` で返却されたプロミス (`Promise`) が `NotAllowedError` の `DOMException` で拒否されます。

`midi`

現在の文書が Web MIDI API を使用することを許可するかどうかを制御します。このポリシーが無効であれば、 `Navigator.requestMIDIAccess()` から返却された `Promise` が `DOMException` で拒否されます。

`navigation-override`

ページ作成者が 空間ナビゲーションの動作を制御したり、完全にキャンセルしたりすることができる仕組みの利用可能性を制御します。

`oversized-images` (en-US)

現在の文書が大きな画像をダウンロードして表示することを許可するかどうかを制御します。

`payment`

現在の文書が Payment Request API を使用することを許可するかどうかを制御します。このポリシーが有効であれば、 `PaymentRequest()` コンストラクターで `SecurityError` の `DOMException` が発生します。

`picture-in-picture`

現在の文書が、該当する API を使用して Picture-in-Picture モードで動画を再生することを許可するかどうかを制御します。

`publickey-credentials-get` (en-US)

現在の文書が Web Authentication API を使用して、すでに保存されている公開鍵資格情報を再取得することを許可するかどうかを制御します (例: `navigator.credentials.get({publicKey: ..., ...})` (en-US))。

`speaker-selection` (en-US)

現在の文書が Audio Output Devices API を使用して、スピーカーを列挙したり選択したりすることを許可するかどうかを制御します。

`sync-xhr` (en-US)

現在の文書が同期 `XMLHttpRequest` リクエストを行うことを許可するかどうかを制御します。

`unoptimized-images` (en-US)
Experimental

Non-standard

現在の文書が最適化されていない画像をダウンロードしたり表示したりすることを許可するかどうかを制御します。

`unsized-media` (en-US)
Experimental

Non-standard

現在の文書が初期レイアウトの完了後にメディア要素の大きさを変更することを許可するかどうかを制御し案す。

`usb` (en-US)

現在の文書が WebUSB API を使用することを許可するかどうかを制御します。

`screen-wake-lock`

現在の文書が Screen Wake Lock API を使用して、端末が画面をオフにしたり暗くしたりしてはいけないことを示すことを許可するかどうかを制御します。

`web-share`

現在の文書が Web Share API の `Navigator.share()` を使用して、テキスト、リンク、画像、その他のコンテンツをモバイルアプリなどのユーザーが任意に選択した任意の場所に共有することを許可するかどうかを制御します。

`xr-spatial-tracking`

現在の文書が WebXR Device API を使用して WebXR セッションと対話することを許可するかどうかを制御します。

例
-

SecureCorp Inc. が、アプリケーションでマイクと Geolocation API を無効にしたがっているとします。以下の権限ポリシーを設定する HTTP レスポンスヘッダーを配信することで実現できます。
```

Permissions-Policy: microphone=(), geolocation=()
```

オリジンのリストに `()` キーワードを指定すると、指定された機能がオリジンに関係なく、すべての閲覧コンテキスト (iframe を含む) で無効になります。

仕様書
---

| Specification |
| --- |
| Permissions Policy # permissions-policy-http-header-field |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* 権限ポリシー
* `Document.featurePolicy` および `FeaturePolicy` (en-US)
* Feature-Policy Tester (Chrome Developer Tools extension)
* `Content-Security-Policy`
* `Referrer-Policy`


Accept-Encoding - HTTP

Accept-Encoding
===============

**`Accept-Encoding`** は HTTP のリクエストヘッダーで、クライアントが理解することができるコンテンツのエンコーディング（ふつうは圧縮アルゴリズム）を示します。コンテンツネゴシエーションを使用して、サーバーは提案されたものから一つを選択して使用し、 `Content-Encoding` レスポンスヘッダーを使用してクライアントに選択結果を知らせます。

クライアントとサーバーが同じ圧縮アルゴリズムに対応していた場合でも、 `identity` の値が受け付けられる場合は、サーバーはレスポンスの本体を圧縮しないことを選択する場合があります。これには主に 2 つの場合があります。

* 送信されるデータがすでに圧縮されており、 2 回目の圧縮によって送信するデータが小さくならない場合。これは圧縮を伴う画像形式（JPEG など）が該当します。
* サーバーが過負荷になってもり、圧縮に必要な計算上のオーバーヘッドの余裕がない場合。通常、 Microsoft はサーバーが計算能力の 80% 以上を使用している場合、圧縮しないことを推奨しています。

`identity` の値、つまりエンコードをしないということは、 `identity;q=0` または `*;q=0` で `identity` とは別な値が明確に設定されていない限り、サーバーは `406` `Not Acceptable` エラーを返してはいけません。

**メモ:**

* IANA レジストリーが公式なコンテンツエンコーディングの完全なリストを管理しています。
* 他にも `bzip` および `bzip2` の 2 種類のエンコーディングが使用されることがありますが、標準ではありません。これはこれら 2 つの UNIX プログラムで使用されているアルゴリズムを実装しています。なお、前者は特許ライセンスの問題で開発終了しています。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | はい |

構文
--

```http
Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: \*

// 複数のアルゴリズムを quality value で重み付けする構文:
Accept-Encoding: deflate, gzip;q=1.0, \*;q=0.5
```

ディレクティブ
-------

`gzip`

Lempel-Ziv coding (LZ77) と 32 ビット CRC を用いた圧縮形式です。

`compress`

Lempel-Ziv-Welch (LZW) アルゴリズムを用いた圧縮形式です。

`deflate`

zlib 構造体と *deflate* 圧縮アルゴリズムを用いた圧縮形式です。

`br`

Brotli アルゴリズムを用いた圧縮形式です。

`identity`

等価関数を示します（つまり、圧縮も変更もありません）。この値は存在しなくても、常に受け付け可能とみなされます。

`*`

ヘッダーに挙げられていないあらゆるコンテンツエンコーディングに一致します。これはこのヘッダーがない場合の既定値です。すべてのアルゴリズムに対応しているという意味ではありません。評価される設定がないだけです。

`;q=` （q 値の重みづけ）

*weight* と呼ばれる相対的な品質値を使用して表現される設定の順序づけをするための任意の値です。

例
-

```http
Accept-Encoding: gzip

Accept-Encoding: gzip, compress, br

Accept-Encoding: br;q=1.0, gzip;q=0.8, \*;q=0.1
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # field.accept-encoding |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* HTTP コンテンツネゴシエーション
* コンテンツネゴシエーションの結果を伴うヘッダー: `Content-Encoding`
* 他の同様のヘッダー: `TE` (en-US), `Accept`, `Accept-Language`


Cookie - HTTP

Cookie
======

**`Cookie`** は HTTP のリクエストヘッダーで、以前サーバーが `Set-Cookie` ヘッダーで送信し、保存された HTTP クッキーを含みます。

`Cookie` ヘッダーは任意であり、例えば、ブラウザーのプライバシー設定でクッキーをブロックしている場合などは省略できます。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | はい |

構文
--
```

Cookie: <cookie-list>
Cookie: name=value
Cookie: name=value; name2=value2; name3=value3
```

<cookie-list>

名前と値のリストを `<cookie-name>=<cookie-value>` の形で表したものです。リストの組はセミコロンと空白 (`'; '`) で区切られます。

例
-
```

Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 6265, セクション 5.4: Cookie | HTTP State Management Mechanism |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Set-Cookie`
* `Document.cookie`


Accept-CH - HTTP

Accept-CH
=========

**安全なコンテキスト用:** この機能は一部またはすべての対応しているブラウザーにおいて、安全なコンテキスト (HTTPS) でのみ利用できます。

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

**`Accept-CH`** ヘッダーはサーバーによって設定され、クライアントが後続のリクエストに含めるクライアントヒントヘッダーを指定します。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | ? |

**メモ:** クライアントヒントには、安全なオリジン (TLS 経由) でのみアクセスできます。 Accept-CH ヘッダーと Accept-CH-Lifetime ヘッダーは、クライアントヒントが確実に送信されるように、すべての安全なリクエストに対して保持する必要があります。

構文
--
```

Accept-CH: <list of client hints>
```

例
-
```

Accept-CH: DPR, Viewport-Width
Accept-CH: Width
Accept-CH-Lifetime: 86400
Vary: DPR, Viewport-Width, Width
```

**メモ:** 受け入れられたクライアントのヒントに基づいて、レスポンスを変更することを忘れないでください。

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Accept-CH-Lifetime`
* `Vary`


Authorization - HTTP

Authorization
=============

HTTP の **`Authorization`** リクエストヘッダーは、ユーザーエージェントがサーバーから認証を受けるための証明書を保持し、ふつうは、必ずではありませんが、サーバーが `401` `Unauthorized` ステータスと `WWW-Authenticate` ヘッダーを返した後に使われます。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--

```http
Authorization: <type> <credentials>
```

ディレクティブ
-------

<type>

認証方式。一般的には "Basic" です。それ以外に以下のような種類があります。

* 認証スキームの IANA レジストリ
* AWS サーバーの認証 (`AWS4-HMAC-SHA256`)

<credentials>

"Basic" 認証方式を使用している場合、認証情報は次のように構築されます。

* コロンで結合したユーザー名とパスワード (`aladdin:opensesame`)。
* 結果の文字列は base64 でエンコードされます (`YWxhZGRpbjpvcGVuc2VzYW1l`)。

**メモ:** Base64 エンコードは暗号化でもハッシュでもありません。この方法の安全性はクリアテキストで認証情報を送るのと同等です (Base64 は可逆エンコーディングです)。 Basic 認証は HTTPS との組み合わせで使用することをお勧めします。

例
-
```

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

Apache や nginx サーバーで HTTP Basic 認証を使用してサイトを保護する方法の例については、 HTTP authentication を参照してください。

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7235, セクション 4.2: Authorization | HTTP/1.1: Authentication |
| RFC 7617 | The 'Basic' HTTP Authentication Scheme |

関連情報
----

* HTTP 認証
* `WWW-Authenticate`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`, `403`, `407`


Upgrade-Insecure-Requests - HTTP

Upgrade-Insecure-Requests
=========================

HTTP の **`Upgrade-Insecure-Requests`** リクエストヘッダーは、暗号化および認証されたレスポンスに対するクライアントの設定を表す信号をサーバーに送信し、 CSP の `upgrade-insecure-requests` ディレクティブが正常に処理できることを示します。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Upgrade-Insecure-Requests: 1
```

例
-

クライアントは、次のように `upgrade-insecure-requests` のアップグレードメカニズムをサポートしていることをサーバーに通知します。
```

GET / HTTP/1.1
Host: example.com
Upgrade-Insecure-Requests: 1
```

これで、サーバーは安全なバージョンのサイトにリダイレクトできます。 `Vary` ヘッダーを使用することで、アップグレードメカニズムに対応していないクライアントにキャッシュからサイトが提供されなくなります。
```

Location: https://example.com/
Vary: Upgrade-Insecure-Requests
```

仕様書
---

| Specification |
| --- |
| Upgrade Insecure Requests # preference |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Content-Security-Policy`
* CSP `upgrade-insecure-requests` ディレクティブ


Alt-Svc - HTTP

Alt-Svc
=======

**`Alt-Svc`** は HTTP のレスポンスヘッダーで、同じリソースに到達できる代替サービスを宣伝するために使用します。 代替サービスは、プロトコル/ホスト/ポートの組み合わせによって定義します。

構文
--
```

Alt-Svc: clear
Alt-Svc: <protocol-id>=<alt-authority>; ma=<max-age>
Alt-Svc: <protocol-id>=<alt-authority>; ma=<max-age>; persist=1
```

`clear`

特別な値 `clear` は、そのオリジンのすべての代替を無効にすることをオリジンが要求することを示します。

`<protocol-id>`

ALPN プロトコル識別子。 例には、HTTP/2 の h2 および HTTP/3 プロトコルのドラフト 25 の h3-25 が含まれています。

`<alt-authority>`

任意のホストのオーバーライド、コロン、および必須のポート番号で構成される代替機関を指定する引用符付きの文字列。

`ma=<max-age>`省略可

代替サービスが新鮮であると見なす秒数。 省略した場合のデフォルトは 24 時間です。 代替サービスのエントリは、最大で *<max-age>* から（`Age` ヘッダーからの）レスポンスの経過時間を差し引いた秒数までキャッシュできます。 キャッシュされたエントリが期限切れになると、クライアントは新しい接続にこの代替サービスを使用できなくなります。

`persist=1`省略可

通常、キャッシュされた代替サービスエントリは、ネットワーク構成の変更時にクリアされます。 persist=1 パラメータを使用すると、そのような変更によってエントリが削除されなくなります。

区切り文字としてカンマを使用して、単一の `Alt-Svc` ヘッダーで複数のエントリを指定できます。 その場合、早期のエントリーがより望ましいと考えられます。

例
-
```

Alt-Svc: h2=":443"; ma=2592000;
Alt-Svc: h2=":443"; ma=2592000; persist=1
Alt-Svc: h2="alt.example.com:443", h2=":443"
Alt-Svc: h3-25=":443"; ma=3600, h2=":443"; ma=3600
```

仕様書
---

| 仕様書 | 状態 | 備考 |
| --- | --- | --- |
| RFC 7838 | IETF RFC | 初回定義 |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* ウェブ上のリソースの識別


Origin - HTTP

Origin
======

**`Origin`** リクエストヘッダーは、リクエストが発生したオリジン（スキーム、ホスト名、ポート番号）を示します。
 例えば、ユーザーエージェントがページに含まれるリソース、または実行するスクリプトによってフェッチされるリソースをリクエストする必要がある場合、ページのオリジンがそのリクエストに含まれることがあります。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | はい |

構文
--

```http
Origin: null
Origin: <scheme>://<hostname>
Origin: <scheme>://<hostname>:<port>
```

ディレクティブ
-------

`null`

オリジンが「プライバシーに配慮した」ものであるか、HTML仕様で定義された不透明なオリジンである（具体的な事例は解説の節に掲載されています）。

`<scheme>`

 使用されるプロトコル。
 通常、 HTTP プロトコルまたはそのセキュアバージョンである HTTPS です。

`<hostname>`

サーバーのドメイン名 (仮想ホスティングの場合) または IP アドレス。

`<port>` 省略可

 サーバーが待ち受けしている TCP ポート番号。
 ポート番号が指定されていない場合、リクエストされたサービスの既定のポート番号（HTTP URL の場合は "80" など）が暗黙的に指定されます。

解説
--

`Origin` ヘッダーは `Referer` ヘッダーと似ていますが、パス全体が公開されるわけではなく、 `null` になることがある点が異なります。
 これは、オリジン情報が機密または不要となる場合を除き、オリジンリクエストの「セキュリティコンテキスト」を提供するために使用されます。

大まかに言うと、ユーザーエージェントが `Origin` リクエストヘッダーを追加するのは以下のものです。

* オリジン間リクエスト
* 同一オリジンリクエスト、ただし `GET` または `HEAD` リクエストを除く（すなわち、同一オリジンの `POST`, `OPTIONS`, `PUT`, `PATCH`, `DELETE` の各リクエストに追加される。）

上記のルールにはいくつかの例外があります。例えば、オリジンを跨ぐ `GET` または `HEAD` リクエストが CORS モード外で行われた場合、 `Origin` ヘッダーは追加されません。

`Origin` ヘッダー値は様々な場合に `null` になることがあります（網羅的ではない）。

* スキームが `http`, `https`, `ftp`, `ws`, `wss`, `gopher` のいずれでもないオリジン（`blob`, `file`, `data` を含む）。
* 別オリジンの画像やメディアデータ（`<img>`, `<video>`, `<audio>` 要素の場合も含む）。
* `createDocument()` を使用してプログラム的に作成された文書、 `data:` URL から生成された文書、または作成者の閲覧コンテキストを持たない文書。
* オリジン間のリダイレクト。
* iframeのサンドボックス属性が値 `allow-same-origin` を含んでいない場合。
* ネットワークエラーとなったレスポンス。
* `Referrer-Policy` が `no-referrer` に設定され、`cors` 以外のリクエストモードが設定された場合（単純な形式の投稿など）。

**メモ:** `null` を返す可能性のあるケースについて、より詳しいリストが Stack Overflow の When do browsers send the Origin header? When do browsers set the origin to null? に掲載されています。

例
-

```http
Origin: https://developer.mozilla.org
```

```http
Origin: http://developer.mozilla.org:80
```

仕様書
---

| Specification |
| --- |
| The Web Origin Concept # section-7 |
| Fetch Standard # origin-header |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Host`
* `Referer`
* 同一オリジンポリシー
* When do browsers send the Origin header? When do browsers set the origin to null? (Stack Overflow)


Accept-Charset - HTTP

Accept-Charset
==============

**`Accept-Charset`** は HTTP のリクエストヘッダーで、クライアントが理解できる文字エンコーディングを広報します。コンテンツネゴシエーションを使用して、サーバーは提案の 1 つを選択、使用し、クライアントに選択結果を `Content-Type` レスポンスヘッダー内、ふつうは `charset=` 引数の中で通知します。通常はそれぞれのリソースの既定値が正しく、これを送信するとフィンガープリンティング (en-US)を許してしまうことがあるため、ブラウザーは通常、このヘッダーを設定しません。

サーバーが一致する文字エンコーディングを提供できない場合、理論的には `406 Not Acceptable` エラーコードを返すことができます。しかし、より使い勝手をよくするために、これはめったに行われず、 `Accept-Charset` ヘッダーは無視されます。

**メモ:** HTTP/1.1 の初期のバージョンでは、既定の文字エンコーディングを ISO-8859-1 と定義していました。これはすでに推奨されなくなっており、コンテンツ型ごとに個別に既定値が設定されるようになりました。

UTF-8 への対応が進み、圧倒的に推奨される文字エンコーディングになっています。設定に基づいたエントロピーを減少させることでより良いプライバシーを保証するために、すべてのブラウザーが `Accept-Charset` ヘッダーを省略しています。 Internet Explorer 8 以降、 Safari 5 以降、 Opera 11 以降、 Firefox 10 以降、 Chrome 27 以降は送信しなくなりました。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | はい |

構文
--
```

Accept-Charset: <charset>

// 複数の型を品質値で重みづけした構文
Accept-Charset: utf-8, iso-8859-1;q=0.5
```

ディレクティブ
-------

`<charset>`

`utf-8` または `iso-8859-15` のような文字セット。

`*`

ヘッダー内の他の場所に記述されていない文字セット。 `'*'` はワイルドカードとして使用されます。

`;q=<weight>`

エンコーディングはすべて、*重み*と呼ばれる相対的な品質値を使用して表現された設定の順番で配置されます。

例
-
```

Accept-Charset: iso-8859-1

Accept-Charset: utf-8, iso-8859-1;q=0.5

Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7231, セクション 5.3.3: Accept-Charset | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |

ブラウザーの互換性
---------

{{Compat}}関連情報
----

* HTTP のコンテンツネゴシエーション
* Accept-Charset is no more
* コンテンツネゴシエーションの結果を含むヘッダー: `Content-Type`
* 他の同様のヘッダー: `TE` (en-US), `Accept-Encoding`, `Accept-Language`, `Accept`


Via - HTTP

Via
===

一般ヘッダーの **`Via`** は、フォワードプロキシとリバースプロキシの両方のプロキシによって追加され、リクエストヘッダーとレスポンスヘッダーに表示されます。 メッセージ転送の追跡、要求ループの回避、および要求/応答チェーンに沿った送信者のプロトコル機能の識別に使用されます。

|  |  |
| --- | --- |
| ヘッダー種別 | General header |
| Forbidden header name | yes |

構文
--
```

Via: [ <protocol-name> "/" ] <protocol-version> <host> [ ":" <port> ]
or
Via: [ <protocol-name> "/" ] <protocol-version> <pseudonym>
```

ディレクティブ
-------

<protocol-name>

オプション。"HTTP"など、使用するプロトコル名。

<protocol-version>

"1.1"など、使用されているプロトコルのバージョン。

<host> and <port>

パブリックプロキシの URL とポート。

<pseudonym>

内部プロキシの名前/エイリアス。

例
-
```

Via: 1.1 vegur
Via: HTTP/1.1 GWA
Via: 1.0 fred, 1.1 p.example.net
```

仕様書
---

| Specification | Title |
| --- | --- |
| RFC 7230, セクション 5.7.1: Via | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

ブラウザーの互換
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `X-Forwarded-For`
* Heroku's proxy library Vegur


Accept-Ranges - HTTP

Accept-Ranges
=============

HTTP の **`Accept-Ranges`** レスポンスヘッダーは、サーバーが部分的なリクエストに対応していることを周知するために使用するマーカーです。このフィールドの値は、範囲の定義に使用できる単位を示します。

`Accept-Ranges` ヘッダーがあると、ブラウザーは開始から再開するのではなく、中断されたダウンロードを再開しようとする可能性があります。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Accept-Ranges: <range-unit>
Accept-Ranges: none
```

ディレクティブ
-------

`<range-unit>`

サーバーが対応している範囲の単位を定義します。 `bytes` は RFC 7233 で公式に定義されている唯一の範囲の単位ですが、追加の範囲の単位が HTTP Range Unit Registry に登録されている可能性があります。

`none`

範囲の単位には対応していないことを示し、これはヘッダー自体がないのと等価になりますので、滅多に使用されませんが、 IE9 のように一部のブラウザーでは、ダウンロードマネージャーで一時停止ボタンを無効にしたり削除したりするために使用されます。

例
-
```

Accept-Ranges: bytes
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7233, セクション 2.3: Accept-Ranges | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `If-Range`
* `Range`
* IANA HTTP Range Unit Registry


Expect-CT - HTTP

Expect-CT
=========

`Expect-CT` ヘッダーは、サイトが証明書の透明性の要件の報告や強制に参加して、サイトの不正な認証情報の使用が通知されない状態を防ぐことができます。

CT の要件は、以下のいずれかの仕組みで満たすことができます。

* 個々のログで発行された署名付き証明書のタイムスタンプを埋め込めるようにするための X.509v3 証明書の拡張
* ハンドシェイク中に送信される `signed_certificate_timestamp` 型の TLS 拡張
* OCSP ステープリング (つまり、 `status_request` TLS 拡張) に対応し、 `SignedCertificateTimestampList` を提供すること

**メモ:** サイトが `Expect-CT` ヘッダーを有効にすると、ブラウザーが\*\*公開 CT ログ\*\*に現れるサイトのすべての認証情報をチェックするよう要求します。

**メモ:** ブラウザーは、 HTTP では `Expect-CT` ヘッダーを**無視**し、 HTTPS 接続でのみ効果を発揮します。

**メモ:** `Expect-CT` は 2021 年 6 月に廃止される可能性が高いです。 2018 年 5 月以降、新しい証明書は既定で SCT に対応することが期待されています。 2018 年 3 月以前の証明書は 39 ヶ月の有効期限が認められていましたが、それらが 2021 年 6 月にすべて失効します。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | はい |

構文
--
```

Expect-CT: report-uri="<uri>",
           enforce,
           max-age=<age>
```

ディレクティブ
-------

`max-age`

`Expect-CT` ヘッダーフィールドを受信した後で、ユーザーエージェントがメッセージを受信したホストを、既知の Expect-CT ホストと見なすべき時間を秒数で指定します。

キャッシュが表現可能な値よりも大きな値を受信した場合や、計算でオーバーフローが発生した場合、キャッシュは値を 2,147,483,648 (2^31) または使用している表現方法で最も大きな整数値とみなします。

`report-uri="<uri>"` 省略可

ユーザーエージェントが `Expect-CT` の失敗を報告する URI を指定します。

`enforce` ディレクティブと `report-uri` ディレクティブが両方ともある場合、設定は "enforce-and-report" の設定と呼ばれ、ユーザーエージェントに証明書の透明性ポリシーに従い、違反を報告することを指示します。

`enforce` 省略可

ユーザーエージェントに (報告するだけでなく) 証明書の透明性ポリシーに従い、ユーザーエージェントが証明書の透明性ポリシーに違反するコネクションを拒否するよう指示します。

`enforce` ディレクティブと `report-uri` ディレクティブが両方ともある場合、設定は "enforce-and-report" の設定と呼ばれ、ユーザーエージェントに証明書の透明性ポリシーに従い、違反を報告することを指示します。

例
-

以下の例は証明書の透明性を 24 時間強制し、違反を `foo.example` に報告することを示します。
```

Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report"
```

メモ
--

信頼ストアに手動で追加されたルート CA は、 `Expect-CT` の報告/強制を上書きし、抑制します。

ブラウザーは、サイトが証明書の透明性要件を満たす証明書を提供できることを「証明」しない限り、 `Expect-CT` ポリシーを記憶しません。ブラウザーは、どの CT ログが証明書のログとして信頼できるとみなされるかについて、独自の信頼モデルを実装しています。

Chrome のビルドは、インストールのビルド日から 10 週間後に `Expect-CT` ポリシーの施行を停止するように設計されています。

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| Internet Draft | Expect-CT Extension for HTTP |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


X-XSS-Protection - HTTP

X-XSS-Protection
================

**非標準:** この機能は標準ではなく、標準化の予定もありません。公開されているウェブサイトには使用しないでください。ユーザーによっては使用できないことがあります。実装ごとに大きな差があることもあり、将来は振る舞いが変わるかもしれません。

HTTP の **`X-XSS-Protection`** レスポンスヘッダーは Internet Explorer, Chrome, Safari の機能で、反射型クロスサイトスクリプティング (XSS) 攻撃を検出したときに、ページの読み込みを停止するためのものです。サイトが強力な `Content-Security-Policy` を実装しており、インライン JavaScript (`'unsafe-inline'`) の使用を無効にしている場合、これらの保護は現代のブラウザーではほとんど不要となります。

**警告:** この機能は、まだ CSP に対応していない古いブラウザーのユーザーを保護できるにもかかわらず、場合によっては、他の安全なウェブサイトで**XSS 保護機能が XSS の脆弱性を作り出す可能性**があります。詳細については、下記の節を参照してください。

**メモ:**

* Chrome は XSS Auditor を削除しました。
* Firefox は対応しておらず、 `X-XSS-Protection` を今後も実装しません
* Edge は XSS filter を廃止しました。つまり、古いブラウザーに対応する必要がない場合は、代わりに `Content-Security-Policy` を使用し `unsafe-inline` を許可しないことをお勧めします。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--

```http
X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
```

0

XSS フィルタリングを無効化します。

1

XSS フィルタリングを有効化します（通常はブラウザーの既定値です）。クロスサイトスクリプティング攻撃を検知すると、ブラウザーはページをサニタイズします（安全でない部分を取り除きます）。

1; mode=block

XSS フィルタリングを有効化します。攻撃を検知すると、ページをサニタイジングするよりも、ページのレンダリングを停止します。

1; report=<reporting-URI> (Chromium only)

XSS フィルタリングを有効化します。クロスサイトスクリプティング攻撃を検知すると、ブラウザーはページをサニタイズし、攻撃レポートを作成します。レポートを送信するために、 CSP `report-uri` ディレクティブ機能を利用します。

XSS フィルタリングに起因する脆弱性
-------------------

あるウェブページの抜粋である以下の HTML コードを考えてみましょう。

```html
<script>
 var productionMode = true;
</script>
<!-- [...] -->
<script>
 if (!window.productionMode) {
 // 脆弱性のあるデバッグコード
 }
</script>
```

このコードは、ブラウザーが XSS フィルタリングを行わない場合は、完全に安全です。しかし、もしブラウザーがフィルタリングを行い、検索クエリーが `?something=%3Cscript%3Evar%20productionMode%20%3D%20true%3B%3C%2Fscript%3E` である場合、ブラウザーはページ内のスクリプトを `<script>var productionMode = true;</script>` の部分を（URI にあったためサーバーがそれをレスポンスに記載したと思い）無視して残りを実行するかもしれません、 `window.productionMode` が `undefined` と評価されて安全ではないデバッグコードを実行させる原因となることが考えられます。

`X-XSS-Protection` ヘッダーを `0` または `1; mode=block` のいずれかに設定すると、上記のような脆弱性を防ぐことができます。前者はブラウザーがすべてのスクリプトを実行するようにし、後者はページがまったく処理されないようにします（ただし、この手法はウェブサイトが `<iframe>` に埋め込まれている場合は、サイドチャネル攻撃に対して脆弱になる可能性があります）。

例
-

XSS 攻撃が反映されたページを見つけたらその読み込みをブロックする場合。

```http
X-XSS-Protection: 1; mode=block
```

PHP

```php
header("X-XSS-Protection: 1; mode=block");
```

Apache (.htaccess)
```

<IfModule mod_headers.c>
  Header set X-XSS-Protection "1; mode=block"
</IfModule>
```

Nginx
```

add_header "X-XSS-Protection" "1; mode=block";
```

仕様書
---

仕様書や草案で定義されたものではありません。

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Content-Security-Policy`
* Controlling the XSS Filter – Microsoft
* Understanding XSS Auditor – Virtue Security
* The misunderstood X-XSS-Protection – blog.innerht.ml


X-Forwarded-Host - HTTP

X-Forwarded-Host
================

**X-Forwarded-Host** (XFH) ヘッダーは、 HTTP の `Host` リクエストヘッダー内でクライアントから要求された元のホストを特定するための事実上の標準となっているヘッダーです。

リバースプロキシー (ロードバランサー、 CDN) のホスト名とポート番号は、リクエストを扱う元のサーバーとは異なってもよく、この場合はもともと使用されていたのがどのホストであるかを特定するのに `X-Forwarded-Host` ヘッダーが便利です。

このヘッダーはデバッグ、統計、位置に依存したコンテンツの生成などに使用され、クライアントの IP アドレスのようなプライバシーに敏感な情報を公開します。従って、このヘッダーを展開する時は、ユーザーのプライバシーに留意する必要があります。

標準化されたヘッダーは HTTP `Forwarded` ヘッダーです。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

X-Forwarded-Host: <host>
```

ディレクティブ
-------

<host>

転送されたサーバーのドメイン名

例
-
```

X-Forwarded-Host: id42.example-cdn.com
```

仕様書
---

現行のどの仕様書にも含まれていません。このヘッダーの標準化版は `Forwarded` ヘッダーです。

関連情報
----

* `Host`
* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Proto`


Transfer-Encoding - HTTP

Transfer-Encoding
=================

**`Transfer-Encoding`** ヘッダーは、ペイロード本文をユーザーに安全に転送するために使われる符号化方式を指定します。

**メモ:** HTTP/2 は HTTP 1.1 のチャンク化した転送エンコードの仕組みに対応しておらず、新規にもっと効率的な、データストリーミングの仕組みを提供しています。

`Transfer-Encoding` はホップバイホップヘッダーであり、リソース自体ではなく、二つのノード間のメッセージに適用されます。複数ノードコネクションのそれぞれの区間は、異なる `Transfer-Encoding` の値を使用することがあります。コネクション全体を通してデータを圧縮したい場合は、代わりにエンドトゥエンドの `Content-Encoding` ヘッダーを使用してください。

本文のない `HEAD` リクエストに対するレスポンスで使われたときは、対応する `GET` メッセージに適用されるであろう値を示します。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | はい |

構文
--
```

Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip
Transfer-Encoding: identity

// コンマで区切って複数の値を並べることができます
Transfer-Encoding: gzip, chunked
```

ディレクティブ
-------

`chunked`

データはチャンク (塊) の連続で送られます。この場合は `Content-Length` ヘッダーが省略されます。それぞれのチャンクの先頭に現在のチャンクの長さを 16 進数の形式で追加し、その後で '`\r\n`' が続き、チャンク自体ももう一つの '`\r\n`' が続きます。最後のチャンクは通常のチャンクですが、長さが 0 であるという点が異なります。この後に、一連のエンティティのヘッダーフィールド (おそらく空) から成るトレイラーが続きます。

`compress`

Lempel-Ziv-Welch (LZW) アルゴリズムを使用した形式です。この値の名前はこのアルゴリズムを実装している UNIX の *compress* プログラムから採られました。
 特許問題 (2003 年に期限切れ) の影響もあり、多くの UNIX ディストリビューションから compress プログラムが消滅したように、今日ではこのコンテンツ符号化方式を使用しているブラウザーはほとんどありません。

`deflate`

zlib 構造体 (RFC 1950 で定義) と *deflate* 圧縮アルゴリズム (RFC 1951 で定義) を使用します。

`gzip`

Lempel-Ziv coding (LZ77) と 32 ビット CRC を使用する形式です。これは元は UNIX の *gzip* プログラムの形式です。 HTTP/1.1 標準は、互換性のために、このコンテンツ符号化方式の別名として`x-gzip` を解釈することにサーバーが対応することを推奨しています。

`identity`

恒等写像 (つまり、圧縮なし、変更なし) であることを示します。このトークンは、特に明示された場合は、常に受け付けられるとみなされます。

例
-

### チャンク化の符号化

チャンク化の符号化は、大量のデータをクライアントに送り、リクエストが完了するまでレスポンスの合計の長さが分からない場合に便利です。例えば、巨大な HTML の表をデータベースのクエリの結果として作成したり、大きな画像を転送したりする場合などです。チャンク化されたレスポンスは以下のようになります。
```

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7230, セクション 3.3.1: Transfer-Encoding | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Accept-Encoding`
* `Content-Encoding`
* `Content-Length`
* トレイラーの使用を制御するヘッダーフィールド: `TE` (en-US) (リクエスト) および `Trailer` (en-US) (レスポンス)
* チャンク化された転送エンコーディング


Cross-Origin-Opener-Policy - HTTP

Cross-Origin-Opener-Policy
==========================

HTTP の **`Cross-Origin-Opener-Policy`** (COOP) はレスポンスヘッダーで、最上位の文書がほかのオリジンの文書と閲覧コンテキストのグループを共有していないことを保証することができます。

COOP は文書のプロセスを分離し、潜在的な攻撃者がポップアップで文書を開いていたとしても、グローバルオブジェクトにアクセスできないようにし、 XS-Leaks と呼ばれる一連のオリジン間アタックを防止します。

COOP を持つクロスオリジン文書が新しいウィンドウで開かれた場合、開いている文書はその参照を持たず、新しいウィンドウの `window.opener` プロパティは `null` になります。これは、発信するナビゲーションにのみ影響する `rel=noopener` よりもウィンドウへの参照をより制御することができるようになります。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Cross-Origin-Opener-Policy: unsafe-none
Cross-Origin-Opener-Policy: same-origin-allow-popups
Cross-Origin-Opener-Policy: same-origin
```

### ディレクティブ

`unsafe-none`

これが既定値です。 opener 自体が `same-origin` または `same-origin-allow-popups` という COOP を持っていない限り、文書を opener の閲覧コンテキストグループに追加することを許可します。

`same-origin-allow-popups`

COOP を設定しないか、あるいは COOP を `unsafe-none` に設定することで分離を回避した、新しく開かれたウィンドウやタブへの参照を保持します。

`same-origin`

閲覧コンテキストを同一オリジン文書に限定します。クロスオリジン文書は同じ閲覧コンテキストには読み込まれません。

例
-

### 一部の機能はクロスオリジン分離に依存する

`SharedArrayBuffer` オブジェクトや `Performance.now()` といった非スロットルタイマーなどの特定の機能は、文書に `same-origin` 値を設定した COOP ヘッダーがある場合のみ利用可能です。
```

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
```

また、同様に設定する必要がある `Cross-Origin-Embedder-Policy` ヘッダーも参照してください。

クロスオリジン分離が成功したかどうかを確認するには、ウィンドウとワーカーのコンテキストで利用可能な `crossOriginIsolated` (en-US) プロパティを確認してください。

```js
if (crossOriginIsolated) {
  // Post SharedArrayBuffer
} else {
  // Do something else
}
```

仕様書
---

| Specification |
| --- |
| HTML Standard # the-coop-headers |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Cross-Origin-Embedder-Policy`


Accept-Language - HTTP

Accept-Language
===============

HTTP の **`Accept-Language`** リクエストヘッダーは、クライアントがどの言語を理解できるか、どの種類のロケールが推奨されるかを示します。 (言語というのは、英語のような自然言語を意味し、プログラミング言語ではありません。) コンテンツネゴシエーションを使用して、サーバーは提案されたものから一つを選択して使用し、 `Content-Language` レスポンスヘッダーを使用してクライアントに選択結果を知らせます。ブラウザーはユーザーインターフェイスの言語に従って、このヘッダーに適切な値を設定し、ユーザーはこれを変更することができますが、稀です (そしてフィンガープリントにつながるとして難色を示されます)。

このヘッダーはヒントであり、サーバーが言語を判別するための方法として、明示的なユーザーの選択によって制御する特定の URL など、他のものがない場合に使用されます。サーバーは明示的な決定を上書きしないことを推奨します。 `Accept-Language` の中身はユーザーが制御できないことが良くあります（旅行中で外国のインターネットカフェを使用している場合など）。ユーザーはユーザーインターフェースのロケール以外の言語によるページを訪問したがっているかもしれません。

サーバーが一致する言語を何も提供できない場合は、理論的には `406` (Not Acceptable) エラーコードを送り返すことができます。しかし、ユーザーの使い勝手をより良くするため、これはほとんど行われておらず、このような場合には一般に `Accept-Language` ヘッダーを無視するという方法が採られます。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | いいえ |
| CORS セーフリストリクエストヘッダー |
 はい。値が `0-9`, `A-Z`, `a-z`, space
 or `*,-.;=` のみであるという追加の制約あり。
  |

構文
--
```

Accept-Language: <language>
Accept-Language: *

// 重み値の構文によって重みづけされた複数の種別
Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
```

ディレクティブ
-------

`<language>`

言語タグです (「ロケール識別子」とも呼ばれることがあります)。これは言語を表す 2 ～ 3 文字の基本言語タグと、任意で追加のサブタグを `'-'` で区切って続けます。追加情報の多くは言語や地域の変化形 (`'en-US'` または `'fr-CA'` など) または使用する文字の種類 (`'sr-Latn'` など) です。正書法の種類 (`'de-DE-1996'`) など他の変化形は、通常このヘッダーのコンテキストでは使用されません。

`*`

任意の言語です。 `'*'` はワイルドカードとして使用されます。

`;q=` (Q 値の重み)

*重み*と呼ばれる、相対的な品質値を使用して表現される優先順位の順序で配置された値です。

例
-
```

Accept-Language: de

Accept-Language: de-CH

Accept-Language: en-US,en;q=0.5
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7231, セクション 5.3.5: Accept-Language | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |
| BCP 47 | Tags for the Identification of Language |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* HTTP コンテンツネゴシエーション
* コンテンツネゴシエーションの結果を伴うヘッダー: `Content-Language`
* 他の同様のヘッダー: `TE` (en-US), `Accept-Encoding`, `Accept-Charset`, `Accept`


Server - HTTP

Server
======

**`Server`** ヘッダーは、リクエストを処理したオリジンサーバー、すなわち、レスポンスを生成したサーバーで使用されたソフトウェアを説明します。

**警告:** `Server` の値は、攻撃者が既知のセキュリティホールを悪用するのを (少し) 容易にする情報を暴露する可能性があるので、過度に詳細にすることは避けてください。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Server: <product>
```

ディレクティブ
-------

`<product>`

リクエストを処理したソフトウェアまたは製品の名前です。通常は `User-Agent` と似た形式です。

どのくらいの詳細を含めるかのバランスを取るのは興味深いことです。 OS のバージョンを公開することは、先ほどの過度に詳細な値についての警告で述べたように、おそらく悪い考えです。しかし、 Apache のバージョンを公開すると、あるバージョンが持つ `Content-Encoding` と `Range` を組み合わせたバグをブラウザーが回避するのに役立ちます。

例
-
```

Server: Apache/2.4.1 (Unix)
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7231, セクション 7.4.2: Server | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Allow`


Keep-Alive - HTTP

Keep-Alive
==========

**`Keep-Alive`** 一般ヘッダーは、送信者が接続の仕組みや、タイムアウト値と最大リクエスト数の設定に使用される可能性があることをヒントとすることができます。

**メモ:** このヘッダーが意味を持つためには、 `Connection` ヘッダーを "keep-alive" に設定する必要があります。

**警告:** `Connection` や `Keep-Alive` などの接続固有のヘッダーフィールドは HTTP/2 では禁止されています。 Chrome と Firefox は HTTP/2 レスポンスでこれらを無視しますが、 Safari は HTTP/2 仕様の要件に準拠しており、これらを含むレスポンスは読み込まれません。

|  |  |
| --- | --- |
| ヘッダー種別 | 一般ヘッダー |
| 禁止ヘッダー名 | はい |

構文
--
```

Keep-Alive: parameters
```

ディレクティブ
-------

`parameters`

カンマで区切られたパラメータのリスト。各パラメータは識別子と等号 (`'='`) で区切られた値で構成されます。以下の識別子が利用可能です。

* `timeout`: 待機状態の接続を開いたままにしておく必要のある最小時間 (秒単位) を示します。keep-alive TCP メッセージがトランスポートレベルで設定されていない場合、TCP タイムアウトよりも長いタイムアウトが無視されることに注意してください。
* `max`: 接続を閉じる前にこの接続で送信できるリクエストの最大数を示します。`0` 以外の場合、次のレスポンスで別のリクエストが送信されるため、パイプラインでない接続ではこの値は無視されます。HTTP パイプラインは、パイプラインを制限するために使用できます。

例
-

`Keep-Alive` ヘッダーを含むレスポンスです。
```

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000
Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
Server: Apache

(本文)
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| HTTP Keep-Alive Header | Keep-Alive Header (IETF Internet Draft) |
| RFC 7230, appendix A.1.2: Keep-Alive | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Connection`
* HTTP/1.x のコネクション管理


Host - HTTP

Host
====

**`Host`** リクエストヘッダーは、リクエストが送信される先のサーバーのホスト名とポート番号を指定します。

ポート番号が指定されなかった場合は、要求されたサービスの既定のポート（例えば HTTPS の URL であれば`443`、 HTTP の URL であれば `80`）とみなされます。

`Host` ヘッダー項目はすべての HTTP/1.1 リクエストメッセージで送信する必要があります。 HTTP/1.1 リクエストメッセージに `Host` ヘッダー項目がなかったり、二つ以上あったりした場合は `400` (Bad Request) ステータスコードが返されることがあります。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | はい |

構文
--
```

Host: <host>:<port>
```

ディレクティブ
-------

<host>

（仮想ホストの）サーバーのドメイン名。

<port> 省略可

サーバーが待受けしている TCP のポート番号。

例
-
```

Host: developer.mozilla.org
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7230, セクション 5.4: Host | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `400`
* `<base>`


Strict-Transport-Security - HTTP

Strict-Transport-Security
=========================

HTTP の **`Strict-Transport-Security`** レスポンスヘッダー (しばしば HSTS と略されます) は、ウェブサイトがブラウザーに HTTP の代わりに HTTPS を用いて通信を行うよう指示するためのものです。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload
```

ディレクティブ
-------

`max-age=<expire-time>`

秒単位で、そのサイトに HTTPS だけで接続することをブラウザーが記憶する時間です。

`includeSubDomains` 省略可

省略可能で、この引数が指定されると、この規則がサイトのすべてのサブドメインにも適用されます。

`preload` 省略可

詳しくは Strict Transport Security のプリロード を参照してください。仕様書で定義されているものではありません。

解説
--

もし、訪問者が `http://www.foo.com/` または単に foo.com と入力したとき、ウェブサイトが接続を HTTP で受け付け、 HTTPS にリダイレクトするようになっていると、訪問者はリダイレクトされる前にまず、暗号化されないバージョンのサイトと通信する可能性があります。これは中間者攻撃の機会を作ってしまいます。リダイレクトは訪問者を、本来のサイトの安全なバージョンではなく、悪意のあるサイトに導くために利用される可能性があるからです。

HTTP の Strict Transport Security ヘッダーは、ブラウザーに対してサイトを HTTP を使用して読み込まず、サイトへのすべてのアクセスを、自動的に HTTP から HTTPS リクエストに変換するよう指示することができます。

**メモ:** サイトに HTTP を使用してアクセスしたとき、ブラウザーは `Strict-Transport-Security` ヘッダーを無視します。これは攻撃者が HTTP 接続に介入して、ヘッダーを挿入したり削除したりするかもしれないからです。ウェブサイトに HTTPS でアクセスして、証明書のエラーがない場合、ブラウザーはサイトが HTTPS でアクセスできることを知り、 `Strict-Transport-Security` ヘッダーを信用します。

### 事例

あなたが、空港で無料の Wi-Fi アクセスポイントにログインしてウェブの利用を開始し、オンラインバンキングサービスで残高の確認や取引を行ったとします。しかし不運にも、あなたが使用したアクセスポイントはハッカーのノートパソコンであり、そのハッカーはあなたの HTTP リクエストを傍受して、本物の銀行のサイトではなく偽のサイトへリダイレクトしたとします。こうなると、あなたの個人情報はハッカーにさらされてしまいます。

Strict Transport Security はこの問題を解決します。いったん銀行のウェブサイトへ HTTPS でアクセスすれば、そして銀行のウェブサイトが Strict Transport Security を利用していれば、ブラウザーは自動的に HTTPS のみを用いるよう理解して、ハッカーによるこの種の中間者攻撃の実行を防ぎます。

### ブラウザーでの扱い

最初にサイトに HTTPS でアクセスして `Strict-Transport-Security` ヘッダーが返されると、ブラウザーはこの情報を記録し、以降は HTTP を使用してサイトを読み込みもうとすると、自動的に HTTPS を使用するようになります。

Strict-Transport-Security ヘッダーで指定された有効期限が経過すると、次回は自動的に HTTPS を使用するのではなく、通常通りに HTTP でサイトを読み込もうとします。

なお、 Strict-Transport-Security ヘッダーがブラウザーへ送られるたびに、そのウェブサイトに対する有効期限が更新されるので、サイトはこの情報を更新して期限切れを防ぐことができます。 Strict-Transport-Security を無効にする必要がある場合は、 HTTPS 通信時に max-age の値を 0 に設定することで `Strict-Transport-Security` ヘッダーが失効し、ブラウザーからの HTTP 接続が許されるようになります。

Strict Transport Security のプリロード
--------------------------------

Google は HSTS 先読みサービス を行っています。ガイドラインに従ってドメインを登録すれば、ブラウザーはドメインに安全ではない接続を行わないようになります。サービスは Google によって運営されており、すべてのブラウザーが先読みリストを使用する意志を示しています (または既に使用を始めています)。但し、これは HSTS 仕様書にあるものではなく、公式なものとして扱うべきではありません。

* Chrome が実装している HSTS 先読みリストに関する情報 : https://www.chromium.org/hsts
* Firefox が実装している HSTS 先読みリストに関する参照 : nsSTSPreloadList.inc
例
-

既存および将来のすべてのサブドメインで、1 年間を期限として HTTPS を使用する設定です。これは HTTP のみで提供できるページやサブドメインへのアクセスをブロックします。
```

Strict-Transport-Security: max-age=31536000; includeSubDomains
```

以下の例では、 `max-age` は前回の 1 年間を期限とする `max-age` を延長して 2 年間に設定します。なお、1 年間はブラウザーの HSTS 先読みリストに含まれるドメインで有効です。しかし、2 年間は https://hstspreload.org で説明されているとおり、ウェブサイトの最終的な HSTS 設定のゴールとして推奨されています。また、最後の `preload` は Chromium, Edge, Firefox などの主要なブラウザーの HSTS 先読みリストで必要です。
```

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
```

仕様書
---

| Specification |
| --- |
| HTTP Strict Transport Security (HSTS) # section-6.1 |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* ブログ記事: HTTP Strict Transport Security has landed!
* ブログ記事: HTTP Strict Transport Security (force HTTPS)
* OWASP の記事: HTTP Strict Transport Security
* Wikipedia: HTTP Strict Transport Security
* ブラウザー試験サイト: HSTS and HPKP test
* 安全なコンテキストに制限されている機能


Access-Control-Max-Age - HTTP

Access-Control-Max-Age
======================

**`Access-Control-Max-Age`** レスポンスヘッダーは、プリフライトリクエストの結果 (つまり `Access-Control-Allow-Methods` および `Access-Control-Allow-Headers` ヘッダーに含まれる情報) をキャッシュすることができる時間の長さを示します。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Access-Control-Max-Age: <delta-seconds>
```

ディレクティブ
-------

<delta-seconds>

 結果をキャッシュすることができる最長の秒数です。
 Firefox は24 時間 (86400 秒) キャッシュすることができます。
 Chromium (v76 以前) は10 分 (600 秒) です。
 Chromium (v76 以降) は2 時間 (7200 秒) です。
 Chromium は既定値を 5 分に設定することもできます。
 **-1**の値はキャッシュを無効にし、すべての呼び出しをチェックするためにプリフライトの OPTIONS が必要になります。

例
-

プリフライト要求の結果は 10 分間キャッシュされます。
```

Access-Control-Max-Age: 600
```

仕様書
---

| Specification |
| --- |
| Fetch Standard # http-access-control-max-age |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Methods`


Forwarded - HTTP

Forwarded
=========

**`Forwarded`** ヘッダーは、リバースプロキシサーバーからの情報を含みます。リクエストの経路にプロキシーが介在している場合には、変更されたり失われたりします。

このヘッダーの代替で、事実上の標準となっているものは `X-Forwarded-For`, `X-Forwarded-Host`, `X-Forwarded-Proto` ヘッダーです。

このヘッダーは、デバッグ、統計、ロケーション依存コンテンツの生成に使用され、クライアントの IP アドレスなどの機密情報を公開します。したがって、このヘッダーを展開する際には、ユーザーのプライバシーを念頭に置く必要があります。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Forwarded: by=<identifier>;for=<identifier>;host=<host>;proto=<http|https>
```

ディレクティブ
-------

<identifier>

プロキシーの使用時に変更または失われた情報を公開する識別子。これは次のいずれかです。

* IP アドレス (v4 または v6、任意でポート番号付き、 ipv6 は引用符と角括弧で囲まれます)
* 難読化された識別子 ("\_hidden" や "\_secret" など)
* または先行するエンティティが不明な場合 (およびリクエストの転送が行われたことを示したい場合) は "unknown"

by=<identifier>

リクエストがプロキシサーバーに入ってきたインターフェイス。

for=<identifier>

リクエストを発行したクライアントと、その後のプロキシーチェーン内のプロキシー。

host=<host>

プロキシーから受信したときの `Host` リクエストヘッダー。

proto=<http|https>

そのプロトコルがリクエストの作成に使用されたか (ふつうは "http" または "https")。

例
-

### `Forwarded` ヘッダーの使用
```

Forwarded: for="_mdn"

# 大文字小文字の区別なし
Forwarded: For="[2001:db8:cafe::17]:4711"

# セミコロン区切り
Forwarded: for=192.0.2.60; proto=http; by=203.0.113.43

# 複数の値をコンマで区切って追加可能
Forwarded: for=192.0.2.43, for=198.51.100.17
```

### `X-Forwarded-For` から `Forwarded` への移行

アプリケーション、サーバー、プロキシーが標準化された `Forwarded` ヘッダーに対応している場合は、 `X-Forwarded-For` を置き換えることができます。なお、 IPv6 アドレスは、 `Forwarded` では引用符と角括弧で囲む必要があります。
```

X-Forwarded-For: 123.34.567.89
Forwarded: for=123.34.567.89

X-Forwarded-For: 192.0.2.43, "[2001:db8:cafe::17]"
Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]"
```

仕様書
---

| Specification |
| --- |
| Forwarded HTTP Extension # section-4 |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `X-Forwarded-For`
* `X-Forwarded-Host`
* `X-Forwarded-Proto`
* `Via` – 接続しているクライアントではなく、プロキシー自身についての情報を提供します。


WWW-Authenticate - HTTP

WWW-Authenticate
================

HTTP の **`WWW-Authenticate`** レスポンスヘッダーは、リソースへのアクセス権を得るために使われる HTTP 認証メソッド (「チャレンジ」) を定義します。

**メモ:** このヘッダーは、一般的な HTTP 認証の枠組みの一部であり、多くの認証方式で使用することができます。
 それぞれの「チャレンジ」には、サーバーが対応している方式と、その方式型に定義されている追加引数が記載されています。

HTTP 認証を使用するサーバーは、保護されたリソースへのリクエストに対して `401` `Unauthorized` レスポンスを返します。このレスポンスには、1 つ以上の `WWW-Authenticate` ヘッダーと 1 つ以上のチャレンジが含まれていなければならず、リソースへのアクセスにどのような認証方式が使用できるか (およびそれぞれの方式が必要とする追加データ) を示します。

 1 つの `WWW-Authenticate` ヘッダーには複数のチャレンジが許され、1 つのレスポンスには複数の `WWW-Authenticate` ヘッダーが許されます。
 サーバーは、他のレスポンスメッセージに `WWW-Authenticate` ヘッダーを含めることで、資格情報を提供することがレスポンスに影響を与える可能性があることを示すこともできます。

`WWW-Authenticate` ヘッダーを受け取った後、クライアントは通常、ユーザーに資格情報を求めるプロンプトを表示し、リソースを再リクエストします。この新しいリクエストは `Authorization` ヘッダーを使用して、選択された「チャレンジ」の認証方法に応じて適切にエンコードされた資格情報をサーバーに提供します。クライアントは、対応しているチャレンジのうち、最も安全なものを選択することが期待されます (なお、「最も安全な」方法については議論の余地がある場合もあります)。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--

 1 つ以上のチャレンジを指定する必要があります。
 複数のチャレンジを指定する場合は、カンマで区切って 1 つのヘッダーに入れたり、個々のヘッダーで指定したりすることができます。

```http
// チャレンジを単一のヘッダーで指定
WWW-Authenticate: challenge1, ..., challengeN

// チャレンジを複数のヘッダーで指定
WWW-Authenticate: challenge1
...
WWW-Authenticate: challengeN
```

 1 つのチャレンジは以下のような形式になっています。方式トークン (`<auth-scheme>`) が必須であることに注意してください。
 `realm`、`token68`、その他の引数の有無は、選択した方式の定義に依存します。

```http
// 可能なチャレンジの形式 (方式に依存)
WWW-Authenticate: <auth-scheme>
WWW-Authenticate: <auth-scheme> realm=<realm>
WWW-Authenticate: <auth-scheme> token68
WWW-Authenticate: <auth-scheme> auth-param1=token1, ..., auth-paramN=auth-paramN-token
WWW-Authenticate: <auth-scheme> realm=<realm> token68
WWW-Authenticate: <auth-scheme> realm=<realm> token68 auth-param1=auth-param1-token , ..., auth-paramN=auth-paramN-token
WWW-Authenticate: <auth-scheme> realm=<realm> auth-param1=auth-param1-token, ..., auth-paramN=auth-paramN-token
WWW-Authenticate: <auth-scheme> token68 auth-param1=auth-param1-token, ..., auth-paramN=auth-paramN-token
```

例えば、Basic 認証では任意で `realm` および `charset` キーを指定することができますが、`token68` には対応していません。

```http
WWW-Authenticate: Basic
WWW-Authenticate: Basic realm=<realm>
WWW-Authenticate: Basic realm=<realm>, charset="UTF-8"
```

ディレクティブ
-------

`<auth-scheme>`

認証方式です。有名なものとしては、 `Basic`、`Digest`、`Negotiate`、`AWS4-HMAC-SHA256` などがあります (大文字小文字の区別なし)。

**メモ:** 詳しい情報やオプションについては、HTTP 認証 > 認証方式を参照してください。

**realm=**<realm> 省略可

 保護領域を説明する文字列です。
 realm によってサーバーが保護する領域を分割することができ (そのような分割を許可しているスキームが対応している場合)、どの特定のユーザー名/パスワードが必要であるかをユーザーに通知します。
 realm が指定されていない場合は、クライアントはよく書式化されたホスト名を代わりに表示します。

`<token68>` 省略可

 方式によっては役立つ可能性のあるトークンです。このトークンでは、66 種類の予約されていない URI 文字に加えて、いくつかの文字を使用できます。
 仕様書によれば、 base64、base64url、base32、base16 (16 進数) の各エンコード方式のいずれかを、パディングの有無にかかわらず、ホワイトスーペースを除いて保持することができます。

`<auth-scheme>` とキー `realm` 以外の認証引数は、それぞれの認証方式に固有のものです。
 通常、これらについては関連する仕様を確認する必要があります (一部のスキームのキーを以下に示します)。

### Basic

**`<realm>`** 省略可

上記通りです。

**`charset="UTF-8"`** 省略可

 ユーザー名とパスワードを送信するときのサーバーが優先するエンコード方式をクライアントに伝えます。
 文字列 "UTF-8" だけが許可されており、大文字小文字の区別はありません。
 これは realm 文字列のエンコード方式とは関係がありません。

### Digest

**`<realm>`** 省略可

 使用するユーザー名/パスワードを示す文字列です。
 少なくともホスト名を含める必要がありますが、アクセス権を持つユーザーやグループを示す場合もあります。

**`domain`** 省略可

 引用符を付け、空白で区切った URL 接頭辞のリストで、この資格情報を使用するすべての場所を定義します。
 このキーが指定されていない場合、この資格情報はウェブルート以下のどこでも使用できます。

**`nonce`**

 サーバーが指定する引用符の付いた文字列で、特定の資格情報が有効とみなされる期間を制御するためにサーバーが使用できます。
 これは、401 レスポンスが行われるたびに一意に生成されなければならず、さらに頻繁に再生成される可能性があります (たとえば、ダイジェストを 1 回だけ使用できるようにするなど)。
 仕様書には、この値を生成するために利用可能なアルゴリズムに関する助言が含まれています。
 nonce の値は、クライアントには不透明です。

**`opaque`**

 サーバーが指定する引用符の付いた文字列で、 `Authorization` で変更されずに返されるべきものです。
 これはクライアントには不透明です。サーバーは Base64 または 16 進数のデータを含めることを推奨します。

**`stale`** 省略可

 大文字小文字を区別しないフラグで、クライアントからの前回のリクエストが、使用された `nonce` が古すぎる (stale) ために拒否されたことを示します。
 これが `true` であれば、新しい `nonce` で暗号化された同じユーザー名/パスワードを使ってリクエストを再試行できます。
 それ以外の値の場合は、ユーザー名/パスワードが無効なので、ユーザーに再度リクエストする必要があります。

**`algorithm`** 省略可

 ダイジェストの生成に使用するアルゴリズムです。
 セッション以外での有効な値は `"MD5"` (指定されていない場合の既定値)、`"SHA-256"`、`"SHA-512"` です。
 セッションで有効な値は `"MD5-sess"`、`"SHA-256-sess"`、`"SHA-512-sess"` です。

**`qop`**

引用符の付いた文字列で、サーバーが対応している保護の品質を示します。これは必ず指定しなければならず、認識できないオプションは無視されます。

* `"auth"`: 認証
* `"auth-int"`: 完全性保護付きの認証

**`charset="UTF-8"`** 省略可

 ユーザー名とパスワードを送信する際に、サーバーが優先するエンコード方式をクライアントに伝えます。
 大文字小文字を区別しない文字列 "UTF-8" のみが許可されます。

**`userhash`** 省略可

サーバーが `"true"` を指定することで、ユーザー名のハッシュ化に対応していることを示すことができます (既定値は `"false"` です)。

例
-

### Basic 認証

通常、`WWW-Authenticate` ヘッダーを含むサーバーのレスポンスは以下のようなものです。

```http
WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"
```

このヘッダーを受け取ったユーザーエージェントは、まずユーザーにユーザー名とパスワードの入力を求め、それからリソースを再リクエストします。このとき、`Authorization` ヘッダーに (エンコードされた) 認証情報を含めます。`Authorization` ヘッダーは次のようになります。

```http
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

`"Basic"` 認証では、資格情報はまず、ユーザー名とパスワードをコロンで結合し (`aladdin:opensesame`)、その結果の文字列を `base64` でエンコードすることで構築します (`YWxhZGRpbjpvcGVuc2VzYW1l`)。

**メモ:** Apache や nginx サーバーで HTTP Basic 認証を使用してサイトを保護する方法の例については、 HTTP 認証 を参照してください。

### SHA-256 と MD5 を使用した Digest 認証

**メモ:** この例は、RFC 7616 "HTTP Digest Access Authentication" から引用しています (この仕様書の他の例では、`SHA-512`、`charset`、`userhash` の使用方法を示しています)。

 クライアントは、Digest 認証で保護された URI "http://www.example.org/dir/index.html" の文書にアクセスしようとしています。
 この文書のユーザー名は "Mufasa" で、パスワードは "Circle of Life" です (各単語の間にスペースがあることに注意してください)。

 クライアントが初めて文書をリクエストしたとき、`Authorization` ヘッダーフィールドは送信されません。
 ここでサーバーは、対応している各ダイジェストアルゴリズムのチャレンジを含む HTTP 401 メッセージでレスポンスします (`SHA256`、`MD5` の順)。

```http
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
 realm="http-auth@example.org",
 qop="auth, auth-int",
 algorithm=SHA-256,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
WWW-Authenticate: Digest
 realm="http-auth@example.org",
 qop="auth, auth-int",
 algorithm=MD5,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
```

 クライアントはユーザー名とパスワードの入力をユーザーに促し、それから `Authorization` ヘッダーフィールドに資格情報をエンコードして入れます。
 クライアントが MD5 ダイジェストを選択した場合、`Authorization` ヘッダーフィールドは次のようになります。

```http
Authorization: Digest username="Mufasa",
 realm="http-auth@example.org",
 uri="/dir/index.html",
 algorithm=MD5,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 nc=00000001,
 cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
 qop=auth,
 response="8ca523f5e9506fed4657c9700eebdbec",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
```

クライアントが SHA-256 ダイジェストを選択した場合は、 `Authorization` ヘッダーフィールドは次のようになります。

```http
Authorization: Digest username="Mufasa",
 realm="http-auth@example.org",
 uri="/dir/index.html",
 algorithm=SHA-256,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 nc=00000001,
 cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
 qop=auth,
 response="753927fa0e85d155564e2e272a28d1802ca10daf449
 6794697cf8db5856cb6c1",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # field.www-authenticate |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* HTTP 認証
* `Authorization`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`, `403`, `407`


Timing-Allow-Origin - HTTP

Timing-Allow-Origin
===================

**`Timing-Allow-Origin`** レスポンスヘッダーは、 Resource Timing API の機能を介して取得された属性の値の表示を許可されているオリジンを指定します。そうでない場合、クロスオリジンの制限によりゼロとして報告されます。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Timing-Allow-Origin: *
Timing-Allow-Origin: <origin>[, <origin>]*
```

ディレクティブ
-------

`*`

サーバーはワイルドカードとして "\*" を指定することができ、それによって全てのオリジンがタイミングリソースを見ることができます。

`<origin>`

タイミングリソースを表示できる URI を指定します。 複数のオリジンをカンマ区切りで指定できます。

例
-

リソースがタイミングリソースを表示できるようにする場合。
```

Timing-Allow-Origin: *
```

`https://developer.mozilla.org` がタイミングリソースを表示できるようにするには、次のように指定できます。
```

Timing-Allow-Origin: https://developer.mozilla.org
```

仕様書
---

| Specification |
| --- |
| Resource Timing # sec-timing-allow-origin |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* Resource Timing API
* Resource Timing API の使用
* `Vary`


Cache-Control - HTTP

Cache-Control
=============

**`Cache-Control`** は HTTP のヘッダーフィールドで、 キャッシュ をブラウザーや共有キャッシュ（プロキシーや CDN など）において制御するためのディレクティブ (指示) を、リクエストとレスポンスの両方で保持します。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー,
 レスポンスヘッダー |
| 禁止ヘッダー名 | いいえ |
| CORS セーフリストレスポンスヘッダー | はい |

構文
--

キャッシュのディレクティブには、以下のような規則があります。

* 大文字と小文字は区別されませんが、実装によっては大文字のディレクティブを認識しないものもあるので、小文字を推奨します。
* 複数のディレクティブはカンマで区切ります。
* いくつかのディレクティブにはオプションの引数があります。
### キャッシュディレクティブ

標準的な `Cache-Control` ディレクティブは以下のように定義されています。

| リクエスト | レスポンス |
| --- | --- |
| `max-age` | `max-age` |
| `max-stale` | - |
| `min-fresh` | - |
| - | `s-maxage` |
| `no-cache` | `no-cache` |
| `no-store` | `no-store` |
| `no-transform` | `no-transform` |
| `only-if-cached` | - |
| - | `must-revalidate` |
| - | `proxy-revalidate` |
| - | `must-understand` |
| - | `private` |
| - | `public` |
| - | `immutable` |
| - | `stale-while-revalidate` |
| `stale-if-error` | `stale-if-error` |

注意: 互換性一覧表で対応状況を確認してください。解釈できないユーザーエージェントはこれらを無視します。

用語集
---

このドキュメントでは、次の用語が使用されています。すべてではありませんが、仕様書に基づいています。

`(HTTP) キャッシュ`

リクエストとレスポンスを保持し、次のリクエストで再利用するための実装。共有キャッシュまたはプライベートキャッシュのいずれかです。

`共有キャッシュ`

オリジンサーバーとクライアントの間に存在するキャッシュ (Proxy, CDN など)。1 つのレスポンスを保存し、それを複数のユーザーで再利用します。したがって、開発者は共有キャッシュにパーソナライズされたコンテンツをキャッシュとして保存することは避けるべきです。

`プライベートキャッシュ`

クライアント内に存在するキャッシュです。*ローカルキャッシュ*、あるいは単に*ブラウザーキャッシュ*などとも呼ばれます。ユーザーのためにパーソナライズされたコンテンツを保存し、再利用できます。

`レスポンスの格納`

キャッシュ可能な場合には、レスポンスをキャッシュに保存します。しかし、そのまま再利用されるとは限りません。（通常、「キャッシュ」はレスポンスを保存することを意味します。）

`レスポンスの再利用`

キャッシュされたレスポンスを次のリクエストに再利用します。

`レスポンスの再検証`

オリジンサーバーに、保存されているレスポンスがまだ新しいか確認します。通常は条件付きのリクエストで行います。

`新鮮なレスポンス`

レスポンスが新しい状態であることを示します。これは通常、リクエストの指示に応じて、レスポンスを後続のリクエストに再利用できることを意味します。

`古いレスポンス`

レスポンスが古い状態になっていることを示します。これは通常、レスポンスがそのままでは再利用できないことを意味します。キャッシュストレージは古いレスポンスをすぐに削除する必要はありません。なぜなら、再検証によってレスポンスが古いものから再び新しい状態に変わる可能性があるからです。

`Age`

レスポンスが生成されてからの経過時間です。レスポンスが新しい状態か古い状態かの基準となります。

ディレクティブ
-------

このセクションでは、キャッシュに影響を与えるディレクティブ（レスポンスディレクティブとリクエストディレクティブの両方）を列挙します。

### レスポンスディレクティブ

#### `max-age`

レスポンスディレクティブの`max-age=N` は、レスポンスが生成されてから *N* 秒後まで、レスポンスが新鮮なままであることを示します。
```

Cache-Control: max-age=604800
```

キャッシュがこのリクエストを保存し、新鮮なうちに後続のリクエストに再利用できることを示します。

なお、`max-age` はレスポンスを受信してからの経過時間ではなく、オリジンサーバーでレスポンスが生成されてからの経過時間であることに注意してください。したがって、他のキャッシュ（レスポンスが通ったネットワーク経路上）が 100 秒間保存した場合（レスポンスヘッダーフィールドの `Age` で示される）、ブラウザーキャッシュはその鮮度の有効期間から 100 秒を差し引きます。
```

Cache-Control: max-age=604800
Age: 100
```

#### `s-maxage`

レスポンスディレクティブの `s-maxage` も、レスポンスが新鮮である期間を示します(`max-age` に似ています)。しかし、これは共有キャッシュ特有のもので、共有キャッシュは `s-maxage` と `max-age` の両方が存在した場合 `max-age` を無視します。
```

Cache-Control: s-maxage=604800
```

#### `no-cache`

レスポンスディレクティブの `no-cache` は、キャッシュに保存できることを示しますが、キャッシュがオリジンサーバーから切断された場合でも、再利用の前にオリジンサーバーで検証しなければなりません。
```

Cache-Control: no-cache
```

キャッシュに、保存されているコンテンツを再利用する際に、必ず更新がないかどうかをチェックさせたい場合は、 `no-cache` を使用する必要があります。これは、キャッシュがオリジンサーバーに各リクエストを再検証することを要求することで実現されます。

`no-cache` はキャッシュにレスポンスを保存することを許可しますが、再利用する前に再検証することを要求します。もし、「キャッシュさせない」の意味が実際には「保存させない」であるなら、`no-store` が使用すべきディレクティブです。

#### `must-revalidate`

レスポンスディレクティブの `must-revalidate` は、レスポンスがキャッシュに保存され、新鮮なうちは再利用できることを示します。古くなったレスポンスは、再利用する前にオリジンサーバーで検証されなければなりません。

通常、`must-revalidate` は `max-age` と共に使用されます。
```

Cache-Control: max-age=604800, must-revalidate
```

HTTP では、キャッシュがオリジンサーバーから切り離されたときに、古いレスポンスを再利用できます。`must-revalidate` はそれを防ぐための方法で、キャッシュは保存されたレスポンスを元のサーバーで再検証するか、それが検証不可能な場合は 504 (Gateway Timeout) のレスポンスを生成します。

#### `proxy-revalidate`

レスポンスディレクティブの `proxy-revalidate` は `must-revalidate` と同等ですが、共有キャッシュにのみ適用されます。

#### `no-store`

レスポンスディレクティブの `no-store` は、あらゆる種類のキャッシュが（プライベートであろうと共有であろうと）このレスポンスを保存しないようにすることを指示します。
```

Cache-Control: no-store
```

#### `private`

レスポンスディレクティブの `private` は、レスポンスがプライベートキャッシュ（ブラウザーのローカルキャッシュなど）にのみ保存できることを示します。
```

Cache-Control: private
```

ユーザー個人を特定するコンテンツ、特にログイン後に受け取るレスポンスや、Cookie で管理されるセッションについては、`private` ディレクティブを追加する必要があります。

パーソナライズされたコンテンツを持つレスポンスに `private` を付け忘れると、そのレスポンスが共有キャッシュに保存され、複数のユーザーによって再利用されてしまい、個人情報の漏えいに繋がる可能性があります。

#### `public`

ヘッダーフィールドに `Authorization` を持つリクエストに対するレスポンスは、共有キャッシュに保存してはいけません。しかし、`public` ディレクティブはそのようなレスポンスを共有キャッシュに保存します。
```

Cache-Control: public
```

一般に、ページが Basic 認証または Digest 認証で制御されている場合、ブラウザーは `Authorization` ヘッダーを付けてリクエストを送信します。つまり、レスポンスは制限されたユーザー（アカウントを持つユーザー）のみにアクセス制御され、たとえ `max-age` がついていても基本的に共有キャッシュに保存可能ではありません。

その制限を解除するために `public` ディレクティブが使用できます。
```

Cache-Control: public, max-age=604800
```

なお、`s-maxage` や `must-revalidate` もこの制限を解除します。

リクエストに `Authorization` ヘッダーがない場合、あるいはレスポンスに `s-maxage` または `must-revalidate` をすでに使用している場合は、`public` を使用する必要はありません。

#### `must-understand`

レスポンスディレクティブの `must-understand` は、ステータスコードに基づいてキャッシュの要件を理解している場合にのみ、キャッシュがレスポンスを保存すべきであると示します。

`must-understand` は、フォールバック動作のために `no-store` と組み合わせる必要があります。
```

Cache-Control: must-understand, no-store
```

キャッシュが `must-understand` に対応していない場合は、無視されます。`no-store` も存在する場合は、レスポンスは保存されません。

キャッシュが `must-understand` に対応している場合、ステータスコードに基づいてキャッシュの要件を理解してレスポンスを保存します。

#### `no-transform`

仲介者 (intermedialies) の中には、さまざまな理由でコンテンツを変換するものがあります。たとえば、転送サイズを小さくするために画像を変換するものなどです。場合によっては、これはコンテンツプロバイダーにとって望ましくありません。

`no-transform` は、仲介者が（キャッシュを実装しているかどうかに関係なく）レスポンスの内容を変換すべきではないことを示します。

注意: Google's Web Light は、そのような仲介者の一種です。これは、キャッシュストアや低速接続のデータを最小化するために画像を変換し、オプトアウトオプションとして `no-transform` に対応します。

#### `immutable`

レスポンスディレクティブの `immutable` は、レスポンスが新鮮な間は更新されないことを示します。
```

Cache-Control: public, max-age=604800, immutable
```

静的なリソースに対する最近のベストプラクティスは、バージョン/ハッシュを URL に含める一方で、リソースには決して手を加えず必要なときに、新しいバージョン番号/ハッシュを持つ新しいバージョンでリソースを更新し、URL も異なるものにすることです。これを **cache-busting** パターンと呼びます。
```

<script src=https://example.com/react.0.0.0.js></script>
```

 ユーザーがブラウザーをリロードすると、ブラウザーはオリジンサーバーに検証のための条件付きリクエストを送信します。しかし、これらの静的リソースは、ユーザーがブラウザーをリロードしても決して変更されないため、再検証する必要がありません。
 `immutable` はキャッシュにレスポンスが新鮮な間は不変であることを伝え、サーバーへの不要な条件付きリクエストを回避します。

リソースに cache-busting パターンを使用し、長い `max-age` を適用すると、再検証を避けるために `immutable` も追加することができます。

#### `stale-while-revalidate`

レスポンスディレクティブの `stale-while-revalidate` は、キャッシュを再検証している間、古いレスポンスの再利用が可能なことを示します。
```

Cache-Control: max-age=604800, stale-while-revalidate=86400
```

上記の例では、レスポンスは 7 日間（604800 秒間）は新鮮です。7 日後、レスポンスは古くなりますが、キャッシュは翌日（86400 秒後）のリクエストに再利用できます。ただし、バックグラウンドでレスポンスを再検証することが条件です。

再検証により、キャッシュは再び新鮮になるため、クライアントはその期間中は常に新鮮であったかのように見えます。これにより再検証の遅延ペナルティを効果的にクライアントから隠蔽できます。

その間にリクエストがなければ、キャッシュは古くなり、次のリクエストは正常に再検証されます。

#### `stale-if-error`

レスポンスディレクティブの `stale-if-error` は、オリジンサーバーがエラー（500、502、503、504）でレスポンスを返したときに、キャッシュが古いレスポンスを再利用できることを指示します。
```

Cache-Control: max-age=604800, stale-if-error=86400
```

上記の例では、レスポンスは 7 日間（604800 秒間）は新鮮です。7 日を過ぎると古くなりますが、サーバーがエラーでレスポンスを返した場合はさらに 1 日（86400 秒間）利用できます。

一定時間経過後、保存されたレスポンスは通常通り古くなります。つまり、オリジンサーバーがエラーレスポンスを送信した場合、クライアントはそのままエラーレスポンスを受信します。

リクエストディレクティブ
------------

### `no-cache`

リクエストディレクティブの `no-cache` はキャッシュに、再利用する前にオリジンサーバーでレスポンスを検証するように要求します。
```

Cache-Control: no-cache
```

`no-cache` は、キャッシュに新しいレスポンスがある場合でも、クライアントが最新のレスポンスを要求することを可能にします。

ブラウザーは通常、ユーザーがページを**強制再読み込み**したときに、リクエストに `no-cache` を追加します。

### `no-store`

リクエストディレクティブの `no-store` は、オリジンサーバーのレスポンスが保存される可能性がある場合でも、クライアントがリクエストと対応するレスポンスを保存しないようにキャッシュに要求することを可能にします。
```

Cache-Control: no-store
```

主要なブラウザーは `no-store` を使ったリクエストに対応していないことに注意してください。

### `max-age`

リクエストディレクティブの `max-age=N` は、オリジンサーバーで *N* 秒以内に生成された、保存済みレスポンスをクライアントが許可することを示します。
```

Cache-Control: max-age=3600
```

上記の場合、`Cache-Control: max-age=604800` のレスポンスが 3 時間前にキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用できません。

以下で説明するように、多くのブラウザーは**再読み込み**時に、このディレクティブを使用します。
```

Cache-Control: max-age=0
```

`max-age=0` は `no-cache` の回避策です。多くの古い (HTTP/1.0 の) キャッシュの実装は `no-cache` に対応していないからです。最近のブラウザーは、後方互換性のために `max-age=0` を「再読み込み」の際に使用し、`no-cache` を使用して「強制再読み込み」を行うようになっています。

### `max-stale`

リクエストディレクティブの `max-stale=N` は、クライアントが *N* 秒以内に失効した保存されたレスポンスを許可することを示します。
```

Cache-Control: max-stale=3600
```

上記の場合、3 時間前に `Cache-Control: max-age=604800` を持つレスポンスがキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用できません。

クライアントは、オリジンサーバーがダウンしているときや遅すぎるときにこのヘッダーを使うことができ、多少古くてもキャッシュされたレスポンスをキャッシュから受け入れることができます。

主要なブラウザーは `max-stale` を指定したリクエストに対応していないことに注意してください。

### `min-fresh`

リクエストディレクティブの `min-fresh` は、クライアントが少なくとも *N* 秒間新鮮な保存されたレスポンスを許可することを示します。
```

Cache-Control: min-fresh=600
```

上記の場合、51 分前に `Cache-Control: max-age=3600` を持つレスポンスがキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用できません。

クライアントがこのヘッダーを使用できるのは、ユーザーのレスポンスが新鮮であることだけでなく、一定期間更新されないことも要求する場合です。

主要なブラウザーは `min-fresh` を使ったリクエストに対応していないことに注意してください。

### `no-transform`

レスポンスの `no-transform` と同じ意味ですが、リクエストに対するものです。

### `only-if-cached`

クライアントは、キャッシュがすでに保存済みのレスポンスを転送する必要があることを示します。キャッシュにレスポンスが保存されている場合、それが再利用されます。

利用例
---

### 格納を防止

レスポンスをキャッシュに保存したくない場合は、 `no-store` ディレクティブを使用します。
```

Cache-Control: no-store
```

`no-cache` は「保存することはできるが、検証する前に再利用しない」という意味なので、レスポンスが保存されないようにするためのものではないことに注意してください。
```

Cache-Control: no-cache
```

理論的には、ディレクティブが衝突した場合、最も制限の厳しいディレクティブが尊重されるべきです。つまり、以下の例は基本的に無意味です。`private`, `no-cache`, `max-age=0`, `must-revalidate` は `no-store` と競合しているからです。
```

# 競合
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate

# 以下のものと等しい
Cache-Control: no-store
```

### "cache busting" における静的資産のキャッシュ

バージョン/ハッシュビルドを持つ静的資産を構築する場合、ファイル名やクエリー文字列にバージョン/ハッシュを追加することは、キャッシュを管理するための良い方法です。

例：

```html
<!-- index.html -->
<script src=/assets/react.min.js></script>
<img src=/assets/hero.png width=900 height=400>
```

React ライブラリーのバージョンは、ライブラリーを更新すると変わりますし、`hero.png` も画像を編集すると変わります。そのため、これらは `max-age` を使ってキャッシュに保存するのは難しくなります。

このような場合、特定の番号のついたバージョンのライブラリーを使用し、画像の URL にハッシュを含めることでキャッシュの要求を満たすことができます。

```html
<!-- index.html -->
<script src=/assets/react.0.0.0min.js></script>
<img src=/assets/hero.png?hash=deadbeef width=900 height=400>
```

コンテンツは決して変更されないので、 `max-age` を長い値や `immutable` にすることができます。
```

# /assets/*
Cache-Control: max-age=31536000, immutable
```

ライブラリーを更新したり、画像を編集したりすると、新しいコンテンツは新しい URL を持つはずなので、キャッシュは再利用されません。それを "cache busting" パターンと呼びます。

`no-cache` を使用して HTML レスポンス自体がキャッシュされないようにしてください。 `no-cache` では再検証することができるので、クライアントが HTML レスポンスや静的資産の新しいバージョンを正しく受信します。
```

# /index.html
Cache-Control: no-cache
```

注意: `index.html` が Basic 認証または Digest 認証で制御されている場合、`/assets` 以下のファイルは共有キャッシュに保存されません。もし `/assets/` のファイルが共有キャッシュに保存するのに適しているなら、 `public`、`s-maxage` または `must-revalidate` のうちの 1 つが必要です。

### コンテンツを常に最新にする

動的に生成されるコンテンツや、静的であっても頻繁に更新されるコンテンツでは、ユーザーが常に最新版を受信できるようにしたいものです。

もし、レスポンスがキャッシュされることを意図していないからといって `Cache-Control` ヘッダーを追加しなければ、予期せぬ結果を引き起こす可能性があります。キャッシュストレージは、推測でキャッシュすることが許されています。したがって、キャッシュに関する何らかの要求がある場合は、常に `Cache-Control` ヘッダーで明示的に示す必要があります。

レスポンスに `no-cache` を追加すると、サーバーで再検証が行われるので、毎回新鮮なレスポンスを提供できます。また、クライアントがすでに新しいレスポンスを持っている場合は、`304 Not Modified` とだけレスポンスを返します。
```

Cache-Control: no-cache
```

ほとんどの HTTP/1.0 キャッシュは `no-cache` ディレクティブに対応していないので、歴史的には `max-age=0` が回避策として使用されてきました。しかし、`max-age=0` だけでは、キャッシュがオリジンサーバーから切断されたときに、古いレスポンスが再利用される可能性がありました。`must-revalidate` はそれに対応するものです。そのため、以下の例では `no-cache` と同等になっています。
```

Cache-Control: max-age=0, must-revalidate
```

しかし、今のところ、単に `no-cache` を代わりに使用できます。

### 既に格納されたキャッシュのクリア

残念ながら、すでに保存されているレスポンスをキャッシュからクリアするためのキャッシュディレクティブはありません。

クライアントやキャッシュが、あるパスに対する新鮮なレスポンスを保存しており、サーバーへリクエストを送信しない状態を想像してください。そのパスに対してサーバーができることは何もありません。

代替として `Clear-Site-Data` はブラウザーのキャッシュをクリアできます。しかし、これはあるサイトの保存されたすべてのレスポンスをクリアするので注意してください。そして、クリアされるのはブラウザー内のキャッシュのみで、共有キャッシュはクリアされません。

仕様書
---

| Specification |
| --- |
| HTTP Caching # field.cache-control |
| HTTP Immutable Responses # the-immutable-cache-control-extension |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

HTTP Caching
RFC5861 - HTTP Cache-Control Extensions for Stale Content
RFC8246 - HTTP Immutable Responses

関連情報
----

* HTTP キャッシュの FAQ
* Caching Tutorial for Web Authors and Webmasters
* Caching best practices & max-age gotchas
* Cache-Control for Civilians
* `Age`
* `Expires`
* `Pragma`


Link - HTTP

Link
====

HTTP の **`Link`** エンティティヘッダーフィールドは、 HTTP ヘッダー内の 1 つ以上のリンクをシリアル化する手段を提供します。意味的には、 HTML の `<link>` 要素と同等です。

構文
--

```http
Link: <uri-reference>; param1=value1; param2="value2"
```

`<uri-reference>`

URI 参照。 `<` と `>` で囲む必要があります。

### 引数

リンクヘッダーには `;` で区切られた引数が含まれており、 `<link>` 要素の属性に相当します。

例
-

URI （絶対または相対）は `<` と `>` で囲む必要があります。

```http
Link: <https://example.com>; rel="preconnect"
```

```http
Link: https://bad.example; rel="preconnect"
```

### 複数リンクを指定

カンマで区切られた複数のリンクを指定できます。次に例を示します。

```http
Link: <https://one.example.com>; rel="preconnect", <https://two.example.com>; rel="preconnect", <https://three.example.com>; rel="preconnect"
```

仕様書
---

| Specification |
| --- |
| Web Linking # header |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `103 Early Hints`


Feature-Policy: ambient-light-sensor - HTTP

Feature-Policy: ambient-light-sensor
====================================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `ambient-light-sensor` ディレクティブは、現在の文書が `AmbientLightSensor` インターフェイスを通じて端末の周囲の環境における明るさの量に関する情報を収集することを許可するかどうかを制御します。

構文
--
```

Feature-Policy: ambient-light-sensor <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`ambient-light-sensor` の既定の許可リストは `'self'` です。

仕様書
---

| Specification |
| --- |
| Generic Sensor API # permissions-policy |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: midi - HTTP

Feature-Policy: midi
====================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `midi` ディレクティブは、現在の文書が Web MIDI API を使用することを許可するかどうかを制御します。このポリシーが有効であれば、 `Navigator.requestMIDIAccess()` から返却された `Promise` が `DOMException` で拒否されます。

構文
--
```

Feature-Policy: midi <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

許可リストは `'self'` です。

仕様書
---

| Specification |
| --- |
| Web MIDI API # permissions-policy-integration |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: geolocation - HTTP

Feature-Policy: geolocation
===========================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `geolocation` ディレクティブは、現在の文書が `Geolocation` インターフェイスを使用することを許可するかどうかを制御します。このポリシーが有効であれば、 `getCurrentPosition()` および `watchPosition()` を呼び出すと、関数のコールバックが呼び出され、 `GeolocationPositionError` のコードが `PERMISSION_DENIED` になります。

既定では、 Geolocation API は最上位の文書およびその同じオリジンの子フレームの中で使用することができます。このディレクティブは別オリジンのフレームによる位置情報へのアクセスを許可したり拒否したりします。同じオリジンのフレームも含みます。

構文
--
```

Feature-Policy: geolocation <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`geolocation` の既定の許可リストは `'self'` です。

例
-

### 一般的な例

SecureCorp Inc. が、自分自身のオリジンおよびオリジンが `https://example.com` のものを除いてすべての Geolocation API を無効にしようとしているとします。以下の機能ポリシーを設定する HTTP レスポンスヘッダーを配信することで実現できます。
```

Feature-Policy: geolocation 'self' https://example.com
```

### <iframe> 要素と

FastCorp Inc. が、特定の <iframe> を除いたすべての別オリジンの子フレームの `geolocation` を無効にしようとしているとします。以下の機能ポリシーを設定する HTTP レスポンスヘッダーを配信することで実現できます。
```

Feature-Policy: geolocation 'self'
```

それから allow 属性を `<iframe>` 要素に含めてください。

```html
<iframe src="https://other.com/map" allow="geolocation"></iframe>
```

興味深いことに、 `allow` 属性は、同じオリジンの文書を含むフレームであっても、あるフレームでは機能を有効にし、他のフレームでは機能を無効にするという選択をすることができます。

仕様書
---

| Specification |
| --- |
| Geolocation API # permissions-policy |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: accelerometer - HTTP

Feature-Policy: accelerometer
=============================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `accelerometer` ディレクティブは、現在の文書が `Accelerometer` インターフェイスを通じて端末の加速度に関する情報を収集することを許可するかどうかを制御します。

構文
--
```

Feature-Policy: accelerometer <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

この機能の `allowlist` 値の既定値は `'self'` です。

仕様書
---

| Specification |
| --- |
| Generic Sensor API # permissions-policy |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: payment - HTTP

Feature-Policy: payment
=======================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーフィールドにおける `payment` ディレクティブは、現在の文書が Payment Request API を使用することを許可するかどうかを制御します。このポリシーが無効であれば、 `PaymentRequest()` コンストラクターで `SyntaxError` の `DOMException` が発生します。

構文
--
```

Feature-Policy: payment <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`payment` 機能の既定の許可リストの値は `'self'` です。

仕様書
---

| Specification |
| --- |
| Payment Request API 1.1 # permissions-policy |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダーフィールド
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: display-capture - HTTP

Feature-Policy: display-capture
===============================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `display-capture` ディレクティブは、現在の文書が Screen Capture API、すなわち `getDisplayMedia()` を使用して画面の内容をキャプチャすることを許可するかどうかを制御します。

文書で `display-capture` が無効になっていた場合、文書は `getDisplayMedia()` を通じて画面キャプチャを行うことができなくなります。

構文
--
```

Feature-Policy: display-capture <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`display-capture` の許可リストの既定値は `'self'` です。

仕様書
---

| Specification |
| --- |
| Screen Capture # permissions-policy-integration |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用
* Screen Capture API
* Screen Capture API の使用


Feature-Policy: fullscreen - HTTP

Feature-Policy: fullscreen
==========================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `fullscreen` ディレクティブは、現在の文書が `Element.requestFullScreen()` を使用することを許可するかどうかを制御します。このポリシーが有効であれば、 返却された `Promise` が `TypeError` で拒否されます。

既定では、最上位の文書およびその同じオリジンの子フレームが全画面モードを要求し、入ることができます。このディレクティブは別オリジンのフレームが全画面モードを使用することを許可したり拒否したりします。同じオリジンのフレームも含みます。

**メモ:** このディレクティブ (つまり `allow` 属性で設定したもの) と `allowfullscreen` 属性の両方が `<iframe>` 要素に存在する場合、このディレクティブが優先されます。以前は `fullscreen` ディレクティブが `allowfullscreen` 属性と同時に存在しないと動作しないバグがありましたが、Firefox 80 では修正されています (Firefox バグ 1608358)。

構文
--
```

Feature-Policy: fullscreen <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`fullscreen` の既定の許可リストは `'self'` です。

例
-

### 一般的な例

SecureCorp Inc. は、自分自身のオリジンおよびオリジンが `https://example.com` のものを除いてすべての Fullscreen API を無効にしようとしているとします。以下の機能ポリシーを設定する HTTP レスポンスヘッダーを配信することで実現できます。
```

Feature-Policy: fullscreen 'self' https://example.com
```

### <iframe> 要素と

FastCorp Inc. は、特定の <iframe> を除いたすべての別オリジンの子フレームの `fullscreen` を無効にしようとしているとします。以下の機能ポリシーを設定する HTTP レスポンスヘッダーを配信することで実現できます。
```

Feature-Policy: fullscreen 'self'
```

それから allow 属性を `<iframe>` 要素に含めます。

```html
<iframe src="https://other.com/videoplayer" allow="fullscreen"></iframe>
```

iframe の属性は、選択的に特定のフレームの機能を有効にし、その他はたとえそれらのフレームが同じオリジンからきた文書を含んでいても無効にします。

仕様書
---

| Specification |
| --- |
| Fullscreen API Standard # permissions-policy-integration |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: battery - HTTP

Feature-Policy: battery
=======================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `battery` ディレクティブは、現在の文書で `Navigator.getBattery()` で得られる `BatteryManager` (en-US) インターフェイスを通じて、端末のバッテリーに関する情報の収集を許可するかどうかを制御します。

構文
--
```

Feature-Policy: battery <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`battery` の許可リストの既定値は `'self'` です。

仕様書
---

| Specification |
| --- |
| Battery Status API # permissions-policy-integration |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用
* Battery Status API
* `Navigator.getBattery()`
* `BatteryManager` (en-US)


Feature-Policy: camera - HTTP

Feature-Policy: camera
======================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `camera` ディレクティブは、現在の文書が動画入力機器を使用することを許可するかどうかを制御します。このポリシーが有効であれば、 `MediaDevices.getUserMedia()` から返却された `Promise` が `NotAllowedError` で拒否されます。

構文
--
```

Feature-Policy: camera <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`camera` の許可リストの既定値は `'self'` です。

仕様書
---

| Specification |
| --- |
| Media Capture and Streams # permissions-policy-integration |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: screen-wake-lock - HTTP

Feature-Policy: screen-wake-lock
================================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける **`screen-wake-lock`** ディレクティブは、現在の文書が Screen Wake Lock API を使用して、端末が画面を暗くしたりオフにしたりしないよう指示することを許可するかどうか制御します。

**メモ:** 早期の仕様書の草稿では、このディレクティブは `wake-lock` と呼ばれていました。

構文
--
```

Feature-Policy: screen-wake-lock <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`screen-wake-lock` の既定の許可リストは `'self'` です。

仕様書
---

| Specification |
| --- |
| Screen Wake Lock API # policy-control |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* Screen Wake Lock API
* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用
* 許可リストの既定値


Feature-Policy: autoplay - HTTP

Feature-Policy: autoplay
========================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `autoplay` ディレクティブは、現在の文書で `HTMLMediaElement` インターフェイスによってメディアの自動再生をリクエストすることを許可するかどうかを制御します。このポリシーが有効であれば、 `HTMLMediaElement.play()` から返却された `Promise` が `DOMException` で拒否されます。 `<audio>` および `<video>` 要素の `autoplay` 属性は無視されます。

自動再生や自動再生ブロックの詳細については、 メディアおよび Web Audio API の自動再生ガイド の記事を参照してください。

構文
--
```

Feature-Policy: autoplay <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

Google Chrome における既定値は
 `'self'` です。

仕様書
---

| Specification |
| --- |
| HTML Standard # autoplay-feature |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: xr-spatial-tracking - HTTP

Feature-Policy: xr-spatial-tracking
===================================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `xr-spatial-tracking` ディレクティブは、現在の文書が WebXR Device API を使用することを許可するかどうかを制御します。このポリシーは、 `navigator.xr.requestSession()` (en-US) が空間追跡を必要とする `XRSession` (en-US) を返すことができるかどうか、またユーザーエージェントが `navigator.xr.isSessionSupported()` (en-US) と `devicechange` イベントを通じて空間追跡をサポートするセッションへのサポートを `navigator.xr` オブジェクトで示せるかどうかを制御します。

構文
--
```

Feature-Policy: xr-spatial-tracking <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

既定の許可リストは `'self'` です。

仕様書
---

| Specification |
| --- |
| WebXR Device API # permissions-policy |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* WebXR Device API
* `navigator.xr.requestSession()` (en-US), `navigator.xr.isSessionSupported()` (en-US), `navigator.xr` の `devicechange` イベント
* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: encrypted-media - HTTP

Feature-Policy: encrypted-media
===============================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `encrypted-media` ディレクティブは、現在の文書が Encrypted Media Extensions (en-US) API (EME) を使用することを許可するかどうかを制御します。このポリシーが有効であれば、 `Navigator.requestMediaKeySystemAccess()` (en-US) から返却された `Promise` が `DOMException` で拒否されます。

構文
--
```

Feature-Policy: encrypted-media <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`encrypted-media` の既定の許可リストは `'self'` です。

仕様書
---

| Specification |
| --- |
| Encrypted Media Extensions # permissions-policy-integration |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: microphone - HTTP

Feature-Policy: microphone
==========================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `microphone` ディレクティブは、現在の文書がオーディオ入力機器を使用することを許可するかどうかを制御します。このポリシーが有効であれば、 `MediaDevices.getUserMedia()` で返却された `Promise` が `NotAllowedError` で拒否されます。

構文
--
```

Feature-Policy: microphone <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`geolocation` の既定の許可リストは `'self'` です。

仕様書
---

| Specification |
| --- |
| Media Capture and Streams # permissions-policy-integration |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: document-domain - HTTP

Feature-Policy: document-domain
===============================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `document-domain` ディレクティブは、現在の文書が `document.domain` を設定することを許可するかどうかを制御します。このポリシーが無効であった場合、 `document.domain` を設定しようとすると失敗し、 `SecurityError` の `DOMException` が発生します。

構文
--
```

Feature-Policy: document-domain <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

`document-domain` の既定の許可リストは `*` です。

仕様書
---

| Specification |
| --- |
| HTML Standard # policy-controlled-features |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Feature-Policy: web-share - HTTP

Feature-Policy: web-share
=========================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Feature-Policy` ヘッダーにおける `web-share` ディレクティブは、減殺の文書が Web Share API の `Navigator.share()` メソッドを使用して、テキスト、リンク、画像、その他のコンテンツをユーザーが選択した任意の宛先にシェアすることを許可するかどうかを制御します。

構文
--
```

Feature-Policy: web-share <allowlist>;
```

<allowlist>

この機能を許可するオリジンのリストです。 `Feature-Policy` を参照してください。

既定のポリシー
-------

既定値は `'self'` です。

仕様書
---

| Specification |
| --- |
| Web Share API # permissions-policy |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

ブラウザーへの実装は https://github.com/w3c/web-share/issues/169 で議論されています。

関連情報
----

* `Feature-Policy` ヘッダー
* 機能ポリシー
* 機能ポリシーの使用


Permissions-Policy: picture-in-picture - HTTP

Permissions-Policy: picture-in-picture
======================================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

HTTP の `Permissions-Policy` ヘッダーにおける `picture-in-picture` ディレクティブは、現在の文書で動画をピクチャインピクチャモードで再生することを許可するかどうかを制御します。

特に、この機能の使用をブロックするようポリシーが定義されていた場合、 `HTMLVideoElement.requestPictureInPicture()` を呼び出すと `DOMException` 例外が `SecurityError` 型で発生します。

構文
--

```http
Permissions-Policy: picture-in-picture=<allowlist>;
```

`<allowlist>`

この機能を使用する権限が与えられているオリジンのリスト。詳しくは `Permissions-Policy` > 構文を参照してください。

既定のポリシー
-------

`picture-in-picture` の既定の許可リストは `*` です。

仕様書
---

| Specification |
| --- |
| Picture-in-Picture # permissions-policy |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Permissions-Policy` ヘッダー
* 権限ポリシー


Firefox ユーザーエージェント文字列リファレンス - HTTP

Firefox ユーザーエージェント文字列リファレンス
===========================

この文書では、 Firefox 4 以降および Gecko 2.0 以降ベースのアプリケーションで用いられるユーザーエージェント文字列について説明します。 Gecko 2.0 での変更点について詳しくは Final User Agent string for Firefox 4E (ブログ記事) をご覧ください。ユーザーエージェントの検出に関する文書や Hacks の投稿もご覧ください。

全般的な形式
------

Firefox 自身のユーザーエージェント文字列は、 4 つの部分に分けられます。

`Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion`

* `Mozilla/5.0` はブラウザーが Mozilla 互換であることを示す一般的なトークンであり、今日のほとんどすべてのブラウザーで共通しています。
* `platform` は、ブラウザーが動作しているネイティブプラットフォーム (例: Windows、Mac、Linux、または Android)、およびモバイル端末であるかを表します。 Firefox OS 端末は単に "`Mobile`" となり、ウェブがプラットフォームです。 `platform` は "; " (セミコロン) 区切りの複数トークンで構成されることがある点に注意してください。詳細や例については後述します。
* `rv:geckoversion` は、Gecko のリリースバージョンを示します (例: "`17.0`")。最近のブラウザーでは `geckoversion` と `firefoxversion` が同じです。
* `Gecko/geckotrail` は、ブラウザーが Gecko ベースであることを示します。
* デスクトップ版では、 `geckotrail` は固定文字列 "`20100101`" です。
* `Firefox/firefoxversion` はブラウザーが Firefox であることを示すとともに、バージョン番号を提供します (例: "`17.0`")。
* モバイル版は Firefox 10 より、 `geckotrail` と `firefoxversion` が同じです。

**メモ:** Gecko ベースのブラウザー向けに推奨する推定法（機能の検出を行う代わりにブラウザーエンジンの推定を行わ**なければならない**場合）は、 "`Gecko`" および "`rv:`" の文字列が存在するかの検出です。これは、他ブラウザーの一部に "`like Gecko`" というトークンが含まれるためです。

Gecko ベースの他製品では下記 2 つの形式のいずれかであり、各トークンの意味は以下に記載した内容を除いて同じです。

`Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail appname/appversion`
`Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion appname/appversion`

* `appname/appversion` は、アプリケーションの名称とバージョンを示します。例えばこれは、"`Camino/2.1.1`" や "`SeaMonkey/2.7.1`" となります。
* `Firefox/firefoxversion` は、Firefox を想定するウェブサイトと最大限の互換性を得るために一部の Gecko ベースのブラウザーが組み入れる場合がある、省略可能な互換性トークンです。 `firefoxversion` は一般的に、導入した Gecko のバージョンに相当する Firefox のリリースを表します。一部の Gecko ベースのブラウザーはこのトークンを使用しないかもしれません。従って、推定の際は Firefox ではなく Gecko を探してください!

Firefox 4 と Gecko 2.0 以前では、拡張機能やプラグインがユーザーエージェント部を持つことが可能でしたが、Firefox バグ 581008 以降はそれが不可能になりました。

モバイルおよびタブレットの標示
---------------

UA 文字列で `platform` の部分は、 Firefox が携帯電話サイズまたはタブレットの機器で動作しているかを示します。携帯電話フォームファクターの機器で Firefox が動作している場合は、 `Mobile;` というトークンが UA 文字列で `platform` の部分に現れます。一方タブレット機器で Firefox が動作している場合は、 `Tablet;` というトークンが UA 文字列で `platform` の部分に現れます。
```

Mozilla/5.0 (Android 4.4; Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Mozilla/5.0 (Android 4.4; Tablet; rv:41.0) Gecko/41.0 Firefox/41.0
```

**メモ:** のバージョン番号は重要ではありません。バージョン番号を基に判断しないでください。

ある機器のフォームファクター向けのコンテンツを決めるために好ましい方法は、CSS メディアクエリーの使用です。しかし機器のフォームファクターの対象コンテンツを決めるために UA 推定を用いている場合は、携帯電話フォームファクターでは **Mobi** (Opera Mobile が "Mobile" ではなく "Mobi" と表記するため) を検索するようにして、"Android" と機器のフォームファクターに対応関連があるとは**考えない**ようにしてください。そうすることで Firefox を他の携帯電話やタブレットのオペレーティングシステム向けに公開した場合や Android がラップトップ PC に使用された場合でもコードが動作します。また、タッチ対応端末を検出するには "Mobi" や "Tablet" を検索するのではなく、タッチ機能を検出してください。タブレットではないタッチ対応端末の場合もあります。

**メモ:** Firefox OS 端末では、オペレーティングシステムを示す部分がない形式となります (例: "Mozilla/5.0 (Mobile; rv:15.0) Gecko/15.0 Firefox/15.0")。ウェブがプラットフォームです。

Windows
-------

Windows のユーザーエージェントには以下のバリエーションがあり、その中で *x.y* は Windows NT のバージョンを表します（例えば、Windows NT 6.1）。

Linux
-----

Linux には多様なプラットフォームが存在します。 Linux ディストリビューションによってはユーザーエージェント文字列を変更する拡張機能を含んでいることがあります。いくつかの一般的な例は以下のとおりです。

| Linux のバージョン | Gecko のユーザーエージェント文字列 |
| --- | --- |
| Linux デスクトップ (i686 CPU) | Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20100101 Firefox/10.0 |
| Linux デスクトップ (x86\_64 CPU) | Mozilla/5.0 (X11; Linux x86\_64; rv:10.0) Gecko/20100101 Firefox/10.0 |

Android (バージョン 40 以下)
---------------------

| フォームファクター | Gecko のユーザーエージェント文字列 |
| --- | --- |
| 携帯電話 | Mozilla/5.0 (Android; Mobile; rv:40.0) Gecko/40.0 Firefox/40.0 |
| タブレット | Mozilla/5.0 (Android; Tablet; rv:40.0) Gecko/40.0 Firefox/40.0 |

Android (バージョン 41 以降)
---------------------

バージョン 41 以降の Android 版 Firefox では platform トークンに Android のバージョンが含まれます。相互運用性向上のため、 Android 4 以前のバージョンでブラウザーが動作している場合は 4.4 と出力します。 Android のバージョン 4 以降では実際のバージョン番号が出力されます。なお、Gecko エンジンはすべての Android のバージョンに対して同じ機能を提供しています。

| フォームファクター | Gecko のユーザーエージェント文字列 |
| --- | --- |
| 携帯電話 | Mozilla/5.0 (Android 4.4; Mobile; rv:41.0) Gecko/41.0 Firefox/41.0 |
| タブレット | Mozilla/5.0 (Android 4.4; Tablet; rv:41.0) Gecko/41.0 Firefox/41.0 |

Focus for Android
-----------------

バージョン 1 から、 Focus は Android WebView によって実現されており、以下のユーザーエージェント文字列書式を使用しています。
```

Mozilla/5.0 (Linux; <Android Version> <Build Tag etc.>) AppleWebKit/<WebKit Rev> (KHTML, like Gecko) Version/4.0 Focus/<focusversion> Chrome/<Chrome Rev> Mobile Safari/<WebKit Rev>
```

タブレット版の WebView はモバイル版のミラーですが、 `Mobile` トークンを含みません。

バージョン 6 から、ユーザーが GeckoView ベースの Focus for Android を隠し設定で選択できるようになっています。 Gecko との互換性を示すため、 GeckoView の UA 文字列を使用します。

| Focus のバージョン (レンダリングエンジン) | ユーザーエージェント文字列 |
| --- | --- |
| 1.0 (WebView Mobile) | Mozilla/5.0 (Linux; Android 7.0) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Focus/1.0 Chrome/59.0.3029.83 Mobile Safari/537.36 |
| 1.0 (WebView Tablet) | Mozilla/5.0 (Linux; Android 7.0) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Focus/1.0 Chrome/59.0.3029.83 Safari/537.36 |
| 6.0 (GeckoView) | Mozilla/5.0 (Android 7.0; Mobile; rv:62.0) Gecko/62.0 Firefox/62.0 |

Klar for Android
----------------

バージョン 4.1 以降、 Klar for Android は Focus for Android と同じ UA 文字列を使用します。バージョン 4.1 より前では、 *Klar/<version>* *product/version* のトークンを送っていました。.

| Klar のバージョン (レンダリングエンジン) | ユーザーエージェント文字列 |
| --- | --- |
| 1.0 (WebView) | Mozilla/5.0 (Linux; Android 7.0) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Klar/1.0 Chrome/58.0.3029.83 Mobile Safari/537.36 |
| 4.1+ (WebView) | Mozilla/5.0 (Linux; Android 7.0) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Focus/4.1 Chrome/62.0.3029.83 Mobile Safari/537.36 |
| 6.0+ (GeckoView) | Mozilla/5.0 (Android 7.0; Mobile; rv:62.0) Gecko/62.0 Firefox/62.0 |

Focus for iOS
-------------

Focus for iOS のバージョン 7 は、以下の形式のユーザーエージェント文字列を使用します。
```

Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/7.0.4 Mobile/16B91 Safari/605.1.15
```

メモ: このユーザーエージェント文字列は iPhone XR シミュレーターから取得したもので、端末によって異なるかもしれません。

Firefox for Fire TV
-------------------

Firefox for Fire TV のバージョン 3 (およびそれ以前もおそらく) は、以下の書式のユーザーエージェント文字列を使用します。
```

Mozilla/5.0 (Linux; <Android version>) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Focus/<firefoxversion> Chrome/<Chrome Rev> Safari/<WebKit Rev>
```

| Firefox TV のバージョン | ユーザーエージェント文字列 |
| --- | --- |
| v3.0 | Mozilla/5.0 (Linux; Android 7.1.2) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Focus/3.0 Chrome/59.0.3017.125 Safari/537.36 |

Firefox for Echo Show
---------------------

Firefox for Echo Show はバージョン 1.1 から、以下の書式のユーザーエージェント文字列を使用しています。
```

Mozilla/5.0 (Linux; <Android version>) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Focus/<firefoxversion> Chrome/<Chrome Rev> Safari/<WebKit Rev>
```

| Firefox for Echo Show のバージョン | ユーザーエージェント文字列 |
| --- | --- |
| v1.1 | Mozilla/5.0 (Linux; Android 5.1.1) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Focus/1.1 Chrome/59.0.3017.125 Safari/537.36 |

Firefox OS
----------

| フォームファクター | Gecko のユーザーエージェント文字列 |
| --- | --- |
| 携帯電話 | Mozilla/5.0 (Mobile; rv:26.0) Gecko/26.0 Firefox/26.0 |
| タブレット | Mozilla/5.0 (Tablet; rv:26.0) Gecko/26.0 Firefox/26.0 |
| テレビ | Mozilla/5.0 (TV; rv:44.0) Gecko/44.0 Firefox/44.0 |
| 端末特有 | Mozilla/5.0 (Mobile; ***nnnn;*** rv:26.0) Gecko/26.0 Firefox/26.0 |

### 端末特有のユーザーエージェント文字列

Mozilla は**強く反対**していますが、残念ながら一部の機器メーカーは端末の ID を表すトークンを、ユーザーエージェント文字列に含めています。これに当てはまる場合は Firefox OS のユーザーエージェント文字列が、前出の表で示したように端末特有の文字列になります。 ***nnnn;*** が、端末を示すメーカーのコードです (ガイドラインもご覧ください)。私たちは "**NexusOne;**", "**ZTEOpen;**", "**Open C;**" などを見つけました（空白を入れることも非推奨です）。ユーザーエージェント検出のロジックを支援するためにこの情報を提供しますが、 Mozilla はユーザーエージェント文字列で端末 ID を検出することを推奨しません。

ユーザーエージェント文字列に端末 ID を持つ場合を含むすべてのモバイル端末を検出するであろう、JavaScript の正規表現は以下のとおりです。

```js
/mobi/i;
```

`i` は大文字・小文字を区別しないことを示し、 `mobi` がすべてのモバイルブラウザーに一致します。

### Firefox OS のバージョン番号

Firefox OS のバージョン番号は UA 文字列に含まれませんが、 UA 文字列には Gecko のバージョンからバージョン情報を特定することができます。

| Firefox OS のバージョン番号 | Gecko のバージョン番号 |
| --- | --- |
| 1.0.1 | 18.0 |
| 1.1 | 18.1 |
| 1.2 | 26.0 |
| 1.3 | 28.0 |
| 1.4 | 30.0 |
| 2.0 | 32.0 |
| 2.1 | 34.0 |
| 2.2 | 37 |
| 2.5 | 44 |

**メモ:** この対応関係は Mercurial リポジトリー名から容易に判断できます。`mozilla-b2g` で始まるリポジトリーが Firefox OS のリリースリポジトリーであり、Firefox OS と Gecko の両バージョンがその名前に含まれています。

Firefox OS のバージョン番号は 4 つの数字があります: `X.X.X.Y`. 始めの 2 つの数字は Mozilla の製品チームが管理しており、新機能を伴うバージョンを表します（例: v1.1、1.2 など）。3 番目の番号はセキュリティ更新向けの定期的なバージョンの識別 (最大 6 週間ごと) として増えていきます。4 番目の番号は OEM が管理します。

関連情報
----

* クロスブラウザー対応のための UA 文字列の推定における推奨事項
* window.navigator.userAgent


CSP: block-all-mixed-content - HTTP

CSP: block-all-mixed-content
============================

**非推奨:** この機能は非推奨になりました。まだ対応しているブラウザーがあるかもしれませんが、すでに関連するウェブ標準から削除されているか、削除の手続き中であるか、互換性のためだけに残されている可能性があります。使用を避け、できれば既存のコードは更新してください。このページの下部にある互換性一覧表を見て判断してください。この機能は突然動作しなくなる可能性があることに注意してください。

**警告:** このディレクティブは、仕様上、廃止されたものとしてマークされています。すべての混合コンテンツは、自動アップグレードできない場合、ブロックされるようになりました。

HTTP の `Content-Security-Policy` (CSP) **`block-all-mixed-content`** ディレクティブは、ページが HTTPS を使用しているときに HTTP で資産を読み込むことを防ぎます。

能動的および受動的の両方を含む、すべての混合コンテンツリソースのリクエストがブロックされます。これは `<iframe>` の文書にも適用され、ページ全体で混合コンテンツがないことを保証します。

**メモ:** `upgrade-insecure-requests` ディレクティブが `block-all-mixed-content` の前に評価されます。
 前者が設定されていれば、後者は何もしません。どちらかのディレクティブを設定してください。 HTTP にリダイレクトした後で HTTPS を強制することができない古いブラウザーで HTTPS を強制させたくない限り、両方の効果はありません。

構文
--

```http
Content-Security-Policy: block-all-mixed-content;
```

例
-

```http
Content-Security-Policy: block-all-mixed-content;

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">
```

 より詳細なレベルで http 資産を無効にするには、個々のディレクティブに `https:` を設定することもできます。
 安全ではない HTTP の画像を許可しないようにするには次のようにします。

```http
Content-Security-Policy: img-src https:
```

仕様書
---

 現在のどの仕様にも属していません。
 古い仕様書である Mixed Content Level 1 で定義されていたものです。

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Content-Security-Policy`
* `upgrade-insecure-requests`
* 混合コンテンツ