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

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

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

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

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

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

**メモ:** 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) の説明
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
================================

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

**`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`** リクエストヘッダーは、リクエストを正しく扱うためにサーバーが実行する必要があると期待されていることを示します。

仕様書で定義されている期待は `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
=============

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

**`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`** リクエストヘッダーは、リクエストを条件付きにします。サーバーはリソースが指定された日時以降に変更されていない場合のみ、要求されたリソースを返信したり、 `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
============================

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