recursal/MDN huggingface dataset:
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
=============

**`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
=====

**`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
=============================

**`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`
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
======================

**`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 解説書
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) の説明
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
===========

**`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`** リクエストヘッダーは、リクエストを条件付きにします。 `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
=====

**`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`** リクエストヘッダーは、リクエストを条件付にします。サーバーは最後にリソースが変更された時刻が、リクエストにより与えられた時刻より後の場合にのみ、リクエストされたリソースを `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
======================

**`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
==============================

**`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`
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
====

**`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
===

**安全なコンテキスト用:** この機能は一部またはすべての対応しているブラウザーにおいて、安全なコンテキスト (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
=======

**`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`** (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
===

**`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`