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

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

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

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

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

**`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`** レスポンスヘッダーは、リソースが最後に変更されたとオリジンのサーバーが判断している日時を含みます。これは受信または保存されたリソースが、同じものであるかを判断する検証材料として使用されます。 `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`** リクエストヘッダーは、リクエストを条件付きにします。 `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`
Warning
=======

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

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

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

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

構文
--
```

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

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

<warn-code>

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

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

<warn-agent>

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

<warn-text>

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

<warn-date>

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

警告コード
-----

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

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

例
-
```

Warning: 110 anderson/1.3.37 "Response is stale"

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

仕様書
---

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

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

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

関連情報
----

* `Date`
* HTTP response status codes
Sec-Fetch-User
==============

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

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

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

構文
--


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

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

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

例
-

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


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

仕様書
---

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

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

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

関連情報
----

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

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

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


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


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

構文
--


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

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

`<day-name>`

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

`<day>`

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

`<month>`

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

`<year>`

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

`<hour>`

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

`<minute>`

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

`<second>`

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

GMT

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

例
-
```

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



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

仕様書
---

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

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

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

関連情報
----

* `Age`
Device-Memory
=============

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

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

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

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

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

構文
--

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

Device-Memory: <number>
```

例
-

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

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


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

Device-Memory: 1
```

仕様書
---

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

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

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

関連情報
----

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

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

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

構文
--
```

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

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

<type>

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

<credentials>

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

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

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

例
-
```

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

仕様書
---

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

関連情報
----

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

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

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

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

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

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

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

構文
--
```

Referer: <url>
```

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

<url>

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

例
-
```

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

仕様書
---

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

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

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

関連情報
----

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

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

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

構文
--
```

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

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

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

`<MIME_type>/<MIME_subtype>`

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

`<MIME_type>/*`

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

`*/*`

すべての MIME タイプ

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

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

例
-
```

Accept: text/html

Accept: image/*

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

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

仕様書
---

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

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

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

関連情報
----

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