If-Range - HTTP

If-Range
========

**`If-Range`** HTTP リクエストヘッダはレンジリクエストを条件付きにします：条件が満たされれば、レンジリクエストが発行され、サーバは適切なボディを持つ `206` `Partial Content` 回答を返します。条件が満たされていない場合、 `200` の状態でリソース全体が返送されます。

このヘッダは `Last-Modified` バリデータ、または `ETag` のいずれかで使用できますが、両方では使用できません。

最も一般的な使用事例は、最後のフラグメントが受信されてから格納されたリソースが変更されていないことを保証するために、ダウンロードを再開することです。

|  |  |
| --- | --- |
| ヘッダータイプ | Request header |
| Forbidden header name | いいえ |

構文
--
```

If-Range: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
If-Range: <etag>
```

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

<etag>

リクエストされたリソースを表すエンティティータグです。これは `"675af34563dc-tr34"` のようにダブルクオートに囲まれた ASCII の文字列で、弱い比較アルゴリズムを使うことを示すために `W/` がプレフィックスとしてつくことがあります。

<day-name>

One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).

<day>

2 digit day number, e.g. "04" or "23".

<month>

One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case sensitive).

<year>

4 digit year number, e.g. "1990" or "2016".

<hour>

2 digit hour number, e.g. "09" or "23".

<minute>

2 digit minute number, e.g. "04" or "59".

<second>

2 digit second number, e.g. "04" or "59".

`GMT`

Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.

例
-
```

If-Range: Wed, 21 Oct 2015 07:28:00 GMT
```

仕様
--

| 仕様書 | タイトル |
| --- | --- |
| RFC 7233, セクション 3.2: If-Range | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |

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

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

関連情報
----

* `ETag`
* `Last-Modified`
* `If-Modified-Since`
* `If-Unmodified-Since`
* `If-Match`
* `If-None-Match`
* `206` `Partial Content`
* HTTP Conditional Requests


Content-Encoding - HTTP

Content-Encoding
================

**`Content-Encoding`** は表現ヘッダーで、表現（メッセージの内容）に適用されているエンコード方式とその順番を保持しています。
 これによって受信者は、元の内容の形式を取得するために、その表現をデコードする方法を知ることができます。
 コンテンツのエンコード方式は、主に元のメディア形式に関する情報を失うことなくメッセージデータを圧縮するために使用されます。

元のメディア/コンテンツの形式は `Content-Type` ヘッダーで指定し、 `Content-Encoding` はデータの表現、つまり「コード化形式」に適用されることに注意してください。元のメディアが何らかの方法でエンコードされている場合（zip ファイルなど）、この情報は `Content-Encoding` ヘッダーには含まれません。

可能な限りデータを圧縮してこのフィールドを使用することを推奨しますが、 JPEG 画像などの一部のリソースは、すでに圧縮されています。時には、さらに圧縮をしても長さが短縮されないどころか、かえって長くなることもあります。

|  |  |
| --- | --- |
| ヘッダー種別 | 表現ヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--

```http
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br

// 複数の場合、適用された順序
Content-Encoding: deflate, gzip
```

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

`gzip`

Lempel-Ziv coding (LZ77) を使用し、32 ビットの CRC が付いた形式です。これは UNIX の *gzip* プログラムの独自形式です。 HTTP/1.1 標準は、このエンコード方式に対応するサーバーは、互換性の面から `x-gzip` もエイリアスとして解釈するよう推奨しています。

`compress`

Lempel-Ziv-Welch (LZW) アルゴリズムを使用した形式です。この値の名前は、このアルゴリズムを実装している UNIX の *compress* プログラムから取られました。このエンコード方式は、特許問題（2003 年に期限切れ）を一因として、 compress プログラムが多くの UNIX ディストリビューションから削除されたのと同様に、現在では多くのブラウザーから削除されています。

`deflate`

zlib 構造（RFC 1950 で定義）の deflate 圧縮アルゴリズム（RFC 1951) で定義）を使用します。

`br`
Non-standard

Brotli アルゴリズムを使用した形式です。

例
-

### gzip での圧縮

クライアント側では、送信で使用してほしい圧縮方式のリストを HTTP リクエストで示すことができます。 `Accept-Encoding` ヘッダーを使用して、コンテンツのエンコード方式の交渉が行われます。

```http
Accept-Encoding: gzip, deflate
```

サーバーは使用した方式を、 `Content-Encoding` レスポンスヘッダーで応答します。

```http
Content-Encoding: gzip
```

なお、サーバーはどの圧縮方式も使用することを義務づけられていません。圧縮はサーバー設定や使用しているサーバーモジュールに強く依存します。

仕様書
---

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

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

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

関連情報
----

* `Accept-Encoding`
* `Transfer-Encoding`


From - HTTP

From
====

**`From`** リクエストヘッダーには、リクエスト元の user agent を制御する人のユーザーの E メールアドレスが含まれています。

ロボティックユーザーエージェント (クローラなど) を使用している場合は、`From` ヘッダーを送信する必要があります。ロボットが過度の不要なリクエストや無効なリクエストを送信しているなど、サーバーに問題が発生した場合は連絡できます。

**警告:** アクセス制御または認証には `From` ヘッダーを使用しないでください。

|  |  |
| --- | --- |
| ヘッダータイプ | Request header |
| Forbidden header name | いいえ |

構文
--
```

From: <email>
```

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

<email>

マシンに使用可能な電子メールアドレス。

例
-
```

From: webmaster@example.org
```

仕様
--

| 仕様書 | タイトル |
| --- | --- |
| RFC 7231, セクション 5.5.1: From | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

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

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

関連情報
----

* `Host`


Content-Type - HTTP

Content-Type
============

**`Content-Type`** 表現ヘッダーは、リソースのメディア種別を示すために使用します。

レスポンスにおいては、 `Content-Type` ヘッダーはクライアントに返されたコンテンツの実際の種類を伝えます。ブラウザーは MIME を推定し、このヘッダーの値に従わないこともあります。 `X-Content-Type-Options` を `nosniff` に設定すると、この動作を防ぐことができます。

リクエストにおいては (`POST` または `PUT` などで)、クライアントがサーバーに実際に送ったデータの種類を伝えます。

|  |  |
| --- | --- |
| ヘッダー種別 | 表現ヘッダー |
| 禁止ヘッダー名 | いいえ |
| CORS セーフリストレスポンスヘッダー | はい |
| CORS セーフリストリクエストヘッダー | はい。 *CORS 危険リクエストヘッダーバイト*である 0x00-0x1F (0x09 (HT) を除く)、`"():<>?@[\]{}`、0x7F (DEL) を値に含むことができないという制限付きです。また、 MIME タイプの解釈値 (引数を除いたもの) が `application/x-www-form-urlencoded`, `multipart/form-data`, `text/plain` の何れかである必要があります。 |

構文
--
```

Content-Type: text/html; charset=UTF-8
Content-Type: multipart/form-data; boundary=something
```

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

`media-type`

リソースやデータの MIME タイプです。

charset

標準の文字エンコーディングです。

boundary

マルチパートの本文では `boundary` ディレクティブが必要で、これはメールゲートウェイを通過しても大丈夫だと知られている文字の中から 1～70 文字で構成され、ホワイトスペースで終了しないものです。これはメッセージの複数パートの境界を囲むために使用します。ふつう、ヘッダーの境界は 2 本のダッシュで始まり、最後の境界には最後にも 2 本のダッシュが入ります。

例
-

### HTML フォームにおける `Content-Type`

HTML フォームを送信する `POST` リクエストでは、リクエストの `Content-Type` は `<form>` 要素の `enctype` 属性で指定します。

```html
<form action="/" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="some text" />
  <input type="file" name="myFile" />
  <button type="submit">Submit</button>
</form>
```

このリクエストはこのように見えます (ここではあまり重要でないヘッダーは省略しています)。
```

POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575

-----------------------------974767299852498929531610575
Content-Disposition: form-data; name="description"

some text
-----------------------------974767299852498929531610575
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain

(content of the uploaded file foo.txt)
-----------------------------974767299852498929531610575--
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # status.206 |
| HTTP Semantics # field.content-type |

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

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

関連情報
----

* `Accept`
* `Content-Disposition`
* `206` Partial Content
* `X-Content-Type-Options`


Set-Cookie - HTTP

Set-Cookie
==========

**`Set-Cookie`** は HTTP のレスポンスヘッダーで、サーバーからユーザーエージェントへクッキーを送信するために使用され、ユーザーエージェントはそれを後でサーバーに送り返すことができます。
 複数のクッキーを送信するには、複数の **`Set-Cookie`** ヘッダーを同じレスポンスで送信してください。

**警告:** ブラウザーは、フロントエンドの JavaScript コードが `Set-Cookie` ヘッダーにアクセスするのをブロックします。これは、 Fetch 仕様が `Set-Cookie` を禁止レスポンスヘッダー名として定義しているためで、フロントエンドコードに公開されるすべてのレスポンスからフィルタリングしなければなりません。

詳細については、HTTP クッキーのガイドを参照してください。

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

構文
--
```

Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
Set-Cookie: <cookie-name>=<cookie-value>; Secure
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure

// 以下の例のように、複数のディレクティブも利用することができます。
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
```

属性
--

`<cookie-name>=<cookie-value>`

 クッキーの名前とその値を定義します。
 クッキーの定義は、名前と値の組で始まります。

`<cookie-name>` は任意の US-ASCII 文字の集合を含むことができますが、制御文字、空白、タブは例外です。
 `( ) < > @ , ; : \ " / [ ] ? = { }` のような区切り文字も含むことができません。

`<cookie-value>` は任意で二重引用符で囲むことができ、制御文字、ホワイトスペース、二重引用符、カンマ、セミコロン、バックスラッシュを除くすべての US-ASCII 文字が利用できます。

**エンコーディング**: 多くの実装ではクッキーの値に URL エンコーディングを施します。
 しかし、 RFC の仕様書で要求されているわけではありません。
 URL エンコーディングを使用すると、 `<cookie-value>` に許可される文字の要件を満たすのに役立ちます。

**メモ:** 一部の `<cookie-name>` は特殊な意味を持ちます。

**`__Secure-` の接頭辞**: `__Secure-` (接頭辞にダッシュを含む) で始まるクッキー名は、 `secure` フラグを設定することが必要で、安全なページ (HTTPS) でなければなりません。

**`__Host-` の接頭辞**: `__Host-` で始まるクッキー名は、 `secure` フラグを設定し、安全なページ (HTTPS) から読み込む必要があり、ドメインを指定することができず (従って、サブドメインにも送られません)、パスが `/` である必要があります。

`Expires=<date>` 省略可

 クッキーの有効期限を示す、 HTTP の日時タイムスタンプです。
 詳細な書式は `Date` を参照してください。

 指定されなかった場合は、クッキーは**セッションクッキー**の寿命になります。
 セッションはクライアントが終了したときに終了するので、セッションクッキーはその時点で削除されます。

**警告:** 多くのウェブブラウザーはセッション復元と呼ばれる機能を持っており、これによってすべてのタブを保存し、次回ブラウザーを起動したときに復元することができます。ブラウザーを実際には閉じていないかのように、セッションクッキーも復元されます。

有効期限が設定されていた場合、期限はサーバーではなく、クッキーが設定されているクライアントからの相対時刻で設定されます。

`Max-Age=<number>` 省略可

クッキーの期限までの秒数を示します。ゼロまたは負の数値の場合は、クッキーは直ちに期限切れになります。 `Expires` および `Max-Age` の両方が設定されていたら、 `Max-Age` が優先されます。

`Domain=<domain-value>` 省略可

クッキーを送信する先のホストを定義します。

指定されなかった場合は、この属性は既定で現在の文書の URL におけるホスト名の部分になり、サブドメインを含みません。

初期の仕様書とは逆に、ドメイン名の前のドット (`.example.com`) は無視されます。

複数のホストやドメインの値を指定することは*できません*が、ドメイン*が*指定された場合、すべてのサブドメインが常に含まれます。

`Path=<path-value>` 省略可

リクエストの URL に含む必要があるパスを示します。含まれていないと、ブラウザーは `Cookie` ヘッダーを送信しません。

スラッシュ (`/`) の文字はディレクトリー区切りとして解釈され、サブディレクトリーも同様に一致します。例えば、 `Path=/docs` である場合、

* `/docs`, `/docs/`, `/docs/Web/`, `/docs/Web/HTTP` のリクエストパスはすべて一致します)。
* `/`, `/docsets`, `/fr/docs` のリクエストパスは一致しません。

`Secure` 省略可

クッキーが、リクエストが SSL と HTTPS プロトコルを使用して行われた場合にのみサーバーに送信されることを示します。ただし HTTP クッキーは、例えば情報が暗号化されないなど、安全ではない仕組みを継承しているので、機密な情報や敏感な情報を転送したり格納したりしないようにしてください。

**メモ:** Secure を設定すると、Cookie 内の機密情報 (セッションキー、ログイン情報など) へのアクセスがすべて防げると思わないでください。この属性を持つクッキーは、クライアントのハードディスクにアクセスしたり、 `HttpOnly` クッキー属性が設定されていない場合に JavaScript からアクセスしたりすることで、依然として読み取り/変更が可能です。

安全でないサイト (`http:`) では、 `Secure` 属性のクッキーを設定できません (Chrome 52、Firefox 52 以降)。Firefox では、`Secure` 属性が localhost で設定されている場合、https: の要件は無視されます (Firefox 75以降)。

`HttpOnly` 省略可

 JavaScript が `Document.cookie` プロパティなどを介してこのクッキーにアクセスすることを禁止します。
 なお、 `HttpOnly` で作成されたクッキーは、JavaScript で開始されたリクエスト、例えば、 `XMLHttpRequest.send()` や `fetch()` と共に送信されます。
 これにより、クロスサイトスクリプティング (XSS) 攻撃を軽減します。

`SameSite=<samesite-value>` 省略可

クロスサイトリクエストでクッキーを送信するかどうかを制御し、クロスサイトリクエストフォージェリ攻撃 (CSRF) に対するある程度の防御を提供します。

使用可能な属性値は以下の通りです。

`Strict`

 ブラウザーが同一サイトのリクエストに対してのみクッキーを送信することを意味します。つまり、クッキーを設定したのと同じサイトから発信されるリクエストのことです。
 リクエストが異なるドメインやスキームから発信された場合（同じドメインであっても）、 `SameSite=Strict` 属性のクッキーは送信されません。

`Lax`

 画像やフレームを読み込むリクエストのようなクロスサイトリクエストではクッキーを送信しませんが、ユーザーが外部サイトから元のサイトに移動するとき（例えば、リンクをたどるとき）には送信されることを意味します。
 これは `SameSite` 属性が指定されていない場合の既定の動作です。

`None`

 ブラウザーがクロスサイトと同一サイトの両方のリクエストでクッキーを送信することを意味します。
 この値を設定する際には、 `Secure` 属性も設定する必要があります。 `SameSite=None; Secure` のようにします。

**メモ:** SameSite クッキー (en-US)に関する標準は、最近次のように改訂されました。

1. `SameSite` が指定されなかった場合のクッキー送信の動作は `SameSite=Lax` になりました。以前は既定ではすべてのリクエストに対して送信されていました。
2. `SameSite=None` が指定されたクッキーには `Secure` 属性も指定されるようになりました（すなわち、安全なコンテキストが必要になりました）。
3. 同じドメインのクッキーが異なるスキーム（`http:` または `https:`）で送信された場合、同じサイトからのクッキーとは見なされなくなりました。

下記のオプションは新しい動作を含んでいます。特定のブラウザーの実装についての情報は、ブラウザーの互換性 (en-US)一覧表 （"`SameSite`: Defaults to `Lax`" と "`SameSite`: Secure context required" の行）を参照してください。

例
-

### セッションクッキー

**セッションクッキー**は、クライアントが終了したときに削除されます。 `Expires` や `Max-Age` ディレクティブを指定しないと、クッキーはセッションクッキーになります。
```

Set-Cookie: sessionId=38afes7a8
```

### 永続的クッキー

**永続的なクッキー**は、特定の日付 (`Expires`) または特定の期間 (`Max-Age`) 後に削除され、クライアントが閉じられたときには削除されません。
```

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
```

```
Set-Cookie: id=a3fWa; Max-Age=2592000
```

### 不正なドメイン

オリジンのサーバーを含まないドメインに所属するクッキーは、ユーザーエージェントが拒否します。

次のクッキーを `originalcompany.com` でホスティングされたサーバーから設定しようとすると拒否されます。
```

Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk
```

提供するドメインのサブドメインへのクッキーは拒否されます。

以下のクッキーを `example.com` でホスティングされたサーバーから設定しようとすると拒否されます。
```

Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com
```

### クッキーの接頭辞

`__Secure-` または `__Host-` の接頭辞が付いたクッキー名は、安全な (HTTPS の) オリジンから `secure` ディレクティブを設定した場合のみ使用することができます。

加えて、 `__Host-` の接頭辞が付いたクッキーは、 `/` (ホストの任意のパスという意味) を持つ必要があり、 `Domain` ディレクティブを持つことができません。

**警告:** クッキーの接頭辞を実装していないクライアントでは、これらの保証を受けることができず、クッキーは常に受け入れられます。
```

// どちらも安全な (HTTPS の) オリジンから受け入れられます
Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
Set-Cookie: __Host-ID=123; Secure; Path=/

// Secure ディレクティブが無いため、拒否されます
Set-Cookie: __Secure-id=1

// Path=/ ディレクティブが無いため、拒否されます
Set-Cookie: __Host-id=1; Secure

// Domain を設定したため、拒否されます
Set-Cookie: __Host-id=1; Secure; Path=/; Domain=example.com
```

仕様書
---

| Specification |
| --- |
| HTTP State Management Mechanism # sane-set-cookie |

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

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

### 互換性のメモ

* Chrome 52 および Firefox 52 以降、セキュリティで保護されていないサイト (`http:`) では、 `Secure` ディレクティブ付きでクッキーを設定することはできなくなりました。
関連情報
----

* HTTP クッキー
* `Cookie`
* `Document.cookie`
* SameSite cookies (en-US)


Accept-CH-Lifetime - HTTP

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

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

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

**`Accept-CH-Lifetime`** ヘッダーは、クライアントが後続のリクエストにどのクライアントヒントのヘッダーを含める必要があるかを指定する `Accept-CH` ヘッダーの値の永続性を指定するためにサーバーによって設定されます。

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

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

構文
--
```

Accept-CH-Lifetime: <age>
```

例
-
```

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

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

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

関連情報
----

* `Accept-CH`
* `Vary`


Content-Length - HTTP

Content-Length
==============

**`Content-Length`** エンティティヘッダーは、受信者に送信されるエンティティ本文の長さをバイト単位で示します。

|  |  |
| --- | --- |
| ヘッダー種別 | エンティティヘッダー |
| 禁止ヘッダー名 | はい |

構文
--
```

Content-Length: <length>
```

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

<length>

オクテット列の長さの 10 進数表記。

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7230, セクション 3.3.2: Content-Length | 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.

関連情報
----

* `Transfer-Encoding`


Access-Control-Allow-Methods - HTTP

Access-Control-Allow-Methods
============================

**`Access-Control-Allow-Methods`** レスポンスヘッダーは、プリフライトリクエストのレスポンスの中で、リソースにアクセスするときに利用できる 1 つまたは複数のメソッドを指定します。

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

構文
--
```

Access-Control-Allow-Methods: <method>, <method>, ...
Access-Control-Allow-Methods: *
```

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

<method>

許可された HTTP リクエストメソッドのコンマ区切りリスト。

`*` (ワイルドカード)

"`*`" の値は、資格情報のないリクエスト (HTTP Cookie や HTTP 認証情報のないリクエスト) の特殊なワイルドカードです。資格情報付きのリクエストでは、特別な意味のない "`*`" というメソッド名として扱われます。

例
-
```

Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Methods: *
```

仕様書
---

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-methods |

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

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

関連情報
----

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Headers`
* `Access-Control-Request-Method`


Tk - HTTP

Tk
==

**`Tk`** 応答ヘッダーは、該当する要求に適用される追跡状態を示します。

|  |  |
| --- | --- |
| ヘッダー種別 | 応答ヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Tk: !  (工事中)
Tk: ?  (動的)
Tk: G  (ゲートウェイ又は複数の関係者)
Tk: N  (追跡なし)
Tk: T  (追跡中)
Tk: C  (同意済みの追跡中)
Tk: P  (潜在的な同意)
Tk: D  (DNT を無視)
Tk: U  (更新済み)
```

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

!

工事中。オリジンのサーバーは現在の追跡状態の通信のテストを行っています。

?

動的。オリジンのサーバーは追跡状態を特定するために追加情報が必要です。

G

ゲートウェイ又は複数の関係者。サーバーは、複数の関係者が関わる交換のゲートウェイとして機能しています。

N

追跡なし。

T

追跡中。

C

同意済みの追跡中。オリジンのサーバーは、このユーザー、ユーザーエージェント、機器が追跡に関する事前の同意を得ていると考えています。

P

潜在的な同意。オリジンのサーバーは、このユーザー、ユーザーエージェント、機器を追跡するための事前の同意をリアルタイムで受け取ったかどうかを知りませんが、そのような同意が確定するまで `DNT:1` データを使用または共有しないことを約束します。 そのような同意が受領されていない `DNT:1` データを 48 時間以内に削除または永久に匿名化することを約束します。

D

DNT を無視。オリジンのサーバーは、要求しているユーザーエージェントから受信した追跡設定を尊重することができないか、またはそうしたくない。

U

更新済み。この要求により、このユーザー、ユーザーエージェント、機器に適用可能な追跡状態が変更される可能性があります。

例
-

追跡しないように宣言しているリソースへの `Tk` ヘッダーは次のようになります。
```

Tk: N
```

仕様書
---

#### No specification found

No specification data found for `http.headers.Tk`.
Check for problems with this page or contribute a missing `spec_url` to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

ブラウザーの対応
--------

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

関連情報
----

* `DNT` ヘッダー
* `Navigator.doNotTrack`


Pragma - HTTP

Pragma
======

**`Pragma`** は HTTP/1.0 の一般ヘッダーで、実装固有のヘッダーであり、リクエスト - レスポンスチェーンに沿ってさまざまな影響を与えます。 `Cache-Control` HTTP/1.1 ヘッダーがまだ存在しない HTTP/1.0 キャッシュとの下位互換性のために使用されます。

**メモ:** `Pragma` は HTTP レスポンスには指定されていないため、リクエストの `Cache-Control` ヘッダーフィールドが省略されている場合は `Cache-Control: no-cache` と同じように動作しますが、一般的な HTTP/1.1 `Cache-Control` ヘッダーの代わりに信頼できるものではありません。`Pragma` は HTTP/1.0 クライアントとの下位互換性のためにのみ使用してください。

|  |  |
| --- | --- |
| ヘッダー種別 | 一般ヘッダー,
 ただしレスポンスの振る舞いは指定されていないため、実装固有です。
  |
| 禁止ヘッダー名 | いいえ |
| CORS セーフリストレスポンスヘッダー | はい |

構文
--
```

Pragma: no-cache
```

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

no-cache

`Cache-Control: no-cache` と同じです。キャッシュされたコピーを解放する前に、キャッシュが検証のためにオリジンサーバーにリクエストを送信するようにします。

例
-
```

Pragma: no-cache
```

仕様書
---

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

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

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

関連情報
----

* `Cache-Control`
* `Expires`


Upgrade - HTTP

Upgrade
=======

HTTP 1.1 (専用) の `Upgrade` ヘッダーは、すでに確立されたクライアントとサーバー間のプロトコルを、異なるプロトコルに（同じ転送プロトコルを通じて）アップグレードするために使用することができます。例えば、クライアントが HTTP 1.1 から HTTP 2.0 へ、または HTTP や HTTPS のコネクションを WebSocket へアップグレードすることができます。

**警告:** HTTP/2 は明確にこの仕組み／ヘッダーを使用することを禁止しています。これは HTTP/1.1 専用です。

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

概要
--

`Upgrade` ヘッダーフィールドは、クライアントがサーバーに対して、優先度の降順に列挙したプロトコルのうちの 1 つ（以上）に切り替えるよう促すために使用することができます。

例えば、クライアントが下記のような `GET` リクエストを送信する際に、切り替えるべき推奨プロトコル（この場合は "example/1" および "foo/2"）を列挙することができます。
```

GET /index.html HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: example/1, foo/2
```

**メモ:** `Connection: upgrade` は `Upgrade` を送る際に設定する必要があります。

サーバーはどのような理由であろうと、無視することができます。その場合、サーバーは `Upgrade` ヘッダーが送信されていないかのように応答する必要があります（たとえば `200 OK`）。

サーバーが接続をアップグレードすることを決めた場合、次のようにする必要があります。

1. `101 Switching Protocols` レスポンスステータスを返し、そこに切り替え先のプロトコルを示した `Upgrade` ヘッダーを入れる必要があります。例えば次のようにします。

```http
HTTP/1.1 101 Switching Protocols
Upgrade: foo/2
Connection: Upgrade
```

2. 元のリクエストに*新しいプロトコルを使用して*レスポンスを送ります（サーバーは、元のリクエストを完了できるプロトコルにのみ切り替えることができます）。

サーバーは、 `426` `Upgrade Required` レスポンスの一部としてこのヘッダーを送信することもあります。これはサーバーが現在のプロトコルではリクエストを実行しないが、プロトコルが変更されれば実行するかもしれないことを示すものです。クライアントは上記の手順でプロトコルの変更を要求することができます。

より詳細な情報と例は、プロトコルのアップグレードメカニズム (en-US)に記載されています。

構文
--
```

Connection: upgrade
Upgrade: protocol_name[/protocol_version]
```

メモ:

* `Connection` ヘッダーで種別を `upgrade` に指定することが、 `Upgrade` ヘッダーを送信する上で*常に*必要です（前述の通り）。
* プロトコルはカンマ区切りで、優先度順に列挙してください。プロトコルのバージョンは省略可能です。例を挙げます。
```

Connection: upgrade
Upgrade: a_protocol/1, example ,another_protocol/2.2
```

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

カンマ区切りのプロトコル名のリスト（それぞれに省略可能でプロトコルバージョン）

プロトコル名に省略可能で（"/" で区切って）バージョンをつけたものを 1 つ以上。プロトコルは優先度の降順で列挙します。

例
-
```

Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
```

```
Connection: Upgrade
Upgrade: websocket
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # field.upgrade |
| HTTP Semantics # status.426 |
| HTTP/2 # informational-responses |

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

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

関連情報
----

* プロトコルのアップグレードメカニズム (en-US)
* `101` `Switching Protocol`
* `426` `Upgrade Required`
* `Connection`


Content-Language - HTTP

Content-Language
================

**`Content-Language`** は エンティティヘッダー で、ユーザが自分の好みの言語に応じて区別できるように、オーディエンス向けの言語を記述するために使用されます。

たとえば、"`Content-Language: de-DE`" が設定されている場合、その文書はドイツ語のスピーカーを対象としてます (ただし、文書がドイツ語で記述されていることを示すわけではありません。 たとえば、ドイツ語スピーカーのための語学コースの一部としての英語が書かれているかもしれません。文書が記述されている言語を示す場合は、代わりに `lang` 属性を使用します)。

`Content-Language` が指定されていない場合、既定ではコンテンツがすべての言語のオーディエンスを対象としています。`Content-Language` ヘッダーをテキスト形式の文書やさまざまな種類のメディアに適用するだけでなく、複数の言語タグを使用することもできます。

|  |  |
| --- | --- |
| ヘッダー種別 | エンティティヘッダー |
| 禁止ヘッダー名 | いいえ |
| CORS セーフリストレスポンスヘッダー | はい |
| CORS セーフリストリクエストヘッダー |
 はい、値を `0-9`, `A-Z`, `a-z`, 空白、
 `*,-.;=` のみに限定するという追加の制限があります。
  |

構文
--
```

Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA
```

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

`language-tag`

複数の言語タグはカンマで区切られています。各言語タグはハイフン文字 ("`-`", `%x2D`) で区切られた、大文字小文字を区別しない 1 つ以上のサブタグのシーケンスです。ほとんどの場合、言語タグは関連する言語の広いファミリを識別するプライマリ言語サブタグ (たとえば、"`en`" = 英語) で構成され、オプションとして、その言語の範囲を絞り込むか狭める一連のサブタグ ("`en-CA`" = カナダで伝達される英語の種類) が続きます。

**メモ:** 言語タグは、使用される言語コードの ISO 639 規格 (ISO 639-1 のコードリストであることが多い) に依存する、RFC 5646 でフォーマットが定義されています。

例
-

### 文書が書かれている言語を示す

グローバル `lang` 属性は、HTML 要素全体またはその一部の言語を示すために HTML 要素で使用されます。

```html
<html lang="de"></html>
```

文書の言語を記述するために、このような meta 要素を以下のように使用**しないで**ください。

```html
<!-- /!\ This is bad practice -->
<meta http-equiv="content-language" content="de" />
```

### リソースのターゲットオーディエンスを示す

`Content-Language` ヘッダーは、**ページの対象読者**を指定するために使用され、複数の言語であることを示すことができます。
```

Content-Language: de, en
```

仕様書
---

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

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

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

関連情報
----

* `Accept-Language`
* HTTP headers, meta elements and language information
* HTML の `lang` 属性


Cross-Origin-Resource-Policy - HTTP

Cross-Origin-Resource-Policy
============================

**メモ:** Chrome のバグのため、 Cross-Origin-Resource-Policy を設定すると PDF のレンダリングが中断され、一部の PDF の最初のページを超えて読むことができなくなることがあります。 Firefox のバグのため、Cross-Origin-Resource-Policy を設定すると、状況によっては一部のリソース（PDF など）のダウンロードができなくなることがあります。本番環境では、このヘッダーの使用に注意してください。

HTTP の **`Cross-Origin-Resource-Policy`** レスポンスヘッダーは、ブラウザーが指定されたリソースへの no-cors のクロスオリジン/クロスサイトのリクエストをブロックするという要望を伝えます。

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

構文
--
```

Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
```

例
-

以下のレスポンスヘッダーにより、互換性のあるユーザーエージェントはクロスオリジンの no-cors リクエストを許可しなくなります。
```

Cross-Origin-Resource-Policy: same-origin
```

その他の例は、 https://resourcepolicy.fyi/ を参照してください。

仕様書
---

| Specification |
| --- |
| Fetch Standard # cross-origin-resource-policy-header |

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

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

関連情報
----

* Cross-Origin Resource Policy (CORP) の説明


Content-Disposition - HTTP

Content-Disposition
===================

通常の HTTP レスポンスにおける **`Content-Disposition`** レスポンスヘッダーは、コンテンツがブラウザーで*インライン*で表示されることを求められているか、つまり、ウェブページとして表示するか、ウェブページの一部として表示するか、ダウンロードしてローカルに保存する*添付ファイル*とするかを示します。

本文が `multipart/form-data` である場合、 **`Content-Disposition`** ヘッダーは、マルチパートを構成する各サブパートに付与され、そのフィールドに関する情報を示します。サブパートは`Content-Type` ヘッダーで定義された *boundary* によって区切られます。マルチパートの本文自体に付与した場合、 `Content-Disposition` は何の意味も持ちません。

`Content-Disposition` ヘッダーはメールにおける MIME メッセージのより広い用途で定義されたものですが、 HTTP のフォームと `POST` リクエストに利用可能な引数は一部だけです。ヘッダーの値である `form-data` と、省略可能なディレクティブ `name` と `filename` のみが HTTP の用途で使用することができます。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー
 (本文の場合)一般ヘッダー
 (マルチパート本文の一部の場合)
  |
| 禁止ヘッダー名 | いいえ |

構文
--

### 本文に適用するレスポンスヘッダーとして

この用法では、`inline` (既定値。ウェブページの一部として、またはウェブページとして表示可能であることを示します)、もしくは `attachment` (ダウンロードすべきであることを示します。多くのブラウザーは `filename` 引数の値を使い、「名前を付けて保存」ダイアログを表示します) を最初の引数して指定します。
```

Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="filename.jpg"
```

### マルチパート本文で使うヘッダーとして

この用法では最初の引数は常に `form-data` です。追加のパラメーターは大文字小文字を区別せず、 `'='` 記号に続けてクォートされた文字列で引数を指定します。複数の引数はセミコロン (`';'`) で区切ります。
```

Content-Disposition: form-data
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"
```

### ディレクティブ

`name`

 このサブパートの内容が参照するフォームの HTML フィールドの名前を含む文字列が続きます。同じフィールド内の複数のファイルを扱う場合 (例えば、 `<input type="file">` 要素の `multiple` 属性)、同じ名前を持つ複数のサブパートが存在することがあります。
 `name` の値が `'_charset_'` という値である場合は、その部分が HTML フィールドではなく、明示的な文字セット情報のない部分に使用される既定の文字セットであることを示します。

`filename`

送信された元のファイル名を含む文字列を指定します。このファイル名は常に任意であり、アプリケーションで使用する際は注意が必要です。例えばパス情報を取り除いたり、サーバーのファイルシステムに合わせてファイル名の変換を行ったりすべきです。この引数は、ほとんどの情報を提供します。 `Content-Disposition: attachment` と組み合わせて使用すると、ユーザーに表示される「名前を付けて保存」ダイアログの既定のファイル名として使用されます。

`filename*`

引数の `filename` と `filename*` の違いは、 `filename*` が RFC 5987 で定義されているエンコーディングを使用するという点のみです。単一のヘッダーフィールドの値に `filename` と `filename*` の両方が存在する場合は、両方が解釈できる場合、 `filename*` が `filename` よりも優先されます。

例
-

「ファイル名を付けて保存」ダイアログを起動するレスポンスです。
```

200 OK
Content-Type: text/html; charset=utf-8
Content-Disposition: attachment; filename="cool.html"
Content-Length: 21

<HTML>Save me!</HTML>
```

このサンプル HTML ファイルは、ブラウザーに表示されるのではなく、通常のダウンロードとして保存されます。ほとんどのブラウザーは、 (既定で) `cool.html` というファイル名で保存することを提案します。

`multipart/form-data` 形式を使用して送信された HTML フォームの例で、 `Content-Disposition` ヘッダーを使用したものです。
```

POST /test.html HTTP/1.1
Host: example.org
Content-Type: multipart/form-data;boundary="boundary"

--boundary
Content-Disposition: form-data; name="field1"

value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example.txt"

value2
--boundary--
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7578 | Returning Values from Forms: multipart/form-data |
| RFC 6266 | Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) |
| RFC 2183 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field |

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

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

互換性の注意
------

* Firefox 5 は、 `Content-Disposition` レスポンスヘッダーで `filename` と `filename*` の両引数が提供されている場合、より効果的に処理します。 `filename` 引数が先にあった場合でも、提供されたすべての名前を調べ、利用可能な場合は `filename*` 引数を使用します。以前は、先に一致した引数がより適切な名前が使われていませんでした。 Firefox バグ 588781 を参照してください。
関連情報
----

* HTML Forms
* `Content-Type`: マルチパート本文の境界を定義
* `FormData` インターフェイス: `XMLHttpRequest` API でフォームデータを操作するために使用


Connection - HTTP

Connection
==========

**`Connection`** 一般ヘッダーは、現在のトランザクションが完了したあとも、ネットワーク接続を開いたままにするかどうかを制御します。もし送信された値が `keep-alive` であった場合は、接続が維持されて閉じられなくなり、同一のサーバーに送るべき後続のリクエストで再利用されます。

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

標準のホップバイホップヘッダー (`Keep-Alive`、`Transfer-Encoding`、`TE` (en-US)、`Connection`、`Trailer` (en-US)、`Upgrade`、`Proxy-Authorization`、`Proxy-Authenticate`) を除き、メッセージで使用しているホップバイホップヘッダーは `Connection` ヘッダーに列挙する必要があります。したがって、これを解釈する最初のプロキシーはそれを消費する必要があり、その先に転送してはいけません。標準のホップバイホップヘッダーも列挙する必要があります。

|  |  |
| --- | --- |
| ヘッダー種別 | リクエストヘッダー、レスポンスヘッダー |
| 禁止ヘッダー名 | yes |

構文
--
```

Connection: keep-alive
Connection: close
```

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

`close`

クライアントあるいはサーバーが接続を閉じる意思があることを示します。これは HTTP/1.0 リクエストの既定の動作です。

カンマ区切りの HTTP ヘッダーのリスト [通常は `keep-alive` のみ]

クライアントが接続を開いておく意思があることを示します。接続の維持は HTTP/1.1 の既定の動作です。ヘッダー名のリストは、介在する最初の非透過プロキシーやキャッシュが削除するヘッダーの名前です。これらのヘッダーは最終的な宛先ノードではなく、送信者と最初のエンティティ間の接続の定義に使用します。

仕様書
---

| Specification |
| --- |
| HTTP Semantics # field.connection |

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

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


Access-Control-Allow-Credentials - HTTP

Access-Control-Allow-Credentials
================================

**`Access-Control-Allow-Credentials`** レスポンスヘッダーは、リクエストの資格情報モード (`Request.credentials`) が `include` である場合に、レスポンスをフロントエンドの JavaScript コードに公開するかどうかをブラウザーに指示します。

証明書の資格情報モード (`Request.credentials`) が `include` である場合、レスポンスがフロントエンドの JavaScript コードに公開されるのは `Access-Control-Allow-Credentials` の値が `true` である場合のみです。

資格情報は Cookie、認証ヘッダー、または TLS クライアント証明書です。

プリフライトリクエストに対するレスポンスの一部として使用された場合は、実際のリクエストが資格情報を使用して行われた可能性があるかどうかを示します。なお、単純な `GET` リクエストはプリフライトが行われないので、資格情報を持つリソースに対してリクエストが行われた場合、このヘッダーがリソースとともに返されない場合、レスポンスはブラウザーによって無視されウェブコンテンツは返されません。

`Access-Control-Allow-Credentials` ヘッダーは、 `XMLHttpRequest.withCredentials` プロパティまたは Fetch API の `Request()` コンストラクター内の `credentials` オプションとの組み合わせで動作します。資格情報を含む CORS リクエストにおいて、ブラウザーがレスポンスを JavaScript コードに公開するようにするためには、サーバー側 (`Access-Control-Allow-Credentials` ヘッダーを使用) とクライアント側 (XHR, Fetch Ajax リクエストの資格情報モードの設定) の両方が、資格情報を含むことを承認しなければなりません。

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

構文
--
```

Access-Control-Allow-Credentials: true
```

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

true

このヘッダーの唯一の有効な値は `true` です (大文字小文字を区別します)。資格情報を必要としない場合は、 (値を false に設定するのではなく) このヘッダーを完全に省略します。

例
-

資格情報の許可:
```

Access-Control-Allow-Credentials: true
```

XHR を資格情報付きで使用:

```js
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://example.com/", true);
xhr.withCredentials = true;
xhr.send(null);
```

Fetch を資格情報付きで使用:

```js
fetch(url, {
  credentials: "include",
});
```

仕様書
---

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-credentials |

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

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

関連情報
----

* `XMLHttpRequest.withCredentials`
* `Request()`


Access-Control-Allow-Origin - HTTP

Access-Control-Allow-Origin
===========================

**`Access-Control-Allow-Origin`** レスポンスヘッダーは、指定されたオリジンからのリクエストを行うコードでレスポンスが共有できるかどうかを示します。

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

構文
--
```

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Origin: null
```

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

`*`

*資格情報がない*リクエストでは、リテラル値 "`*`" をワイルドカードとして指定することができます。この値はブラウザーに、すべてのオリジンからのリクエストコードにリソースへのアクセスを許可するように指示します。資格情報がある時にワイルドカードを使用すると、エラーを返します。

`<origin>`

オリジンを指定します。1 つのオリジンだけを指定することができます。サーバーが複数のオリジンからのクライアントに対応している場合、リクエストを行った特定のクライアントのオリジンを返さなければなりません。

`null`

オリジンを "null" に指定します。

**メモ:** `null` は使用しないでください。「`Access-Control-Allow-Origin: "null"` を返すと安全であるように見えますが、リソースのオリジンが階層的ではないスキーム (例えば `data:` や `file:`) を使用しており、サンドボックス化された文書はすべて "null" となるように定義されています。多くのユーザーエージェントはそのような文書に `Access-Control-Allow-Origin: "null"` ヘッダーが付いているとアクセスを許可するので、あらゆるオリジンが "null" を持つ悪意のある文書を生成することができます。したがって、 ACAO ヘッダーで "null" 値を使用することは避けるべきです。」

例
-

あらゆるオリジンからのコードにリソースへのアクセスを許可するようブラウザーに指示するレスポンスには、次のような行を含めてください。
```

Access-Control-Allow-Origin: *
```

`https://developer.mozilla.org` のオリジンからリクエストを行うコードに対して、リソースへのアクセスを許可するようブラウザーに指示するレスポンスには、次のような行を含めてください。
```

Access-Control-Allow-Origin: https://developer.mozilla.org
```

`Access-Control-Allow-Origin` の値で複数のオリジンに許可を限定するには、サーバー側で `Origin` リクエストヘッダーの値をチェックし、許可するオリジンのリストと比較して、 `Origin` の値がリスト中にあれば、 `Access-Control-Allow-Origin` の値に `Origin` と同じ値を設定してください。

### CORS とキャッシング

`Access-Control-Allow-Origin` の値が ("`*`" ワイルドカードではなく) 具体的なオリジンであるレスポンスをサーバーが送信する場合、レスポンスには `Vary` レスポンスヘッダーに `Origin` という値を設定して、 `Origin` リクエストヘッダーの値によって値が変わることをブラウザーに対して示してください。
```

Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin
```

仕様書
---

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-origin |

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

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

関連情報
----

* `Origin`
* `Vary`
* Cross-Origin Resource Sharing (CORS)
* `Cross-Origin-Resource-Policy`


Expect - HTTP

Expect
======

HTTP の **`Expect`** リクエストヘッダーは、リクエストを正しく扱うためにサーバーが実行する必要があると期待されていることを示します。

仕様書で定義されている期待は `Expect: 100-continue` だけで、サーバーが応答するべきことは以下の通りです。

* ヘッダーに含まれている情報で、直ちに成功とする条件を満たしているのであれば `100`。
* 期待に沿うことができなければ `417` (Expectation Failed)。それ以外であれば他の 4xx 状態になります。

例えば、サーバーは `Content-Length` が長すぎるとリクエストを拒否する可能性があります。

`Expect` ヘッダーを送信するブラウザーはあまりありませんが、 cURL のような一部の他のクライアントは既定で送信します。

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

構文
--

現在は "100-continue" 以外の期待は定義されていません。
```

Expect: 100-continue
```

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

100-continue

クライアントがこの要求で (おそらく大規模な) メッセージ本文を送信しようとしていることを受信者に通知し、 `100` (Continue) 暫定応答を受信することを期待します。

例
-

### 巨大なメッセージ本文

クライアントは Expect ヘッダーで要求を送信し、メッセージ本文を送信する前にサーバーが応答するのを待ちます。
```

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue
```

サーバーはリクエストヘッダーをチェックし、 `100` (Continue) 応答を返信して、クライアントにメッセージ本体を送信するよう指示するか、又は期待に沿わない場合は、 `417` (Expectation Failed) 状態になります。

仕様書
---

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

ブラウザーの対応
--------

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

関連情報
----

* `417` `Expectation Failed`
* `100` `Continue`


Content-Range - HTTP

Content-Range
=============

**`Content-Range`** レスポンスの HTTP ヘッダーは、全体のメッセージのどこにメッセージが含まれているかを示します。

|  |  |
| --- | --- |
| ヘッダータイプ | Response header |
| Forbidden header name | いいえ |
| CORS-safelisted response-header | いいえ |

構文
--
```

Content-Range: <unit> <range-start>-<range-end>/<size>
Content-Range: <unit> <range-start>-<range-end>/*
Content-Range: <unit> */<size>
```

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

<unit>

範囲を指定する単位。これは通常 `bytes` です。

<range-start>

指定された単位の整数で、リクエスト範囲の開始を示します。

<range-end>

リクエストされた範囲の終わりを示す指定された単位の整数。

<size>

ドキュメントの合計サイズ (または未知の場合は `'*'` )。

例
-
```

Content-Range: bytes 200-1000/67589
```

仕様
--

| 仕様書 | タイトル |
| --- | --- |
| RFC 7233, セクション 4.2: Content-Range | 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`
* `Content-Type`
* `206` `Partial Content`
* `416` `Range Not Satisfiable`


SourceMap - HTTP

SourceMap
=========

**`SourceMap`** HTTP レスポンスヘッダーは、生成されたコードをソースマップにリンクし、ブラウザーが元のソースを再構成し、再構成されたオリジナルをデバッガに提示できるようにします。

|  |  |
| --- | --- |
| ヘッダータイプ | Response header |
| Forbidden header name | いいえ |

構文
--
```

SourceMap: <url>
X-SourceMap: <url> (deprecated)
```

### ディレクティブ

`<url>`

(リクエスト URL に対する) 相対パスまたはソースマップファイルを指す絶対 URL

例
-
```

SourceMap: /path/to/file.js.map
```

仕様
--

| 仕様書 | タイトル |
| --- | --- |
| Draft document | Source Map Revision 3 Proposal |

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

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

関連情報
----

* Firefox Developer Tools: using a source map


If-Unmodified-Since - HTTP

If-Unmodified-Since
===================

HTTP の **`If-Unmodified-Since`** リクエストヘッダーは、リクエストを条件付きにします。サーバーはリソースが指定された日時以降に変更されていない場合のみ、要求されたリソースを返信したり、 `POST` などの安全ではないメソッドをの場合はそれを受け付けたりします。リソースが指定された日時以降に変更されていた場合は、レスポンスは`412` (Precondition Failed) エラーになります。

一般的な使用例は 2 つあります。

* `POST` のような安全ではないメソッドとの組み合わせで、一部のウィキで行われているような楽観的並行性制御を実装するために利用することができます。この場合、元の文書を受け取った後で、保存されている文書が変更されていると、編集が拒否されます。
* `If-Range` ヘッダー付きの範囲付きリクエストとの組み合わせで、断片をリクエストする際に文書が変更されていないことを確認するために使用することができます。

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

構文
--
```

If-Unmodified-Since: <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 における時刻は常にグリニッジ標準時で表され、ローカル時刻になることはありません。

例
-
```

If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7232, セクション 3.4: If-Unmodified-Since | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

ブラウザーの対応
--------

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

関連情報
----

* `Last-Modified`
* `If-Modified-Since`
* `If-Match`
* `If-None-Match`
* `If-Range`
* `412` `Precondition Failed`


Access-Control-Allow-Headers - HTTP

Access-Control-Allow-Headers
============================

**`Access-Control-Allow-Headers`** レスポンスヘッダーは、 `Access-Control-Request-Headers` を含むプリフライトリクエストへのレスポンスで、実際のリクエストの間に使用できる HTTP ヘッダーを示すために使用されます。

このヘッダーは、リクエストに `Access-Control-Request-Headers` ヘッダーが含まれている時に必要です。

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

構文
--
```

Access-Control-Allow-Headers: <header-name>[, <header-name>]*
Access-Control-Allow-Headers: *
```

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

<header-name>

対応しているリクエストヘッダーの名前です。ヘッダーはコンマで区切って、任意の数のリストにすることができます。

`*` (ワイルドカード)

"`*`" の値は、資格情報のないリクエスト (HTTP Cookie や HTTP の認証情報のないリクエスト) の特殊なワイルドカード値です。認証情報付きのリクエストでは、特別な意味のない "`*`" というヘッダー名として扱われます。なお、 `Authorization` ヘッダーはワイルドカードで表すことができず、常に明示的に列挙する必要があります。

CORS セーフリストリクエストヘッダー, `Accept`, `Accept-Language`, `Content-Language`, `Content-Type` は常に許可されており、このヘッダーで列挙する必要はありません。しかし、これらのヘッダーを `Access-Control-Allow-Headers` に列挙することで、これらのヘッダーでも追加の制約の適用を回避することができることに注意してください。

例
-

### カスタムヘッダー

`Access-Control-Allow-Headers` ヘッダーがどのように見えるかの例です。*CORS セーフリストリクエストヘッダー*に加えて、 `X-Custom-Header` という名前のカスタムヘッダーがサーバーへの CORS リクエストで対応しています。
```

Access-Control-Allow-Headers: X-Custom-Header
```

### 複数のヘッダー

この例は、複数のヘッダーへの対応を指定するときの `Access-Control-Allow-Headers` を示しています。
```

Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests
```

### 追加の制約の回避

CORS セーフリストリクエストヘッダーは常に許可され、ふつうは `Access-Control-Allow-Headers` に列挙する必要はありませんが、それでも列挙すれば追加の制約が適用されることを回避できます。
```

Access-Control-Allow-Headers: Accept
```

### プリフライトリクエストの例

`Access-Control-Allow-Headers` を伴うプリフライトリクエストの例を見てみましょう。

#### リクエスト

最初にリクエストです。プリフライトリクエストは `OPTIONS` リクエストで、次のように 3 つのプリフライトリクエストヘッダー、 `Access-Control-Request-Method`, `Access-Control-Request-Headers`, `Origin` の組み合わせを含みます。
```

OPTIONS /resource/foo
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: origin, x-requested-with
Origin: https://foo.bar.org
```

#### レスポンス

CORS リクエストが `DELETE` メソッドを使うことをサーバーが許可した場合、 `Access-Control-Allow-Methods` レスポンスヘッダーで返信し、そこでは `DELETE` とともに対応するその他のメソッドのリストが含まれます。
```

HTTP/1.1 200 OK
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: https://foo.bar.org
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400
```

要求されたメソッドに対応していない場合は、サーバーはエラーを返します。

仕様書
---

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-headers |

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

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

関連情報
----

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Methods`
* `Access-Control-Request-Headers`


Access-Control-Expose-Headers - HTTP

Access-Control-Expose-Headers
=============================

**`Access-Control-Expose-Headers`** レスポンスヘッダーは、レスポンスの一部としてどのヘッダーを公開するかを、その名前を列挙して示します。

既定では、公開される CORS セーフリストレスポンスヘッダーは 7 つだけです。

* `Cache-Control`
* `Content-Language`
* `Content-Length`
* `Content-Type`
* `Expires`
* `Last-Modified`
* `Pragma`

クライアントが他のヘッダーにアクセスできるようにするには、 `Access-Control-Expose-Headers` ヘッダーを使用してヘッダーを列挙する必要があります。

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

構文
--
```

Access-Control-Expose-Headers: <header-name>, <header-name>, ...
Access-Control-Expose-Headers: *
```

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

<header-name>

ゼロ個以上のヘッダー名の一覧で、 CORS セーフリストレスポンスヘッダーに含まれないものであり、リソースが使用する可能性があり、公開される可能性があるものです。

`*` (ワイルドカード)

 "`*`" の値は、資格情報のないリクエスト (HTTP Cookie や HTTP の資格情報のないリクエスト) の特殊なワイルドカード値です。資格情報付きのリクエストでは、特別な意味のない "`*`" というヘッダー名として扱われます。
 なお、 `Authorization` ヘッダーはワイルドカードで表すことができず、常に明示的に列挙する必要があります。

例
-

CORS セーフリストにないレスポンスヘッダーを公開するには、次のように指定します。
```

Access-Control-Expose-Headers: Content-Length
```

`X-Kuma-Revision` のようなカスタムヘッダーをさらに公開するには、複数のヘッダーをカンマで区切って指定することができます。
```

Access-Control-Expose-Headers: Content-Length, X-Kuma-Revision
```

資格情報のないリクエストでは、ワイルドカード値を使うこともできます。
```

Access-Control-Expose-Headers: *
```

但し、 `Authorization` ヘッダーはワイルドカードの対象にならないので、明示的に列挙する必要があります。
```

Access-Control-Expose-Headers: *, Authorization
```

仕様書
---

| Specification |
| --- |
| Fetch Standard # http-access-control-expose-headers |

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

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

関連情報
----

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Origin`


Server-Timing - HTTP

Server-Timing
=============

**`Server-Timing`** ヘッダーは、指定されたリクエスト－レスポンスのサイクルについての 1 つ以上のメトリックと説明を通信します。ユーザーのブラウザーの開発ツール内や、 `PerformanceServerTiming` (en-US) インターフェイス内で、任意のバックエンドサーバーのタイミングメトリック (データベースの読み書き、 CPU 時間、ファイルシステムアクセス、など) を表面化させるために使用します。

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

構文
--

`Server-Timing` ヘッダーの構文では、さまざまな方法でメトリックを通信することができます。サーバーメトリック名のみ、メトリックと値、メトリックと値と説明、メトリックと説明などです。

仕様書では、 HTTP のオーバーヘッドを最小化するために、名前と説明を (略語を使用したり可能な限り値を省略したりして) できるだけ短くすることを推奨しています。
```

// 単一の値のないメトリック
Server-Timing: missedCache

// 単一のメトリックと値
Server-Timing: cpu;dur=2.4

// 単一のメトリックと説明と値
Server-Timing: cache;desc="Cache Read";dur=23.2

// 二つのメトリックと値
Server-Timing: db;dur=53, app;dur=47.2

// Server-Timing as trailer
Trailer: Server-Timing
--- response body ---
Server-Timing: total;dur=123.4
```

プライバシーとセキュリティ
-------------

`Server-Timing` ヘッダーは微妙なアプリケーションやインフラの情報を公開する可能性があります。どのメトリックが、いつ、サーバー側の誰に返されるかを制御することを検討してください。例えば、メトリックを認証されたユーザーのみに見せ、一般には見せないようにすることもできます。

PerformanceServerTiming インターフェイス
--------------------------------

`Server-Timing` ヘッダーのメトリックがブラウザーの開発者ツールに現れるのに加えて、 `PerformanceServerTiming` (en-US) インターフェイスでツールが JavaScript から自動的にメトリックを収集し処理することができます。このインターフェイスは同じオリジンに制約されていますが、 `Timing-Allow-Origin` ヘッダーを使用することで、サーバーメトリックにアクセスすることができるドメインを指定することができます。このインターフェイスはブラウザーによっては、安全なコンテキスト (HTTPS) のみでしか利用できません。

仕様書
---

| Specification |
| --- |
| Server Timing # the-server-timing-header-field |

ブラウザーの対応
--------

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

関連情報
----

* `PerformanceServerTiming` (en-US)


Range - HTTP

Range
=====

**`Range`** は HTTP のリクエストヘッダーで、サーバーが返すべき文書の部分を示します。1 つの `Range` ヘッダーで複数の部分を一度にリクエストすることができ、サーバーはこれらの範囲をマルチパートの文書で返すことができます。サーバーが範囲を送り返す場合、サーバーはレスポンスに `206` `Partial Content` を使用します。範囲が無効な場合、サーバは `416` `Range Not Satisfiable` エラーを返します。サーバーは `Range` ヘッダ－を無視して、文書全体を `200` のステータスコードで返すこともできます。

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

構文
--
```

Range: <unit>=<range-start>-
Range: <unit>=<range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=-<suffix-length>
```

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

<unit>

範囲を指定する単位です。これはふつう `bytes` です。

<range-start>

整数値で、リクエストする範囲の先頭を指定した単位で示します。

<range-end>

整数値で、リクエストする範囲の末尾を指定した単位で示します。この値は省略可能で、省略時は文書の末尾が範囲の末尾として扱われます。

<suffix-length>

整数値で、返す長さを位でファイルの末尾からの個数を示します。

例
-

ファイルから 3 つの範囲をリクエストします。
```

Range: bytes=200-1000, 2000-6576, 19000-
```

ファイルの先頭の 500 バイトと末尾の 500 バイトをリクエストします。範囲が重複した場合はサーバーがリクエストを拒否することがあります。
```

Range: bytes=0-499, -500
```

仕様書
---

| 仕様書 | 状態 |
| --- | --- |
| RFC 7233, セクション 3.1: Range | 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`
* `Content-Range`
* `Content-Type`
* `206` `Partial Content`
* `416` `Range Not Satisfiable`


Access-Control-Request-Method - HTTP

Access-Control-Request-Method
=============================

**`Access-Control-Request-Method`** リクエストヘッダーは、プリフライトリクエストを発行する際にブラウザーが使用し、実際のリクエストが行われた際にどの HTTP メソッドが使用されるかをサーバーに知らせるために使用されます。プリフライトリクエストは常に OPTIONS であり、実際のリクエストとは同じメソッドを使用しないため、このヘッダーが必要です。

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

構文
--
```

Access-Control-Request-Method: <method>
```

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

<method>

HTTP リクエストメソッドの 1 つ。例えば `GET`, `POST`, `DELETE` など。

例
-
```

Access-Control-Request-Method: POST
```

仕様書
---

| Specification |
| --- |
| Fetch Standard # http-access-control-request-method |

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

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

関連情報
----

* `Access-Control-Request-Headers`


User-Agent - HTTP

User-Agent
==========

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

**警告:** ブラウザーによって異なるウェブページやサービスを提供することが、通常は悪い考えである理由については、ユーザーエージェント文字列を用いたブラウザーの判定をお読みください。

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

構文
--
```

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

ウェブブラウザーでよくある書式は以下のようなものです。
```

User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <extensions>
```

### ディレクティブ

`<product>`

製品の識別子です。名前または開発コードネームです。

`<product-version>`

製品のバージョン番号です。

`<comment>`

ゼロ個以上のコメントで、サブ製品情報など、より詳細な情報を含みます。

Firefox の UA 文字列
----------------

Firefox や Gecko ベースのユーザエージェント文字列の詳細については、 Firefox のユーザエージェント文字列リファレンスを参照してください。 Firefox の UA 文字列は 4 つの部分に分解されます。
```

Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion
```

1. `Mozilla/5.0` は、 Mozilla と互換性があるブラウザーであるということを示す一般的なトークンで、現在はほぼすべてのブラウザーで共通です。
2. ***platform*** は、ブラウザーが動作しているプラットフォーム (Windows, Mac, Linux, Android など)、およびモバイル端末かどうかを示します。 Firefox OS のスマートフォンはウェブプラットフォームなので、 `Mobile` だけです。 ***platform*** が複数の "; " という区切りから成っていることに留意してください。後述の詳細と例も併せてご覧ください。
3. **rv:*geckoversion*** は Gecko のリリースバージョンです ("*17.0*" など)。最近のブラウザーの ***geckoversion*** は ***firefoxversion*** と同じです。
4. ***Gecko/geckotrail*** は、ブラウザーが Gecko を基にしていることを示します。 (デスクトップでは、 ***geckotrail*** は常に `20100101` の固定文字列です。)
5. ***Firefox/firefoxversion*** は、ブラウザーが Firefox であること、またそのバージョン ("*17.0*" など) を示しています。
### 例
```

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0
```

Chrome の UA 文字列
---------------

Chrome (または Chromium/Blink ベースのエンジン) のユーザーエージェント文字列は Firefox のものと似ています。互換性のため、 `KHTML, like Gecko` や `Safari` のような文字列が追加されています。

### 例
```

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
```

Opera の UA 文字列
--------------

Opera ブラウザーも Blink エンジンに基づいているので、大部分は同じですが、 `"OPR/<version>"` を追加します。

### 例
```

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41
```

古い Presto ベースの Opera のリリースは、次のものを使用していました。
```

Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00
Opera/9.60 (Windows NT 6.0; U; en) Presto/2.1.1
```

Safari の UA 文字列
---------------

この例では、ユーザーエージェント文字列はモバイル Safari のものです。これは `Mobile` という語を含んでいます。

### 例
```

Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1
```

Internet Explorer の UA 文字列
--------------------------

### 例
```

Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)
```

クローラーやボットの UA 文字列
-----------------

### 例
```

Googlebot/2.1 (+http://www.google.com/bot.html)
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7231, セクション 5.5.3: User-Agent | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| RFC 2616, セクション 14.43: User-Agent | Hypertext Transfer Protocol — HTTP/1.1 |

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

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

関連情報
----

* User-Agent detection, history and checklist
* Firefox ユーザーエージェント文字列リファレンス
* ユーザーエージェント文字列を用いたブラウザーの判定


Proxy-Authenticate - HTTP

Proxy-Authenticate
==================

HTTP **`Proxy-Authenticate`** レスポンスヘッダーは、プロキシサーバーの背後にあるリソースへのアクセスに使用される認証メソッドを定義します。プロキシサーバーへのリクエストを認証し、プロキシサーバーがリクエストをさらに送信できるようにします。

`Proxy-Authenticate` ヘッダーは、 `407` `Proxy Authentication Required` とともに送信されます。

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

構文
--
```

Proxy-Authenticate: <type> realm=<realm>
```

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

<type>

認証方式。 一般的なタイプは "Basic" です。 IANA は認証方式のリストを管理しています。

realm=<realm>

保護された領域、つまり realm の詳細。 realm が指定されていない場合、クライアントはふつう代わりに整形されたホスト名を表示します。

例
-
```

Proxy-Authenticate: Basic

Proxy-Authenticate: Basic realm="Access to the internal site"
```

仕様書
---

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

ブラウザーの対応
--------

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

関連情報
----

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


X-Content-Type-Options - HTTP

X-Content-Type-Options
======================

**`X-Content-Type-Options`** は HTTP のレスポンスヘッダーで、 `Content-Type` ヘッダーで示された MIME タイプを変更せずに従うべきであることを示すために、サーバーによって使用されるマーカーです。これにより、MIME タイプのスニッフィングを抑止することができます。言い替えれば、 MIME タイプを意図的に設定することができます。

このヘッダーは、 Microsoft が IE 8 において、コンテンツのスニッフィングにより、実行不可能な MIME タイプを実行可能な MIME タイプに変換してしまうという事故を抑止するためのとして導入したものです。それ以来、他のブラウザーは MIME スニッフィングのアルゴリズムにそれほど積極的ではなくても、このヘッダーを導入してきました。

Firefox 72 から、 `Content-type` が提供されている場合、 MIME スニッフィングの抑止が最上位の文書にも適用されるようになりました。これにより、 HTML のウェブページが `text/html` 以外の MIME タイプで提供された場合、表示されるのではなくダウンロードされることがあります。両方のヘッダーを正しく設定してください。

サイトのセキュリティテスターは通常、このヘッダーが設定されていることを期待しています。

**メモ:** `X-Content-Type-Options` は、 `nosniff` によるリクエストブロッキングをリクエスト先が "`script`" と "`style`" の場合のみ適用します。しかし、 Cross-Origin Read Blocking (CORB) 保護を HTML, TXT, JSON, XML の各ファイル (SVG `image/svg+xml` を除く) に対して有効にすることもできます。

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

構文
--
```

X-Content-Type-Options: nosniff
```

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

`nosniff`

リクエスト先のタイプが `style` でありその MIME タイプが `text/css` ではない場合、または、タイプが `script` で MIME タイプが JavaScript の MIME タイプではない場合にリクエストをブロックします。

仕様書
---

| Specification |
| --- |
| Fetch Standard # x-content-type-options-header |

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

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

### ブラウザー固有の注意事項

* Firefox 72 は最上位の文書で `X-Content-Type-Options: nosniff` を有効にします。
関連情報
----

* `Content-Type`
* Microsoft による X-Content-Type-Options の 元の定義
* Mozilla Observatory ツールによるウェブサイトの設定 (このヘッダーを含む) の安全性とセキュリティのテスト
* Firefox における MIME 混同攻撃の緩和
* Cross-Origin Read Blocking (CORB)
* Google Docs CORB 解説書


X-Frame-Options - HTTP

X-Frame-Options
===============

**`X-Frame-Options`** は HTTP のレスポンスヘッダーで、ブラウザーがページを `<frame>`、`<iframe>`、`<embed>`、`<object>` の中に表示することを許可するかどうかを示すために使用します。サイトはコンテンツが他のサイトに埋め込まれないよう保証することで、クリックジャッキング攻撃を防ぐために使用することができます。

セキュリティが強化されるのは、ユーザーが `X-Frame-Options` に対応したブラウザーを使用して文書にアクセスした場合のみです。

**メモ:** `Content-Security-Policy` ヘッダーに `frame-ancestors` ディレクティブがあり、対応しているブラウザーにおいてこのヘッダーを置き換えています。

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

構文
--

`X-Frame-Options` には 2 つの有効なディレクティブがあります。
```

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
```

### ディレクティブ

`DENY` を指定した場合は、フレームにページを他のサイトから読み込もうとした時だけでなく、同じサイトから読み込もうとした時にも失敗します。一方、 `SAMEORIGIN` を指定した場合は、フレームの中のページを含むサイトが、ページを提供しているサイトと同じである限り、フレーム内でページを利用することができます。

`DENY`

ページをフレーム内に表示することは、それを試みているサイトが何であろうとできません。

`SAMEORIGIN`

ページは、ページ自体と同じオリジンのフレーム内でのみ表示されます。仕様書ではこのオプションを最上位、親、チェーン全体のどれに適用するかをブラウザーベンダーに任せていますが、すべての祖先が同じオリジンでない限り、利用価値がないと議論されています。 (Firefox バグ 725490 を参照)。対応の詳細はブラウザーの互換性もご覧ください。

`ALLOW-FROM uri`
非推奨

これは廃止されたディレクティブであり、最近のブラウザーでは動作しません。使用しないでください。対応している古いブラウザーでは、ページは指定されたオリジン *uri* のフレーム内でのみ表示されます。なお、以前の Firefox では `SAMEORIGIN` と同じ問題がありました。 — フレームの祖先が同じオリジンであるかどうかをチェックしません。 `Content-Security-Policy` ヘッダーには `frame-ancestors` ディレクティブがあり、代わりにこれを使用することができます。

例
-

**メモ:** X-Frame-Options を `<meta>` 要素に設定しても意味がありません。例えば、`<meta http-equiv="X-Frame-Options" content="deny">` は効果がありません。使用しないでください。以下の例にあるように、 `X-Frame-Options` は HTTP ヘッダーを通じて設定された場合のみ動作します。

### Apache の設定

Apache で X-Frame-Options ヘッダをすべてのページで送信するように設定するには、サイトの設定に以下の記述を追加してください。
```

Header always set X-Frame-Options "SAMEORIGIN"
```

Apache で `X-Frame-Options` を DENY に設定するには、サイトの設定に以下の記述を追加してください
```

Header set X-Frame-Options "DENY"
```

### nginx の設定

nginx で `X-Frame-Options` ヘッダーを送信するように設定するには、以下の記述を http、server、 location のいずれかの設定に追加してください。
```

add_header X-Frame-Options SAMEORIGIN always;
```

### IIS の設定

IIS で `X-Frame-Options` ヘッダーを送信するように設定するには、サイトの `Web.config` ファイルに以下の設定を追加してください。

```html
<system.webServer>
  ...

  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
    </customHeaders>
  </httpProtocol>

  ...
</system.webServer>
```

または、IIS マネージャーのユーザーインターフェイスを使用してこの構成を設定する方法については、マイクロソフトのサポート記事を参照してください。

### HAProxy の設定

HAProxy で `X-Frame-Options` ヘッダーを送信するように設定するには、以下の記述を front-end、listen、backend のいずれかの設定に追加してください。
```

rspadd X-Frame-Options:\ SAMEORIGIN
```

他にも、より新しいバージョンでは次のような設定ができます。
```

http-response set-header X-Frame-Options SAMEORIGIN
```

### Express の設定

Express で `X-Frame-Options` ヘッダーを送信するように設定するには、helmet を使用して frameguard でヘッダーを設定してください。以下の記述をサーバー設定に追加してください。

```js
const helmet = require("helmet");
const app = express();
app.use(helmet.frameguard({ action: "SAMEORIGIN" }));
```

他にも、直接 frameguard を使用することもできます。

```js
const frameguard = require("frameguard");
app.use(frameguard({ action: "SAMEORIGIN" }));
```

仕様書
---

| Specification |
| --- |
| HTML Standard # the-x-frame-options-header |

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

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

関連情報
----

* `Content-Security-Policy` の `frame-ancestors` ディレクティブ
* HTTP Header Field X-Frame-Options - RFC 7034
* ClickJacking Defenses - IEBlog
* Combating ClickJacking with X-Frame-Options - IEInternals


NEL - HTTP

NEL
===

HTTP の **`NEL`** レスポンスヘッダーは、ネットワークリクエストログ記録を構成するために使用されます。

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

構文
--
```

NEL: { "report_to": "name_of_reporting_group", "max_age": 12345, "include_subdomains": false, "success_fraction": 0.0, "failure_fraction": 1.0 }
```

仕様書
---

| 仕様書 |
| --- |
| Network Error Logging |

関連情報
----

* Network Error Logging (NEL) の説明


Content-Security-Policy-Report-Only - HTTP

Content-Security-Policy-Report-Only
===================================

HTTP の **`Content-Security-Policy-Report-Only`** レスポンスヘッダーにより、ウェブ開発者はポリシーの効果を監視する (ただし強制はしない) ことによりポリシーを試行することができます。これらの違反レポートは JSON の文書で構成され、 HTTP の `POST` リクエストを通して指定された URI に送信されます。

詳細については、コンテンツセキュリティポリシー (CSP) のこの記事も参照してください。

|  |  |
| --- | --- |
| ヘッダー種別 | レスポンスヘッダー |
| 禁止ヘッダー名 | いいえ |
|
 This header is not supported inside a `<meta>`
 element.
  |

構文
--
```

Content-Security-Policy-Report-Only: <policy-directive>; <policy-directive>
```

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

`Content-Security-Policy` ヘッダーのディレクティブは `Content-Security-Policy-Report-Only` にも適用することができます。

CSP の `report-uri` ディレクティブをこのヘッダーで使用しないと、このヘッダーは負荷が高く何もしない機械となります。

例
-

このヘッダーは発生した違反を報告します。これを使用して、コンテンツセキュリティポリシーを反復的に処理できます。サイトがどのように動作するのかを観察したり、違反レポートやマルウエアリダイレクトを監視したりして、 `Content-Security-Policy` ヘッダーで強制することが要求されるポリシーを選択します。
```

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
```

レポートを受信し続けながら、ポリシーの強制も行いたい場合は、 `Content-Security-Policy` ヘッダーに `report-uri` ディレクティブを指定して使用してください。
```

Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
```

違反レポートの構文
---------

レポート JSON オブジェクトには、次のデータが含まれています。

`blocked-uri`

The URI of the resource that was blocked from loading by the Content Security Policy. If the blocked URI is from a different origin than the document-uri, then the blocked URI is truncated to contain just the scheme, host, and port.

`disposition`

Either `"enforce"` or `"report"` depending on whether the `Content-Security-Policy` header or the `Content-Security-Policy-Report-Only` header is used.

`document-uri`

The URI of the document in which the violation occurred.

`effective-directive`

The directive whose enforcement caused the violation.

`original-policy`

The original policy as specified by the `Content-Security-Policy-Report-Only` HTTP header.

`referrer`

The referrer of the document in which the violation occurred.

`script-sample`

The first 40 characters of the inline script, event handler, or style that caused the violation.

`status-code`

The HTTP status code of the resource on which the global object was instantiated.

`violated-directive`

The name of the policy section that was violated.

違反レポートのサンプル
-----------

Let's consider a page located at `http://example.com/signup.html`. It uses the following policy, disallowing everything but stylesheets from `cdn.example.com`.
```

Content-Security-Policy-Report-Only: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
```

The HTML of `signup.html` looks like this:

```html
<!doctype html>
<html>
  <head>
    <title>Sign Up</title>
    <link rel="stylesheet" href="css/style.css" />
  </head>
  <body>
    ... Content ...
  </body>
</html>
```

Can you spot the violation? Stylesheets are only allowed to be loaded from `cdn.example.com`, yet the website tries to load one from its own origin (`http://example.com`). A browser capable of enforcing CSP will send the following violation report as a POST request to `http://example.com/_/csp-reports`, when the document is visited:

```js
{
  "csp-report": {
    "document-uri": "http://example.com/signup.html",
    "referrer": "",
    "blocked-uri": "http://example.com/css/style.css",
    "violated-directive": "style-src cdn.example.com",
    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /\_/csp-reports",
    "disposition": "report"
  }
}
```

As you can see, the report includes the full path to the violating resource in `blocked-uri`. This is not always the case. For example, when the `signup.html` would attempt to load CSS from `http://anothercdn.example.com/stylesheet.css`, the browser would *not* include the full path but only the origin (`http://anothercdn.example.com`). This is done to prevent leaking sensitive information about cross-origin resources.

仕様書
---

| Specification |
| --- |
| Content Security Policy Level 3 # cspro-header |

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

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

関連情報
----

* `Content-Security-Policy`
* CSP `report-uri` ディレクティブ
* WebExtensions のコンテンツセキュリティ
* Display security and privacy policies In Firefox Developer Tools


X-Forwarded-Proto - HTTP

X-Forwarded-Proto
=================

**X-Forwarded-Proto** (XFP) ヘッダーは、プロキシーまたはロードバランサーへ接続するのに使っていたクライアントのプロトコル (HTTP または HTTPS) を特定するために事実上の標準となっているヘッダーです。サーバーのアクセスログにはサーバーとロードバランサーの間で使われたプロトコルが含まれていますが、クライアントとロードバランサーの間で使用されたプロトコルは含まれていません。クライアントとロードバランサーの間で使用されたプロトコルを特定するには、 `X-Forwarded-Proto` リクエストヘッダーを使用することができます。

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

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

構文
--
```

X-Forwarded-Proto: <protocol>
```

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

<protocol>

転送されたプロトコル (http または https)

例
-
```

X-Forwarded-Proto: https
```

その他の標準外の形式:
```

# Microsoft
Front-End-Https: on

X-Forwarded-Protocol: https
X-Forwarded-Ssl: on
X-Url-Scheme: https
```

仕様書
---

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

関連情報
----

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


Retry-After - HTTP

Retry-After
===========

**`Retry-After`** レスポンス HTTP ヘッダーは、ユーザーエージェントがフォローアップリクエストを行う前にどれくらい待つべきかを示します。このヘッダーが使用される主なケースは 3 つあります。

* `503` (Service Unavailable) レスポンスで送信された場合、これはサービスが利用できないと予想される期間を示します。
* `429` (Too Many Requests) レスポンスとともに送信された場合、これは新しいリクエストを行うまでどれくらい待つかを示します。
* `301` (Moved Permanently) のようなリダイレクトレスポンスとともに送信された場合、リダイレクトされたリクエストを発行する前にユーザエージェントが待機するように要求される最小時間を示します。

|  |  |
| --- | --- |
| ヘッダータイプ | Response header |
| Forbidden header name | いいえ |

構文
--
```

Retry-After: <http-date>
Retry-After: <delay-seconds>
```

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

<http-date>

再試行する日付。HTTP の日付形式の詳細については `Date` ヘッダーを参照してください。

<delay-seconds>

レスポンスを受信してから遅延する秒数を示す負でない 10 進数の整数。

例
-

### スケジュールされたダウンタイムの処理

クライアントとサーバーの両方で `Retry-After` ヘッダーがサポートされているのは、依然として矛盾しています。ただし、Googlebot のような一部のクローラとスパイダーは `Retry-After` ヘッダーを尊重します。`503` (Service Unavailable) レスポンスと共に送信すると便利です。これにより、ダウンタイムが終了したときに検索エンジンがサイトのインデックスを作成し続けるようになります。
```

Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120
```

仕様
--

| 仕様書 | タイトル |
| --- | --- |
| RFC 7231, セクション 7.1.3: Retry-After | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

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

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

関連情報
----

* Google Webmaster blog: How to deal with planned site downtime
* `503` (Service Unavailable)
* `301` (Moved Permanently)


If-Match - HTTP

If-Match
========

HTTP の **`If-Match`** リクエストヘッダーは、リクエストを条件付きにします。 `GET` および `HEAD` メソッドの場合、リストされた `ETag` のいずれかと一致する場合にのみ、サーバーは要求されたリソースを返します。`PUT` と他の安全ではないメソッドでは、この場合のみリソースをアップロードします。

格納された `ETag` との比較では、*強い比較アルゴリズム*を使用、つまり二つのファイルがバイト単位で同一である場合のみ同一とみなします。列挙された `ETag` に `W/` 接頭辞がついている場合は弱いエンティティタグであることを示し、この比較アルゴリズムでの比較は行われません。

一般的な使用例は二つあります。

* `GET` および `HEAD` メソッドの場合は、 `Range` ヘッダーと組み合わせて使用され、リクエストされた新しい範囲が以前のものと同じリソースからのものであることを保証することができます。一致しない場合、 `416` (Range Not Satisfiable) レスポンスが返されます。
* 他のメソッド、特に `PUT` の場合は、 `If-Match` を使用して更新プログラムが失われる問題を防ぐことができます。ユーザーがアップロードしたいリソースの変更が、元のリソースがフェッチされた後に行われた別の変更を上書きしないかどうかを確認できます。リクエストを満たすことができない場合、 `412` (Precondition Failed) レスポンスが返されます。

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

構文
--
```

If-Match: <etag_value>
If-Match: <etag_value>, <etag_value>, …
```

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

<etag\_value>

リクエストされたリソースを一意に表すエンティティタグです。二重引用符の間に置かれた ASCII 文字列 (`"675af34563dc-tr34"` など) です。これらのタグは「弱い」こと、つまり、意味的にはリソースを表現しているが、バイト単位の一致を示していないことを示すために、 `W/` という接頭辞を付けることができます。しかし、 **`If-Match`** ヘッダーでは、弱いエンティティタグは一致することはありません。

`*`

アスタリスクは任意のリソースを表す特殊な値です。

例
-
```

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-Match: "67ab43", "54ed21", "7892dd"

If-Match: *
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7232, セクション 3.1: If-Match | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

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

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

関連情報
----

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-None-Match`
* `416` `Range Not Satisfiable`
* `412` `Precondition Failed`


Allow - HTTP

Allow
=====

**`Allow`** ヘッダーは、あるリソースが対応しているメソッドの一覧を示します。

このヘッダーは、サーバーが `405` `Method Not Allowed` ステータスコードで返答する場合、使用することができるリクエストメソッドを示すために送信する必要があります。 `Allow` ヘッダーが空である場合、リソースが許可しているリクエストメソッドがないことを示し、例えば指定されたリソースにおいて一時的に発生する可能性があります。

|  |  |
| --- | --- |
| ヘッダー種別 | エンティティヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Allow: <http-methods>
```

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

<http-methods>

許可されている HTTP リクエストメソッドの一覧。

例
-
```

Allow: GET, POST, HEAD
```

仕様書
---

| 仕様書 | 状態 |
| --- | --- |
| RFC 7231, セクション 7.4.1: Allow | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

関連情報
----

* `405`
* `Server`


If-Modified-Since - HTTP

If-Modified-Since
=================

HTTP の **`If-Modified-Since`** リクエストヘッダーは、リクエストを条件付にします。サーバーは最後にリソースが変更された時刻が、リクエストにより与えられた時刻より後の場合にのみ、リクエストされたリソースを `200` ステータスと共に返却します。もしリクエストにより与えられた時刻以降にリソースが変更されていなければ、レスポンスは本文を持たない `304` になります。前回のリクエストの `Last-Modified` レスポンスヘッダーは、最後にリソースが変更された時刻を含みます。 `If-Unmodified-Since` とは異なり、 `If-Modified-Since` は `GET` もしくは `HEAD` でのみ使用できます。

本ヘッダーは `If-None-Match` との組み合わせで使用された場合、サーバーが `If-None-Match` に対応していない場合を除き無視されます。

最も一般的な使用方法は `ETag` に関連付けられていない、キャッシュされたリソースを更新するために用いることです。

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

構文
--
```

If-Modified-Since: <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 における時刻は常にグリニッジ標準時で表され、ローカル時刻になることはありません。

例
-
```

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7232, セクション 3.3: If-Modified-Since | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

ブラウザーの対応
--------

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

関連情報
----

* `ETag`
* `If-Unmodified-since`
* `If-Match`
* `If-None-Match`
* `304` `Not Modified`


X-DNS-Prefetch-Control - HTTP

X-DNS-Prefetch-Control
======================

**`X-DNS-Prefetch-Control`** は HTTP のレスポンスヘッダーで、 DNS 先読み、つまりユーザーが進むことができるリンクと、画像、 CSS、 JavaScript などの文書から参照される項目の両方で、ブラウザーが事前にドメイン名の解決を実行する機能を制御します。

この先読みはバックグラウンドで行われるので、参照されている項目が必要になった時に DNS が解決されている可能性が高くなります。これによって、ユーザーがリンクをクリックしたときに遅延が短縮されます。

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

構文
--

```http
X-DNS-Prefetch-Control: on
X-DNS-Prefetch-Control: off
```

### ディレクティブ

on

DNS 先読みを有効にします。この機能に対応しているブラウザーは、このヘッダーが存在しない場合はこの動作をします。

off

DNS 先読みを無効にします。これはページのリンクを制御しない場合や、ドメインに情報漏洩させたくないと分かる場合に有用です。

解説
--

DNS リクエストは帯域で見ればとても小さいものですが、遅延は、特にモバイルネットワークではとても大きいものです。 DNS の先読みを投機的に行うと、ユーザーがリンクをクリックするときなど特定の場面の遅延を著しく短縮することができます。場合によっては、遅延を秒単位で短縮することができます。

ブラウザーによってはこの先読みの実装で、ドメイン名の解決が実際のページのコンテンツの読み込みと (直後ではなく) 並列で行うことができます。これを行うことで、遅延の大きい名前解決プロセスがコンテンツの読み込みを遅らせないようにします。

ページの読み込み時間は – 特にモバイルネットワークにおいては – この方法で著しく改善できます。画像のドメイン名がリクエストに先立って解決できれば、多数の画像を読み込むページの読み込み時間に 5% 以上の改善が見られることがあります。

### ブラウザーの先読みの構成

一般に、先読みを管理することを考える必要はありません。しかし、ユーザーは先読みを無効にしたいと思うかもしれません。 Firefox では、設定の `network.dns.disablePrefetch` を `true` にすることで実現できます。

また、既定では、埋め込みリンクのホスト名の先読みは HTTPS で読み込まれた文書では実行されません。 Firefox では、設定の `network.dns.disablePrefetchFromHTTPS` を `false` に設定することでこれを変更することができます。

例
-

### 先読みの有効化と無効化

次のように、サーバー側から `X-DNS-Prefetch-Control` ヘッダーを送信するか、個別の文書で `http-equiv` 属性を `<meta>` 要素に設定します。

```html
<meta http-equiv="x-dns-prefetch-control" content="off" />
```

逆の設定をするには `content` を "`on`" にしてください。

### 特定のホスト名の参照の強制

リンク種別を `dns-prefetch` にした `<link>` 要素に `rel` 属性を使用することで、そのホスト名を使用した特定のアンカーを提供せずに、特定のホスト名を強制的に検索することができます。

```html
<link rel="dns-prefetch" href="https://www.mozilla.org/contribute/" />
```

この例では、 "www.mozilla.org/contribute" というドメイン名が事前に解決されます。

同様に、 link 要素は完全な URL を提供せずにホスト名を解決するために使用することができますが、ホスト名の前に 2 つのスラッシュを付けた場合だけです。

```html
<link rel="dns-prefetch" href="//www.mozilla.org/contribute/" />
```

ホスト名の強制的な先読みは、例えば、あるサイトのホームページ自体では使用されていないにもかかわらず、サイト全体で頻繁に参照されるドメイン名を強制的に事前解決するために有用かもしれません。これは、ホームページの性能には影響しないかもしれませんが、サイトの全体的なパフォーマンスを向上させます。

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

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

関連情報
----

* Firefox の DNS 先読み (ブログ記事)
* Google Chrome じゃ DNS 先読み制御を扱います


Access-Control-Request-Headers - HTTP

Access-Control-Request-Headers
==============================

**`Access-Control-Request-Headers`** リクエストヘッダーはプリフライトリクエストを発行する際にブラウザーが使用し、実際のリクエストが行う際にどの HTTP ヘッダーを使用するかをサーバーに知らせます。

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

構文
--
```

Access-Control-Request-Headers: <header-name>, <header-name>, ...
```

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

<header-name>

リクエストに含まれる HTTP ヘッダーのカンマ区切りのリスト。

例
-
```

Access-Control-Request-Headers: X-PINGOTHER, Content-Type
```

仕様書
---

| Specification |
| --- |
| Fetch Standard # http-access-control-request-headers |

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

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

関連情報
----

* `Access-Control-Request-Method`


X-Forwarded-For - HTTP

X-Forwarded-For
===============

**X-Forwarded-For** (XFF) ヘッダーは、 HTTP プロキシーサーバーを通過してウェブサーバーへ接続したクライアントの、送信元 IP アドレスを特定するために事実上の標準となっているヘッダーです。

**警告:** このヘッダーを適切に使用しない場合、セキュリティリスクがあります。詳細は セキュリティーとプライバシーの懸念 の項を確認してください。

クライアントがサーバーに直接接続を行った場合、クライアントの IP アドレスはサーバーに送信されます。（そして、しばしばサーバーのアクセスログに記録されます）しかし、クライアントの接続がフォワードプロキシー または リバースプロキシーを通過する場合はサーバーは最後のプロキシーの IP アドレスしかわからず、ほとんど役に立ちません。これは最後のプロキシーがサーバーの一部としてのロードバランサーである場合に特にあてはまります。そのため、より役に立つクライアント IP アドレスをサーバーに提供するために `X-Forwarded-For` リクエストヘッダーが用いられます。

このヘッダーの詳しい使用方法は 構文解析 と IP アドレスの選択 の項を確認してください。

|  |  |
| --- | --- |
| ヘッダー種別 | 要求ヘッダー |
| 禁止ヘッダー名 | はい |

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

セキュリティーとプライバシーの懸念
-----------------

このヘッダーは設計上、クライアントの IP アドレスなどプライバシーに関わる情報を公開します。それゆえに、このヘッダーを利用する場合はユーザーのプライバシーに留意する必要があります。

`X-Forwarded-For` ヘッダーはクライアントとサーバーの間に信頼できるリバースプロキシー（例: ロードバランサーのような）が存在しない場合は信頼できません。もし、クライアントと全てのプロキシーが悪意がなく正しく振る舞う場合、ヘッダー内の IP アドレスのリストは ディレクティブ 項で説明された意味を持ちます。しかし、クライアントもしくはプロキシーに悪意がある、または設定ミスがある場合、ヘッダーの一部（もしくは全て）がなりすましの可能性があります。（もしくは、リストではないか IP アドレスを全く含まないか）

もし、信頼できるリバースプロキシーがクライアントとサーバーの間にある場合、最終的な `X-Forwarded-For` IP アドレス（信頼できるプロキシーごとに1つ）は信頼できるプロキシーによって追加されたものなので、信頼できることになります。（サーバーがこれらのプロキシーを介してのみアクセスできて、かつ、直接アクセスできない場合に *限ります*）

セキュリティのために `X-Forwarded-For` を使用する場合（レートリミットや IP によるアクセス制限など）は信頼できるプロキシー *によってのみ* 追加された IP アドレスを使用しなければなりません。信頼できない値を使用した場合、レートリミットの回避、アクセス制限のバイパス、メモリの枯渇など、セキュリティや可用性に悪影響を及ぼす可能性があります。

逆に言うと、左端の（信頼できない）値はなりすましによる悪影響が無い場合にのみ使用します。

構文
--
```

X-Forwarded-For: <client>, <proxy1>, <proxy2>
```

要素はカンマ区切りで、前後に空白を含めることもできます。

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

<client>

クライアントの IP アドレス

<proxy1>, <proxy2>

要求が複数のプロキシーを通して行われる場合、それぞれの通過するプロキシーの IP アドレスが書き出されます。つまり、クライアントとプロキシーが悪意や設定ミスがなく、正しく振る舞った場合に、右端の IP アドレスが最も後のプロキシーであり、左端の IP アドレスが元のクライアントの IP アドレスです。

例
-
```

X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348

X-Forwarded-For: 203.0.113.195

X-Forwarded-For: 203.0.113.195, 2001:db8:85a3:8d3:1319:8a2e:370:7348

X-Forwarded-For: 203.0.113.195,2001:db8:85a3:8d3:1319:8a2e:370:7348,150.172.238.178
```

構文解析
----

`X-Forwarded-For` ヘッダーを適切に解析しなかった場合、なりすましの値をセキュリティ関連用途に使用してしまう可能性があります。その結果、前述のような悪影響が発生します。

リクエストには複数の `X-Forwarded-For` ヘッダーが含まれる可能性があります。（RFC2616によると）それらのヘッダーの IP アドレスは、最初のヘッダーの 最初の IP アドレスから最後のヘッダーの最後の IP アドレスまでをひとつながりの単一のリストとして扱う必要があります。これらを単一のリストとして扱うには2つの方法があります:

* 全ての `X-Forwarded-For` ヘッダーをカンマで結合してからカンマ区切りのリストにする、もしくは
* 各々の `X-Forwarded-For` ヘッダーをカンマ区切りのリストにしてから結合する

複数の `X-Forwarded-For` ヘッダーのうち1つだけ使用するのは不十分です。

（いくつかのリバースプロキシーは自動的に複数の `X-Forwarded-For` ヘッダーを1つに結合します。しかし、そうであると推定しないのが最も安全です。）

IP アドレスの選択
----------

アドレスを選択するときは、 IP の完全なリスト — 全ての `X-Forwarded-For` ヘッダー — を使用する必要があります。

クライアントから最も近い `X-Forwarded-For` の IP アドレスを選択する場合（信頼できない、かつ、セキュリティに関係の *ない* 目的で）は、左端から *有効* で *プライベート/内部* ではない最初の IP アドレスを選択する必要があります。（なりすましの値は IP アドレスではない可能性があるため "有効" である必要があります。また、 "プライベート/内部アドレスではない" というのはクライアントが彼らの内部ネットワークのプロキシーを使用した可能性があり、その場合 プライベートネットワーク で IP アドレスが追加されている可能性があるためです。）

*信頼できる* 最初の `X-Forwarded-For` クライアント IP アドレスを選択する場合、追加の設定が要求されます。これらは一般的に2つの方法があります:

* **信頼できるプロキシーの数**: インターネットとサーバーの間のリバースプロキシーの数が設定されている。`X-Forwarded-For` IP リストは右端から1を引いて位置から検索されます。（例えば、リバースプロキシーが1つの場合は、そのプロキシーはクライアントの IP アドレスを追加するため右端の IP アドレスを使用するべきです。もし、リバースプロキシーが3つある場合、最後の2つの IP アドレスは内部のものになるでしょう。）
* **信頼できるプロキシーのリスト**: 信頼できるリバースプロキシーの IP リストもしくは IP の範囲が設定されている。 `X-Forwarded-For` IP リストは右端から検索されますが、この時に信頼できるプロキシーリストのアドレスはスキップされます。信頼できるリストに一致しなかった最初のアドレスが目的のアドレスです。

最初の信頼できる `X-Forwarded-For` IP アドレスは実際のクライアントコンピューターではなく信頼できない中間プロキシーのものかもしれません、しかし、それはセキュリティ用途のための唯一適した IP アドレスです。

サーバーがインターネットから直接接続可能な場合 — たとえ信頼できるリバースプロキシーの後ろに設置されていたとしても — `X-Forwarded-For` IP リストはセキュリティ関連用途に使用するには信頼できないということに注意してください。

仕様書
---

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

関連情報
----

* `Forwarded`
* `X-Forwarded-Host`
* `X-Forwarded-Proto`
* `Via`


Early-Data - HTTP

Early-Data
==========

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

**`Early-Data`** ヘッダーは中間者により設定され、リクエストが TLS 早期データで伝えられたこと、そして中間者が `425 (Too Early)` ステータスコードを理解していることを示します。

**`Early-Data`** ヘッダーはリクエストの発信者 (つまり、ブラウザー) によって設定されることはありません。

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

構文
--
```

Early-Data: 1
```

例
-
```

GET /resource HTTP/1.0
Host: example.com
Early-Data: 1
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 8470, セクション 5.1: The Early-Data Header Field | Using Early Data in HTTP |

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

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


ETag - HTTP

ETag
====

**`ETag`** （または**エンティティタグ**）は HTTP のレスポンスヘッダーで、リソースの特定バージョンの識別子です。ウェブサーバーは、コンテンツが変更されていない場合はレスポンス全体を再送する必要がないので、キャッシュがより効率的になり通信帯域を節約することができます。加えて、 ETag はリソースが同時に更新されて互いを上書きすること (「空中衝突」) を防ぐのに役立ちます。

指定された URL のリソースが変更された場合は、新しい `Etag` 値を生成する必要があります。これらを比較することで、リソースの 2 つの表現が同じかどうかを素早く判断できます。

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

構文
--

```http
ETag: W/"<etag\_value>"
ETag: "<etag\_value>"
```

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

`W/` 省略可

`'W/'` (大文字) は弱いバリデーターを使用することを示します。弱い ETag は生成が簡単ですが、比較にはあまり役立ちません。強力なバリデーターは比較には理想的ですが、効率的に生成するのはとても困難です。同じリソースを表現する 2 つの弱い `ETag` の値があった場合、意味的には同等ですが、バイト単位では同じではない可能性があります。すなわち、弱い ETag はバイト範囲指定のリクエストが行われたときにキャッシュされませんが、強い ETag は範囲指定のリクエストもキャッシュします。

"<etag\_value>"

リクエストされたリソースを一意に表すエンティティタグです。これは二重引用符で囲まれた ASCII 文字列であり、 `"675af34563dc-tr34"`のような形です。 `ETag` 値を生成する方法は指定されていません。コンテンツのハッシュ、最終更新タイムスタンプのハッシュ、単なるリビジョン番号などがよく使用されます。例えば、 Wiki エンジンは、文書内の記事コンテンツの 16 進ハッシュを使用することがあります。

例
-

```http
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"
```

### 空中衝突の回避

`ETag` と `If-Match` ヘッダの助けを借りて、編集の空中衝突を検出することができます。

たとえば、 MDN を編集する場合、現在の Wiki コンテンツのハッシュが算出され、そのレスポンスで `Etag` に入れられます。

```http
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

Wiki ページに変更を保存 (データの投稿) するとき、 `POST` リクエストには、 `If-Match` ヘッダーに `ETag` 値を入れて、新しいかどうかをチェックします。

```http
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

ハッシュが一致しない場合は、文書が途中で編集されたことを意味し、 `412` `Precondition Failed` エラーが発生します。

### 変更されていないリソースのキャッシュ

もう一つの `ETag` ヘッダーの典型的な使用例として、変更されていないリソースをキャッシュすることがあります。ユーザーが (`ETag` が設定されている) 指定された URL を再度訪問した時、それが*古くなったもの* (古すぎて使用できない) であった場合、クライアントは `If-None-Match` ヘッダー欄で `ETag` の値を送ります。

```http
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

サーバーは、クライアントの `ETag` (`If-None-Match` で送信されたもの) を現在のバージョンの `ETag` と比較し、両方の値が一致する (つまりリソースは変更されていない) 場合、サーバーは `304` `Not Modified` ステータスを本文なしで返送し、キャッシュされたレスポンスのバージョンがまだ使用可能 (新しい) であることをクライアントに通知します。

仕様書
---

| Specification |
| --- |
| HTTP Semantics # field.etag |

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

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

関連情報
----

* `If-Match`
* `If-None-Match`
* `304 Not Modified`
* `Precondition Failed`
* W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout


DPR - HTTP

DPR
===

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

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

**`DPR`** ヘッダーは、CSS ピクセル毎に対応する物理デバイスピクセルの数であるクライアントのデバイスピクセル比 (device pixel ratio、DPR)) を表すクライアントヒントのヘッダーです。

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

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

構文
--
```

DPR: <number>
```

例
-

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

Accept-CH: DPR
Accept-CH-Lifetime: 86400
```

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

DPR: 1.0
```

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

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

関連情報
----

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


Expires - HTTP

Expires
=======

**`Expires`** ヘッダーには、レスポンスが古くなると見なされる日時が入ります。

値 0 のような無効な日付は過去の日付を表し、リソースがすでに有効期限切れであることを意味します。

**メモ:** レスポンスに `max-age` または `s-maxage` ディレクティブを持つ `Cache-Control` ヘッダーがある場合、`Expires` ヘッダーは無視されます。

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

構文
--
```

Expires: <http-date>
```

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

<http-date>

HTTP-date タイムスタンプ

例
-
```

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

仕様書
---

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

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

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

関連情報
----

* `Cache-Control`
* `Age`


Cross-Origin-Embedder-Policy - HTTP

Cross-Origin-Embedder-Policy
============================

HTTP の **`Cross-Origin-Embedder-Policy`** (COEP) レスポンスヘッダーは、（CORP または CORS を使用して）文書に明示的に許可を与えていない外部オリジンのリソースが、文書に読み込まれることを防止するものです。

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

構文
--
```

Cross-Origin-Embedder-Policy: unsafe-none | require-corp
```

### ディレクティブ

`unsafe-none`

これが既定値です。 CORS プロトコルや `Cross-Origin-Resource-Policy` ヘッダーで明示的に許可していなくても、文書が外部オリジンのリソースを取得することを許可します。

`require-corp`

 文書は、同じオリジンからのリソース、または他のオリジンからロード可能であると明示的にマークされたリソースのみをロードすることができます。
 外部オリジンのリソースが CORS に対応している場合、 COEP でブロックされずに読み込むには、`crossorigin` 属性や `Cross-Origin-Resource-Policy` ヘッダーを使用する必要があります。

例
-

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

`SharedArrayBuffer` オブジェクトや `Performance.now()` のような特定の機能には、文書に `require-corp` 値を設定した COEP ヘッダーがある場合のみ、スロットルなしタイマーを使用してアクセスすることができます。
```

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

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

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

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

### CORS による COEP の遮断の回避

`require-corp` を使用して COEP を有効にし、読み込む必要があるクロスオリジンリソースがある場合、それは CORS に対応する必要があり、 COEP によるブロックを回避するには、他のオリジンからロード可能であると明示的にマークする必要があります。例えば、サードパーティーサイトから読み込むこの画像には、`crossorigin` 属性を使用することができます。

```html
<img src="https://thirdparty.com/img.png" crossorigin />
```

仕様書
---

| Specification |
| --- |
| HTML Standard # coep |

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

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

関連情報
----

* `Cross-Origin-Opener-Policy`


Age - HTTP

Age
===

**`Age`** ヘッダーには、プロキシーのキャッシュに入ってからの経過時間（秒）が含まれています。

`Age` ヘッダーは通常０に近い値となっています。もし `Age: 0` であるなら、 おそらくオリジンサーバーからフェッチされただけでしょう。 それ以外の場合は、一般的にプロキシーの現在の日時と HTTP レスポンスに含まれていた`Date` ヘッダーとの差分から算出されます。

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

構文
--
```

Age: <delta-seconds>
```

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

<delta-seconds>

オブジェクトがプロキシキャッシュに入っていた時間 (秒単位) を表す負でない整数。

例
-
```

Age: 24
```

仕様
--

| 仕様書 | タイトル |
| --- | --- |
| RFC 7234, セクション 5.1: Age | Hypertext Transfer Protocol (HTTP/1.1): Caching |

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

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

関連情報
----

* `Cache-Control`
* `Expires`


DNT - HTTP

DNT
===

**非推奨:** この機能は非推奨になりました。まだ対応しているブラウザーがあるかもしれませんが、すでに関連するウェブ標準から削除されているか、削除の手続き中であるか、互換性のためだけに残されている可能性があります。使用を避け、できれば既存のコードは更新してください。このページの下部にある互換性一覧表を見て判断してください。この機能は突然動作しなくなる可能性があることに注意してください。

**`DNT`** (**D**o **N**ot
 **T**rack) リクエストヘッダーは、ユーザーのトラッキングの設定を示します。これにより、ユーザーはパーソナライズされたコンテンツではなく、プライバシーを優先するかどうかを指定できます。

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

構文
--

```http
DNT: 0
DNT: 1
DNT: null
```

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

0

ユーザーは対象のサイトでトラッキングを許可している。

1

ユーザーは対象のサイトでトラッキングを拒否している。

null

ユーザーはトラッキングに関する設定を指定していない。

例
-

### JavaScript から Do Not Track の状態を読み取る

ユーザーの DNT 設定は `Navigator.doNotTrack` プロパティを使用して JavaScript から読み取ることもできます。

```js
navigator.doNotTrack; // "0" or "1"
```

仕様書
---

#### No specification found

No specification data found for `http.headers.DNT`.
Check for problems with this page or contribute a missing `spec_url` to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

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

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

関連情報
----

* `Navigator.doNotTrack`
* `Tk` ヘッダー
* Do Not Track (Wikipedia)
* What Does the "Track" in "Do Not Track" Mean? – EFF
* DNT (Electronic Frontier Foundation)
* DNT ブラウザー設定のヘルプ:
    + Firefox
    + Chrome


Vary - HTTP

Vary
====

**`Vary`** HTTP レスポンスヘッダーは、オリジンのサーバーから新しく要求するのではなく、キャッシュされたレスポンスを使用できるかどうかを決定するために将来のリクエストヘッダーをどのように一致させるかを決定します。これは、コンテンツネゴシエーションアルゴリズムでリソースの表現を選択するときにどのヘッダーを使用したかを示すためにサーバーによって使用されます。

`Vary` ヘッダーは `200` `OK` レスポンスに設定されるのと同様に、 `304` `Not Modified` にも設定されます。

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

構文
--
```

Vary: *
Vary: <header-name>, <header-name>, ...
```

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

\*

URL のための各リクエストは、固有でキャッシュ不可能なリクエストとして扱われると仮定されます。これを示すのには `Cache-Control`: `no-store` を使用したほうが良く、こちらはより明確に読むことができ、オブジェクトが保存されないことを示します。

<header-name>

コンマ区切りで、キャッシュされたレスポンスが使用されるかどうかを決定する際に関わるヘッダー名のリストです。

例
-

### 動的な提供

`Vary: User-Agent` ヘッダーが使用されたとき、キャッシュサーバーはキャッシュからページを提供するかどうかを決定する際にユーザーエージェントを考慮するべきです。例えば、モバイルユーザーに対して異なるコンテンツを提供しているのであれば、誤ってサイトのデスクトップ版のサイトをモバイルユーザーに対して提供してしまうことを防ぐのに役立ちます。これは Google 等の検索エンジンがページのモバイル版を発見するのに役立ち、 クローキング を求めずに区別することができる可能性があります。
```

Vary: User-Agent
```

仕様書
---

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

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

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

互換性メモ
-----

* Vary with care – Vary header problems in IE6-9
関連情報
----

* Understanding The Vary Header - Smashing Magazine
* Best Practices for Using the Vary Header – fastly.com
* Content negotiation


Clear-Site-Data - HTTP

Clear-Site-Data
===============

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

**`Clear-Site-Data`** ヘッダーは、リクエストしているウェブサイトに関連付けられた閲覧用データ（クッキー、ストレージ、キャッシュ）を消去します。ウェブ開発者がそのオリジンのためにブラウザーがローカルに保存したデータをより制御できます。

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

構文
--

`Clear-Site-Data` ヘッダーは、1 つ以上のディレクティブを受け付けます。すべての種類のデータを消去する場合は、ワイルドカードのディレクティブ (`"*"`) を使用することができます。

```http
// 単一のディレクティブ
Clear-Site-Data: "cache"

// 複数のディレクティブ（カンマ区切り）
Clear-Site-Data: "cache", "cookies"

// ワイルドカード
Clear-Site-Data: "\*"
```

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

**メモ:** すべてのディレクティブは引用符で囲まれた文字列の文法に従わなければなりません。二重引用符を含まないディレクティブは無効です。

`"cache"`
Experimental

サーバーが、レスポンス URL のオリジンに関するローカルにキャッシュされたデータ（つまり、ブラウザーキャッシュ、HTTP キャッシュを参照）の消去を望んでいることを示します。ブラウザーによっては、予備レンダリングページ、スクリプトキャッシュ、 WebGL シェーダーキャッシュ、アドレスバーのサジェスト等のようなものも消去します。

`"cookies"`

サーバーが、レスポンス URL のオリジンに関するすべてのクッキーの消去を望んでいることを示します。これは登録されたドメインにサブドメインを含め影響します。ですから、 `https://example.com` と同様に `https://stage.example.com` のクッキーも消去されます。

`"storage"`

サーバーが、レスポンス URL のオリジンに関するすべての DOM ストレージの消去を望んでいることを示します。これは以下のようなストレージ機構を含みます。

* localStorage （`localStorage.clear` を実行）
* sessionStorage （`sessionStorage.clear` を実行）
* IndexedDB （それぞれのデータベースに `IDBFactory.deleteDatabase` を実行）
* サービスワーカーの登録（登録されたそれぞれのサービスワーカーに対して、 `ServiceWorkerRegistration.unregister` を実行）
* Web SQL データベース
* FileSystem API のデータ
* プラグインのデータ（`NPP_ClearSiteData` によって消去）

`"executionContexts"`

サーバーが、レスポンスのオリジンに関するすべての閲覧コンテキストの再読み込みを望んでいることを示します。 (`Location.reload`)

`"*"` （ワイルドカード）

サーバーが、レスポンスのオリジンに関するすべての種類のデータの消去を望んでいることを示します。このヘッダーの将来のバージョンでデータの種類が追加された場合、それも消去します。

例
-

### ウェブサイトのログアウト

ユーザーがウェブサイトやサービスからログアウトした場合、ローカルに保存されているデータを削除したい場合があります。サイトからのログアウトが正常に完了したことを確認するページ (`https://example.com/logout` など)を送信する際に `Clear-Site-Data` ヘッダーを追加することで、これを実現することができます。

```http
Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"
```

### クッキーの消去

以下のヘッダーが `https://example.com/clear-cookies` のレスポンスで配信された場合、同じドメイン `https://example.com` 及びあらゆるサブドメイン（`https://stage.example.com` など）が消去されます。

```http
Clear-Site-Data: "cookies"
```

仕様書
---

| Specification |
| --- |
| Clear Site Data # header |

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

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

関連情報
----

* `Cache-Control`


Content-Location - HTTP

Content-Location
================

**`Content-Location`** ヘッダーは、返されるデータの代替場所を示します。主な用途はコンテンツネゴシエーションの結果として送信されたリソースの URL を示すことです。

`Location` と `Content-Location` は異なります。`Location` はリダイレクトの URL を示し、`Content-Location` は今後のコンテンツネゴシエーションなしでリソースへのアクセスに使用する直接 URL を示します。 `Location` はレスポンスに関連付けられたヘッダーで、 `Content-Location` は返されたデータに関連付けられます。この区別は例がないと抽象的に見えるかもしれません。

|  |  |
| --- | --- |
| ヘッダー種別 | エンティティヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--
```

Content-Location: <url>
```

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

<url>

(リクエスト URL に対する) 相対 URL または絶対 URL。

例
-

### サーバーからのデータのリクエストを様々な形式で行う

たとえば、サイトの API が JSON, XML, または CSV 形式でデータを返すとします。特定の文書の URL が `https://example.com/documents/foo` である場合、サイトはリクエストの `Accept` ヘッダーに応じて `Content-Location` 用に異なる URL を返すことができます。

| リクエストヘッダー | レスポンスヘッダー |
| --- | --- |
| `Accept: application/json, text/json` | `Content-Location: /documents/foo.json` |
| `Accept: application/xml, text/xml` | `Content-Location: /documents/foo.xml` |
| `Accept: text/plain, text/*` | `Content-Location: /documents/foo.txt` |

これらの URL は例です。サイトではクエリ文字列パラメータ：`/documents/foo?format=json`、`/documents/foo?format=xml` など、任意の URL パターンでさまざまなファイルタイプを提供できます。

その後クライアントはその特定の URL で JSON バージョンが利用可能であることを覚えて、次に文書を要求するときにコンテンツのネゴシエーションをスキップします。

サーバーは `Accept-Language` のような他のコンテンツネゴシエーションヘッダーを考慮することもできます。

### 新しい文書を指す (HTTP 201 Created)

サイトの API を通じて新しいブログ投稿を作成しているとします。
```

PUT /new/post
Host: example.com
Content-Type: text/markdown

# My first blog post!

I made this through `example.com`'s API. I hope it worked.
```

サイトは投稿が公開されたことを確認する一般的な成功メッセージを返します。サーバーは `Content-Location` を使用して新しい投稿がどこにあるかを指定します。
```

HTTP/1.1 201 Created
Content-Type: text/plain; charset=utf-8
Content-Location: /my-first-blog-post

✅ Success!
```

### トランザクションの結果の URL を示す

サイトの別のユーザーに送金するための `<form>` があるとします。

```html
<form action="/send-payment" method="post">
  <p>
    <label
 >Who do you want to send the money to?
      <input type="text" name="recipient" />
    </label>
  </p>

  <p>
    <label
 >How much?
      <input type="number" name="amount" />
    </label>
  </p>

  <button type="submit">Send Money</button>
</form>
```

フォームが送信されると、サイトは取引の領収書を生成します。サーバーは `Content-Location` を使用して、将来のアクセスのために領収書の URL を示すことができます。
```

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Location: /my-receipts/38

<!doctype html>
(Lots of HTML…)

<p>You sent $38.00 to ExampleUser.</p>

(Lots more HTML…)
```

仕様書
---

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

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

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

関連情報
----

* `Location`


Accept-Patch - HTTP

Accept-Patch
============

**`Accept-Patch`** は HTTP のレスポンスヘッダーで、サーバーが認識できるメディアタイプを伝えます。

何らかのメソッドに対するレスポンスの **`Accept-Patch`** は、 Request-URI で特定されるリソースに対して PATCH が受け入れられることを意味しています。 2 つのよくあるケースがこれをもたらします。

サポートされていないメディアタイプの PATCH リクエストを受信したサーバーは、`415` `Unsupported Media Type`と、 1 つ以上のサポートされているメディアタイプを参照する Accept-Patch ヘッダーで応答する可能性があります。

**メモ:**

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

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

構文
--

```http
Accept-Patch: application/example, text/example
Accept-Patch: text/example;charset=utf-8
Accept-Patch: application/merge-patch+json
```

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

なし

例
-

```http
Accept-Patch: application/example, text/example

Accept-Patch: text/example;charset=utf-8

Accept-Patch: application/merge-patch+json
```

仕様書
---

| Specification |
| --- |
| RFC 5789 # section-3.1 |

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

ブラウザーの互換性はこのヘッダーには関係ありません（ヘッダーはサーバーから送られ、仕様書ではクライアントの動作を定義していません）。

関連情報
----

* HTTP メソッド `PATCH`
* HTTP Semantic and context RFC 7231, セクション 4.3.4: PUT


Location - HTTP

Location
========

**`Location`** レスポンスヘッダーはリダイレクト先の URL を示します。 `3xx` (リダイレクト) または ``201`` (created) ステータスレスポンスを返すときのみ意味を成します。

リダイレクトの場合、 HTTP メソッドは元のメソッドとリダイレクトの種類によって、 `Location` で示されたページにアクセスする新しいリクエストを生成するために使用します。

* `303` (See Other) レスポンスは常に `GET` メソッドを使用するように誘導され、 `307` (Temporary Redirect) および `308` (Permanent Redirect) は元のリクエストにおいて使用されたメソッドを変更しません。
* `301` (Moved Permanently) と `302` (Found) は多くの場合はメソッドを変更しませんが、古いユーザーエージェントは変更することがあります (そのため、基本的に結果は不明です)。

これらのステータスコードを持つすべてのレスポンスは、 `Location` ヘッダーを送信します。

リソース作成 (created) では、新しく作成されたリソースへの URL を示します。

`Location` と `Content-Location` は異なります。 `Location` ヘッダーは、リダイレクトの対象 (または新しく作成されたリソースの URL) を示し、 `Content-Location` ヘッダーはコンテンツネゴシエーションが起きたとき、更なるコンテンツネゴシエーションが起きないように、リソースへアクセスできる直接的な URL を指します。 `Location` はレスポンスに関連付くヘッダーで、 `Content-Location` は返されるエンティティに関連付けられます。

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

構文
--
```

Location: <url>
```

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

<url>

(リクエスト URL からの) 相対 URL、または絶対 URL。

例
-
```

Location: /index.html
```

仕様書
---

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

ブラウザーの対応
--------

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

関連情報
----

* `Content-Location`
* `Location` ヘッダーを含むレスポンスのステータス: `201`, `301`, `302`, `303`, `307`, `308`.


Last-Modified - HTTP

Last-Modified
=============

HTTP の **`Last-Modified`** レスポンスヘッダーは、リソースが最後に変更されたとオリジンのサーバーが判断している日時を含みます。これは受信または保存されたリソースが、同じものであるかを判断する検証材料として使用されます。 `ETag` ヘッダーよりも精度は低く、その代替手段になります。 `If-Modified-Since` や `If-Unmodified-Since` ヘッダーを含む条件付きリクエストはこのフィールドを使用します。

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

構文
--
```

Last-Modified: <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 における時刻は常にグリニッジ標準時で表され、ローカル時刻になることはありません。

例
-
```

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7232, セクション 2.2: Last-Modified | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

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

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

関連情報
----

* `If-Modified-Since`
* `If-Unmodified-Since`
* `Etag`


If-None-Match - HTTP

If-None-Match
=============

HTTP の **`If-None-Match`** リクエストヘッダーは、リクエストを条件付きにします。 `GET` および `HEAD` メソッドの場合、指定されたものの中に要求されたリソースの `ETag` に一致するものがない場合のみ、サーバーはリソースを `200` ステータスで返します。その他のメソッドの場合、最終的に存在するリソースの `ETag` が列挙されたいずれの値とも一致しない場合にのみ処理します。

`GET` および `HEAD` メソッドの場合、条件が満たされなかったら、サーバーは HTTP ステータスコード 304 (Not Modified) を返さなければなりません。サーバー側の変更を適用するメソッドの場合、ステータスコード 412 (Precondition Failed) が使用されます。なお、 304 レスポンスを生成するサーバーは、 Cache-Control, Content-Location, Date, ETag, Expires, Vary の各ヘッダーフィールドについて、同じリクエストに対して 200 (OK) レスポンスで送信されるものを生成しなければなりません。

格納されている `ETag` との比較では、*弱い比較アルゴリズム*を使用、つまり二つのファイルの内容が同等であれば等しいとみなします。バイト単位で等しい必要はありません。たとえば、フッターの作成日が異なる二つのページは、同一と見なされます。

`If-Modified-Since` と一緒に使用した場合、 **`If-None-Match`** が優先されます (サーバーが対応している場合)。

一般的な使用例は二つあります。

* `GET` および `HEAD` メソッドの場合は、関連付けられた `ETag` を持つキャッシュされたエンティティを更新するため。
* 他のメソッド、特に `PUT` の場合、 `If-None-Match` は `*` 値と共に使用され、存在するかどうか分かっていないファイルを保存する際に、以前他のアップロードが行われておらず、以前 PUT されたデータを失わないことを保証するために使用することができます。この問題は、 lost update problem の一種です。

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

構文
--
```

If-None-Match: "<etag_value>"
If-None-Match: "<etag_value>", "<etag_value>", …
If-None-Match: *
```

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

<etag\_value>

リクエストされたリソースを一意に表すエンティティタグです。二重引用符の間に置かれた ASCII 文字列 (`"675af34563dc-tr34"` など) であり、 `W/` の接頭辞を付けると、弱い比較アルゴリズムを使用するべきであることを示すことができます (このアルゴリズムだけを使用する場合は `If-None-Match` では意味がありません)。

`*`

アスタリスクは任意のリソースを表す特殊な値です。通常 `PUT` を使用するリソースのアップロードの場合、その識別子を持つ別なリソースがすでにアップロードされていることをする場合にのみ有用です。

例
-
```

If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-None-Match: W/"67ab43", "54ed21", "7892dd"

If-None-Match: *
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7232, セクション 3.2: If-None-Match | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

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

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

関連情報
----

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-Match`
* `304` `Not Modified`
* `412` `Precondition Failed`


Referrer-Policy - HTTP

Referrer-Policy
===============

**`Referrer-Policy`** は HTTP ヘッダーで、 (`Referer` ヘッダーで送られる) リファラー情報をリクエストにどれだけ含めるかを制御します。 HTTP ヘッダーのほかに、 HTML でこのポリシーを設定することもできます。

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

構文
--
```

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url
```

**メモ:** 元のヘッダー名である `Referer` は "referrer" という語のスペルミスです。 `Referrer-Policy` ヘッダーはこのスペルミスをしていません。

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

`no-referrer`

`Referer` ヘッダーが省略されます。送信されるリクエストにはリファラー情報が含まれません。

`no-referrer-when-downgrade`

プロトコルのセキュリティ水準が同一である、または向上する場合 (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS) は、オリジン、パス、クエリー文字列が `Referer` ヘッダーで送信されます。セキュリティ水準が低下するリクエスト (HTTPS→HTTP, HTTPS→file) では `Referer` ヘッダーが送信されません。

`origin`

オリジンのみが `Referer` ヘッダーで送信されます。
 たとえば、 `https://example.com/page.html` にある文書からは、 `https://example.com/` というリファラーが送信されます。

`origin-when-cross-origin`

同一のプロトコル水準 (HTTP→HTTP, HTTPS→HTTPS) で同一オリジンのリクエストを行う場合はオリジン、パス、クエリー文字列を送信します。オリジン間リクエストや安全性の低下する移動先 (HTTPS→HTTP) ではオリジンのみを送信します。

`same-origin`

同一オリジンのリクエストではオリジン、パス、クエリー文字列を送信します。オリジン間リクエストでは `Referer` ヘッダーを送信しません。

`strict-origin`

プロトコルのセキュリティ水準が同じである場合 (HTTPS→HTTPS) にのみオリジンを送信します。安全性の低下する移動先 (HTTPS→HTTP) には `Referer` ヘッダーを送信しません。

`strict-origin-when-cross-origin` (既定値)

同一オリジンのリクエストを行う際はオリジン、パス、クエリー文字列を送信します。オリジン間リクエストでは、プロトコルのセキュリティ水準が同じである場合 (HTTPS→HTTPS) にのみオリジンを送信します。安全性の低下する移動先 (HTTPS→HTTP) には `Referer` ヘッダーを送信しません。

**メモ:** これはポリシーが指定されていない場合や、与えられた値が無効であった場合の既定のポリシーです (仕様書改訂 November 2020 を参照) 。以前の既定値は `no-referrer-when-downgrade` でした。

`unsafe-url`

セキュリティに関係なく、どのリクエストを行った場合でも、オリジン、パス、クエリー文字列を送信します。

**警告:** このポリシーは、 HTTPS リソースの URL から安全ではないオリジンへプライベートである可能性がある情報を漏洩します。設定する場合は影響をよく検討してください。

HTML との統合
---------

HTML 内でリファラーポリシーを設定することもできます。例えば、 `<meta>` 要素で name に `referrer` を設定することで、文書全体のリファラーポリシーを設定することができます。

```html
<meta name="referrer" content="origin" />
```

`<a>`, `<area>`, `<img>`, `<iframe>`, `<script>`, `<link>` の各要素に `referrerpolicy` 属性を指定し、個別のリクエストにリファラーポリシーを設定することもできます。

```html
<a href="http://example.com" referrerpolicy="origin"></a>
```

他に、 `noreferrer` link 関係を `a`, `area`, `link` の各要素に設定することもできます。

```html
<a href="http://example.com" rel="noreferrer"></a>
```

**警告:** 上記のように、 `noreferrer` link 関係はダッシュ記号を用いずに記述されます。 `<meta>` 要素で文書全体のリファラーポリシーを指定するときはダッシュを*つけて* `<meta name="referrer" content="no-referrer">` のように記述します。

CSS との統合
--------

CSS はスタイルシートから参照されるリソースにアクセスすることがあります。これらのリソースは同様にリファラーポリシーに従います。

* 外部の CSS スタイルシートでは、そのレスポンスの `Referrer-Policy` ヘッダーにより上書きされない限り、既定のポリシー (`strict-origin-when-cross-origin`) が使用されます。
* `<style>` 要素または `style` 属性については、所有者の文書のリファラーポリシーが使用されます。
例
-

### `no-referrer`

| 基点の文書 | 移動先 | 使用されるリファラー |
| --- | --- | --- |
| `https://example.com/page` | *すべての場所* | *（リファラーなし）* |

### `no-referrer-when-downgrade`

| 基点の文書 | 移動先 | 使用されるリファラー |
| --- | --- | --- |
| `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |
| `https://example.com/page` | `https://mozilla.org` | `https://example.com/page` |
| `https://example.com/page` | **http**://example.com | *（リファラーなし）* |

### `origin`

| 基点の文書 | 移動先 | 使用されるリファラー |
| --- | --- | --- |
| `https://example.com/page` | *すべての場所* | `https://example.com/` |

### `origin-when-cross-origin`

| 基点の文書 | 移動先 | 使用されるリファラー |
| --- | --- | --- |
| `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |
| `https://example.com/page` | `https://mozilla.org` | `https://example.com/` |
| `https://example.com/page` | **http**://example.com/page | `https://example.com/` |

### `same-origin`

| 基点の文書 | 移動先 | 使用されるリファラー |
| --- | --- | --- |
| `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |
| `https://example.com/page` | `https://mozilla.org` | *（リファラーなし）* |

### `strict-origin`

| 基点の文書 | 移動先 | 使用されるリファラー |
| --- | --- | --- |
| `https://example.com/page` | `https://mozilla.org` | `https://example.com/` |
| `https://example.com/page` | **http**://example.com | *（リファラーなし）* |
| **http**://example.com/page | *すべての場所* | `http://example.com/` |

### `strict-origin-when-cross-origin`

| 基点の文書 | 移動先 | 使用されるリファラー |
| --- | --- | --- |
| `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |
| `https://example.com/page` | `https://mozilla.org` | `https://example.com/` |
| `https://example.com/page` | **http**://example.com | *（リファラーなし）* |

### `unsafe-url`

| 基点の文書 | 移動先 | 使用されるリファラー |
| --- | --- | --- |
| `https://example.com/page?q=123` | *すべての場所* | `https://example.com/page?q=123` |

### 代替ポリシーの指定

必要なポリシーのブラウザーの対応状況が十分ではなく、代替ポリシーを設定したい場合は、カンマ区切りのリストを使用し、必要なポリシーを最後に指定してください。
```

Referrer-Policy: no-referrer, strict-origin-when-cross-origin
```

上記のシナリオでは、 `no-referrer` はブラウザーが `strict-origin-when-cross-origin` に対応していない場合のみ使用されます。

**メモ:** 複数の値を設定する方法は、 HTTP の `Referrer-Policy` ヘッダーのみが対応しており、 `referrerpolicy` 属性では対応していません。

ブラウザー固有の設定
----------

### Firefox の設定

Firefox のユーザー設定では*既定の*リファラーポリシーを構成できます。設定名はバージョンにより異なります。

* Firefox バージョン 59以降: `network.http.referer.defaultPolicy` (プライベートネットワークでは `network.http.referer.defaultPolicy.pbmode`)
* Firefox バージョン 53 から 58: `network.http.referer.userControlPolicy`

どちらも `0 = no-referrer`, `1 = same-origin`, `2 = strict-origin-when-cross-origin`, `3 = no-referrer-when-downgrade` と、同じ設定値をとります。

仕様書
---

| Specification |
| --- |
| Referrer Policy # referrer-policy-header |

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

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

関連情報
----

* ウェブセキュリティ > Referer ヘッダー: プライバシーとセキュリティの考慮事項
* Wikipedia の HTTP リファラ
* Fetch の使用時: `Request.referrerPolicy`
* 廃止された `Content-Security-Policy` の `referrer`
非推奨
 ディレクティブ
* 同一オリジンポリシー
* Tighter Control Over Your Referrers – Mozilla Security Blog