recursal/MDN huggingface dataset:
Accept-Encoding
===============

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

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

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

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

**メモ:**

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


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

構文
--


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

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

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

`gzip`

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

`compress`

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

`deflate`

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

`br`

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

`identity`

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

`*`

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

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

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

例
-


```http
Accept-Encoding: gzip

Accept-Encoding: gzip, compress, br

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

仕様書
---

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

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

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

関連情報
----

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

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

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

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

構文
--
```

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


<cookie-list>

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

例
-
```

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

仕様書
---

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

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

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

関連情報
----

* `Set-Cookie`
* `Document.cookie`
Accept-CH
=========

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

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

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

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

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

構文
--
```

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

例
-
```

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


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

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

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

関連情報
----

* `Accept-CH-Lifetime`
* `Vary`
Authorization
=============

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

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

構文
--


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

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

<type>

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

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

<credentials>

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

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

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

例
-
```

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```


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

仕様書
---

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

関連情報
----

* HTTP 認証
* `WWW-Authenticate`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`, `403`, `407`
Upgrade-Insecure-Requests
=========================

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

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

構文
--
```

Upgrade-Insecure-Requests: 1
```

例
-

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

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


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

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

仕様書
---

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

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

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

関連情報
----

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

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

構文
--
```

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


`clear`

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

`<protocol-id>`

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

`<alt-authority>`

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

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

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

`persist=1`省略可

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

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

例
-
```

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

仕様書
---

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

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

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

関連情報
----

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

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


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

構文
--


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

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

`null`

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

`<scheme>`

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


`<hostname>`

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

`<port>` 省略可

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


解説
--

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

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

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

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

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

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

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

例
-


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



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

仕様書
---

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

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

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

関連情報
----

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

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

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

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

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


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

構文
--
```

Accept-Charset: <charset>

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

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

`<charset>`

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

`*`

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

`;q=<weight>`

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

例
-
```

Accept-Charset: iso-8859-1

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

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

仕様書
---

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

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

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

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

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

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

構文
--
```

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

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

<protocol-name>

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

<protocol-version>

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

<host> and <port>

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

<pseudonym>

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

例
-
```

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

仕様書
---

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

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

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

関連情報
----

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

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

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

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

構文
--
```

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

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

`<range-unit>`

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

`none`

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

例
-
```

Accept-Ranges: bytes
```

仕様書
---

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

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

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

関連情報
----

* `If-Range`
* `Range`
* IANA HTTP Range Unit Registry
Expect-CT
=========

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

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

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

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

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

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


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

構文
--
```

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

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

`max-age`

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

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

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

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

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

`enforce` 省略可

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

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

例
-

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

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

メモ
--

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

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

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

仕様書
---

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

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

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
X-XSS-Protection
================

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

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

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

**メモ:**

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


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

構文
--


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


0

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

1

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

1; mode=block

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

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

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

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

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


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


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

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

例
-

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


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


PHP


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


Apache (.htaccess)
```

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


Nginx
```

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

仕様書
---

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

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

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

関連情報
----

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

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

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

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

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

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

構文
--
```

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

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

<host>

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

例
-
```

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

仕様書
---

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

関連情報
----

* `Host`
* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Proto`
Transfer-Encoding
=================

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

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

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

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

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

構文
--
```

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

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

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

`chunked`

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

`compress`

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


`deflate`

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

`gzip`

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

`identity`

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

例
-

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

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

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

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

仕様書
---

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

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

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

関連情報
----

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

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

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

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

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

構文
--
```

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

### ディレクティブ

`unsafe-none`

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

`same-origin-allow-popups`

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

`same-origin`

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

例
-

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

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

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


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

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


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

仕様書
---

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

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

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

関連情報
----

* `Cross-Origin-Embedder-Policy`