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

理由
--
```

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'
======================================================================

理由
--
```

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

理由
--
```

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

理由
--
```

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’
=========================================================================

理由
--
```

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

理由
--
```

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

理由
--
```

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 ‘\*’
============================================================================================

理由
--
```

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

理由
--
```

Reason: CORS disabled
```

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

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

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

関連情報
----

* CORS のエラー
* 用語集: CORS
* CORS 入門
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
==================================================

理由
--
```

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’
=========================================================================

理由
--
```

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

理由
--
```

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

理由
--
```

Reason: CORS preflight channel did not succeed
```

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

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

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

* CORS のエラー
* 用語集: CORS
* CORS 入門
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`メソッド**は、指定された 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` リクエストメソッド**は、指定されたリソースを削除します。

|  |  |
| --- | --- |
| リクエストの本文 | 可 |
| 成功時のレスポンスの本文 | 可 |
| 安全性 | なし |
| べき等性 | あり |
| キャッシュ | 不可 |
| 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` メソッド**は、この `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` リクエストメソッド**は、新しいリソースを作成するか、指定したリソースの表現をリクエストのペイロードで置き換えます。

`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` メソッド**は、サーバーにデータを送信します。リクエストの本文の型は `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` メソッド**は、リクエストしたリソースを用いて双方向の通信を開始します。これはトンネリングを開始するときに使用されます。

例えば、 `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` メソッド**は、特定のリソースの表現をリクエストします。 `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` リクエストメソッド**は、リソースへの部分的な変更を適用します。

`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 文書の形式を指定します。