404 Not Found - HTTP

404 Not Found
=============

 HTTP の **`404 Not Found`** レスポンスステータスコードは、サーバーがリクエストされたリソースを見つけることができないことを示します。
 404 ページにつながるリンクは、壊れたリンクまたは死んだリンクと呼ばれ、リンク切れの対象となることがあります。

 404 ステータスコードは、そのリソースが見つからないことを示すだけです。リソースが一時的または永続的に失われているかどうかを示してはいません。
 リソースが永久に削除された場合は、代わりに `410` (Gone) を使用してください。

ステータス
-----
```

404 Not Found
```

独自のエラーページ
---------

独自の 404 ページを表示して、ユーザーにとってより有益な、次に何をすべきかのガイダンスを提供することができます。例えば、 Apache サーバーの場合、 `.htaccess` ファイルで独自の 404 ページへのパスを指定することができます。
```

ErrorDocument 404 /notfound.html
```

独自の 404 ページの例については、この 404 ページを参照してください。

**メモ:** 適度なデザインのカスタマイズは良いことです。あなたの 404 ページをユーモアや思いやりのあるものにすることは自由ですが、ユーザーを混乱させないようにしてください。

仕様書
---

| Specification |
| --- |
| HTTP Semantics # status.404 |

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

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

関連情報
----

* `410`
* Wikipedia: HTTP 404


502 Bad Gateway - HTTP

502 Bad Gateway
===============

HyperText Transfer Protocol (HTTP) の **`502 Bad Gateway`** サーバーエラーレスポンスコードは、ゲートウェイまたはプロキシとして機能しているサーバーが上流のサーバーから無効なレスポンスを受け取ったことを示しています。

**メモ:** ゲートウェイはネットワークの様々なものを指す可能性があり、 502 エラーは通常修正できるものではありませんが、ウェブサーバーまたはアクセスを中継させようとしているプロキシによる修正が必要です。

ステータス
-----
```

502 Bad Gateway
```

仕様書
---

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

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

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

以下に示す情報は、 MDN の GitHub から取得したものです。 (https://github.com/mdn/browser-compat-data).

関連情報
----

* `504`
* HTTP/1.1: Status Code Definitions


205 Reset Content - HTTP

205 Reset Content
=================

HTTP **`205 Reset Content`** のレスポンスステータスはクライアントにドキュメントビューをリセットするように指示します。たとえば、フォームの内容をクリアしたり、キャンバスの状態をリセットしたり、UI をリフレッシュすることができます。

ステータス
-----
```

205 Reset Content
```

仕様
--

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

互換性メモ
-----

* このレスポンスが永続的な接続上で誤って本文を含むと、ブラウザーの動作が異なります。詳細については 204 No Content を参照してください。
関連情報
----

* `204` No Content


400 Bad Request - HTTP

400 Bad Request
===============

HyperText Transfer Protocol (HTTP) の **`400 Bad Request`** レスポンスステータスコードは、何らかのクライアント側のエラーであると分かったために、サーバーがそのリクエストを処理しない (できない) ことを表します (例えば、リクエストの構文が正しくない、リクエストメッセージのフレーミングが無効、リクエスト経路に偽りがあるなど)。

**警告:** クライアントは変更なしにこのリクエストを繰り返すべきではありません。

ステータス
-----
```

400 Bad Request
```

仕様書
---

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

関連情報
----

* HTTP/1.1: Status Code Definitions


431 Request Header Fields Too Large - HTTP

431 Request Header Fields Too Large
===================================

HTTP の **`431 Request Header Fields Too Large`** レスポンスステータスコードは、リクエストの HTTP ヘッダーが長すぎるためにサーバーがリクエストの処理を拒否したことを示します。ヘッダーフィールドを縮小した上で、リクエストを再送信する*ことができます*。

431 はリクエストヘッダーの**全体の大きさ**が大きすぎる場合や、**単一の**ヘッダーフィールドが長すぎる場合に使用することができます。このエラーが発生した場合は、レスポンス本文でこの二つの問題のどちらであるかを示すと役立ちます。 — できれば、どのヘッダーが長すぎるのかも含めたほうがよいでしょう。これによってユーザーが、クッキーを消去するなど、問題の解決を試みることができます。

サーバーは次のような場合に、よくこのステータスを生成します。

* `Referer` の URL が長すぎる場合
* そのリクエストで送られた Cookie が多すぎる場合
ステータス
-----
```

431 Request Header Fields Too Large
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 6585, セクション 5: 431 Request Header Fields Too Large | Additional HTTP Status Codes |

関連情報
----

* `414 URI Too Long`
* Request header


307 Temporary Redirect - HTTP

307 Temporary Redirect
======================

HTTP の **`307 Temporary Redirect`** リダイレクトステータスレスポンスコードは、リクエストされたリソースが一時的に `Location` で示された URL へ移動したことを示します。

元のリクエストのメソッドと本文は、リダイレクトされたリクエストを行う際に再利用されます。使用されるメソッドを `GET` に変更したい場合は、代わりに `303 See Other` を使用してください。これは `PUT` メソッドへのレスポンスで、アップロードされたリソースではないところで「XYZ のアップロードに成功しました」のような確認メッセージを表示したい場合に便利です。

`307` と `302` の唯一の違いは、 `307` はリダイレクトされたリクエストが行われるときに、メソッドと本文が変更されないことが保証されることです。 `302` では、一部の古いクライアントは不正にメソッドを `GET` に変更してしまいます。 `GET` 以外のメソッドと `302` による挙動はウェブで予測することができず、 `307` の挙動は予測できます。 `GET` リクエストでは、両者の挙動は同じです。

ステータス
-----
```

307 Temporary Redirect
```

仕様書
---

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

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

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

関連情報
----

* `302 Found`: このステータスコードと同等ですが、 `GET` 以外の時にメソッドが変更されるかもしれない。
* `303 See Other`: 使用されるメソッドを `GET` に変更する一時リダイレクト。
* `301 Moved Permanently`: 永久リダイレクト


418 I'm a teapot - HTTP

418 I'm a teapot
================

HTTP の **`418 I'm a teapot`** クライアントエラーレスポンスコードは、サーバーが、自身がティーポットであることを理由としてコーヒーを入れることを拒否することを示します。コーヒーとティーの複合ポットで、一時的にコーヒーが提供できない場合は、代わりに 503 を返してください。このエラーは、1998 年のエイプリルフールのジョークである Hyper Text Coffee Pot Control Protocol に由来します。

一部のウェブサイトでは、自動化されたクエリなど、処理したくないリクエストに対してこのレスポンスを使用しています。

ステータス
-----
```

418 I'm a teapot
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 2324, セクション 2.3.2: 418 I'm a teapot | Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): Semantics and Content |
| RFC 7168, セクション 2.3.3: 418 I'm a teapot | The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA): Response Codes |

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

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

関連情報
----

* Wikipedia: Hyper Text Coffee Pot Control Protocol


201 Created - HTTP

201 Created
===========

HTTP の **`201 Created`** 成功ステータスレスポンスコードは、リクエストが成功してリソースの作成が完了したことを表します。レスポンスが返される前に、新たなリソースが作成され、レスポンスメッセージの本文にて新しいリソースが返されます。その位置はリクエスト URL、または `Location` ヘッダーの内容となります。

このステータスコードの一般的な使用例は、 `POST` リクエストの結果です。

状態
--
```

201 Created
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7231, セクション 6.3.2: 201 Created | 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 リクエストメソッド


429 Too Many Requests - HTTP

429 Too Many Requests
=====================

HTTP **`429 Too Many Requests`** レスポンスステータスコードは、ユーザーが指定された時間内に多くのリクエストを送信した ("rate limiting") ことを示します。

新しいリクエストを行う前にどのくらい待つかを示す `Retry-After` ヘッダをこのレスポンスに含めることができます。

ステータス
-----
```

429 Too Many Requests
```

例
-
```

HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 6585, セクション 4: 429 Too Many Requests | Additional HTTP Status Codes |

関連情報
----

* `Retry-After`
* HTTP/1.1: Status Code Definitions
* Python solution: How to avoid HTTP error 429 python


506 Variant Also Negotiates - HTTP

506 Variant Also Negotiates
===========================

The HyperText Transfer Protocol (HTTP) **`506 Variant Also Negotiates`** レスポンスステータスコードは、透過的コンテンツネゴシエーション (**transparent content negotiation**) のコンテキストで提供される場合があります (参照 RFC 2295)。このプロトコルは、サーバーが複数のバリアントに対応している場合に、クライアントが与えられたリソースの最良のバリアントを取得することを可能にします。

**`Variant Also Negotiates`** ステータスコードは、選択されたバリアント自体がコンテンツネゴシエーションに関与するように構成されているため、適切なネゴシエーションエンドポイントではない内部サーバー構成エラーを示します。

ステータス
-----
```

506 Variant Also Negotiates
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 2295, セクション 8.1: 506 Variant Also Negotiates | Transparent Content Negotiation in HTTP |


425 Too Early - HTTP

425 Too Early
=============

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

HTTP (HyperText Transfer Protocol) の **`425 Too Early`** レスポンスステータスコードは、サーバーがリプレイ攻撃の可能性を生み出すリプレイされた要求を処理するリスクを負わないことを示します。

ステータス
-----
```

425 Too Early
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 8470, セクション 5.2: 425: Early Data | Using Early Data in HTTP |

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

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


103 Early Hints - HTTP

103 Early Hints
===============

HTTP **`103 Early Hints`** インフォメーションレスポンスステータスコードは、主に `Link` ヘッダーと共に使用され、サーバーがまだレスポンスを準備している間にユーザーエージェントがリソースのプリロードを開始できるようにすることを目的としています。

構文
--
```

103 Early Hints
```

仕様
--

| 仕様書 | ステータス | コメント |
| --- | --- | --- |
| RFC 8297: 103 Early Hints | IETF RFC | 初期定義 |

ブラウザーの実装状況
----------

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

関連情報
----

* `Link`


414 URI Too Long - HTTP

414 URI Too Long
================

HTTP の **`414 URI Too Long`** レスポンスステータスコードは、クライアントがリクエストした URL が、サーバーが解釈しようとするものよりも長いことを示します。

これが発生する条件はわずかです。

* クライアントが、 `POST` リクエストを長いクエリー文字列をもつ `GET` リクエストに変換した場合。
* クライアントがリダイレクトのループに陥った場合 (たとえば、リダイレクトされた URL 接頭辞が自分自身の接尾辞を指していた場合や、受け取った URL の扱いを誤った場合)。
* 潜在的なセキュリティホールを利用しようとしているクライアントがサーバーを攻撃している場合などです。
ステータス
-----
```

414 URI Too Long
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7231, セクション 6.5.12: 414 URI Too Long | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

関連情報
----

* `431 Request Header Fields Too Large`
* URI


410 Gone - HTTP

410 Gone
========

HyperText Transfer Protocol (HTTP) の **`410 Gone`** クライエントエラーレスポンスコードは、元のサーバーで利用できなくなっている対象リソースにアクセスしていることを示します。この状態は永久的です。

この状態が一時的なものか永久なのか分からない場合は、代わりに `404` ステータスコードを使用してください。

**メモ:** 410 レスポンスは既定でキャッシュ可能です。

ステータス
-----
```

410 Gone
```

仕様書
---

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

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

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

以下に示す情報は、 MDN の GitHub から取得したものです。 (https://github.com/mdn/browser-compat-data).

関連情報
----

* `404`


421 Misdirected Request - HTTP

421 Misdirected Request
=======================

HTTP **`421 Misdirected Request`** クライエントエラーレスポンスコードは、リクエストがレスポンスを生成できないサーバーに送られたことを示します。これは、接続が再利用されたり、代替サービスが選択されたとき起こり得ます。

ステータス
-----
```

421 Misdirected Request
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # name-421-misdirected-request |


408 Request Timeout - HTTP

408 Request Timeout
===================

HyperText Transfer Protocol (HTTP) **`408 Request Timeout`** レスポンスステータスコードはサーバーがこの未使用のコネクションをシャットダウンすることを意味します。 *クライアントからの以前のリクエストがなくても*、一部のサーバーによってアイドル状態のコネクションで送信されます。

`408` はサーバーがコネクションを待機し続けるのではなく、閉じることを決定することを意味しているため、サーバーはレスポンスで "close" `Connection` ヘッダーフィールドを送信する必要があります。

このレスポンスは HTTP 事前接続メカニズム使用してサーフィンを高速化するために、Chrome や、Firefox 27+、IE9 などの、いくつかのブラウザーでよく利用されます。

**メモ:** このメッセージを送信せずに接続をシャットダウンするサーバーもあります。

ステータス
-----
```

408 Request Timeout
```

仕様
--

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

参照
--

* `Connection`
* `X-DNS-Prefetch-Control`


424 Failed Dependency - HTTP

424 Failed Dependency
=====================

HTTP **`424 Failed Dependency`** クライエントエラーレスポンスコードは、要求されたアクションが他のアクションに依存しており、そのアクションが失敗したため、対象のリソースに対してメソッドを実行できなかったことを示します。

普通のウェブサーバーがこのステータスコードを返すことは通常ありません。しかし、WebDAV などの他のプロトコルが返すことはあります。たとえば、WebDAV では、`PROPPATCH` 要求が発行され、あるコマンドが失敗した場合は、他のコマンドも自動的に `424 Failed Dependency` で失敗します。

ステータス
-----
```

424 Failed Dependency
```

仕様書
---

| Specification |
| --- |
| RFC 4918 # section-11.4 |

関連情報
----

* `403` (Forbidden)


415 Unsupported Media Type - HTTP

415 Unsupported Media Type
==========================

HTTP **`415 Unsupported Media Type`** クライアントエラーレスポンスコードは、ペイロードフォーマットがサポートされていないフォーマットであるため、サーバーがリクエストの受け入れを拒否することを示します。

フォーマットの問題はリクエストされた `Content-Type` または `Content-Encoding` によるものか、または直接データを検査した結果に起因する可能性があります。

ステータス
-----
```

415 Unsupported Media Type
```

仕様
--

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

関連情報
----

* `Content-Type`
* `Content-Encoding`
* `Accept`


102 Processing - HTTP

102 Processing
==============

**非推奨:** この機能は非推奨になりました。まだ対応しているブラウザーがあるかもしれませんが、すでに関連するウェブ標準から削除されているか、削除の手続き中であるか、互換性のためだけに残されている可能性があります。使用を避け、できれば既存のコードは更新してください。このページの下部にある互換性一覧表を見て判断してください。この機能は突然動作しなくなる可能性があることに注意してください。

HTTP **`102 Processing`** 情報ステータスレスポンスコードは、リクエスト全体が受信され、サーバーがそれを処理中であることをクライアントに示します。

このステータスコードは、リクエストの処理に長時間かかるとサーバーが判断した場合のみ送信されます。これは、クライアントにリクエストがまだ死んでいないことを伝えます。

**メモ:** このステータスコードは非推奨になっており、もう送られるべきではありません。クライアントはまだ受け入れる可能性がありますが、単純に無視します。

ステータス
-----
```

102 Processing
```

仕様書
---

| Specification |
| --- |
| Unknown specification # section-10.1 |

関連情報
----

* `Expect`
* `100`


411 Length Required - HTTP

411 Length Required
===================

HyperText Transfer Protocol (HTTP) **`411 Length Required`** クライアントエラーレスポンスコードは、サーバーが定義された `Content-Length` ヘッダーのないリクエストの受け入れを拒否することを示します。

**メモ:** 仕様によっては、一連のチャンクでデータを送信する場合 `Content-Length` ヘッダは省略され、各チャンクの先頭に、現在のチャンクの長さを 16 進形式で追加する必要があります。詳細は `Transfer-Encoding` を参照してください。

ステータス
-----
```

411 Length Required
```

仕様
--

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

関連情報
----

* `Content-Length`
* `Transfer-Encoding`


208 Already Reported - HTTP

208 Already Reported
====================

**メモ:** いくつかのパスにリソースを *バインド* する機能は WebDAV プロトコルの拡張です。(WebDAV サーバーにアクセスしているウェブアプリケーションが受信する可能性があります) ウェブページにアクセスしているブラウザーがこのステータスコードを受け取ることは無いでしょう。

 HTTP **`208 Already Reported`** レスポンスコードは、容量を節約し、競合を防ぐため、`207` (`207 Multi-Status`) レスポンスで用いられます。
 同じリソースが (たとえばコレクションの一部として) 異なるパスで複数回要求された場合、最初のもののみ `200` で報告されます。
 それ以外のすべてのバインディングへのレスポンスはこの `208` ステータスコードで報告されるので、競合を起こさず、レスポンスは短く保たれます。

ステータス
-----
```

208 Already Reported
```

例
-

```http
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 1241

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>http://www.example.com/Coll/</D:href>
    <D:propstat>
      <D:prop>
        <D:displayname>Loop Demo</D:displayname>
        <D:resource-id>
          <D:href>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
        </D:resource-id>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>http://www.example.com/Coll/Foo</D:href>
    <D:propstat>
      <D:prop>
        <D:displayname>Bird Inventory</D:displayname>
        <D:resource-id>
          <D:href>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9</D:href>
        </D:resource-id>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>http://www.example.com/Coll/Bar</D:href>
    <D:propstat>
      <D:prop>
        <D:displayname>Loop Demo</D:displayname>
        <D:resource-id>
          <D:href>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
        </D:resource-id>
      </D:prop>
      <D:status>HTTP/1.1 208 Already Reported</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>
```

仕様書
---

| Specification |
| --- |
| Unknown specification # section-7.1 |

関連情報
----

* `200`


409 Conflict - HTTP

409 Conflict
============

HTTP **`409 Conflict`** はリクエストが現在のサーバーの状態と競合したことを示すステータスコード。

競合は `PUT` メソッドを使用したリクエストのレスポンスで最も発生しやすい。例えば、サーバーにすでに存在しているファイルよりも古いバージョンのファイルをアップロードした際に 409 の応答が返され、バージョン管理システムの競合が発生する可能性がある。

ステータス
-----
```

409 Conflict
```

仕様
--

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

参照
--

* `PUT`


302 Found - HTTP

302 Found
=========

HyperText Transfer Protocol (HTTP) の **`302 Found`** リダイレクトステータスレスポンスコードは、リクエストされたリソースが一時的に `Location` で示された URL へ移動したことを示します。ブラウザーはこのページにリダイレクトしますが、検索エンジンはリソースへのリンクを更新しません (「SEO 用語」では、「リンクジュース」が新しい URL に送られなかったと言われます)。

仕様書ではリダイレクトの際にメソッド (と本文) を変更しないよう要求していますが、すべてのユーザーエージェントが準拠している訳ではありません (まだこの種のバグのあるソフトウェアが見つかるでしょう)。従って、 `302` コードは `GET` または `HEAD` メソッドへのレスポンスのみに使用し、 `POST` メソッドのままリダイレクトする場合は代わりに `307 Temporary Redirect` (こちらでは明確にメソッドの変更が禁止されている) を使用することが推奨されています。

使用されるメソッドを `GET` に変更したい場合は、代わりに `303 See Other` を使用してください。これは `PUT` メソッドへのレスポンスとして、アップロードされたリソースではなく「XYZ のアップロードに成功しました」のような確認メッセージを表示したい場合に便利です。

ステータス
-----

```html
302 Found
```

仕様書
---

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

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

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

関連情報
----

* `307 Temporary Redirect` 使用されたメソッドが変更されない場面では、このステータスコードと等価。
* `303 See Other` メソッドを `GET` に変更する一時リダイレクト。
* `301 Moved Permanently` 永久リダイレクト


405 Method Not Allowed - HTTP

405 Method Not Allowed
======================

HyperText Transfer Protocol (HTTP) の **`405`** `Method Not Allowed` レスポンスステータスコードは、リクエストメソッドをサーバー側で認識しているが、対象のリソースでは対応していないことを示します。

サーバーは 405 レスポンスで、対象のリソースで現在対応しているメソッドの一覧を含む **`Allow`** ヘッダー欄を生成しなければなりません。

ステータス
-----
```

405 Method Not Allowed
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 7231, セクション 6.5.5: 405 Method Not Allowed | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

関連情報
----

* `Allow`
* HTTP/1.1: Status Code Definitions
* How to Fix 405 Method Not Allowed
* Troubleshooting HTTP 405


503 Service Unavailable - HTTP

503 Service Unavailable
=======================

HyperText Transfer Protocol (HTTP) の **`503 Service Unavailable`** サーバーエラーレスポンスコードで、サーバーがリクエストを処理する準備ができていないことを示します。

一般的な原因は、サーバーがメンテナンス中のために停止していることや、過負荷状態になっていることです。このレスポンスは、一時的な条件に使用する必要があり、 `Retry-After` HTTP ヘッダーには、もし可能であれば、サービスの復旧に要する予想時間を含めるべきです。

**メモ:** このレスポンスと共に、問題を分かりやすく説明するページを送信する必要があります。

503 のステータスはしばしば一時的な状態であり、レスポンスは頻繁にキャッシュされるべきではないため、このレスポンスと共に送信されるキャッシュ関連のヘッダーは注意する必要があります。

ステータス
-----
```

503 Service Unavailable
```

仕様書
---

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

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

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

以下に示す情報は、 MDN の GitHub から取得したものです。 (https://github.com/mdn/browser-compat-data).

関連情報
----

* `Retry-After`
* HTTP/1.1: Status Code Definitions


204 No Content - HTTP

204 No Content
==============

HTTP の **`204 No Content`** は成功ステータスレスポンスコードで、リクエストが成功したものの、クライアントが現在のページから移動する必要がないことを示します。

 これは例えば、ウィキサイトで「保存して編集を続ける」機能を実装するときに使用される可能性があります。
 この場合、ページを保存するために `PUT` リクエストが使用されますが、エディターが他のページに置き換えられるべきではないことを示すために `204 No Content` レスポンスが送信されるものです。

レスポンスコード 204 が返された場合は、既定でキャッシュ可能になっています（そのようなレスポンスには、`ETag` ヘッダーが含まれています）。

ステータス
-----

```http
204 No Content
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # status.204 |

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

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

### 互換性のメモ

* このステータスコードは本体を持たないレスポンスを記述することを意図していますが、サーバーは誤ってヘッダーの後にデータを出力することがあります。プロトコルは、ユーザーエージェントがそのようなレスポンスを様々な方法で処理することを許しています（この仕様のテキストに関する議論はこちらで見られます）。これは、持続的な接続において後続のリクエストに対する明確なレスポンスが無効な本体に含まれてしまう場合に顕著になります。
 Apple Safari はそのようなデータを拒否します。Google Chrome と Microsoft Edge は、有効なレスポンスの前にある無効な最大 4 バイトを破棄します。Firefox は、有効なレスポンスの前にある 1 キロバイトを超える無効なデータを許容します。
関連情報
----

* HTTP リクエストのメソッド


401 Unauthorized - HTTP

401 Unauthorized
================

HTTP **`401 Unauthorized`** は、有効な認証資格が不足していることによりリクエストが適用されないことを示すクライアントエラーのレスポンスコードです。

このステータスは、正しい認証方法を含む `WWW-Authenticate` ヘッダーとともに送信されます。

このステータスは `403` に似ていますが、この場合は再認証が可能です。

ステータス
-----
```

401 Unauthorized
```

例
-
```

HTTP/1.1 401 Unauthorized
Date: Wed, 21 Oct 2015 07:28:00 GMT
WWW-Authenticate: Basic realm="Access to staging site"
```

仕様
--

| 仕様 | タイトル |
| --- | --- |
| RFC 7235, セクション 3.1: 401 Unauthorized | HTTP/1.1: Authentication |

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

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

参照
--

* HTTP authentication
* `WWW-Authenticate`
* `Authorization`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `403`, `407`


200 OK - HTTP

200 OK
======

HTTP **`200 OK`** はリクエストが成功した場合に返すレスポンスコード。200 のレスポンスはデフォルトでキャッシュしてよい。

成功したという意味はリクエストのメソッドによって異なる:

* `GET`: リソースがフェッチされメッセージのボディ部で返送された。
* `HEAD`: エンティティヘッダがボディ部で返送された。
* `POST`: 実行された結果が記載されたリソースがボディ部で返送された。
* `TRACE`: メッセージのボディ部にサーバーで受信したリクエストメッセージを含んでいる。

`PUT` や `DELETE` の成功結果は `200` `OK` ではなく、 `204` `No Content` (や、リソースの初回アップロードによる作成の場合は `201` `Created` )である場合もある。

ステータス
-----
```

200 OK
```

仕様
--

| 仕様 | タイトル |
| --- | --- |
| RFC 7231, セクション 6.3.1: 200 OK | 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 request methods


507 Insufficient Storage - HTTP

507 Insufficient Storage
========================

The HyperText Transfer Protocol (HTTP) **`507 Insufficient Storage`** レスポンスステータスコードは、Web Distributed Authoring and Versioning (WebDAV) プロトコルのコンテキストで提供される場合があります。 (参照 RFC 4918)

サーバーが、リクエストを正常終了するために必要な表現を保存できないため、メソッドを実行できなかったことを示します。

ステータス
-----
```

507 Insufficient Storage
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 4918, セクション 11.5: 507 Insufficient Storage | Web Distributed Authoring and Versioning |


428 Precondition Required - HTTP

428 Precondition Required
=========================

HTTP **`428 Precondition Required`** レスポンスステータスコードは、サーバーがリクエストを条件付きにする必要があることを示します。

通常、これは `If-Match` のような必須の前提条件ヘッダーが**ない**ことを意味します。

前提条件ヘッダーがサーバー側の状態と**一致しない**場合、レスポンスは `412` `Precondition Failed` である必要があります。

ステータス
-----
```

428 Precondition Required
```

仕様
--

| 仕様書 | タイトル |
| --- | --- |
| RFC 6585, セクション 3: 428 Precondition Required | Additional HTTP Status Codes |

関連情報
----

* HTTP conditional requests
* `If-Match`
* `412`


CSP のエラーと警告 (Content Security Policy) - HTTP

CSP のエラーと警告 (Content Security Policy)
=====================================

このページは CSP のエラーと警告に関する記事を参照する親となり、概要を示したり、可能であれば問題解決の一般的な助言をしたりします。

エラー一覧
-----

* The page's settings blocked the loading of a resource: %1$S
* The page's settings blocked the loading of a resource at %2$S ("%1$S").
* A violation occurred for a report-only CSP policy ("%1$S"). The behavior was allowed, and a CSP report was sent.
* The page's settings observed the loading of a resource at %2$S ("%1$S"). A CSP report is being sent.
* Tried to send report to invalid URI: "%1$S"
* couldn't parse report URI: %1$S
* Couldn't process unknown directive '%1$S'
* Ignoring unknown option %1$S
* Ignoring duplicate source %1$S
* Ignoring source '%1$S' (Not supported when delivered via meta element).
* Ignoring "%1$S" within script-src or style-src: nonce-source or hash-source specified
* Ignoring "%1$S" within script-src: 'strict-dynamic' specified
* Ignoring source "%1$S" (Only supported within script-src).
* Keyword 'strict-dynamic' within "%1$S" with no valid nonce or hash might block all scripts from loading
* The report URI (%1$S) should be an HTTP or HTTPS URI.
* This site (%1$S) has a Report-Only policy without a report URI. CSP will not block and cannot report violations of this policy.
* Failed to parse unrecognized source %1$S
* An attempt to execute inline scripts has been blocked
* An attempt to apply inline style sheets has been blocked
* An attempt to call JavaScript from a string (by calling a function like eval) has been blocked
* Upgrading insecure request '%1$S' to use '%2$S'
* Ignoring srcs for directive '%1$S'
* Interpreting %1$S as a hostname, not a keyword. If you intended this to be a keyword, use '%2$S' (wrapped in single quotes).
* Not supporting directive '%1$S'. Directive and values will be ignored.
* Blocking insecure request '%1$S'.
* Ignoring '%1$S' since it does not contain any parameters.
* Ignoring sandbox directive when delivered in a report-only policy '%1$S'
* Referrer Directive '%1$S' has been deprecated. Please use the Referrer-Policy header instead.
* Ignoring '%1$S' because of '%2$S' directive.
* Couldn't parse invalid source %1$S
* Couldn't parse invalid host %1$S
* Couldn't parse scheme in %1$S
* Couldn't parse port in %1$S
* Duplicate %1$S directives detected. All but the first instance will be ignored.
* Directive '%1$S' has been deprecated. Please use directive 'worker-src' to control workers, or directive 'frame-src' to control frames respectively.
* Couldn't parse invalid sandbox flag '%1$S'


Content Security Policy: The page's settings blocked the loading of a resource: xyz - HTTP

Content Security Policy: The page's settings blocked the loading of a resource: xyz
===================================================================================

警告 "Content Security Policy: The page's settings blocked the loading of a resource: xyz" は、`xyz` で指定されたページの CSP 設定が、文書のコンテキストにリソースが読み込まれるのを妨げた場合に発生します。

エラーメッセージ
--------

### Firefox

`Content Security Policy: The pages settings blocked the loading of a resource: xyz`

ここで、

`xyz`

リソースをブロックした CSP ディレクティブの名前です。これはディレクティブの名前そのものか、ポリシーのディレクティブ文字列全体で表される可能性があります。

`uvw`

問題を解決するのに役立つ可能性がある情報を提供する文字列であり、CSP 構成に行う可能性がある特定の変更を含むこともあります。

### Chrome

* `Refused to apply inline style because it violates the following Content Security Policy Directive: "xyz". uvw.`
* `Refused to execute inline script because it violates the following Content Security Policy directive: "xyz". uvw.`
* `Refused to run the JavaScript URL because it violates the following Content Security Policy directive: "xyz". uvw.`
* `Refused to execute inline event handler because it violates the following Content Security Policy directive: "xyz". uvw.`

ここで、

`xyz`

リソースをブロックした CSP ディレクティブの名前です。これはディレクティブの名前そのものか、ポリシーのディレクティブ文字列全体で表される可能性があります。

`uvw`

問題を解決するのに役立つ可能性がある情報を提供する文字列であり、CSP 構成に行う可能性がある特定の変更を含むこともあります。

エラーの原因
------

この警告メッセージは、特定の CSP ディレクティブが存在するためにリソースが読み込まれなかったことを意味します。

関連情報
----

* CSP のエラーと警告
* コンテンツセキュリティポリシー
* `Content-Security-Policy`
* `Content-Security-Policy-Report-Only`


CORS のエラー - HTTP

CORS のエラー
=========

オリジン間リソース共有 (Cross-Origin Resource Sharing) (CORS) は、サーバーが同一オリジンポリシーを緩和することができる標準規格です。例えば、サイトが埋め込み可能なサービスを提供する場合、このような制約を緩和する必要があるかもしれません。このような CORS の構成の設定は必ずしも簡単ではなく、いくらか冒険的です。これらのページでは、よくある CORS のエラーメッセージと解決方法を調査します。

CORS 構成が正しく設定されていないと、ブラウザーのコンソールには `"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"` のようなエラーを表示して、リクエストが CORS のセキュリティ規則を侵害しているためにブロックされたことを示します。これは必ずしも設定ミスとは限りません。実際には、ユーザーのウェブアプリケーションおよびリモートの外部サービスからのリクエストが、意図的に許可されていない場合もあります。ただし、エンドポイントが使用可能である場合、成功するためにはデバッグが必要です。

問題の識別
-----

CORS の構成に関する問題を理解するために、どのリクエストが、なぜ失敗したのかを調べる必要があります。そのためには以下の手順が役立つかもしれません。

1. 問題のウェブサイトやウェブアプリを実行し、開発者ツールを開く。
2. 失敗するトランザクションを再現してみて、コンソールで CORS 違反エラーメッセージが表示されるかを調べる。おそらく次のように見える。

![CORS エラーを表示している Firefox コンソール](/ja/docs/Web/HTTP/CORS/Errors/cors-error2.png)

エラーメッセージのテキストは以下のようなものになるでしょう。
```

Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at https://some-url-here. (Reason:
additional information here).
```

**メモ:** セキュリティ上の理由から、 CORS リクエストで何を失敗したかについては *JavaScript コードからは特定できません*。コードから分かることは、エラーが発生したことだけです。何を失敗したかを特定するための唯一の方法は、詳細をブラウザーのコンソールで見ることです。

CORS のエラーメッセージ
--------------

Firefox のコンソールは、 CORS のためにリクエストが失敗した場合はコンソールにメッセージを表示します。エラーテキストには、何が失敗したのかの分析が追加された「reason」の部分があります。 reason のメッセージは以下の通りです。メッセージをクリックすると、エラーをより詳細に説明し、可能な解決方法を提供する記事を開くことができます。

* Reason: CORS disabled
* Reason: CORS request did not succeed
* Reason: CORS header 'Origin' cannot be added
* Reason: CORS request external redirect not allowed
* Reason: CORS request not http
* Reason: CORS header 'Access-Control-Allow-Origin' missing
* Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
* Reason: Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '\*'
* Reason: Did not find method in CORS header 'Access-Control-Allow-Methods'
* Reason: expected 'true' in CORS header 'Access-Control-Allow-Credentials'
* Reason: CORS preflight channel did not succeed
* Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'
* Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Headers'
* Reason: missing token 'xyz' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel
* Reason: Multiple CORS header 'Access-Control-Allow-Origin' not allowed
関連情報
----

* 用語集: CORS
* CORS 入門
* サーバー側 CORS 設定
* CORS 有効化の画像
* CORS の設定属性
* https://www.test-cors.org – CORS リクエストの試験ページ


Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’ - HTTP

Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’
=========================================================================

理由
--
```

Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’
```

何に失敗したか
-------

サーバーから送信された CORS 要求への応答に、一つ以上の無効なメソッド名を含んだ `Access-Control-Allow-Methods` ヘッダーが含まれています。

`Access-Control-Allow-Methods` ヘッダーは、どの HTTP 要求メソッドが CORS 要求に対応しているかをクライアントに知らせます。ヘッダーの値は、`GET`, `POST`, `HEAD` のような HTTP メソッド名をコンマで区切った文字列です。クライアントのユーザーエージェントが指定された値を理解できない場合、このエラーが発生します。

これはほとんどはサーバー側でしか修正できない問題であり、サーバーの構成を変更して、 `Access-Control-Allow-Methods` ヘッダーから無効又は未知のメソッド名を送らないようにします。クライアントで使用しているユーザーエージェントの HTTP ライブラリが最新版であるかどうかをチェックするのも良いかもしれません。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門
* HTTP ヘッダー


Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz' - HTTP

Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
======================================================================

理由
--
```

Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
```

何が悪いのか
------

リクエストを作成しているオリジンが、 `Access-Control-Allow-Origin` ヘッダーによって許可されたオリジンのいずれにも一致しないことを表します。このエラーは、レスポンスに複数の `Access-Control-Allow-Origin` ヘッダーが含まれていると発生することがあります。

コードが CORS リクエストを使用してアクセスしているサービスが管理下にあるのであれば、 `Access-Control-Allow-Origin` ヘッダーがそのアクセス元が含むように構成されていること、及びそのヘッダーがレスポンス内に 1 つしか含まれていないことを確認してください。ヘッダー自体はコンマ区切りで複数のオリジンを受け付けるので、新しいオリジンを追加することは難しくはありません。

例えば Apache では、サーバー構成（の中の `<Directory>`, `<Location>`, `<Files>`, `<VirtualHost>` のうち適切な節）に次のような行を追加してください。構成はふつう、 `.conf` ファイルまたは（一般的な名前は `httpd.conf` や `apache.conf`）または `.htaccess` ファイルにあります。

**警告:** オリジンの一部として HTTPS または HTTP プロトコルを記載する必要があります。
```

Header set Access-Control-Allow-Origin 'origin'
```

Nginx では、このヘッダーを設定するコマンドは次の通りです。
```

add_header 'Access-Control-Allow-Origin' 'origin'
```

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門
* Enable CORS: I want to add CORS support to my server


Reason: CORS header 'Access-Control-Allow-Origin' missing - HTTP

Reason: CORS header 'Access-Control-Allow-Origin' missing
=========================================================

理由
--
```

Reason: CORS header 'Access-Control-Allow-Origin' missing
```

何が悪いのか
------

CORS リクエストへのレスポンスが、リソースが現在のオリジン内で操作しているコンテンツによってアクセスできるかどうかを判断するために使われる、必須の `Access-Control-Allow-Origin` ヘッダーを欠いています。

サーバーを自分で制御できる場合は、要求しているサイトのオリジンを `Access-Control-Allow-Origin` ヘッダーの値に追加して、アクセスが許可されているドメインの一覧に追加してください。

例えば、 `https://amazing.site` のサイトが CORS を使用したリソースにアクセスできるよう許可するためには、ヘッダーを以下のようにしてください。
```

Access-Control-Allow-Origin: https://amazing.site
```

`*` を使用することで、あらゆるサイトにアクセスを許可するようサイトを構成することもできます。これは公開 API にのみ使用してください。非公開の API には `*` を使用するべきではなく、代わりに具体的なドメインやドメインの一覧を設定してください。加えて、ワイルドカードは `crossorigin` 属性が `anonymous` に設定された要求にのみ動作し、リクエストでは Cookie のような資格情報の送信を抑制します。
```

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

**警告:** ワイルドカードを使用して、非公開の API へのアクセスをすべてのサイトに許可することは、悪い考えです。

何らかのサイトが CORS リクエストを `*` ワイルドカードを使用すること*なく* (たとえば資格情報を有効にする場合) 利用できるようにするには、サーバーにリクエストの `Origin` ヘッダーの値を読み取り、その値を `Access-Control-Allow-Origin` に設定することに加えて、一部のヘッダーがオリジンに応じて動的に設定されることを示すために `Vary: Origin` ヘッダーを設定する必要があります。

例えば Apache では、サーバー構成 (の中の `<Directory>`, `<Location>`, `<Files>`, `<VirtualHost>` のうち適切な節) に次のような行を追加してください。構成はふつう、 `.conf` ファイル又は (一般的な名前は `httpd.conf` や `apache.conf`) 又は `.htaccess` ファイルにあります。
```

Header set Access-Control-Allow-Origin 'origin-list'
```

Nginx では、このヘッダーを設定するコマンドは次の通りです。
```

add_header 'Access-Control-Allow-Origin' 'origin-list'
```

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門


Reason: CORS request did not succeed - HTTP

Reason: CORS request did not succeed
====================================

理由
--
```

Reason: CORS request did not succeed
```

何に失敗したか
-------

CORS を使用した HTTP 要求が、ネットワークまたはプロトコルレベルで HTTP 接続に失敗したために失敗しました。エラーは CORS に直接関連したものではなく、ある種の基本的なネットワークエラーです。

多くの場合、ブラウザーのプラグイン (例えば広告ブロッカーやプライバシー保護) がリクエストをブロックしたときに発生します。

その他の可能性のある原因は以下の通りです。

* 無効な資格情報を用いて `https` のリソースにアクセスしようとすると、このエラーが発生します。
* `http` のリソースに `https` のオリジンのページからアクセスしようとした場合も、このエラーが発生します。
* Firefox 68 では、 `https` のページが `http://localhost` へアクセスすることが禁止されていますが、これは Bug 1488740 で変更される可能性があります。
* サーバーが (プリフライトリクエストに応答したのに) 実際のリクエストには応答しなかった場合。開発中の HTTP サービスが何もデータを返さずに異常停止した場合などが考えられます。
関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門


Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’ - HTTP

Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’
=========================================================================

理由
--
```

Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’
```

何が悪いのか
------

CORS リクエストが認証情報を使用してサーバーの許可を要求されていますが、サーバーの `Access-Control-Allow-Credentials` ヘッダーの値が `true` に設定されておらず、利用できるようになっていません。

この問題をクライアント側で解決するには、コードを修正して認証情報を使用せずにリクエストするようにしてください。

* リクエストが `XMLHttpRequest` を用いて発行されている場合は、 `withCredentials` に `true` を設定しないよう確認してください。
* Server-sent event を使用している場合は、 `EventSource.withCredentials` が `false` (既定値) であることを確認してください。
* Fetch API を使用している場合は、 `Request.credentials` が `"omit"` であることを確認してください。

サーバーの構成を変更してこのエラーを除去するには、サーバーの構成で `Access-Control-Allow-Credentials` ヘッダーの値に `true` を設定するよう調整してください。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門


Reason: Multiple CORS header 'Access-Control-Allow-Origin' not allowed - HTTP

Reason: Multiple CORS header 'Access-Control-Allow-Origin' not allowed
======================================================================

理由
--
```

Reason: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed
```

何が悪いのか
------

複数の `Access-Control-Allow-Origin` ヘッダーがサーバから送信されました。これは許可されていません。

サーバーへのアクセス権があるのであれば、実装を変更して `Access-Control-Allow-Origin` ヘッダーでオリジンを返すようにしてください。ブラウザーは単一のオリジンか null のどちらかの値しか受け付けないので、オリジンのリストを送り返すことはできません。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門
* Enable CORS: I want to add CORS support to my server


Reason: CORS header ‘Origin’ cannot be added - HTTP

Reason: CORS header ‘Origin’ cannot be added
============================================

理由
--
```

Reason: CORS header ‘Origin’ cannot be added
```

何が悪いのか
------

ユーザーエージェントが必要な `Origin` を HTTP リクエストに追加することができませんでした。すべての CORS リクエストは `Origin` ヘッダーを含んでいなければなりません。

これは例えば、 JavaScript のコードが複数のドメインのコンテンツにアクセスできるよう高い権限で実行されている場合などに起こることがあります。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門


Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’ - HTTP

Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘\*’
============================================================================================

理由
--
```

Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’
```

何が悪いのか
------

CORS リクエストが認証フラグ付きで試みられましたが、サーバーが `Access-Control-Allow-Origin` の値としてワイルドカード (`"*"`) を使用して構成されており、認証情報を利用することが許可されていません。

この問題をクライアント側で修正するには、 CORS リクエストを発行する際に認証フラグの値を確実に `false` にするだけです。

* リクエストが `XMLHttpRequest` を用いて発行されている場合は、 `withCredentials` に `true` を設定しないよう確認してください。
* Server-sent event を使用している場合は、 `EventSource.withCredentials` が `false` (既定値) であることを確認してください。
* Fetch API を使用している場合は、 `Request.credentials` が `"omit"` であることを確認してください。

サーバーの動作を調整する必要がある場合は、 `Access-Control-Allow-Origin` の画像を変更して、クライアントが読み込まれたオリジンへのアクセスを許可する必要があるでしょう。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門


Reason: CORS disabled - HTTP

Reason: CORS disabled
=====================

理由
--
```

Reason: CORS disabled
```

何に失敗したか
-------

CORS を使う必要がある要求が行われましたが、ユーザーのブラウザーで CORS が無効になっています。これが発生した場合、ブラウザーの CORS を有効に戻す必要があります。

Firefox では、 CORS を無効にする設定は `content.cors.disable` です。これを `true` に設定すると CORS が無効になり、この場合は常に、 CORS 要求は常にこのエラーで失敗します。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門


Reason: CORS request not HTTP - HTTP

Reason: CORS request not HTTP
=============================

理由
--
```

Reason: CORS request not HTTP
```

何が悪いのか
------

CORS リクエストは URL スキームが HTTPS の場合のみ利用できますが、リクエストで指定された URL が異なる種類のものです。これは、ローカルファイルを指定する URL が、 `file:///` の URL を使用している場合によく起こります。

この問題を修正するには、単純に CORS に関するリクエストを発行する際に HTTPS の URL を使用するようにしてください。

### Firefox 68 におけるローカルファイルセキュリティ

Firefox 67 以前ではユーザが `file:///` URI を用いてページを開いたとき、ページのオリジンはその開かれたページのあるディレクトリとして定義されていました。同じディレクトリやそのサブディレクトリにあるリソースは、CORS 同一オリジンルールを適用する際には同一オリジンとみなされていました。

Firefox 68 以降では CVE-2019-11730 の対策として、 `file:///` URI を用いて開かれたページのオリジンは、それだけのものとして定義されます。つまり、同じディレクトリやそのサブディレクトリにあるリソースは、CORS 同一オリジンルールを満たさなくなりました。この新たな振る舞いは、`privacy.file_unique_origin` 設定を用いてデフォルトで有効になっています。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門
* URL とは


Reason: CORS request external redirect not allowed - HTTP

Reason: CORS request external redirect not allowed
==================================================

理由
--
```

Reason: CORS request external redirect not allowed
```

何が悪いのか
------

CORS リクエストに対して、サーバーが元のリクエストとは異なるオリジンの URL へのリダイレクトを返答しましたが、これは CORS リクエストでは許可されていません。

例えば、 `https://service.tld/fetchdata` のページがリクエストされ、 HTTP レスポンスが "301 Moved Permanently" 又は "307 Temporary Redirect" 又は "308 Permanent Redirect" で、 `Location` が `https://anotherservice.net/getdata` であった場合、この理由で CORS リクエストが失敗します。

問題を修正するには、リダイレクトによって報告された新しい URL を使用するようにコードを更新し、リダイレクトを回避します。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門


Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ - HTTP

Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’
=========================================================================

理由
--
```

Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’
```

何に失敗したか
-------

サーバーから送信された CORS 要求への応答に、一つ以上の無効なヘッダー名を含んだ `Access-Control-Allow-Headers` ヘッダーが含まれています。

`Access-Control-Allow-Headers` ヘッダーは、プリフライト要求への応答の中でサーバーから送信されます。これはどの HTTP ヘッダーが CORS 要求で許可されているかをクライアントに知らせます。クライアントのユーザーエージェントが、このヘッダーで示されたコンマで区切られた値の中から理解できないヘッダーがあれば、このエラーが発生します。

これはほとんどはサーバー側でしか修正できない問題であり、サーバーの構成を変更して、 `Access-Control-Allow-Headers` ヘッダーから無効又は未知のヘッダー名を送らないようにします。クライアントで使用しているユーザーエージェントの HTTP ライブラリが最新版であるかどうかをチェックするのも良いかもしれません。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門
* HTTP ヘッダー


Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel - HTTP

Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel
=====================================================================================================

理由
--
```

Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel
```

何に失敗したのか
--------

`Access-Control-Allow-Headers` ヘッダーがサーバーから送信され、どのヘッダーが CORS 要求に対応しているかを知らせます。 `Access-Control-Allow-Headers` の値はコンマ区切りのヘッダー名のリストで、 "`X-Custom-Information`" やその他の標準的かつ基本的ではないヘッダー名 (常に許可されているもの) を記述します。

このエラーは明確に許可されていないヘッダー (すなわち、サーバーから送られる `Access-Control-Allow-Headers` ヘッダーで指定されたリストに含まれていないもの) のプリフライトリクエストを行おうとしたときに発生します。これを修正するには、サーバーが指定されたヘッダーを許可するように更新するか、このヘッダーを使用しないようにする必要があります。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門
* HTTP ヘッダー


Reason: CORS preflight channel did not succeed - HTTP

Reason: CORS preflight channel did not succeed
==============================================

理由
--
```

Reason: CORS preflight channel did not succeed
```

何に失敗したか
-------

CORS の要求がプリフライトを必要としていますが、プリフライトが実行できませんでした。プロフライトが失敗したと理由として考えられることは複数あります。

* すでにサイト間の要求でプリフライトが行われており、プリフライトを再び行うことが許可されていない。コードを確認して、一つのコネクションで一度だけプリフライトを行うようにしてください。
* プリフライト要求は単に通常のネットワークエラーの類で失敗した。
関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門


Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’ - HTTP

Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’
=========================================================================

理由
--
```

Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’
```

何が悪いのか
------

CORS リクエストで使われている HTTP メソッドが、レスポンスの `Access-Control-Allow-Methods` ヘッダーで指定されたメソッドの一覧に含まれていません。このヘッダーは、 CORS を使用してリクエストで指定された URL にアクセスする時に使われる HTTP メソッドのコンマ区切りのリストを指定します。リクエストが他のメソッドを使用していると、このエラーが発生します。

例えば、レスポンスに以下の行が含まれていると、
```

Access-Control-Allow-Methods: GET,HEAD,POST
```

`PUT` リクエストを使おうとすると、リクエストが失敗し、このエラーが発生します。

コードからサービスにアクセスするときは、許可された HTTP メソッドのみを使用するように確認してください。

**メモ:** サーバーが `Access-Control-Allow-methods` ヘッダーに理解できない又は未定義のメソッド名を含めた場合、別なエラー `Reason: invalid token ‘xyz' in CORS header ‘Access-Control-Allow-Methods’` が発生します。

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門
* HTTP リクエストメソッド


OPTIONS - HTTP

OPTIONS
=======

**HTTP の `OPTIONS`メソッド**は、指定された URL またはサーバーの許可されている通信オプションをリクエストします。クライアントはこのメソッドで URL か、サーバー全体を表すアスタリスク (`*`) を指定することができます。

|  |  |
| --- | --- |
| リクエストの本文 | なし |
| 成功時のレスポンスの本文 | あり |
| 安全性 | あり |
| べき等性 | あり |
| キャッシュ | 不可 |
| HTML フォームでの使用 | 不可 |

構文
--
```

OPTIONS /index.html HTTP/1.1
OPTIONS * HTTP/1.1
```

例
-

### 許可されたリクエストメソッドの識別

サーバーが対応しているリクエストメソッドを調べるには、 `curl` を使用して `OPTIONS` リクエストを発行してください。

```bash
curl -X OPTIONS https://example.org -i
```

レスポンスには、許可されているメソッドを含んだ `Allow` ヘッダーが入ります。
```

HTTP/1.1 204 No Content
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
```

### CORS でのプリフライトリクエスト

CORS では、プリフライトリクエストを `OPTIONS` メソッドで送信すると、サーバーはリクエストを送信して受け付けられるかどうかを応答できるようにします。下記の例では、次の引数に対する許可を要求します。

* プリフライトリクエストで送信される `Access-Control-Request-Method` ヘッダーは、実際のリクエストを送信する際に、リクエストメソッドが `POST` であることをサーバに知らせます。
* `Access-Control-Request-Headers` ヘッダーは、実際のリクエスト送信時に `X-PINGOTHER` と `Content-Type` ヘッダーを持つことをサーバーに知らせます。
```

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.example
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: https://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
```

サーバーは、このような状況下でリクエストを受け入れるかどうかを応答することができるようになりました。下記の例では、サーバーのレスポンスは次のように言っています。

`Access-Control-Allow-Origin`

`https://foo.example` のオリジンは、以下の方法で `bar.example/resources/post-here/` の URL をリクエストすることが許可されています。

`Access-Control-Allow-Methods`

`POST`, `GET`, `OPTIONS` がその URL で許可されているメソッドです。（このヘッダーは `Allow` レスポンスヘッダーに似ていますが、CORS でのみ使用します。）

`Access-Control-Allow-Headers`

レスポンスを検査するスクリプトは `X-PINGOTHER` と `Content-Type` ヘッダーの値を読み取ることが許可されます。

`Access-Control-Max-Age`

上記の許可は、 86,400 秒（1 日）キャッシュされる可能性があります。

```

HTTP/1.1 204 No Content
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # OPTIONS |

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

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

関連情報
----

* `Allow` ヘッダー
* CORS


DELETE - HTTP

DELETE
======

**HTTP の `DELETE` リクエストメソッド**は、指定されたリソースを削除します。

|  |  |
| --- | --- |
| リクエストの本文 | 可 |
| 成功時のレスポンスの本文 | 可 |
| 安全性 | なし |
| べき等性 | あり |
| キャッシュ | 不可 |
| HTML フォームでの使用 | 不可 |

構文
--
```

DELETE /file.html HTTP/1.1
```

例
-

### リクエスト
```

DELETE /file.html HTTP/1.1
Host: example.com
```

### レスポンス

`DELETE` メソッドが正常に受け付けられた場合、可能性があるレスポンスステータスコードがいくつかあります。

* `202` (`Accepted`) は、処理が成功する可能性は高いが、まだ成立はしていない場合のステータスコード。
* `204` (`No Content`) は、処理は完了しておりかつ、さらなる情報が提供されない場合のステータスコード。
* `200` (`OK`) は、 処理は完了しておりかつ、レスポンスメッセージにステータスを表す表現を含んでいる場合のステータスコード。
```

HTTP/1.1 200 OK
Date: Wed, 21 Oct 2015 07:28:00 GMT

<html>
  <body>
    <h1>ファイルが削除されました。</h1>
  </body>
</html>
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # DELETE |

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

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

関連情報
----

* HTTP ステータス: `200`, `202`, `204`


HEAD - HTTP

HEAD
====

**HTTP の `HEAD` メソッド**は、この `HEAD` リクエストが HTTP `GET` メソッドでリクエストされた場合に返されるヘッダーをリクエストします。例えば、ある URL が大きなファイルをダウンロードする可能性がある場合、 `HEAD` リクエストは `Content-Length` ヘッダーを読み込んで、実際にファイルをダウンロードすることなくファイルサイズを確認することができます。

**警告:** `HEAD` メソッドへのレスポンスには本文が含まれては*いけません*。あった場合は無視**しなければなりません**。誤った本文を記述する可能性がある表現ヘッダーは、同様の `GET` リクエストで受け取るであろうレスポンスを記述していると仮定します。

`HEAD` リクエストの結果が、 `GET` リクエストの後でキャッシュされたリソースが古くなっていることを示している場合、 `GET` リクエストが行われなくてもキャッシュが無効化されます。

|  |  |
| --- | --- |
| リクエストの本文 | なし |
| 成功時のレスポンスの本文 | なし |
| 安全性 | あり |
| べき等性 | あり |
| キャッシュ | 可 |
| HTML フォームでの使用 | 不可 |

構文
--
```

HEAD /index.html
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # HEAD |

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

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

関連情報
----

* `GET`


PUT - HTTP

PUT
===

**HTTP の `PUT` リクエストメソッド**は、新しいリソースを作成するか、指定したリソースの表現をリクエストのペイロードで置き換えます。

`PUT` と `POST` との違いは、`PUT` はべき等であり、呼び出し回数が 1 回でも複数回でも同じ効果になる（*副*作用がない）一方で、 `POST` は連続して同じものを実行すると、注文を複数回渡してしまうなどの追加の影響が発生する可能性があります。

|  |  |
| --- | --- |
| リクエストの本文 | あり |
| 成功時のレスポンスの本文 | なし |
| 安全性 | なし |
| べき等性 | あり |
| キャッシュ | 不可 |
| HTML フォームでの使用 | 不可 |

構文
--
```

PUT /new.html HTTP/1.1
```

例
-

### リクエスト
```

PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16

<p>New File</p>
```

### レスポンス

対象リソースに現在の表現が存在せず、 `PUT` リクエストによって正常に作成された場合、サーバーはユーザーエージェントに `201` (`Created`) レスポンスを通知します。
```

HTTP/1.1 201 Created
Content-Location: /new.html
```

対象リソースに現在の表現が存在し、その表現が内容の表現の状態に従って変更が完了した場合、サーバーは `200` (`OK`) または `204` (`No Content`) の何れかのレスポンスによって、リクエストが正常に完了したことを示します。
```

HTTP/1.1 204 No Content
Content-Location: /existing.html
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # PUT |

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

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

関連情報
----

* `201`
* `204`


POST - HTTP

POST
====

**HTTP の `POST` メソッド**は、サーバーにデータを送信します。リクエストの本文の型は `Content-Type` ヘッダーで示されます。

`PUT` と `POST` との違いは、 `PUT` がべき等であることです。一度呼び出しても複数回呼び出しても成功すれば同じ効果になる（*副*作用がない）のに対して、同じ `POST` に成功すると、複数回の注文を行うような、追加の効果が出ます。

`POST` リクエストは、ふつう HTML フォームを介して送信され、サーバーに変化をもたらします。この場合、`<form>` 要素の `enctype` 属性や`<input>` または `<button>` 要素の `formenctype` 属性に適切な文字列が指定することで、コンテンツタイプを選択することができます。

* `application/x-www-form-urlencoded`: キーと値は、 `'&'` で区切られ、キーと値の組が `'='` で結ばれた形でエンコードされます。キーや値が英数字以外の文字であった場合は、パーセントエンコーディングされます。このため、このタイプはバイナリデータを扱うのには向きません（代わりに `multipart/form-data` を使用してください）
* `multipart/form-data`: それぞれの値はデータのブロック ("body part") として送信され、ユーザーエージェントが定義するデリミター ("boundary") がそれぞれの部分を区切ります。キーはそれぞれの部分の `Content-Disposition` ヘッダーの中で与えられます。
* `text/plain`

`POST` リクエストが HTML フォーム以外の方法 — `XMLHttpRequest` など — で送信された場合は、本文はあらゆるタイプを取ることができます。 HTTP 1.1 仕様書で記述されている通り、 `POST` は以下のような機能をカバーする統一的なメソッドになるよう設計されています。

* 既存のリソースの注釈
* 掲示板、ニュースグループ、メーリングリスト、又は同様の記事グループへの投稿
* サインアップモーダルからの新規ユーザーの追加
* フォームの送信結果などにおける、データを扱うプロセスへのデータブロックの受け渡し
* 追加操作によるデータベースの拡張

|  |  |
| --- | --- |
| リクエストの本文 | あり |
| 成功時のレスポンスの本文 | あり |
| 安全性 | なし |
| べき等性 | なし |
| キャッシュ | 鮮度を表す情報が含まれている場合のみ可能 |
| HTML フォームでの利用 | 可 |

構文
--
```

POST /test
```

例
-

既定の `application/x-www-form-urlencoded` コンテンツタイプを使用した単純なフォームです。
```

POST /test HTTP/1.1
Host: foo.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

field1=value1&field2=value2
```

`multipart/form-data` コンテンツタイプを使用したフォームです。
```

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

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

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

value2
--boundary--
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # POST |

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

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

関連情報
----

* `Content-Type`
* `Content-Disposition`
* `GET`


CONNECT - HTTP

CONNECT
=======

**HTTP の `CONNECT` メソッド**は、リクエストしたリソースを用いて双方向の通信を開始します。これはトンネリングを開始するときに使用されます。

例えば、 `CONNECT` メソッドは SSL (HTTPS) を使用したウェブサイトにアクセスする際に使用されます。クライアントは HTTP のプロキシサーバーに希望する宛先への TCP コネクションをトンネリングするように依頼します。その場合、プロキシサーバーはクライアントに代わってコネクションの作成を継続します。一度コネクションがサーバーによって確立されると、プロキシサーバーはクライアント宛て/クライアント発の TCP ストリームのプロキシーを継続します。

`CONNECT` はホップバイホップ (hop-by-hop) のメソッドです。

|  |  |
| --- | --- |
| リクエストの本文 | なし |
| 成功時のレスポンスの本文 | あり |
| 安全性 | なし |
| べき等性 | なし |
| キャッシュ | 不可 |
| HTML フォームでの使用 | 不可 |

構文
--
```

CONNECT www.example.com:443 HTTP/1.1
```

例
-

プロキシーサーバの中には、トンネルの作成に認証を必要とするものがあります。 `Proxy-Authorization` ヘッダーも参照してください。
```

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # CONNECT |

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

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

関連情報
----

* プロキシーサーバー
* `Proxy-Authorization`


GET - HTTP

GET
===

**HTTP の `GET` メソッド**は、特定のリソースの表現をリクエストします。 `GET` を使用したリクエストはデータをリクエストするためだけに使用してください（データを含めるべきではありません）。

**メモ:** `GET` リクエストで本文（ペイロード）を送信すると、実装によってはリクエストを拒否することがあります。これは仕様書では禁止されていませんが、その意味は未定義です。 `GET` リクエストでは本文を送るのを避けた方がいいでしょう。

|  |  |
| --- | --- |
| リクエストの本文 | なし |
| 成功時のレスポンスの本文 | あり |
| 安全性 | あり |
| べき等性 | あり |
| キャッシュ | 可 |
| HTML フォームでの使用 | 可 |

構文
--
```

GET /index.html
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # GET |

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

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

関連情報
----

* HTTP ヘッダー
* `Range`
* `POST`


PATCH - HTTP

PATCH
=====

**HTTP の `PATCH` リクエストメソッド**は、リソースへの部分的な変更を適用します。

`PATCH` は CRUD に見られる "update" の概念にやや類似しています（一般的に、 HTTP は CRUD とは異なり、両者は混同するべきではありません）。

`PATCH` リクエストは、リソースをどのように修正するかの指示のセットと考えられます。これは `PUT` がリソースの完全な表現を送るのと対照的です。

`PATCH` はべき等であるとは限りませんが、そうなる可能性もあります。この点は、常にべき等である `PUT` とは対照的です。「べき等」という言葉は、同じリクエストを何度繰り返しても、リソースが同じ状態になることを意味します。 例えば、自動インクリメントするカウンタフィールドがリソースの不可欠な部分である場合、 `PUT` は自然にそれを上書きしますが（すべてを上書きするので）、 `PATCH` は必ずしもそうとは限りません。

`PATCH` は（`PUT` のように）他のリソースに対して副作用が発生する*場合があります*。

サーバーが `PATCH` に対応しているかどうかを調べるために、サーバーは `Allow` または `Access-Control-Allow-Methods` （CORS の場合）レスポンスヘッダーのリストに追加することで対応状況を知らせることができます。

`PATCH` が許可されていることを示すもう1つの（暗黙の）識別方法は、サーバーが受け付けるパッチ文書の形式を指定する `Accept-Patch` があることです。

|  |  |
| --- | --- |
| リクエストの本文 | あり |
| 成功時のレスポンスの本文 | あり |
| 安全性 | なし |
| べき等性 | なし |
| キャッシュ | 鮮度を表す情報が含まれている場合のみ可能 |
| HTML フォームでの利用 | 不可 |

構文
--
```

PATCH /file.txt HTTP/1.1
```

例
-

### リクエスト
```

PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

[変更の記述]
```

### レスポンス

成功レスポンスは 2xx ステータスコードで示されます。

この例の場合、本文が含まれていないため `204` コードで成功レスポンスが示されます。もし `200` コードであれば本文が含まる可能性があります。
```

HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"
```

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 5789: PATCH | PATCH Method for HTTP |

関連情報
----

* `204`
* `Allow`, `Access-Control-Allow-Methods`
* `Accept-Patch` – サーバーが受け入れる PATCH 文書の形式を指定します。


TRACE - HTTP

TRACE
=====

**HTTP の `TRACE` メソッド**は、対象リソースまでのパスに沿ってメッセージのループバックテストを行い、便利なデバッグの仕組みを提供します。

リクエストの最終受信者は受信したメッセージを、以下に示すいくつかのフィールドを除いて、クライアントに `200` (`OK`) レスポンスを `Content-Type` を `message/http` に設定した本文として返送します。最終受信者はオリジンのサーバーか、リクエストで `Max-Forwards` (en-US) の値が 0 で受け取った最初のサーバーのどちらかです。

|  |  |
| --- | --- |
| リクエストの本文 | なし |
| 成功時のレスポンスの本文 | なし |
| 安全性 | なし |
| べき等性 | あり |
| キャッシュ | 不可 |
| HTML フォームの使用 | 不可 |

構文
--
```

TRACE /index.html
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # TRACE |

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

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

関連情報
----

* HTTP メソッド


データ URL - HTTP

データ URL
=======

**データ URL** は `data:` スキームが先頭についた URL で、小さなファイルをインラインで文書に埋め込むことができます。以前、 WHATWG で取り下げられるまでは "data URIs" と呼ばれていました。

**メモ:** 最近のブラウザーでは、データ URL はナビゲーションを担当する設定オブジェクトの起源を継承するのではなく、一意の不透明な起点として扱われます。

構文
--

データ URL は接頭辞 (`data:`)、データの種類を示す MIME タイプ、テキストではないデータである場合のオプションである `base64` トークン、データ自体の 4 つの部品で構成されます。
```

data:[<mediatype>][;base64],<data>
```

`mediatype` は MIME タイプで, 例えば `'image/jpeg'` で JPEG 画像を表します。省略時の既定値は `text/plain;charset=US-ASCII` です。

データが文字ならば、そのまま埋め込めます (埋め込む文書タイプに応じて、適切な実体参照やエスケープを行なってください)。それ以外では `base64` を指定し、 base64 エンコードしたバイナリデータを埋め込みます。 MIME タイプについての詳しい情報はこちらやこちらにあります。

例:

`data:,Hello%2C%20World!`

平易な text/plain データです。引用符や空白にはパーセントエンコーディング (URL エンコーディング) を使用します。また、 CSV データ (MIME タイプは "text/csv") もスプレッドシートの行を区切るための改行文字を保存するためにパーセントエンコーディングが必要です。

`data:text/plain;base64,SGVsbG8sIFdvcmxkIQ==`

同じ内容の base64 エンコード版

`data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E`

`<h1>Hello, World!</h1>` という HTML 文書

`data:text/html,<script>alert('hi');</script>`

JavaScript のアラートを実行する HTML 文書。終了タグが必要ですので注意してください。

データの base64 形式へのエンコード
---------------------

Base64 はバイナリからテキストへのエンコード方法の集まりで、バイナリデータを 64 進数表現に変換することで ASCII 文字列形式にするものです。 ASCII 文字のみから成るため、 Base64 の文字列は一般に URL でも安全ですので、データ URL のデータのエンコードに利用することができます。

### Javascript でのエンコード

Web API には、 Base64 をエンコードまたはデコードするためのネイティブメソッド、 Base64 があります。

### Unix システムでのエンコード

Linux や Mac OS X システムでのファイルまたは文字列の Base64 エンコードは、コマンドラインの `base64` (または、他にも `uuencode` ユーティリティの `-m` オプションつき) を使用して実現できます。

```bash
echo -n hello|base64
# コンソールへの出力: aGVsbG8=

echo -n hello>a.txt
base64 a.txt
# コンソールへの出力: aGVsbG8=

base64 a.txt>b.txt
# b.txt ファイルへの出力: aGVsbG8=
```

### Microsoft Windows でのエンコード

Windows では、 Convert.ToBase64String を PowerShell で使用することで Base64 エンコードを行うことができます。
```

[convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("hello"))
# outputs to console: aGVsbG8=
```

他にも、 GNU/Linux シェル (WSL など) が `base64` ユーティリティを提供しています。
```

bash$ echo -n hello | base64
# outputs to console: aGVsbG8=
```

よくある問題
------

この章では `data` の URL を作ったり使ったりするときに、よく起こる問題について述べます。
```

data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val
```

これは次の内容の HTML リソースを表します。
```

lots of text...<p><a name="bottom">bottom</a>?arg=val
```

構文

`data` URL の書式は非常に単純ですが、"データ" 部分の前にカンマを置くのを忘れがちです。忘れるとデータが正しく base64 形式にエンコードされません。

HTML におけるフォーマット

`data` はファイル内でファイルを提供しますが、外側の文書に比べて幅がとても広くなる可能性があります。 URL としては、 `data` はホワイトスペース (改行、タブ、空白) で体裁を整えることができるはずですが、 base64 エンコードをすると起こる問題 があります。

長さの制限

ブラウザーは特定の最大長のデータに対応する必要はありません。たとえば、 Opera 11 ブラウザーでは URL が 65535 文字に制限されており、 `data` URL は 65529 文字に制限されています (65529 文字は、 MIME タイプを指定せずにプレーンの `data:` を使用した場合、ソースではなくエンコードされたデータの長さです)。Firefox 97 以降 では、最大 32MB の `data` URL がサポートされます (97 より前のバージョンでは、制限は約 256MB でした)。 Chromium は 512MB 以上の URL 、Webkit (Safari) は 2048MB 以上の URL をサポートしています。

エラー処理の欠如

メディア内の不正な引数や、 `'base64'` の定義内の打ち間違いは無視され、何もエラーは出ません。

クエリ文字列のサポートの欠如、など

データ URL のデータ部分は不透明 (opaque) なので、データ URL と一緒にクエリ文字列 (`<url>?parameter-data` という構文で表されるページ固有のパラメータ) を使うと、データ URL が表現するデータに単にクエリ文字列が含まれたものになります。

セキュリティの課題

多数のセキュリティ問題 (フィッシングなど) がデータ URL に関連付けられており、ブラウザーの最上位でそれらに移動しています。このような問題を軽減するために、Firefox 59+ (リリース版、Nightly/Beta は 58 以降) では `data:` URL へのトップレベルのナビゲーションがブロックされており、他のブラウザーがすぐに対応することを期待しています。詳細については、Firefox 58 におけるデータ URL へのトップレベルナビゲーションのブロックを参照してください。

仕様書
---

| 仕様書 | 題名 |
| --- | --- |
| RFC 2397 | The "data" URL scheme |

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

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

関連情報
----

* Base64
* パーセントエンコーディング
* `atob()`
* `btoa()`
* CSS `url()`
* URI


HTTP の進化 - HTTP

HTTP の進化
========

**HTTP** は World Wide Web を支えるプロトコルです。1989 年から 1991 年にかけてティム・バーナーズ＝リーとそのチームによって開発された HTTP は、その柔軟性を形成しながら分かりやすさを維持するために、多くの変化を遂げてきました。HTTP が、実験室でファイルを交換するためのプロトコルから、高解像度や 3D の画像や動画を伝送する現代のインターネットの迷路へと進化していった経緯をご紹介します。

World Wide Web の発明
------------------

1989 年、CERN で働いていたティム・バーナーズ＝リーは、インターネット上のハイパーテキストシステムを構築するための提案書を執筆しました。当初 *Mesh* と呼ばれていたそのシステムは、1990 年に実装されている間に *World Wide Web* へ改名されました。 World Wide Web は既存の TCP および IP プロトコル上に構築され、4 つの要素から構成されました。

* ハイパーテキスト文書を表現するテキスト形式である *HyperText Markup Language* (HTML)。
* それらの文書を交換するシンプルなプロトコルである *HypertText Transfer Protocol* (HTTP)。
* それらの文書を表示（および編集）するクライアントである、*WorldWideWeb* と呼ばれた最初のウェブブラウザー。
* 文書へのアクセス機能を提供するサーバーである、*httpd* の初期バージョン。

これら 4 つの構成要素は 1990 年の末に完成して、最初のサーバーが早くも 1991 年の初期に CERN の外部で稼働しました。1991 年 8 月 6 日に、ティム・バーナーズ＝リーは *alt.hypertext* 公開ニュースグループへ投稿しました。これが、公開プロジェクトとしての World Wide Web の公式な開始日になると考えられています。

初期段階で使用された HTTP プロトコルはとてもシンプルでした。後に HTTP/0.9 と名付けられ、また時にはワンラインプロトコルとも呼ばれました。

HTTP/0.9 – ワンラインプロトコル
---------------------

初期バージョンの HTTP にはバージョン番号がありませんでした。以降のバージョンと区別するため、後に 0.9 と呼ばれるようになりました。HTTP/0.9 はとても単純です。リクエストは唯一使用可能なメソッドである `GET` で始まって、リソースへのパスが後に続く 1 行で構成されます。サーバーに接続すればプロトコル、サーバー名、ポートが必要ではなくなるため、 URL ではありませんでした。

```http
GET /mypage.html
```

レスポンスも、とても単純でした。こちらはファイル自身だけで構成されます。

```html
<html>
  A very simple HTML page
</html>
```

以降の進化形とは異なり、HTTP ヘッダーがありませんでした。つまり、HTML ファイルだけが転送可能であり、他の種類の文書は転送できませんでした。また、ステータスやエラーのコードはありませんでした。問題が発生すると、人間が使用するために問題の説明を収めた専用の HTML ファイルを生成していました。。

HTTP/1.0 – 拡張性を築く
-----------------

HTTP/0.9 はとても限定的なものでしたが、ブラウザーとサーバーはすばやくそれをより多用途に使えるようにしました。

* バージョン情報は各リクエストの中で送信されました（`HTTP/1.0` は `GET` 行に付加されました）。
* ステータスコード行もレスポンスの始めに送られるようになりました。これにより、ブラウザーはリクエストの成否を認識し、それに応じて動作を変化させることができるように、例えば、固有の方法でローカルキャッシュを更新したり使用したりすることができるようになりました。
* リクエストとレスポンスの両方に、HTTP ヘッダーの概念が導入されました。メタデータを送信できるようになり、プロトコルは非常に柔軟で拡張性が高くなった。
* `Content-Type` ヘッダーのおかげで、プレーンな HTML ファイル以外の文書も送信できるようになりました。

この時点で、一般的なリクエストとレスポンスはこのようになりました。

```http
GET /mypage.html HTTP/1.0
User-Agent: NCSA\_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
 <IMG SRC="/myimage.gif">
</HTML>
```

次の接続が続いて、画像の読み込みをリクエストします (前のリクエストのレスポンスに続きます)。

```http
GET /myimage.gif HTTP/1.0
User-Agent: NCSA\_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(画像コンテンツ)
```

1991 年から 1995 年にかけて、これらは試行錯誤で導入されました。サーバーとブラウザーが機能を追加して、それが取得されるかどうかを確認するのです。相互運用性の問題はよくあることでした。これらの問題を解決するために、1996年11月に一般的な方法を記述した情報文書が公開されました。これは RFC 1945 として知られ、HTTP/1.0 を定義しました。

HTTP/1.1 – 標準化されたプロトコル
----------------------

その間に、適切な標準化が進んでいました。これは、HTTP/1.0 の多様な実装を行うために並行して行われました。HTTP の最初の標準バージョンである HTTP/1.1 は、HTTP/1.0 からわずか数カ月後の 1997 年初頭に公開されました。

HTTP/1.1 では、曖昧な点が明確にされ、多くの改良が加えられました。

* 接続を再利用することができ、その時間が短縮されました。単一の元文書に埋め込まれたリソースを表示するために、何度も開く必要がなくなりました。
* パイプラインが追加されました。これにより、最初のリクエストに対する回答が完全に送信される前に、2つ目のリクエストを送信することができるようになりました。これにより、通信の待ち時間を短縮することができるようになりました。
* チャンクレスポンスにも対応しました。
* 追加のキャッシュ制御メカニズムが導入されました。
* コンテンツネゴシエーション（言語、エンコーダー、種類を含む）が導入されました。これで、クライアントとサーバーは、どのコンテンツを交換するかについて合意できるようになりました。
* `Host` ヘッダーのおかげで、同じIPアドレスから異なるドメインをホスティングできるようになり、サーバーのコロケーションが可能になりました。

すべて単一の接続で行われる典型的なリクエストの流れは、次のようなものになりました。

```http
GET /ja/docs/Glossary/Simple\_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/ja/docs/Glossary/Simple\_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(コンテンツ)

GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: \*/\*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/ja/docs/Glossary/Simple\_header

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(3077 バイトの画像コンテンツ)
```

HTTP/1.1 は、1997 年 1 月に RFC 2068 として初版が発行されました。

15 年以上にわたる拡張
------------

HTTP の拡張性により、新しいヘッダーやメソッドを簡単に作成することができました。HTTP/1.1 プロトコルは、1999 年 6 月に公開された RFC 2616 と HTTP/2 のリリース前の 2014 年 6 月に公開された RFC 7230-RFC 7235 という 2 回の改訂を経て改良されたとはいえ、15年以上も極めて安定していました。

### 安全な転送のための HTTP の使用

HTTP の最大の変化が、1994 年末に起こりました。コンピューターサービス会社の Netscape Communications は、HTTP を基本的な TCP/IP スタック上で送信する代わりに、その上にさらに暗号化された送信レイヤーを作成したのです。SSL です。SSL 1.0 は一般にリリースされることはなかったのですが、SSL 2.0 とその後継の SSL 3.0 によって、電子商取引のウェブサイトを作成することができるようになりました。そのために、サーバーとクライアントの間でやり取りされるメッセージを暗号化し、その真正性を保証していました。SSL はやがて標準化され、TLS となりました。

同じ時期に、暗号化されたトランスポート層が必要であることが明らかになりました。ウェブはもはやほとんど学術的なネットワークではなく、広告主や不特定多数の個人、犯罪者が使用可能な限りの個人データを奪い合うジャングルと化していたのです。HTTP で構築されたアプリケーションがより強力になり、アドレス帳、電子メール、ユーザーの位置情報などの個人情報に使用されるようになると、TLS は電子商取引以外のの用途でも必要とされるようになりました。

### 複雑なアプリケーションのために HTTP を使用する

ティム・バーナーズ＝リーは元々、HTTP を読み取り専用のメディアとして想定していたわけではありません。彼は、人々がリモートで文書を追加したり移動したりできるウェブ、つまり分散ファイルシステムのようなものを作成したかったのです。1996 年頃、HTTP はオーサリングを可能にするために拡張され、WebDAV と呼ばれる標準が作成されました。さらに、アドレス帳の項目を処理する CardDAV、カレンダーを扱う CalDAV など、固有のアプリケーションを記載するようになりました。しかし、これらの \*DAV 拡張はすべて、サーバーが実装しなければ使えないという欠点がありました。

2000 年、HTTP を使用するための新しいパターンが設計さ れました。representational state transfer（またはREST）です。このAPIは、新しいHTTPメソッドに基づくものではなく、基本的なHTTP/1.1メソッドによる固有のURIへのアクセスに頼っていました。これにより、どんなウェブアプリケーションでも、ブラウザーやサーバーを更新することなく、APIにデータを取得したり変更したりさせることができるようになりました。必要な情報はすべて、ウェブサイトが標準のHTTP/1.1で提供するファイルに埋め込まれていました。RESTモデルの欠点は、各ウェブサイトが自分自身で非標準のRESTful APIを定義し、それを完全に制御していたことです。この点は、クライアントとサーバーが相互運用可能であった⽶⽶DAV拡張とは異なる形であった。RESTful APIは、2010年代にとても一般的になりました。

2005 年以降、より多くの API がウェブページで利用できるようになりました。これらの API のうちいくつかは、特定の目的のために HTTP プロトコルを拡張しました。

* サーバー送信イベント。サーバーがクライアントに対して、特別なメッセージを送信できます。
* WebSocket。既存の HTTP 接続を更新することでセットアップできる、新たなプロトコルです。
### ウェブのセキュリティモデルの緩和

HTTP はウェブのセキュリティモデルである同一オリジンポリシーとは独立した存在です。実は、現在のウェブのセキュリティモデルは HTTP を作成した後に開発されたのです。長年かけて、一定の条件の下でこのポリシーの制限の一部を解除できるようにすることにより、より寛大にできることが有効であると立証されました。いつどのようにしてこれらの制限を解除するかは、新たな HTTP ヘッダー群を使用してサーバーからクライアントに送信されます。これはオリジン間リソース共有 (CORS) やコンテンツセキュリティポリシー (CSP) といった仕様で定義されています。

これらの大きな拡張に加えて、ほかにも実験用に限るものを含めて多くのヘッダーが追加されました。主なヘッダーとしてプライバシーを制御するための Do Not Track (`DNT`) ヘッダー、`X-Frame-Options`、`Upgrade-Insecure-Requests` がありますが、さらに多くのヘッダーが存在します。

HTTP/2 – 高パフォーマンスなプロトコル
-----------------------

長い年月をかけて、ウェブページはより複雑になっていきました。中には、自分自身でアプリケーションを作成するものもありました。より多くの視覚的なメディアが表示され、インタラクティブな機能を追加するスクリプトの量とサイズも増加しました。より多くのデータがより多くの HTTP リクエストで送信されるようになり、HTTP/1.1 接続はより複雑でオーバーヘッドになりました。この問題を解決するために、Google は 2010 年代前半に実験的なプロトコルSPDYを実装しました。クライアントとサーバー間でデータを交換するこの代替方法は、ブラウザーとサーバーの両方で作業している開発者の関心を集めました。SPDY は、レスポンスの向上とデータの重複送信の問題を定義し、HTTP/2 プロトコルの基礎となりました。

HTTP/2 プロトコルには、HTTP/1.1 との大きな違いがいくつかあります。

* テキスト形式ではなく、バイナリ形式のプロトコルです。このハードルにより内容を読んだり手作業で作成したりすることができなくなりましたが、改良された最適化技術が実装できるようになりました。
* 多重化されたプロトコルです。同じ接続でリクエストを並行して扱うことができ、HTTP/1.x プロトコルの制約を排除しています。
* ヘッダーを圧縮します。一連のリクエスト内で似たものが存在することが多いため、これはデータ転送の重複やオーバーヘッドを削減します。
* サーバープッシュと呼ばれる仕組みによって、リクエストより先にサーバーがクライアントのキャッシュにデータを加えることができます。

2015 年 5 月に正式に標準化された HTTP/2 の使用は、2022 年 1 月にピークを迎え、すべてのウェブサイトの 46.9% に達しました（こちらの統計情報をご参照ください）。トラフィックの多いウェブサイトは、データ転送のオーバーヘッドとその後の経費を節約するために、最も急速に普及しました。

このように急速に普及したのは、HTTP/2 がウェブサイトやアプリケーションを変更する必要がなかったからだと思われます。使用するために必要なものは、最新のブラウザーに通信する最新のサーバーだけだったからです。発生させるグループも限られており、古いブラウザーやサーバーのバージョンが更新されれば、ウェブ開発者に大きな作業をさせることなく、自然に利用が拡大しました。

HTTP/2 以降の進化
------------

HTTP の拡張性は高く、現在も新機能の追加に使用されています。特筆すべきは、2016 年に現れた HTTP プロトコルの新しい拡張機能を挙げることができます。

* `Alt-Svc` に対応することで、指定されたリソースの場所と同一性を分離することができ、よりスマートな CDN のキャッシュ機構を可能にします。
* クライアントヒントの導入により、ブラウザーやクライアントがサーバーに対して、クライアントの要件やハードウェアの制約に関する情報を率先して伝えることができます。
* `Cookie` ヘッダーにセキュリティ関連の接頭辞が導入され、安全な Cookie が改変されていないことを保証する助けになります。
HTTP/3 - HTTP over QUIC
-----------------------

HTTP の次のメジャーバージョンである HTTP/3 は、以前のバージョンの HTTP と意味づけは同じですが、トランスポート層部分には QUIC を TCP の代わりに使用しています。2022 年 10 月時点で、すべてのウェブサイトの 26% が HTTP/3 を使用していました。

QUIC は、HTTP 接続の待ち時間を大幅に短縮することを目的に設計されています。HTTP/2 と同様に多重化されたプロトコルですが、HTTP/2 は単一の TCP 接続上で実行するため、TCP 層で処理するパケットロス検出と再送信によってすべてのストリームをブロックする可能性があります。QUIC は UDP (en-US) 上で複数のストリームを実行し、ストリームごとに独立してパケットロス検出と再送を実装するために、エラーが発生した場合、そのパケット内のデータがあるストリームだけがブロックされます。

RFC 9114 を定義し、Chromium（およびその亜種である Chrome や Edge）や Firefox を含むほとんどの主要ブラウザーが HTTP/3 に対応しています。


MIME タイプ（IANA メディア種別） - HTTP

MIME タイプ（IANA メディア種別）
=====================

**メディア種別** (別名 **Multipurpose Internet Mail Extensions または MIME タイプ**) は、文書、ファイル、またはバイト列の性質や形式を示します。
 MIME タイプは IETF の RFC 6838 で定義され、標準化されています。

Internet Assigned Numbers Authority (IANA) はすべての公式の MIME タイプを管理しており、Media Types ページで最新の完全な一覧を見ることができます。

**警告:** ブラウザーは URL を処理する方法を決定するために、*ファイル拡張子ではなく* MIME タイプを使用しますので、ウェブサーバーは正しい MIME タイプをレスポンスの `Content-Type` ヘッダーで送信することが重要です。
 これが正しく構成されていないと、ブラウザーはファイルの中身を誤って解釈し、サイトが正しく動作しなかったり、ダウンロードファイルが誤って扱われたりすることがあります。

MIME タイプの構造
-----------

MIME タイプふつう、*タイプ*と*サブタイプ*と、その間をスラッシュ (`/`) で区切ったもので構成されます。間にホワイトスペースは入りません。
```

タイプ/サブタイプ
```

**タイプ**はデータ型が当てはまる全般的なカテゴリー、すなわち `video` や `text` などを表します。

**サブタイプ**は、その MIME タイプが表す正確なデータの種類を識別します。
 例えば、 MIME タイプが `text` の場合、サブタイプは `plain` (プレインテキスト)、 `html` (HTML ソースコード)、 `calendar` (iCalendar/`.ics`) ファイルなどです。

すべてのタイプは利用可能なサブタイプを持っています。 MIME タイプは常にタイプとサブタイプの両方を持ち、一方だけで使われることはありません。

任意で**引数**を追加して、追加の詳細情報を提供することができます。
```

タイプ/サブタイプ;引数=値
```

 例えば、 MIME タイプのうちメインタイプが `text` であるものでは、任意で `charset` 引数を使用して、データ内の文字の文字コードを指定することができます。
 `charset` が指定されなかった場合は、既定では ASCII (`US-ASCII`) が、ユーザーエージェントの設定で上書きされない限り使われます。
 UTF-8 のテキストファイルを指定するには、 MIME タイプとして `text/plain;charset=UTF-8` が使用されます。

MIME タイプは大文字と小文字を区別しませんが、伝統的に小文字で記述されます。引数の値は大文字と小文字を区別することができます。

### タイプ

 タイプには **個別タイプ** (discrete) **マルチパートタイプ** (multipart) の 2 種類があります。
 個別タイプは単一のファイルまたはメディアを表すタイプで、単一のテキストファイルや音楽ファイル、単一の映像などです。
 マルチパートタイプは複数のコンポーネント部品によって構成される文書を表すもので、それぞれの部分が固有の MIME タイプを持ちます。また、マルチパートタイプは一度のトランザクションで一緒に送信される複数のファイルをまとめることもできます。
 例えば、マルチパート MIME タイプは複数のファイルを電子メールに添付するときに使用されます。

#### 個別タイプ

現在 IANA に登録されている個別タイプは以下のとおりです。

`application`

 他のタイプに明確に当てはまらない、あらゆる種類のバイナリーデータです。
 何らかの方法で実行されたり解釈されたりするデータ、または利用するのに特定のアプリケーションや特定の種類のアプリケーションを必要とするバイナリーデータのどちらかです。
 汎用的なバイナリーデータ（または本当のタイプが不明なバイナリーデータ）は `application/octet-stream` です。他のよくある例として、 `application/pdf`, `application/pkcs8`, `application/zip` があります。
 （IANA での application 型の登録を見る）

`audio`

 音声または音楽データです。例えば、 `audio/mpeg`, `audio/vorbis` などがあります。
 （IANA での audio 型の登録を見る）

`example`

 MIME タイプの使用方法を例示する際のプレイスホルダーとして使用するために予約されています。
 これらはサンプルコードのリストや文書の外で使用してはいけません。
 `example` はサブタイプとして使用することもできます。
 例えば、ウェブ上で音声として動作する例として、 MIME タイプの `audio/example` を使用してタイプがプレイスホルダーであり、実世界で使用されるコードでは適切なもので置き換えられることを表します。

`font`

 フォントやタイプフェイスのデータです。よく使われるものとしては `font/woff`, `font/ttf`, `font/otf` などがあります。
 （IANA での font 型の登録を見る）

`image`

 画像またはグラフィックデータで、ビットマップとベクター静止画像の両方を含み、さらに静止画像形式のアニメーション版であるアニメーション GIF や APNG なども含みます。
 よく使われるものとしては、 `image/jpeg`, `image/png`, `image/svg+xml` などがあります。
 （IANA での image 型の登録を見る）

`model`

 三次元のオブジェクトやシーンなどのモデルデータです。例えば、 `model/3mf` や `model/vrml` などがあります。
 （IANA での model 型の登録を見る）

`text`

 テキストのみのデータで、人間が読むことができるあらゆるコンテンツ、ソースコード、コンマ区切り値 (CSV) 形式のデータのようなテキストデータを含みます。
 例えば、 `text/plain`, `text/csv`, `text/html` などがあります。
 （IANA での text 型の登録を見る）

`video`

 動画のデータまたはファイルで、 MP4 movies (`video/mp4`) などがあります。
 （IANA での video 型の登録を見る）

 特定のサブタイプを持たないテキスト形式の文書には、 `text/plain` を使用してください。
 同様に、特定のサブタイプまたは既知のサブタイプを持たないバイナリー形式の文書には、 `application/octet-stream` を使用してください。

#### マルチパートタイプ

**マルチパート**タイプは、ふつうそれぞれ異なる MIME タイプを持つ複数の部品に分割される文書のカテゴリーを示します。
 これらは、特に電子メールにおいて、同じトランザクションの一部である複数の別々のファイルを表すためにも使用されます。これらは**複合文書**を表します。

 HTTP は `multipart/form-data` が HTML フォームの `POST` メソッドで使用されたり、 `multipart/byteranges` が文書の一部を送信するために `206` `Partial Content` で使用されたりする例外を除いて、 HTTP はマルチパート文書を特別な方法で扱いません。
 メッセージは（おそらく文書をインラインで表示する方法がわからず、「名前を付けて保存」をすることを提案されるでしょうが）ブラウザーへ送信されます。

マルチパートタイプは 2 種類があります。

`message`

 他のメッセージをカプセル化したメッセージ。例えば、転送されたメッセージをデータの一部として含む電子メールを表現したり、非常に大きなメッセージを複数のメッセージであるかのように塊で送信できるようにしたりするために使用されます。
 例としては `message/rfc822` （転送されたメッセージや返信されたメッセージの引用）や `message/partial` （大きなメッセージを自動的に小さなメッセージに分割し、受信者が再び組み立てることを可能にします）があります。
 （IANA での message 型の登録を見る）

`multipart`

 個別に異なる MIME タイプを持つ可能性のある複数のコンポーネントから構成されるデータ。
 例としては、 `multipart/form-data` （`FormData` API を使用して生成されたデータ用）や `multipart/byteranges` （RFC 7233, セクション 5.4.1 で定義されており、 HTTP の `206` と共に使用される）が含まれます。"Partial Content" レスポンスは、`Range` ヘッダーを使用して配信されるような、取得したデータがコンテンツの一部分のみである場合に返されます。
 （IANA での multipart 型の登録を見る）

ウェブ開発者向けの重要な MIME タイプ
---------------------

### application/octet-stream

これは、バイナリーファイルでは既定です。これは*未知のバイナリー形式*のファイルを表すものであり、ブラウザーはふつう実行したり、実行するべきか確認したりしません。これらは `Content-Disposition` ヘッダーの値に `attachment` が設定されたかのように扱い、「名前を付けて保存」ダイアログを提案します。

### text/plain

これは、テキスト形式のファイルの既定です。実際には「未知のテキスト形式」のファイルを表すものではありますが、ブラウザーは表示可能であると推測します。

**メモ:** `text/plain` は「任意のテキスト形式データ」を表すものではありませんので注意してください。特定の種類のテキスト形式のデータを想定している場合は、おそらくそのとおりに判断されないでしょう。特に、CSS ファイルを宣言する `<link>` 要素から `text/plain` 形式のファイルをダウンロードすると、 `text/plain` で示されたファイルは正しい CSS ファイルであると認識されません。 CSS の MIME タイプである `text/css` を使用しなければなりません。

### text/css

ウェブページをスタイル付けするための CSS ファイルは `text/css` で送信することが**必要**です。サーバーが CSS ファイルについて `.css` の接尾辞を認識しない場合、 `text/plain` や `application/octet-stream` の MIME タイプで送信することがあります。その場合、多くのブラウザーから CSS として認識されず、無視されることになります。

### text/html

すべての HTML コンテンツは、このタイプで提供するべきです。 XHTML 向けの新たな MIME タイプ (`application/xhtml+xml` など) は、現在ではほぼ無用です。

**メモ:** `application/xml` や `application/xhtml+xml` は、 XML の厳密な解釈ルールや、 `<![CDATA[…]]>` セクション、 HTML/SVG/MathML の名前空間に含まれない要素を使用したい場合に使用してください。

### text/javascript

IANA メディア種別レジストリー、RFC 9239、 HTML 仕様書によれば、 JavaScript コンテンツは MIME タイプとして常に `text/javascript` を使用することになっています。他の MIME タイプは JavaScript において妥当であると見なされず、 `text/javascript` 以外の MIME タイプを使用すると、スクリプトが読み込まれなかったり、実行されなかったりする結果になる可能性があります。

 JavaScript のコンテンツの中には、 `charset` 引数を MIME タイプの一部として使用し、スクリプトコンテンツの文字セットを設定しようとしている不適切なものを見かけることがあります。
 この `charset` パラメータは JavaScript のコンテンツには有効ではなく、ほとんどの場合スクリプトを読み込むのに失敗します。

#### JavaScript の歴史的な MIME タイプ

`text/javascript` MIME タイプに加えて、歴史的な理由で、 MIME スニッフィング標準 (ブラウザーがメディア種別をどのように解釈し、有効なタイプを持たないコンテンツをどう処理するかを定義する方法の定義) は、 JavaScript を以下のいずれかと基本的に一致する MIME タイプを使用して提供することを許可しています。

* `application/javascript`
非推奨
* `application/ecmascript`
非推奨
* `application/x-ecmascript`
Non-standard
* `application/x-javascript`
Non-standard
* `text/ecmascript`
非推奨
* `text/javascript1.0`
Non-standard
* `text/javascript1.1`
Non-standard
* `text/javascript1.2`
Non-standard
* `text/javascript1.3`
Non-standard
* `text/javascript1.4`
Non-standard
* `text/javascript1.5`
Non-standard
* `text/jscript`
Non-standard
* `text/livescript`
Non-standard
* `text/x-ecmascript`
Non-standard
* `text/x-javascript`
Non-standard

**メモ:** あるユーザーエージェントがこれらのいずれか、またはすべてに対応していても、 `text/javascript` だけを使用するようにしてください。
 このタイプは、現在および将来にわたって動作が保証されている唯一の MIME タイプです。

### 画像タイプ

 MIME タイプが `image` であるファイルは、画像データを含んでいます。
 サブタイプは、そのデータがどの画像ファイル形式を表しているかを指定します。

以下の画像タイプは、ウェブページを使用する際に安全である程度に一般的に使用されています。

* `image/apng`: APNG (Animated Portable Network Graphics)
* `image/avif` : AVIF (AV1 Image File Format)
* `image/gif`: GIF (Graphics Interchange Format)
* `image/jpeg`: JPEG (Joint Photographic Expert Group image)
* `image/png`: PNG (Portable Network Graphics)
* `image/svg+xml`: SVG (Scalable Vector Graphics)
* `image/webp`: WEBP (Web Picture format)

画像ファイルの種類と形式ガイドでは、さまざまな画像形式を使用する場合の情報と推奨事項を提供しています。

### 音声と動画のタイプ

画像の場合と同様に、 HTML はウェブブラウザーが `<audio>` と `<video>` 要素が特定のファイルタイプやコーデックに対応することを義務づけていないので、メディアに使用するファイルタイプやコーデックを選択する際には、ターゲット層と彼らが使用しているであろうブラウザーの範囲（およびそれらのバージョン）を考慮しておくことが重要です。

メディアコンテナー形式のガイドでは、ウェブブラウザーが一般的に対応しているファイルタイプの一覧を、その特殊な使用例や持っている欠点、互換性情報などの詳細とともに紹介しています。

音声コーデック (en-US)および映像コーデックガイドでは、ウェブブラウザーがよく対応しているさまざまなコーデックをリストアップし、互換性の詳細とともに、対応している音声チャネル数、使用されている圧縮方式、有効なビットレートなどの技術的な情報を提供しています。
 WebRTC で使用されるコーデック (en-US)ガイドではさらに、主要なウェブブラウザーで対応しているコーデックに特化して、対応したいブラウザーの範囲に応じた最適なコーデックを選ぶことができます。

 音声ファイルや動画ファイルの MIME タイプに関しては、通常、コンテナー形式（ファイルタイプ）を指定します。
 オプションのコーデック引数 (en-US)を MIME タイプに追加すると、使用するコーデックと、コーデックプロファイル、レベルなど、メディアのエンコードに使用したオプションをさらに指定することができます。

 ウェブコンテンツに使用されるMIMEタイプのうち、最も一般的なものを以下に一覧で示します。
 ただし、これは利用可能なすべてのタイプの完全なリストではありません。
 これについてはメディアコンテナー形式のガイドを参照してください。

| MIME タイプ | 音声または動画のタイプ |
| --- | --- |
| `audio/wave` `audio/wav` `audio/x-wav` `audio/x-pn-wav` | WAVE コンテナー形式の音声ファイル。 PCM オーディオコーデック (WAVE コーデック "1") はたいていサポートされていますが、他のコーデックのサポートは (あるとしても) 限定的です。 |
| `audio/webm` | WebM コンテナー形式の音声ファイル。 Vorbis や Opus が WebM 仕様書で公式に対応しているコーデックです。 |
| `video/webm` | WebM コンテナー形式の、おそらく音声も含む動画ファイル。VP8 や VP9 がもっとも一般的に使用される動画コーデックです。 Vorbis や Opus がもっとも一般的な音声コーデックです。 |
| `audio/ogg` | Ogg コンテナー形式の音声ファイル。 Vorbis が、このコンテナーでもっとも一般的に使用される音声コーデックです。しかし、 Opus も同様に Ogg で対応しました。 |
| `video/ogg` | Ogg コンテナー形式の、おそらく音声も含む動画ファイル。通常の動画コーデックは Theora、音声コーデックは Vorbis ですが、 Opus がもっと有名になってきています。 |
| `application/ogg` | OGG コンテナー形式を使用する音声または動画のファイル。通常の動画コーデックは Theora、音声コーデックは Vorbis です。 |

### multipart/form-data

`multipart/form-data` タイプは、入力済みの HTML フォーム の内容をブラウザーからサーバーに送信するときに使用することができます。

 これはマルチパート文書形式として複数の部分から成り、境界（二重ダッシュ `--` で始まる文字列）によって区切られます。
 それぞれの部分は固有のエンティティであり、固有の HTTP ヘッダーとして `Content-Disposition` やファイルアップロードのフィールドには `Content-Type` を持ちます。

```http
Content-Type: multipart/form-data; boundary=aBoundaryString
（マルチパート文書全体に関連付けられる、他のヘッダー）

--aBoundaryString
Content-Disposition: form-data; name="myFile"; filename="img.jpg"
Content-Type: image/jpeg

(データ)
--aBoundaryString
Content-Disposition: form-data; name="myField"

(データ)
--aBoundaryString
(サブパート)
--aBoundaryString--
```

以下の `<form>` があったとします。

```html
<form
 action="http://localhost:8000/"
 method="post"
 enctype="multipart/form-data">
  <label>Name: <input name="myTextField" value="Test" /></label>
  <label><input type="checkbox" name="myCheckBox" /> Check</label>
  <label>
    Upload file: <input type="file" name="myFile" value="test.txt" />
  </label>
  <button>Send the file</button>
</form>
```

これは以下のメッセージを送信します。

```http
POST / HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
Content-Length: 465

-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myTextField"

Test
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myCheckBox"

on
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myFile"; filename="test.txt"
Content-Type: text/plain

Simple file.
-----------------------------8721656041911415653955004498--
```

### multipart/byteranges

`multipart/byteranges` MIME タイプは、部分的なレスポンスをブラウザーへ返すために使用されます。

`206 Partial Content` ステータスコードを送信するとき、この MIME タイプは文書がいくつかの部分で構成されていることを示しており、それぞれのリクエストされた範囲のひとつになります。ほかのマルチパートタイプと同様に、 `Content-Type` で `boundary` を使用してそれぞれの部分を区切ります。それぞれの部分は実際のタイプを表す `Content-Type` ヘッダーと、表現している範囲を表す `Content-Range` ヘッダーを持ちます。

```http
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
Content-Length: 385

--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 100-200/1270

eta http-equiv="Content-type" content="text/html; charset=utf-8" />
 <meta name="viewport" content
--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 300-400/1270

-color: #f0f0f2;
 margin: 0;
 padding: 0;
 font-family: "Open Sans", "Helvetica
--3d6b6a416f9b5--
```

正しい MIME タイプを設定することの重要性
-----------------------

多くのウェブサーバーは未知の種類のリソースについて、既定の `application/octet-stream` MIME タイプを送ります。セキュリティ上の理由で、多くのブラウザーはこのようなリソースに既定のアクションを定義することを許可せず、リソースを使用するためにディスクへ保存することをユーザーに強制します。

以下のような誤ったサーバー設定がよく見られます。

* RAR で圧縮されたファイル。
 この場合、元ファイルの実際の種類であることが理想です。これは、 .RAR ファイルがさまざまな種類の複数のリソースを含むことができるため、たいていは不可能です。
 この場合、サーバーが `application/x-rar-compressed` を送信するように設定してください。
* 音声および動画。
 正しい MIME タイプを持つリソースだけが、 `<video>` または `<audio>` 要素で再生されます。
 音声および動画に対して正しい MIME タイプを使用するよう注意してください。
* 独自のファイルタイプ。
 特別な操作ができなくなるため、`application/octet-stream` の使用は避けてください。ほとんどのブラウザーは、この汎用的な MIME タイプに既定の動作 (「Word で開く」など) を定義することができません。 `application/vnd.mspowerpoint` のような特定の型ならば、ユーザーがそのようなファイルを自動的に選択したプレゼンテーションソフトウェアで開くことができます。
MIME スニッフィング
------------

MIME タイプが欠落している、あるいは MIME タイプが誤って設定されているとクライアントが考えている場合に、ブラウザーは MIME スニッフィングを行います。これは、リソースを確認して正しい MIME タイプを推測します。

 MIME スニッフィングはブラウザーによって様々な方法で、様々な状況下で行われます。
 （例えば、 Safari は受信した MIME タイプが合わない場合は、 URL のファイルの拡張子を見ます。）
 実行可能なコンテンツを表す一部の MIME タイプには、セキュリティ上の懸念があります。
 サーバーは `X-Content-Type-Options` を送信することで、MIME スニッフィングを抑制できます。

文書の種類を伝える他の方法
-------------

MIME タイプは、文書の種類の情報を伝える唯一の方法ではありません。

* 特に Microsoft Windows では、ファイル名の拡張子を使用することがあります。
 拡張子に意味があるとは考えないオペレーティングシステムもありますし（Linux や Mac OS など）、正しいという保証はありません。
* マジックナンバー。ファイルのバイト構造を見ることで、様々な形式の構文によりファイルタイプを推測することができます。
 例えば GIF ファイルは16進数の値 `47 49 46 38 39` (`GIF89`)、 PNG ファイルは `89 50 4E 47` (`.PNG`) で始まります。マジックナンバーを持たない種類のファイルもありますので、 100% 信頼できるシステムではありません。
関連情報
----

* ウェブメディア技術
* ウェブ上で使用されるメディア形式のガイド
* サーバーの MIME タイプを正しく構成する


リソース URL - HTTP

リソース URL
========

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

`resource:` というスキームのプレフィックスが付いたリソース URL は、Firefox と Firefox のブラウザー拡張機能によってリソースを内部的に読み込むために使用されますが、情報の一部はブラウザーが接続するサイトでも利用できます。

構文
--

リソース URL は、接頭辞 (`resource:`) とロードするリソースを指す URL の 2 つの部分で構成されます。
```

resource://<url>
```

例
```

resource://gre/res/svg.css
```

リソース URL ('->') に矢印がある場合は、最初のファイルが次のファイルにロードされたことを意味します。
```

resource://<File-loader> -> <File-loaded>
```

より一般的な詳細については、ウェブ上のリソースの識別を参照してください。

この記事では、組み込みのリソースを指すために Firefox が内部的に使用するリソース URI に焦点を当てます。

脅威
--

`resource:` URL によって共有される情報の一部はウェブサイトで利用できるため、ウェブページは内部スクリプトを実行し、デフォルトの設定を含む Firefox の内部リソースを調べることができます。

たとえば、Browserleaks のスクリプトは、サイトで実行されている簡単なスクリプトでクエリが実行されたときに Firefox が表示する内容を強調表示します (コードは https://browserleaks.com/firefox#more にあります)。

ファイル firefox.js は、プリファレンス名と値を pref() 関数に渡します。 例えば、
```

http://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/browser/app/profile/firefox.js#575
```

ウェブサイトではこの `pref()` 関数をオーバーライドし、スクリプト`resource:///defaults/preferences/firefox.js` を使用して、 Firefox のデフォルト設定を簡単に収集できます。

さらに、プラットフォームやロケールなどのビルド構成によっては、ウェブサイトがこの情報を使用して個々のユーザーを識別できるという意味で、いくつかのデフォルト設定値が異なります。

解決方法
----

この問題を解決するために、 Mozilla は Firefox バグ 863246 のリソースを読み込む動作を変更しました。これは Firefox 57 (Quantum) で登場しました。

過去には、ウェブコンテンツは、 Firefox の内部リソースだけでなく、拡張機能の資産も含め、URI が必要とするあらゆるリソースにアクセスすることができました。 現在、この動作はデフォルトでは禁止されています。

しかし、特定の状況下で Firefox がウェブコンテンツにリソースを読み込む必要があります。 たとえば、ビュー・ソース・ページ (ビュー・ソースまたはビュー選択ソース) を開くと、 `resource:` URI を介して `viewsource.css` が必要です。ウェブコンテンツに公開する必要があるリソースは、 `resource://content-accessible/`という名前の新しい場所に移動されました。これは隔離されており、重要ではないリソースのみが含まれています。 このようにして、重要なリソースを公開し、ほとんどの脅威を排除できます。

**メモ:** ウェブと拡張機能の開発者がリソース URL をもう使用しようとしないことをお勧めします。彼らの使い方はうまくいきませんでした。そしてほとんどの使用法はこれ以上動作しません。

仕様
--

resource: はどの仕様書にも定義されていません。

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

resource: は Firefox のみ対応

関連情報
----

* ウェブ上のリソースの識別
* URL とは何か
* IANA list of URI schemes (`resource:` is covered here)


www 付きと www なしの URL の選択 - HTTP

www 付きと www なしの URL の選択
=======================

ウェブサイトの管理者の間で繰り返される質問が、www URL と非 www URL のどちらを選択するかです。このページでは、何が最良かについてアドバイスを提供します。

ドメイン名とは何か
---------

HTTP の URL では、先頭の `http://` または `https://` に続く部分文字列をドメインと呼びます。ドメイン名は、文書が存在するサーバーにホスティングされています。

サーバーは物理的な装置である必要はありません。同じ物理的な装置上に複数のサーバーを配置できます。あるいは複数の装置がひとつのサーバーとして扱われることもあり、協力して回答を生成したり、サーバー間でリクエストの負荷を分散したりします。重要なことは、意味的に*ひとつのドメイン名がひとつのサーバーを表す*ことです。

では、自身のウェブサイトでどちらかを選択しなければならないのか
-------------------------------

* **はい**、ひとつを選択して維持しなければなりません。基準となる場所に応じてどちらを選択するかはあなた次第ですが、どちらかを選択したら、それを維持してください。それにより、ユーザーや検索エンジンから見てウェブサイトが首尾一貫したものになります。これは、常に選択したドメインにリンクする (ウェブサイト内で相対 URL を使用すれば、難しくはないでしょう)、および常に同じドメインへのリンクを (電子メールやソーシャルネットワークなどで) 共有することを含みます。
* **いいえ**、二つ持つことができます。どちらが公式なドメインであるかについて、一貫性を持って矛盾しないことが重要です。**この公式なドメインは*正規名*と呼ばれます。** すべての絶対パスリンクで正規名を使用するべきです。しかし、それでも他のドメインを機能させることができます。HTTP ではどちらのドメインが正規のものであるかをユーザーや検索エンジンに対して明らかにするとともに、非正規のドメインが機能して想定したページを提供できるようにするための技術が 2 つあります。

従って、正規なドメインとしてひとつ選択してください! 以下の 2 つの技術によって、非正規のドメインも機能させることができます。

非正規の URL のための技術
---------------

どのウェブサイトが*正規*であるかを選択するための、さまざまな方法があります。

### HTTP 301 リダイレクトを使用する

この場合は非正規ドメインへのリクエストに対して適切な HTTP `301` レスポンスを返すために、HTTP リクエストを受けるサーバー (おそらく、www URL 向けと非 www URL 向けは同じでしょう) の設定が必要です。これは、非正規 URL へアクセスしようとしたブラウザーを正規な同等 URL へリダイレクトします。例えば非 www URL を正規なものとして使用することを選択した場合は、すべての www URL を、www をつけない同等の URL にリダイレクトします。

例:

1. サーバーが `http://www.example.org/whaddup` へのリクエストを受けます (正規のドメインが example.org であるとき)。
2. サーバーは ``Location`: http://example.org/whaddup` ヘッダーを伴う `301` コードのレスポンスを返します。
3. クライアントは正規ドメイン `http://example.org/whatddup` へのリクエストを発行します。

HTML5 boilerplate project に、あるドメインから別のドメインへリダイレクトするように Apache を設定する方法 の例があります。

### <link rel="canonical"> を使用する

ページの正規のアドレスは何かを示す、専用の HTML `<link>` 要素をページに追加できます。これは人間向けのページリーダーには影響がありませんが、検索エンジンのクローラーに対してページが実際はどこにあるかを示します。この方法では検索エンジンが同じページで何度もインデックスを作成したり、重複したコンテンツやスパムであると判断されたり、検索エンジンの結果ページでページが排除されたりランクが下がったりすることがなくなります。

このようなタグを追加するときは両方のドメインで同じコンテンツを提供して、どの URL が正規であるかを検索エンジンに示します。先ほどの例では `http://www.example.org/whaddup` が `http://example.org/whaddup` と同じコンテンツを提供していますが、head に `<link>` 要素を追加します:

`<link href="http://example.org/whaddup" rel="canonical">`

リダイレクトの場合と異なり、ブラウザーの履歴では非 www URL と www URL が独立した項目であるとみなします。

どちらでもページを動作させる
--------------

これらの技術と併せて、 www つきドメインと www なしドメインの両方で正しく応答するようにサーバーを設定しましょう。ユーザーがブラウザーの URL バーにどちらの URL を入力するかは予測できませんので、これを行うことはよい助言になります。これは正式な場所としてどちらを使用したいかを選択するという問題であり、その結果に応じて他の URL をリダイレクトします。

状況を判断する
-------

これは自転車置き場問題と考えられる、とても主観的な話題です。もっと深く読んでみたいと思ったら、この件に関する多くの記事をご覧ください。

関連情報
----

* Stats on what people type in the URL bar (2011)


ウェブ上のリソースの識別 - HTTP

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

HTTP リクエストの対象は「リソース」と呼ばれ、その本質は細かく定義されていません。文書、写真、その他の何でもなりえます。それぞれのリソースは、リソースを特定するために HTTP の至るところで使用される Uniform Resource Identifier (URI) で特定されます。

URL と URN
---------

### URL

もっとも一般的な URI の形式は Uniform Resource Locator (URL) であり、*ウェブアドレス*として知られています。

```url
https://developer.mozilla.org
https://developer.mozilla.org/ja/docs/Learn/
https://developer.mozilla.org/ja/search?q=URL
```

ブラウザーのアドレスバーに URL を入力して、URL に関連付けられているページ (リソース) を読み込むように指示できます。

URL はさまざまな部品で構成されており、必須のものと省略可能なものがあります。より複雑な URL として、例えば次のようなものがあります。

```url
http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
```

### URN

Uniform Resource Name (URN) は、特定の名前空間内における名前によってリソースを特定する URI です。

```url
urn:isbn:9780141036144
urn:ietf:rfc:7230
```

2 つの URN は以下のものに対応します。

* George Orwell の書籍 Nineteen Eighty-Four
* IETF 仕様書 7230、 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Uniform Resource Identifiers (URI) の構文
--------------------------------------

### スキームまたはプロトコル

![Protocol](/ja/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-protocol@x2.png)

`http://` はプロトコルです。これは、ブラウザーが使用すべきプロトコルを示します。通常、 HTTP プロトコルまたは安全なバージョンである HTTPS になります。ウェブではこれら 2 つのうちひとつを必要としますが、ブラウザーは `mailto:` （メールクライアントを開く）やファイル転送を扱う `ftp:` といったほかのプロトコルの扱い方も知っていますので、このようなプロトコルが現れても驚かないでください。主なスキームは以下のとおりです。

| スキーム | 説明 |
| --- | --- |
| data | Data URI |
| file | ホスト固有のファイル名 |
| ftp | File Transfer Protocol |
| http/https | Hyper text transfer protocol (安全) |
| javascript | URL に埋め込まれた JavaScript のコード |
| mailto | 電子メールアドレス |
| ssh | Secure shell |
| tel | 電話 |
| urn | Uniform Resource Names |
| view-source | リソースのソースコード |
| ws/wss | (暗号化された) WebSocket 接続 |

### オーソリティ

![ドメイン名](/ja/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-domain@x2.png)

`www.example.com` は、名前空間を統制するドメイン名またはオーソリティです。これは、どのウェブサーバーがリクエストされているかを示します。代わりに IP アドレスを直接使用することもできますが、利便性が低いためウェブではあまり使用されません。

### ポート番号

![ポート番号](/ja/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-port@x2.png)

ここで `:80` はポート番号です。これはウェブサーバー内のリソースへアクセスするために使用する、技術上の「出入口」です。ウェブサーバーがリソースへのアクセスを受け入れるために HTTP プロトコルの標準ポート（HTTP では 80、HTTPS では 443）を使用している場合、通常はポートを省略します。それ以外の場合は、ポートが必須です。

### パス

![ファイルへのパス](/ja/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-path@x2.png)

`/path/to/myfile.html` は、ウェブサーバー内にあるリソースのパスです。初期のウェブではこのようなパスが、ウェブサーバー内の物理的なファイルの場所を表していました。現代のパスはたいてい物理的な実情と関係がない、ウェブサーバーによって制御される抽象的なものになっています。

### クエリー

![引数](/ja/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-parameters@x2.png)

`?key1=value1&key2=value2` は、ウェブサーバーに提供する追加の引数です。この引数は `&` 記号で区切られた、キーと値のペアのリストです。ウェブサーバーは、ユーザーへリソースを返す前に追加の処理を行うために、この引数を使用できます。それぞれのウェブサーバーは引数について独自の規則を持っており、特定のウェブサーバーが引数を扱う方法を知るために唯一信頼できる方法は、ウェブサーバーの所有者に尋ねることです。

### フラグメント

![アンカー](/ja/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-anchor@x2.png)

`#SomewhereInTheDocument` は、リソース自体の別の場所へのアンカーです。アンカーはリソース内の一種の「ブックマーク」を表しており、「ブックマーク」地点にあるコンテンツを表示するようにブラウザーへ指示を与えます。例えば HTML 文書では、ブラウザーはアンカーが定義されている位置にスクロールします。動画や音声の文書では、ブラウザーはアンカーが示す位置への移動を試みます。 # より後の部分はフラグメント識別子としても知られており、リクエストでサーバーには送信されないことは注目に値します。

使用上のメモ
------

HTML コンテンツの中で URL を使用するとき、一般に使うことができる URL スキームはわずかです。サブリソースを参照する場合 — つまり、最初は巨大な文書の一部だけを使用する場合 — は、 HTTP 及び HTTPS スキームしか使用することができません。加えて、ブラウザーはセキュリティ上の理由から、 FTP を使用したサブリソースの読み込みの対応を削除しつつあります。

FTP は最上位では利用できますが (ブラウザーの URL バーに直接入力したり、リンクの対象とした理)、ブラウザーによっては FTP コンテンツの読み込みを他のアプリケーションに委譲するかもしれません。

例
-

```url
https://developer.mozilla.org/ja/docs/Learn
tel:+1-816-555-1212
git@github.com:mdn/browser-compat-data.git
ftp://example.org/resource.txt
urn:isbn:9780141036144
mailto:help@supercyberhelpdesk.info
```

仕様書
---

| Specification |
| --- |
| HTTP Semantics # uri |

関連情報
----

* URL とは何か
* IANA list of URI schemes


よくある MIME タイプ - HTTP

よくある MIME タイプ
=============

これは文書の種類に関連付けられている MIME タイプの一覧であり、一般的な拡張子の昇順に並べています。

2 つの主要な MIME タイプは、既定のタイプの役割として重要です。

* `text/plain` は、テキスト形式ファイルの既定の値です。テキスト形式ファイルは人間が読めるはずであり、バイナリーデータを含んではなりません。
* `application/octet-stream` は、上記以外の場合の既定値です。未知の種類のファイルは、このタイプを使用するべきです。ブラウザーはこれらのファイルを扱う際に特に注意を払い、危険な動作からユーザーを保護しようとします。

IANA は MIME メディアタイプの公式な登録先であり、すべての公式 MIME タイプの一覧 を管理しています。以下の表は、ウェブ向けに重要な一部の MIME タイプを掲載しています:

| 拡張子 | 文書の種類 | MIME タイプ |
| --- | --- | --- |
| `.aac` | AAC 音声 | `audio/aac` |
| `.abw` | AbiWord 文書 | `application/x-abiword` |
| `.arc` | (複数のファイルが埋め込まれた) アーカイブ文書 | `application/x-freearc` |
| `.avi` | AVI: Audio Video Interleave | `video/x-msvideo` |
| `.azw` | Amazon Kindle eBook 形式 | `application/vnd.amazon.ebook` |
| `.bin` | 任意の種類のバイナリーデータ | `application/octet-stream` |
| `.bmp` | Windows OS/2 ビットマップ画像 | `image/bmp` |
| `.bz` | BZip アーカイブ | `application/x-bzip` |
| `.bz2` | BZip2 アーカイブ | `application/x-bzip2` |
| `.csh` | C-Shell スクリプト | `application/x-csh` |
| `.css` | カスケーディングスタイルシート (CSS) | `text/css` |
| `.csv` | カンマ区切り値 (CSV) | `text/csv` |
| `.doc` | Microsoft Word | `application/msword` |
| `.docx` | Microsoft Word (OpenXML) | `application/vnd.openxmlformats-officedocument.wordprocessingml.document` |
| `.eot` | MS 埋め込み OpenType フォント | `application/vnd.ms-fontobject` |
| `.epub` | 電子出版 (EPUB) | `application/epub+zip` |
| `.gz` | GZip 圧縮アーカイブ | `application/gzip` |
| `.gif` | グラフィック交換形式 (GIF) | `image/gif` |
| `.htm .html` | ハイパーテキストマークアップ言語 (HTML) | `text/html` |
| `.ico` | アイコン形式 | `image/vnd.microsoft.icon` |
| `.ics` | iCalendar 形式 | `text/calendar` |
| `.jar` | Java Archive (JAR) | `application/java-archive` |
| `.jpeg` `.jpg` | JPEG 画像 | `image/jpeg` |
| `.js` | JavaScript | `text/javascript` （仕様書: HTML および RFC 9239） |
| `.json` | JSON 形式 | `application/json` |
| `.jsonld` | JSON-LD 形式 | `application/ld+json` |
| `.mid` `.midi` | Musical Instrument Digital Interface (MIDI) | `audio/midi` `audio/x-midi` |
| `.mjs` | JavaScript モジュール | `text/javascript` |
| `.mp3` | MP3 音声 | `audio/mpeg` |
| `.mpeg` | MPEG 動画 | `video/mpeg` |
| `.mpkg` | Apple Installer Package | `application/vnd.apple.installer+xml` |
| `.odp` | OpenDocuemnt プレゼンテーション文書 | `application/vnd.oasis.opendocument.presentation` |
| `.ods` | OpenDocuemnt 表計算文書 | `application/vnd.oasis.opendocument.spreadsheet` |
| `.odt` | OpenDocument テキスト文書 | `application/vnd.oasis.opendocument.text` |
| `.oga` | OGG 音声 | `audio/ogg` |
| `.ogv` | OGG 動画 | `video/ogg` |
| `.ogx` | OGG | `application/ogg` |
| `.opus` | Opus 音声 | `audio/opus` |
| `.otf` | OpenType フォント | `font/otf` |
| `.png` | Portable Network Graphics | `image/png` |
| `.pdf` | Adobe Portable Document Format (PDF) | `application/pdf` |
| `.php` | Hypertext Preprocessor (**Personal Home Page**) | `application/x-httpd-php` |
| `.ppt` | Microsoft PowerPoint | `application/vnd.ms-powerpoint` |
| `.pptx` | Microsoft PowerPoint (OpenXML) | `application/vnd.openxmlformats-officedocument.presentationml.presentation` |
| `.rar` | RAR アーカイブ | `application/vnd.rar` |
| `.rtf` | リッチテキスト形式 (RTF) | `application/rtf` |
| `.sh` | Bourne shell スクリプト | `application/x-sh` |
| `.svg` | Scalable Vector Graphics (SVG) | `image/svg+xml` |
| `.swf` | Small web format (SWF) または Adobe Flash 文書 | `application/x-shockwave-flash` |
| `.tar` | Tape Archive (TAR) | `application/x-tar` |
| `.tif .tiff` | Tagged Image File Format (TIFF) | `image/tiff` |
| `.ts` | MPEG transport stream | `video/mp2t` |
| `.ttf` | TrueType フォント | `font/ttf` |
| `.txt` | テキストファイル (一般に ASCII or ISO 8859-*n*) | `text/plain` |
| `.vsd` | Microsoft Visio | `application/vnd.visio` |
| `.wav` | Waveform 音声形式 | `audio/wav` |
| `.weba` | WEBM 音声 | `audio/webm` |
| `.webm` | WEBM 動画 | `video/webm` |
| `.webp` | WEBP 画像 | `image/webp` |
| `.woff` | Web Open Font Format (WOFF) | `font/woff` |
| `.woff2` | Web Open Font Format (WOFF) | `font/woff2` |
| `.xhtml` | XHTML | `application/xhtml+xml` |
| `.xls` | Microsoft Excel | `application/vnd.ms-excel` |
| `.xlsx` | Microsoft Excel (OpenXML) | `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` |
| `.xml` | `XML` | `application/xml`: 一般のユーザーから読めるもの*ではない*場合 (RFC 3023, section 3) `text/xml`: 一般のユーザーから読めるものである場合 (RFC 3023, section 3) |
| `.xul` | XUL | `application/vnd.mozilla.xul+xml` |
| `.zip` | ZIP アーカイブ | `application/zip` |
| `.3gp` | 3GPP 音声/動画コンテナー | `video/3gpp` 動画を含まない場合は `audio/3gpp` |
| `.3g2` | 3GPP2 音声/動画コンテナー | `video/3gpp2` 動画を含まない場合は `audio/3gpp2` |
| `.7z` | 7-zip アーカイブ | `application/x-7z-compressed` |


オーディオとビデオのストリーミングガイド - ウェブメディア技術

オーディオとビデオのストリーミングガイド
====================

このガイドでは、Web 上のオーディオあるいはビデオメディアをストリーミングするために使用されるテクニックと、可能な限り最高の品質とパフォーマンスを引き出すためにストリーミングを実行する際に使用するコード、メディア、サーバー、およびオプションをどのように最適化するかを検討します。

プロトコル
-----

サーバとストリーミングコードの設定に加えて、パフォーマンスを最適化するために使用できる特別なプロトコルが存在することがあります。

### HTTPS Live Streaming

**HTTPS Live Streaming** (**HLS**) は、Apple が開発したプロトコルで、Safari はそのすべてのプラットフォームでサポートしています。HLS は他の環境でもサポートされている場合がありますが、条件付きでサポートされている場合もあります。

例えば、多くの Web サイトのモバイル専用コンテンツでは、モバイルブラウザが HLS に対応していることを前提としているため、この前提が間違っているために変な互換性エラーが発生することを避けるために、Android 版の Firefox も同様に対応しています。ただし、Android のデスクトップ版は HLS をサポートしていません。

HLS ではプレイリストを利用して、ストリーミングするメディアを選択するだけでなく、同じメディアのバージョンや形式を選択することができます。例えば、HLS では、ユーザーが自分の言語を聞くために、複数の音声ストリームを含むビデオをストリーミングすることができます。さらに、異なるネットワーク条件に最適化されたストリームの形式を提供することもできます。このようにして、ライブストリームを柔軟かつ高パフォーマンスにすることができます。

2017 年半ば現在、HLS は RFC 8216 として標準化されています。

あわせて参照
------

* Web メディア技術
* Web 上のメディアタイプとフォーマットのガイド
* `<audio>` と `<video>`


メディアの種類と形式のガイド: 画像、音声、動画コンテンツ - ウェブメディア技術

メディアの種類と形式のガイド: 画像、音声、動画コンテンツ
=============================

ほぼ最初の頃から、ウェブは何らかの形で視覚メディアのプレゼンテーションに対応してきました。当初、これらの機能は制限されていましたが、さまざまなブラウザーがウェブ上の静止画や動画の画像を含むことに関する問題に対して独自の解決策を見つけたため、有機的に拡張されました。現代のウェブは、メディアのプレゼンテーションや操作をサポートする強力な機能を備えており、さまざまな種類のコンテンツに対応するいくつかのメディア関連 API を備えています。一般的に、ブラウザーが対応するメディア形式は、ブラウザーの作成者に委ねられており、ウェブ開発者の作業を複雑にしています。

このガイドでは、ウェブ上で使用されるメディアを構成する可能性のあるメディアファイルの種類、コーデック、アルゴリズムの概要を説明します。また、これらの様々な組み合わせに対するブラウザーの対応情報や、ファイル形式の優先順位の提案、特定の種類のコンテンツに適したファイル形式の提案も提供しています。

リファレンス
------

### 画像

画像ファイルの種類と形式のガイド

主要なウェブブラウザーが対応している画像ファイルの種類とコンテンツ形式をカバーし、それぞれの種類についての基本的な情報を提供しています。利点、制限、使用例など、ウェブデザイナーや開発者が興味を持つ情報を提供します。

ウェブデザイナーのための画像ファイル形式

ウェブデザイナーにとって有用な様々な画像ファイルの種類についての基本的な情報であり、各種類のベストプラクティスや使用例、特定のコンテンツの種類に適した画像ファイル形式を選択するためのガイドラインなどが含まれています。

### メディアファイルの種類とコーデック

メディアコンテナー (ファイルの種類)

メディアデータを含むファイルの種類のガイド。オーディオに特化したものもあれば、オーディオや映画などの複合視聴覚コンテンツに使われるものもあります。主要なウェブブラウザーが対応している各ファイル種別の概要と、ブラウザーの対応情報、対応している機能が含まれています。

ウェブ音声コーデックガイド (en-US)

一般的なメディアコンテナーや主要なブラウザーで許可されているオーディオコーデックのガイド。メリット、制限、主要な仕様と機能、ユースケースが含まれています。また、与えられたコンテナーでコーデックを使用するための各ブラウザーのサポートもカバーしています。

ウェブ動画コーデックガイド

この記事では、主要なブラウザーが対応してている動画コーデックについての基本的な情報と、一般的には対応されていないが、まだ遭遇する可能性のあるいくつかの情報を提供します。また、コーデックの機能、利点、制限、ブラウザーの対応レベルと制限についても説明します。

一般的なメディアタイプの "codecs" 引数 (en-US)

メディア形式を記述する MIME タイプを指定するときは、 type 文字列の一部として `codecs` 引数を使用して詳細を提供できます。このガイドでは、一般的なメディアタイプの `codecs` 引数の形式と可能な値について説明します。

WebRTC で使われるコーデック (en-US)

WebRTC はコンテナーを使用せず、 `MediaStreamTrack` オブジェクトを使用して音声や動画の各トラックを表現し、エンコードされたメディア自体をピアからピアにストリームします。このガイドでは、WebRTC で一般的に使用されるコーデックについて説明します。

ガイド
---

### 概要

デジタル音声の概要 (en-US)

音声がどのようにデジタル形式に変換され、コンピュータで使用するために保存されるかを紹介します。音声がどのようにサンプリングされるかについての基本的な概念、サンプルレート、音声フレーム、音声圧縮などの概念を説明しています。

デジタル動画の概要 (en-US)

ウェブ上で使用されるデジタルビデオの基本的な概念、例えばカラーフォーマット、クロマサブサンプリング、人間の知覚がビデオコーディングにどのように影響するかなどを解説しています。

### チュートリアルと how-to

学習: 動画と音声のコンテンツ

このチュートリアルでは、ウェブ上でのメディアの利用方法を紹介し、詳細を説明します。

ウェブコンテンツにおけるメディア対応の課題への対応 (en-US)

このガイドでは、メディア形式を賢く選択し、フォールバックや代替形式を提供することで、可能な限り幅広い互換性を提供しながら、品質やパフォーマンスを最大化するウェブコンテンツを構築する方法を見ていきます。

その他のトピック
--------

Media Capabilities API (en-US)

Media Capabilities API を使用すると、アプリやサイトが実行されている端末のエンコーディングおよびデコーディング機能を検出することができます。これにより、どの形式をいつ使用するかをリアルタイムで判断することができます。