diff options
Diffstat (limited to 'files/ja/web/http')
| -rw-r--r-- | files/ja/web/http/conditional_requests/index.html | 148 | ||||
| -rw-r--r-- | files/ja/web/http/conditional_requests/index.md | 140 | ||||
| -rw-r--r-- | files/ja/web/http/headers/accept-language/index.html | 2 | ||||
| -rw-r--r-- | files/ja/web/http/headers/content-type/index.html | 122 | ||||
| -rw-r--r-- | files/ja/web/http/headers/content-type/index.md | 110 | ||||
| -rw-r--r-- | files/ja/web/http/headers/dnt/index.html | 89 | ||||
| -rw-r--r-- | files/ja/web/http/headers/dnt/index.md | 74 | ||||
| -rw-r--r-- | files/ja/web/http/headers/expect-ct/index.html | 62 | ||||
| -rw-r--r-- | files/ja/web/http/headers/index.html | 461 | ||||
| -rw-r--r-- | files/ja/web/http/headers/index.md | 401 | ||||
| -rw-r--r-- | files/ja/web/http/headers/x-content-type-options/index.html | 99 | ||||
| -rw-r--r-- | files/ja/web/http/headers/x-content-type-options/index.md | 67 | ||||
| -rw-r--r-- | files/ja/web/http/network_error_logging/index.html | 155 | ||||
| -rw-r--r-- | files/ja/web/http/status/202/index.html | 37 | ||||
| -rw-r--r-- | files/ja/web/http/status/202/index.md | 31 |
15 files changed, 1021 insertions, 977 deletions
diff --git a/files/ja/web/http/conditional_requests/index.html b/files/ja/web/http/conditional_requests/index.html deleted file mode 100644 index 9a3c57338b..0000000000 --- a/files/ja/web/http/conditional_requests/index.html +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: HTTP 条件付きリクエスト -slug: Web/HTTP/Conditional_requests -tags: - - Conditional Requests - - Guide - - HTTP -translation_of: Web/HTTP/Conditional_requests ---- -<p>{{HTTPSidebar}}</p> - -<p class="summary">HTTP には<em>条件付きリクエスト</em>の概念があり、対象となるリソースと<em>検証子</em>の値とを比較することで、リクエストの結果や、成功か失敗かまでもが変化することがあります。このようなリクエストは、キャッシュの内容を検証して、無用な制御を避けたり、ダウンロードの再開の時などに文書の整合性を検証したり、サーバー上の文書をアップロードまたは変更するときに更新内容を失うことを避ける場合などに役立つことがあります。</p> - -<h2 id="Principles" name="Principles">原理</h2> - -<p>HTTP 条件付きリクエストは、特定のヘッダーの値に応じて異なる処理が行われるリクエストです。これらのヘッダーは前提条件を定義しており、リクエストの結果は前提条件に一致するか否かに応じて変わります。</p> - -<p>リクエストで使用したメソッドや前提条件で使用したヘッダー一式によって、さまざまな動作が定義されています。</p> - -<ul> - <li>{{HTTPMethod("GET")}} などの{{glossary("safe", "安全な")}}メソッドは、一般に文書を取得するメソッドであり、条件付きリクエストは関連する文書のみを返信するために利用することができます。これによって、帯域を節約します。</li> - <li>{{HTTPMethod("PUT")}} などの{{glossary("safe", "安全ではない")}}メソッドは、一般に文書をアップロードするメソッドであり、条件付きリクエストは文書がサーバーに格納されているものと同じものに基づいたものである場合に限ってアップロードするようにするために利用することができます。</li> -</ul> - -<h2 id="Validators" name="Validators">検証子</h2> - -<p>すべての条件ヘッダーは、サーバーに保存されているリソースが特定のバージョンに一致するか確認を試みます。このため、条件付きリクエストではリソースのバージョンを示す必要があります。リソース全体をバイト単位で比較することは不可能であり、常に望まれていることとは限らないので、リクエストはバージョンを記述する値を送信します。このような値は<em>検証子</em>と呼ばれ、二種類があります。</p> - -<ul> - <li>文書が最後に変更された日時である <em>last-modified</em> の日時</li> - <li><em>エンティティタグ</em>または <em>etag</em> と呼ばれる、各バージョンを一意に識別する不透明な文字列。</li> -</ul> - -<p>同じリソースのバージョンの比較は少々複雑です。状況によって、二種類の<em>確認方法</em>があります。</p> - -<ul> - <li><ruby>強い検証<rp> (</rp><rt>Strong validation</rt><rp>) </rp></ruby>は、ダウンロードを再開するときなど、バイト単位の同一性が求められる場合に使用します。</li> - <li><ruby>弱い検証<rp> (</rp><rt>Weak validation</rt><rp>) </rp></ruby>は、ユーザーエージェントが二つのリソースが同じであることを確認することだけが必要である場合に使用します。これは広告の違いやフッターの日付の違いなど、小さな違いがある場合も含みます。</li> -</ul> - -<p>検証の種類と使用される検証子は独立しています。 {{HTTPHeader("Last-Modified")}} と {{HTTPHeader("ETag")}} はどちらの種類の検証もできますが、サーバー側の実装の複雑さは異なります。 HTTP は既定で強い検証を使用し、弱い検証を使用するときはそれを指定します。</p> - -<h3 id="Strong_validation" name="Strong_validation">強い検証</h3> - -<p id="sect1">強い検証は、比較対象のリソースがバイト単位で同一であることを保証します。これは一部の条件ヘッダーで必須、また他のヘッダーでは既定の要件です。強い検証はとても厳密であり、サーバーレベルで保証することが困難である場合もありますが、時には性能を犠牲にしても、データが失われていないことを常に保証します。</p> - -<p>{{HTTPHeader("Last-Modified")}} で強い検証のための一意な識別子を持つことは、とても困難です。多くの場合、リソースの MD5 ハッシュ (あるいはその派生物) を持つ {{HTTPHeader("ETag")}} を使用します。</p> - -<h3 id="Weak_validation" name="Weak_validation">弱い検証</h3> - -<p>弱い検証は、内容が等価であるなら二つのバージョンの文書が等しいと見なされるという点で、強い検証と異なります。例えばフッターの日付だけ、あるいは広告だけが異なる二つのページは、弱い検証では<em>同一</em>であるとみなされますが、強い検証では異なるものとみなされます。弱い検証を作り出す etag のシステムを構築することは、ページのさまざまな要素の重要性を知ることが伴うため複雑になるかもしれませんが、キャッシュの性能を最適化するためにとても役に立ちます。</p> - -<h2 id="Conditional_headers" name="Conditional_headers">条件ヘッダー</h2> - -<p>条件ヘッダーと呼ばれるいくつかの HTTP ヘッダーが、条件付きリクエストをもたらします。</p> - -<dl> - <dt>{{HTTPHeader("If-Match")}}</dt> - <dd>遠方のリソースの {{HTTPHeader("ETag")}} と、このヘッダーに載せた etag が等しければ成功します。デフォルトでは etag に接頭辞 <code>'W/'</code> がついていない限り、強い検証を行います。</dd> - <dt>{{HTTPHeader("If-None-Match")}}</dt> - <dd>遠方のリソースの {{HTTPHeader("ETag")}} と、このヘッダーに載せたそれぞれの etag が異なっていれば成功します。デフォルトでは etag に接頭辞 <code>'W/'</code> がついていない限り、強い検証を行います。</dd> - <dt>{{HTTPHeader("If-Modified-Since")}}</dt> - <dd>遠方のリソースの {{HTTPHeader("Last-Modified")}} の日時が、このヘッダーで指定した日時より新しければ成功します。</dd> - <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt> - <dd>遠方のリソースの {{HTTPHeader("Last-Modified")}} の日時が、このヘッダーで指定した日時より過去または同一であれば成功します。</dd> - <dt>{{HTTPHeader("If-Range")}}</dt> - <dd>{{HTTPHeader("If-Match")}} や {{HTTPHeader("If-Unmodified-Since")}} に似ていますが、 etag または日時をひとつしか持つことができません。条件が失敗すると範囲指定リクエストも失敗して、 {{HTTPStatus("206")}} <code>Partial Content</code> レスポンスの代わりに {{HTTPStatus("200")}} <code>OK</code> でリソース全体を送信します。</dd> -</dl> - -<h2 id="Use_cases" name="Use_cases">使用例</h2> - -<h3 id="Cache_update" name="Cache_update">キャッシュの更新</h3> - -<p>条件付きリクエストのもっとも一般的な使用例は、キャッシュの更新です。キャッシュが空である、あるいはキャッシュを使用しない状態では {{HTTPStatus("200")}} <code>OK</code> ステータスと共に、要求したリソースが送信されます。</p> - -<p><img alt="The request issued when the cache is empty triggers the resource to be downloaded, with both validator value sent as headers. The cache is then filled." src="https://mdn.mozillademos.org/files/13729/Cache1.png" style="height: 265px; width: 741px;"></p> - -<p>リソースと共に、ヘッダーで検証子を送信します。この例では {{HTTPHeader("Last-Modified")}} と {{HTTPHeader("ETag")}} の両方を送信していますが、どちらか一方しか使用しません。これらの検証子はリソースと共に (すべてのヘッダーのように) キャッシュへ保存され、キャッシュが陳腐化したときに条件付きリクエストを作成するために使用します。</p> - -<p>キャッシュが陳腐化していなければ、条件付きリクエストは行いません。しかしキャッシュが陳腐化すると主に {{HTTPHeader("Cache-Control")}} ヘッダーに制御されて、クライアントはキャッシュされた値を直接使用せず、{{HTTPHeader("If-Modified-Since")}} または {{HTTPHeader("If-Match")}} ヘッダーに検証子の値を指定した<em>条件付きリクエスト</em>を発行します。</p> - -<p>リソースが変更されていなければ、サーバーは {{HTTPStatus("304")}} <code>Not Modified</code> レスポンスを返します。これはキャッシュを再び新鮮な状態にして、クライアントはキャッシュされたリソースを使用します。これはリソースをいくらか消費するレスポンスとリクエストのやり取りが発生しますが、通信網でリソース全体を再度転送するよりも効率的です。</p> - -<p><img alt="With a stale cache, the conditional request is sent. The server can determine if the resource changed, and, as in this case, decide not to send it again as it is the same." src="https://mdn.mozillademos.org/files/13731/HTTPCache2.png" style="height: 265px; width: 741px;"></p> - -<p>リソースが変更された場合は、サーバーは条件付きではないリクエストと同様に {{HTTPStatus("200")}}<code> OK</code> レスポンスで新しいバージョンのリソースを送信します。そして、クライアントは新しいリソースを使用します (また、それをキャッシュします)。</p> - -<p><img alt="In the case where the resource was changed, it is sent back as if the request wasn't conditional." src="https://mdn.mozillademos.org/files/13733/HTTPCache3.png"></p> - -<p>サーバー側で検証子を設定することをを除いて、この仕組みは透過的です。どのブラウザーもウェブ開発者が特別な作業を行うことなく、キャッシュを管理してこのような条件付きリクエストを送信します。</p> - -<h3 id="Integrity_of_a_partial_download" name="Integrity_of_a_partial_download">部分ダウンロードの整合性</h3> - -<p>ファイルの部分ダウンロードは、以前の操作を再開することが可能な HTTP の機能であり、すでに取得済みの情報を保持することによって帯域や時間を節約します。</p> - -<p><img alt="A download has been stopped and only partial content has been retrieved." src="https://mdn.mozillademos.org/files/16190/HTTPResume1.png" style="height: 397px; width: 764px;"></p> - -<p>部分ダウンロードをサポートするサーバーは、{{HTTPHeader("Accept-Ranges")}} ヘッダーを送信してそのことを知らせます。このヘッダーが送信されると、クライアントは {{HTTPHeader("Ranges")}} ヘッダーで欠落している範囲を送信することで、ダウンロードを再開できます。</p> - -<p><img alt="The client resumes the requests by indicating the range he needs and preconditions checking the validators of the partially obtained request." src="https://mdn.mozillademos.org/files/13737/HTTPResume2.png"></p> - -<p>この原理はシンプルですが、潜在的な問題がひとつあります。2 回のダウンロードの間にリソースが変更されると、取得した範囲が 2 つの異なるバージョンのリソースに対応してしまい、最終的な文書が壊れてしまうでしょう。</p> - -<p>これを防ぐため、条件付きリクエストを使用します。範囲についてこれを行うための方法が 2 つあります。より柔軟な方法は {{HTTPHeader("If-Modified-Since")}} と {{HTTPHeader("If-Match")}} を使用することであり、前提条件に合わない場合はサーバーがエラーを返します。すると、クライアントはダウンロードを始めから再実行します。</p> - -<p><img alt="When the partially downloaded resource has been modified, the preconditions will fail and the resource will have to be downloaded again completely." src="https://mdn.mozillademos.org/files/13739/HTTPResume3.png"></p> - -<p>この方法でも動作しますが、文書が変更されると余分なレスポンスやリクエストの交換が発生します。これはパフォーマンスを低下させますので HTTP には、この問題を避けるために特化した追加ヘッダーである {{HTTPHeader("If-Range")}} があります。</p> - -<p><img alt="The If-Range headers allows the server to directly send back the complete resource if it has been modified, no need to send a 412 error and wait for the client to re-initiate the download." src="https://mdn.mozillademos.org/files/13741/HTTPResume4.png" style="height: 263px; width: 770px;"></p> - -<p>この解決策はより効率的ですが、柔軟性が若干劣ります (条件で etag をひとつしか使用できません)。ただし、これ以上の柔軟性はほとんど必要ありません。</p> - -<h3 id="Avoiding_the_lost_update_problem_with_optimistic_locking" name="Avoiding_the_lost_update_problem_with_optimistic_locking">楽観的ロックでロストアップデートを避ける</h3> - -<p>リモートの文書の<em>更新</em>は、ウェブアプリケーションで一般的な操作です。これはファイルシステムやソース管理アプリケーションではごく一般的ですが、リモートにリソースを保存できるようにするにはこのような仕組みが必要です。同様に、wiki のような一般的なウェブサイトや他の CMS でも必要です。</p> - -<p>{{HTTPMethod("PUT")}} を使用して、この機能を実装できます。クライアントは始めに元のファイルを読み込んで、変更した後にサーバーへ送信します。</p> - -<p><img alt="Updating a file with a PUT is very simple when concurrency is not involved." src="https://mdn.mozillademos.org/files/13743/HTTPLock1.png"></p> - -<p>残念ながら、並行処理を考慮すると若干の間違いが出てきます。あるクライアントがリソースの新たな複製をローカルで変更している間に、第二のクライアントが同じリソースを取得して、クライアント側で同じことを行えます。これにより、とても不幸なことが発生します。両者がリソースを引き渡すと、最初のクライアントが渡した変更点が次に渡されたものによって破棄されて、第二のクライアントは新たな変更点に気づきません。誰が勝ち取ったかの結果は他者には伝わりませんが、どのクライアントの変更点が反映されるかは引き渡す速度によって変わります。またその速度はクライアントやサーバーのパフォーマンス、さらにはクライアント側で人間が文書を編集するパフォーマンスに依存します。勝ち取る者は、その時々で変わります。これは{{glossary("race condition","競合状態")}}であり、検出やデバッグが難しい不確かな動作をもたらします。</p> - -<p><img alt="When several clients update the same resource in parallel, we are facing a race condition: the slowest win, and the others don't even know they lost. Problematic!" src="https://mdn.mozillademos.org/files/13749/HTTPLock2.png" style="height: 504px; width: 904px;"></p> - -<p>2 つのクライアントの片方を困らせることなく、この問題に対処する方法はありません。しかし、ロストアップデートや競合状態は避けるべきです。予測可能な結果や、クライアントが変更点を却下されたときに通知を受けることを望みます。</p> - -<p>条件付きリクエストで、<em>楽観的ロックアルゴリズム</em> (ほとんどの wiki やソース管理システムで使用されています) を実装できます。この考え方ではすべてのクライアントに、リソースの複製の取得を許可してローカルで変更することを許可します。そして、最初のクライアントが更新内容を送信することを許可して成功させて、以降の古いバージョンになったリソースに基づく更新は拒否します。</p> - -<p><img alt="Conditional requests allow to implement optimistic locking: now the quickest wins, and the others get an error." src="https://mdn.mozillademos.org/files/13751/HTTPLock3.png" style="height: 471px; width: 904px;"></p> - -<p>これは {{HTTPHeader("If-Match")}} および {{HTTPHeader("If-Unmodified-Since")}} ヘッダーを使用して実装します。etag が元のファイルと一致しない、あるいはファイルが取得したときから変更されている場合は、変更点が {{HTTPStatus("412")}} <code>Precondition Failed</code> エラーで拒否されます。このエラーへの対処はクライアント次第であり、今度は最新のバージョンで再び実行するよう人間に通知する、あるいは "diff" を表示して変更点を維持するかを人間が選択できるように支援します。</p> - -<h3 id="Dealing_with_the_first_upload_of_a_resource" name="Dealing_with_the_first_upload_of_a_resource">リソースの最初のアップロードに対処する</h3> - -<p>リソースの最初のアップロードは、前述の状況の特別なケースです。リソースの更新と同様に、2 つのクライアントが同時 (あるいはほぼ同時) にアップロードしようとする競合状態を仮定します。これを防ぐために条件付きリクエストを使用できます。すべての etag を表す特別な値 <code>'*'</code> を持つ {{HTTPHeader("If-None-Match")}} を追加することで、それより前のリクエストが存在しない場合に限り、リクエストが成功します。</p> - -<p><img alt="Like for a regular upload, the first upload of a resource is subject to a race condition: If-None-Match can prevent it." src="https://mdn.mozillademos.org/files/13753/HTTPFirst.png" style="height: 311px; width: 895px;"></p> - -<p><code>If-None-Match</code> は HTTP/1.1 (およびそれ以降) に準拠するサーバーのみで動作します。サーバーが対応しているかが不明である場合は、始めに確認用の {{HTTPMethod("HEAD")}} リクエストをリソースに対して発行しなければなりません。</p> - -<h2 id="Conclusion" name="Conclusion">まとめ</h2> - -<p>条件付きリクエストは HTTP の重要な機能であり、効率的で複雑なアプリケーションの構築を可能にします。キャッシュやダウンロードの再開について、ウェブマスターに求められる作業はサーバーを適切に設定することだけです (一部の環境では正しい etag を設定することが難しいかもしれません)。また、ブラウザーが適切な条件付きリクエストを実行しますので、ウェブ開発者に求められる作業はありません</p> - -<p>一方、ロックの仕組みでは、ウェブ開発者が適切なヘッダーを伴ってリクエストを発行しなければなりません。ウェブマスターはほとんどの場合、それらの確認をアプリケーションに頼ることができるでしょう。</p> - -<p>どちらにせよ、条件付きリクエストはウェブの重要な機能であることは明らかです。</p> diff --git a/files/ja/web/http/conditional_requests/index.md b/files/ja/web/http/conditional_requests/index.md new file mode 100644 index 0000000000..a02ce7ac95 --- /dev/null +++ b/files/ja/web/http/conditional_requests/index.md @@ -0,0 +1,140 @@ +--- +title: HTTP 条件付きリクエスト +slug: Web/HTTP/Conditional_requests +tags: + - Conditional Requests + - Guide + - HTTP +translation_of: Web/HTTP/Conditional_requests +--- +{{HTTPSidebar}} + +HTTP には*条件付きリクエスト*の概念があり、対象となるリソースと*検証子*の値とを比較することで、リクエストの結果や、成功か失敗かまでもが変化することがあります。このようなリクエストは、キャッシュの内容を検証して、無用な制御を避けたり、ダウンロードの再開の時などに文書の整合性を検証したり、サーバー上の文書をアップロードまたは変更するときに更新内容を失うことを避ける場合などに役立つことがあります。 + +## 原理 + +HTTP 条件付きリクエストは、特定のヘッダーの値に応じて異なる処理が行われるリクエストです。これらのヘッダーは前提条件を定義しており、リクエストの結果は前提条件に一致するか否かに応じて変わります。 + +リクエストで使用したメソッドや前提条件で使用したヘッダー一式によって、さまざまな動作が定義されています。 + +- {{HTTPMethod("GET")}} などの{{glossary("safe", "安全な")}}メソッドは、一般に文書を取得するメソッドであり、条件付きリクエストは関連する文書のみを返信するために利用することができます。これによって、帯域を節約します。 +- {{HTTPMethod("PUT")}} などの{{glossary("safe", "安全ではない")}}メソッドは、一般に文書をアップロードするメソッドであり、条件付きリクエストは文書がサーバーに格納されているものと同じものに基づいたものである場合に限ってアップロードするようにするために利用することができます。 + +## 検証子 + +すべての条件ヘッダーは、サーバーに保存されているリソースが特定のバージョンに一致するか確認を試みます。このため、条件付きリクエストではリソースのバージョンを示す必要があります。リソース全体をバイト単位で比較することは不可能であり、常に望まれていることとは限らないので、リクエストはバージョンを記述する値を送信します。このような値は*検証子*と呼ばれ、二種類があります。 + +- 文書が最後に変更された日時である _last-modified_ の日時 +- *エンティティタグ*または _etag_ と呼ばれる、各バージョンを一意に識別する不透明な文字列。 + +同じリソースのバージョンの比較は少々複雑です。状況によって、二種類の*確認方法*があります。 + +- 強い検証 (Strong validation) は、ダウンロードを再開するときなど、バイト単位の同一性が求められる場合に使用します。 +- 弱い検証 (Weak validation) は、ユーザーエージェントが二つのリソースが同じであることを確認することだけが必要である場合に使用します。これは広告の違いやフッターの日付の違いなど、小さな違いがある場合も含みます。 + +検証の種類と使用される検証子は独立しています。 {{HTTPHeader("Last-Modified")}} と {{HTTPHeader("ETag")}} はどちらの種類の検証もできますが、サーバー側の実装の複雑さは異なります。 HTTP は既定で強い検証を使用し、弱い検証を使用するときはそれを指定します。 + +### 強い検証 + +強い検証は、比較対象のリソースがバイト単位で同一であることを保証します。これは一部の条件ヘッダーで必須、また他のヘッダーでは既定の要件です。強い検証はとても厳密であり、サーバーレベルで保証することが困難である場合もありますが、時には性能を犠牲にしても、データが失われていないことを常に保証します。 + +{{HTTPHeader("Last-Modified")}} で強い検証のための一意な識別子を持つことは、とても困難です。多くの場合、リソースの MD5 ハッシュ (あるいはその派生物) を持つ {{HTTPHeader("ETag")}} を使用します。 + +### 弱い検証 + +弱い検証は、内容が等価であるなら二つのバージョンの文書が等しいと見なされるという点で、強い検証と異なります。例えばフッターの日付だけ、あるいは広告だけが異なる二つのページは、弱い検証では*同一*であるとみなされますが、強い検証では異なるものとみなされます。弱い検証を作り出す etag のシステムを構築することは、ページのさまざまな要素の重要性を知ることが伴うため複雑になるかもしれませんが、キャッシュの性能を最適化するためにとても役に立ちます。 + +## 条件ヘッダー + +条件ヘッダーと呼ばれるいくつかの HTTP ヘッダーが、条件付きリクエストをもたらします。 + +- {{HTTPHeader("If-Match")}} + - : 遠方のリソースの {{HTTPHeader("ETag")}} と、このヘッダーに載せた etag が等しければ成功します。既定では etag に接頭辞 `'W/'` がついていない限り、強い検証を行います。 +- {{HTTPHeader("If-None-Match")}} + - : 遠方のリソースの {{HTTPHeader("ETag")}} と、このヘッダーに載せたそれぞれの etag が異なっていれば成功します。既定では etag に接頭辞 `'W/'` がついていない限り、強い検証を行います。 +- {{HTTPHeader("If-Modified-Since")}} + - : 遠方のリソースの {{HTTPHeader("Last-Modified")}} の日時が、このヘッダーで指定した日時より新しければ成功します。 +- {{HTTPHeader("If-Unmodified-Since")}} + - : 遠方のリソースの {{HTTPHeader("Last-Modified")}} の日時が、このヘッダーで指定した日時より過去または同一であれば成功します。 +- {{HTTPHeader("If-Range")}} + - : {{HTTPHeader("If-Match")}} や {{HTTPHeader("If-Unmodified-Since")}} に似ていますが、 etag または日時をひとつしか持つことができません。条件が失敗すると範囲指定リクエストも失敗して、 {{HTTPStatus("206")}} `Partial Content` レスポンスの代わりに {{HTTPStatus("200")}} `OK` でリソース全体を送信します。 + +## 使用例 + +### キャッシュの更新 + +条件付きリクエストのもっとも一般的な使用例は、キャッシュの更新です。キャッシュが空である、あるいはキャッシュを使用しない状態では {{HTTPStatus("200")}} `OK` ステータスと共に、要求したリソースが送信されます。 + + + +リソースと共に、ヘッダーで検証子を送信します。この例では {{HTTPHeader("Last-Modified")}} と {{HTTPHeader("ETag")}} の両方を送信していますが、どちらか一方しか使用しません。これらの検証子はリソースと共に (すべてのヘッダーのように) キャッシュへ保存され、キャッシュが陳腐化したときに条件付きリクエストを作成するために使用します。 + +キャッシュが陳腐化していなければ、条件付きリクエストは行いません。しかしキャッシュが陳腐化すると主に {{HTTPHeader("Cache-Control")}} ヘッダーに制御されて、クライアントはキャッシュされた値を直接使用せず、{{HTTPHeader("If-Modified-Since")}} または {{HTTPHeader("If-Match")}} ヘッダーに検証子の値を指定した*条件付きリクエスト*を発行します。 + +リソースが変更されていなければ、サーバーは {{HTTPStatus("304")}} `Not Modified` レスポンスを返します。これはキャッシュを再び新鮮な状態にして、クライアントはキャッシュされたリソースを使用します。これはリソースをいくらか消費するレスポンスとリクエストのやり取りが発生しますが、通信網でリソース全体を再度転送するよりも効率的です。 + + + +リソースが変更された場合は、サーバーは条件付きではないリクエストと同様に {{HTTPStatus("200")}}` OK` レスポンスで新しいバージョンのリソースを送信します。そして、クライアントは新しいリソースを使用します (また、それをキャッシュします)。 + + + +サーバー側で検証子を設定することをを除いて、この仕組みは透過的です。どのブラウザーもウェブ開発者が特別な作業を行うことなく、キャッシュを管理してこのような条件付きリクエストを送信します。 + +### 部分ダウンロードの整合性 + +ファイルの部分ダウンロードは、以前の操作を再開することが可能な HTTP の機能であり、すでに取得済みの情報を保持することによって帯域や時間を節約します。 + + + +部分ダウンロードをサポートするサーバーは、{{HTTPHeader("Accept-Ranges")}} ヘッダーを送信してそのことを知らせます。このヘッダーが送信されると、クライアントは {{HTTPHeader("Ranges")}} ヘッダーで欠落している範囲を送信することで、ダウンロードを再開できます。 + + + +この原理はシンプルですが、潜在的な問題がひとつあります。2 回のダウンロードの間にリソースが変更されると、取得した範囲が 2 つの異なるバージョンのリソースに対応してしまい、最終的な文書が壊れてしまうでしょう。 + +これを防ぐため、条件付きリクエストを使用します。範囲についてこれを行うための方法が 2 つあります。より柔軟な方法は {{HTTPHeader("If-Modified-Since")}} と {{HTTPHeader("If-Match")}} を使用することであり、前提条件に合わない場合はサーバーがエラーを返します。すると、クライアントはダウンロードを始めから再実行します。 + + + +この方法でも動作しますが、文書が変更されると余分なレスポンスやリクエストの交換が発生します。これはパフォーマンスを低下させますので HTTP には、この問題を避けるために特化した追加ヘッダーである {{HTTPHeader("If-Range")}} があります。 + + + +この解決策はより効率的ですが、柔軟性が若干劣ります (条件で etag をひとつしか使用できません)。ただし、これ以上の柔軟性はほとんど必要ありません。 + +### 楽観的ロックで更新が失われる問題を避ける + +リモートの文書の*更新*は、ウェブアプリケーションで一般的な操作です。これはファイルシステムやソース管理アプリケーションではごく一般的ですが、リモートにリソースを保存できるようにするにはこのような仕組みが必要です。同様に、wiki のような一般的なウェブサイトや他の CMS でも必要です。 + +{{HTTPMethod("PUT")}} を使用して、この機能を実装できます。クライアントは始めに元のファイルを読み込んで、変更した後にサーバーへ送信します。 + + + +残念ながら、並行処理を考慮すると若干の間違いが出てきます。あるクライアントがリソースの新たな複製をローカルで変更している間に、第二のクライアントが同じリソースを取得して、クライアント側で同じことを行えます。これにより、とても不幸なことが発生します。両者がリソースを引き渡すと、最初のクライアントが渡した変更点が次に渡されたものによって破棄されて、第二のクライアントは新たな変更点に気づきません。誰が勝ち取ったかの結果は他者には伝わりませんが、どのクライアントの変更点が反映されるかは引き渡す速度によって変わります。またその速度はクライアントやサーバーのパフォーマンス、さらにはクライアント側で人間が文書を編集するパフォーマンスに依存します。勝ち取る者は、その時々で変わります。これは*競合状態*であり、検出やデバッグが難しい不確かな動作をもたらします。 + + + +2 つのクライアントの片方を困らせることなく、この問題に対処する方法はありません。しかし、更新が失われたりや競合状態になったりすることは避けるべきです。予測可能な結果や、クライアントが変更点を却下されたときに通知を受けることを望みます。 + +条件付きリクエストで、*楽観的ロックアルゴリズム* (ほとんどの wiki やソース管理システムで使用されています) を実装できます。この考え方ではすべてのクライアントに、リソースの複製の取得を許可してローカルで変更することを許可します。そして、最初のクライアントが更新内容を送信することを許可して成功させて、以降の古いバージョンになったリソースに基づく更新は拒否します。 + + + +これは {{HTTPHeader("If-Match")}} および {{HTTPHeader("If-Unmodified-Since")}} ヘッダーを使用して実装します。etag が元のファイルと一致しない、あるいはファイルが取得したときから変更されている場合は、変更点が {{HTTPStatus("412")}} `Precondition Failed` エラーで拒否されます。このエラーへの対処はクライアント次第であり、今度は最新のバージョンで再び実行するよう人間に通知する、あるいは _diff_ を表示して変更点を維持するかを人間が選択できるように支援します。 + +### リソースの最初のアップロードに対処する + +リソースの最初のアップロードは、前述の状況の特別なケースです。リソースの更新と同様に、2 つのクライアントが同時 (あるいはほぼ同時) にアップロードしようとする競合状態を仮定します。これを防ぐために条件付きリクエストを使用できます。すべての etag を表す特別な値 `'*'` を持つ {{HTTPHeader("If-None-Match")}} を追加することで、それより前のリクエストが存在しない場合に限り、リクエストが成功します。 + + + +`If-None-Match` は HTTP/1.1 (およびそれ以降) に準拠するサーバーのみで動作します。サーバーが対応しているかが不明である場合は、始めに確認用の {{HTTPMethod("HEAD")}} リクエストをリソースに対して発行しなければなりません。 + +## まとめ + +条件付きリクエストは HTTP の重要な機能であり、効率的で複雑なアプリケーションの構築を可能にします。キャッシュやダウンロードの再開について、ウェブマスターに求められる作業はサーバーを適切に設定することだけです (一部の環境では正しい etag を設定することが難しいかもしれません)。また、ブラウザーが適切な条件付きリクエストを実行しますので、ウェブ開発者に求められる作業はありません + +一方、ロックの仕組みでは、ウェブ開発者が適切なヘッダーを伴ってリクエストを発行しなければなりません。ウェブマスターはほとんどの場合、それらの確認をアプリケーションに頼ることができるでしょう。 + +どちらにせよ、条件付きリクエストはウェブの重要な機能であることは明らかです。 diff --git a/files/ja/web/http/headers/accept-language/index.html b/files/ja/web/http/headers/accept-language/index.html index f3319e6f02..b21cdeb4a1 100644 --- a/files/ja/web/http/headers/accept-language/index.html +++ b/files/ja/web/http/headers/accept-language/index.html @@ -12,7 +12,7 @@ translation_of: Web/HTTP/Headers/Accept-Language --- <div>{{HTTPSidebar}}</div> -<p>HTTP の <strong><code>Accept-Language</code></strong> リクエストヘッダーは、クライアントがどの言語を理解できるか、どの種類のロケールが推奨されるかを示します。 (言語というのは、英語のような自然言語を意味し、プログラミング言語ではありません。) <a href="/ja/docs/Web/HTTP/Content_negotiation">コンテンツネゴシエーション</a>を使用して、サーバーは提案されたものから一つを選択して使用し、 {{HTTPHeader("Content-Language")}} レスポンスヘッダーを使用してクライアントに選択結果を知らせます。ブラウザーはユーザーインターフェイスの言語に従って、このヘッダーに適切な値を設定し、ユーザーはこれを変更することができますが、稀です (そして指紋につながるとして難色を示されます)。</p> +<p>HTTP の <strong><code>Accept-Language</code></strong> リクエストヘッダーは、クライアントがどの言語を理解できるか、どの種類のロケールが推奨されるかを示します。 (言語というのは、英語のような自然言語を意味し、プログラミング言語ではありません。) <a href="/ja/docs/Web/HTTP/Content_negotiation">コンテンツネゴシエーション</a>を使用して、サーバーは提案されたものから一つを選択して使用し、 {{HTTPHeader("Content-Language")}} レスポンスヘッダーを使用してクライアントに選択結果を知らせます。ブラウザーはユーザーインターフェイスの言語に従って、このヘッダーに適切な値を設定し、ユーザーはこれを変更することができますが、稀です (そしてフィンガープリントにつながるとして難色を示されます)。</p> <p>このヘッダーはヒントであり、サーバーが言語を判別するための方法として、明示的なユーザーの選択によって制御する特定の URL など、他のものがない場合に使用されます。サーバーは明示的な決定を上書きしないことを推奨します。 <code>Accept-Language</code> の中身はユーザーが制御できないことが良くあります（旅行中で外国のインターネットカフェを使用している場合など）。ユーザーはユーザーインターフェースのロケール以外の言語によるページを訪問したがっているかもしれません。</p> diff --git a/files/ja/web/http/headers/content-type/index.html b/files/ja/web/http/headers/content-type/index.html deleted file mode 100644 index 7f54b32569..0000000000 --- a/files/ja/web/http/headers/content-type/index.html +++ /dev/null @@ -1,122 +0,0 @@ ---- -title: Content-Type -slug: Web/HTTP/Headers/Content-Type -tags: - - Content-Type - - HTTP - - Reference - - エンティティヘッダー - - ヘッダー -translation_of: Web/HTTP/Headers/Content-Type ---- -<div>{{HTTPSidebar}}</div> - -<p><strong><code>Content-Type</code></strong> エンティティヘッダーは、リソースの{{Glossary("MIME type","メディア種別")}}を示すために使用します。</p> - -<p>レスポンスにおいては、 <code>Content-Type</code> ヘッダーはクライアントに返されたコンテンツが実際にはどのような種類のものであるかを伝えます。場合によってはブラウザーは MIME を推定し、このヘッダーの値に従わないこともあります。 {{HTTPHeader("X-Content-Type-Options")}} を <code>nosniff</code> に設定すると、この振舞いを防ぐことができます。</p> - -<p>要求においては ({{HTTPMethod("POST")}} または {{HTTPMethod("PUT")}} などで)、クライアントがサーバーにどのような種類のデータが実際に送られたかを伝えます。</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">ヘッダー種別</th> - <td>{{Glossary("Entity header", "エンティティヘッダー")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Forbidden header name", "禁止ヘッダー名")}}</th> - <td>いいえ</td> - </tr> - <tr> - <th scope="row">{{Glossary("CORS-safelisted response header", "CORS セーフリストレスポンスヘッダー")}}</th> - <td>はい</td> - </tr> - <tr> - <th scope="row">{{Glossary("CORS-safelisted request header", "CORS セーフリストリクエストヘッダー")}}</th> - <td>はい。 <em>CORS 危険リクエストヘッダーバイト</em>: <code>"():<>?@[\]{}</code>, Delete, Tab, 制御文字の 0x00 から 0x19 までを値に含むことができないという制限付きです。<br> - また、 MIME タイプの解釈値 (引数を除いたもの) が <code>application/x-www-form-urlencoded</code>, <code>multipart/form-data</code>, <code>text/plain</code> の何れかである必要があります。</td> - </tr> - </tbody> -</table> - -<h2 id="Syntax" name="Syntax">構文</h2> - -<pre class="syntaxbox">Content-Type: text/html; charset=UTF-8 -Content-Type: multipart/form-data; boundary=something -</pre> - -<h2 id="Directives" name="Directives">ディレクティブ</h2> - -<dl> - <dt><code>media-type</code></dt> - <dd>リソースやデータの <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME タイプ</a>です。</dd> - <dt>charset</dt> - <dd>標準の文字エンコーディングです。</dd> - <dt>boundary</dt> - <dd>マルチパートの本文では <code>boundary</code> ディレクティブが必要で、これはメールゲートウェイを通過しても大丈夫だと知られている文字の中から1～70文字で構成され、ホワイトスペースで終了しないものです。これはメッセージの複数パートの境界を囲むために使用します。ふつう、ヘッダーの境界は2本のダッシュで始まり、最後の境界には最後にも2本のダッシュが入ります。</dd> -</dl> - -<h2 id="Examples" name="Examples">例</h2> - -<h3 id="Content-Type_in_HTML_forms" name="Content-Type_in_HTML_forms">HTML フォームにおける <code>Content-Type</code></h3> - -<p>HTML フォームを送信した結果としての {{HTTPMethod("POST")}} 要求において、 <code>Content-Type</code> は {{HTMLElement("form")}} 要素の <code>enctype</code> 属性で指定します。</p> - -<pre class="brush: html"><form action="/" method="post" enctype="multipart/form-data"> - <input type="text" name="description" value="some text"> - <input type="file" name="myFile"> - <button type="submit">Submit</button> -</form> -</pre> - -<p>この要求はこのように見えます。 (ここではあまり重要でないヘッダーは省略しています)</p> - -<pre>POST /foo HTTP/1.1 -Content-Length: 68137 -Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575 - ------------------------------974767299852498929531610575 -Content-Disposition: form-data; name="description" - -some text ------------------------------974767299852498929531610575 -Content-Disposition: form-data; name="myFile"; filename="foo.txt" -Content-Type: text/plain - -(content of the uploaded file foo.txt) ------------------------------974767299852498929531610575-- -</pre> - -<h2 id="Specifications" name="Specifications">仕様書</h2> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">仕様書</th> - <th scope="col">題名</th> - </tr> - </thead> - <tbody> - <tr> - <td>{{RFC("7233", "Content-Type in multipart", "4.1")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td> - </tr> - <tr> - <td>{{RFC("7231", "Content-Type", "3.1.1.5")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> - </tr> - </tbody> -</table> - -<h2 id="Browser_compatibility" name="Browser_compatibility">ブラウザーの互換性</h2> - -<p>{{Compat("http.headers.Content-Type")}}</p> - -<h2 id="See_also" name="See_also">関連情報</h2> - -<ul> - <li>{{HTTPHeader("Accept")}} および {{HTTPHeader("Accept-Charset")}}</li> - <li>{{HTTPHeader("Content-Disposition")}}</li> - <li>{{HTTPStatus("206")}} Partial Content</li> - <li>{{HTTPHeader("X-Content-Type-Options")}}</li> -</ul> diff --git a/files/ja/web/http/headers/content-type/index.md b/files/ja/web/http/headers/content-type/index.md new file mode 100644 index 0000000000..611836d9f2 --- /dev/null +++ b/files/ja/web/http/headers/content-type/index.md @@ -0,0 +1,110 @@ +--- +title: Content-Type +slug: Web/HTTP/Headers/Content-Type +tags: + - Content-Type + - HTTP + - HTTP header + - Representation header + - Reference + - 表現ヘッダー + - ヘッダー +browser-compat: http.headers.Content-Type +translation_of: Web/HTTP/Headers/Content-Type +--- +{{HTTPSidebar}} + +**`Content-Type`** 表現ヘッダーは、リソースの{{Glossary("MIME type","メディア種別")}}を示すために使用します。</p> + +レスポンスにおいては、 `Content-Type` ヘッダーはクライアントに返されたコンテンツの実際の種類を伝えます。ブラウザーは MIME を推定し、このヘッダーの値に従わないこともあります。 {{HTTPHeader("X-Content-Type-Options")}} を `nosniff` に設定すると、この動作を防ぐことができます。 + +リクエストにおいては ({{HTTPMethod("POST")}} または {{HTTPMethod("PUT")}} などで)、クライアントがサーバーに実際に送ったデータの種類を伝えます。 + +<table class="properties"> + <tbody> + <tr> + <th scope="row">ヘッダー種別</th> + <td>{{Glossary("Representation header", "表現ヘッダー")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name", "禁止ヘッダー名")}}</th> + <td>いいえ</td> + </tr> + <tr> + <th scope="row">{{Glossary("CORS-safelisted response header", "CORS セーフリストレスポンスヘッダー")}}</th> + <td>はい</td> + </tr> + <tr> + <th scope="row"> + {{Glossary("CORS-safelisted request header", "CORS セーフリストリクエストヘッダー")}} + </th> + <td> + はい。 <em>CORS 危険リクエストヘッダーバイト</em>である 0x00-0x1F (0x09 (HT) を除く)、<code>"():<>?@[\]{}</code>、0x7F (DEL) を値に含むことができないという制限付きです。<br>また、 MIME タイプの解釈値 (引数を除いたもの) が <code>application/x-www-form-urlencoded</code>, <code>multipart/form-data</code>, <code>text/plain</code> の何れかである必要があります。</td> + </tr> + </tbody> +</table> + +## 構文 + +``` +Content-Type: text/html; charset=UTF-8 +Content-Type: multipart/form-data; boundary=something +``` + +## ディレクティブ + +- `media-type` + - : リソースやデータの [MIME タイプ](/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types)です。 +- charset + - : 標準の文字エンコーディングです。 +- boundary + - : マルチパートの本文では `boundary` ディレクティブが必要で、これはメールゲートウェイを通過しても大丈夫だと知られている文字の中から 1～70 文字で構成され、ホワイトスペースで終了しないものです。これはメッセージの複数パートの境界を囲むために使用します。ふつう、ヘッダーの境界は 2 本のダッシュで始まり、最後の境界には最後にも 2 本のダッシュが入ります。</dd> +</dl> + +## 例 + +### HTML フォームにおける `Content-Type` + + HTML フォームを送信する {{HTTPMethod("POST")}} リクエストでは、リクエストの `Content-Type` は {{HTMLElement("form")}} 要素の `enctype` 属性で指定します。 + +```html +<form action="/" method="post" enctype="multipart/form-data"> + <input type="text" name="description" value="some text"> + <input type="file" name="myFile"> + <button type="submit">Submit</button> +</form> +``` + +このリクエストはこのように見えます (ここではあまり重要でないヘッダーは省略しています)。 + +``` +POST /foo HTTP/1.1 +Content-Length: 68137 +Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575 + +-----------------------------974767299852498929531610575 +Content-Disposition: form-data; name="description" + +some text +-----------------------------974767299852498929531610575 +Content-Disposition: form-data; name="myFile"; filename="foo.txt" +Content-Type: text/plain + +(content of the uploaded file foo.txt) +-----------------------------974767299852498929531610575-- +``` + +## 仕様書 + +{{Specifications}} + +## ブラウザーの互換性 + +{{Compat}} + +## 関連情報 + +- {{HTTPHeader("Accept")}} +- {{HTTPHeader("Content-Disposition")}} +- {{HTTPStatus("206")}} Partial Content +- {{HTTPHeader("X-Content-Type-Options")}} diff --git a/files/ja/web/http/headers/dnt/index.html b/files/ja/web/http/headers/dnt/index.html deleted file mode 100644 index 426113364d..0000000000 --- a/files/ja/web/http/headers/dnt/index.html +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: DNT -slug: Web/HTTP/Headers/DNT -tags: - - DNT - - HTTP - - ヘッダー - - リファレンス -translation_of: Web/HTTP/Headers/DNT ---- -<p>{{HTTPSidebar}}</p> - -<p><strong><code>DNT</code></strong> (<strong>D</strong>o <strong>N</strong>ot <strong>T</strong>rack) リクエストヘッダーは、ユーザーのトラッキングの設定を示します。 これにより、ユーザーはパーソナライズされたコンテンツではなく、プライバシーを優先するかどうかを指定できます.</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">ヘッダータイプ</th> - <td>{{Glossary("Request header")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Forbidden header name")}}</th> - <td>はい</td> - </tr> - </tbody> -</table> - -<h2 id="構文">構文</h2> - -<pre class="syntaxbox notranslate">DNT: 0 -DNT: 1 -DNT: null -</pre> - -<h2 id="宣言">宣言</h2> - -<dl> - <dt>0</dt> - <dd>ユーザーは対象のサイトでトラッキングを許可している。</dd> - <dt>1</dt> - <dd>ユーザーは対象のサイトでトラッキングを拒否している。</dd> - <dt>null</dt> - <dd>ユーザーはトラッキングに関する設定を指定していない。</dd> -</dl> - -<h2 id="例">例</h2> - -<h3 id="JavaScript_から_Do_Not_Track_の状態を読み取る">JavaScript から Do Not Track の状態を読み取る</h3> - -<p>ユーザーの DNT 設定は {{domxref("Navigator.doNotTrack")}} プロパティを使用して JavaScript から読み取ることもできます:</p> - -<pre class="brush: js notranslate">navigator.doNotTrack; // "0" or "1"</pre> - -<h2 id="仕様">仕様</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">仕様</th> - <th scope="col">ステータス</th> - <th scope="col">コメント</th> - </tr> - <tr> - <td>{{SpecName('Tracking','#dnt-header-field', 'DNT Header Field for HTTP Requests')}}</td> - <td>{{Spec2("Tracking")}}</td> - <td>初期定義。</td> - </tr> - </tbody> -</table> - -<h2 id="ブラウザー実装状況">ブラウザー実装状況</h2> - -<p>{{Compat("http.headers.DNT")}}</p> - -<h2 id="関連項目">関連項目</h2> - -<ul> - <li>{{domxref("Navigator.doNotTrack")}}</li> - <li>{{HTTPHeader("Tk")}} ヘッダー</li> - <li><a href="https://en.wikipedia.org/wiki/Do_Not_Track">Do Not Track on Wikipedia</a></li> - <li><a href="https://www.eff.org/deeplinks/2011/02/what-does-track-do-not-track-mean">What Does the "Track" in "Do Not Track" Mean? – EFF</a></li> - <li><a href="http://donottrack.us/">donottrack.us</a></li> - <li>DNT ブラウザー設定のヘルプ: - <ul> - <li><a href="https://www.mozilla.org/ja/firefox/dnt/">Firefox</a></li> - <li><a href="https://support.google.com/chrome/answer/2790761">Chrome</a></li> - </ul> - </li> -</ul> diff --git a/files/ja/web/http/headers/dnt/index.md b/files/ja/web/http/headers/dnt/index.md new file mode 100644 index 0000000000..f961a5e00c --- /dev/null +++ b/files/ja/web/http/headers/dnt/index.md @@ -0,0 +1,74 @@ +--- +title: DNT +slug: Web/HTTP/Headers/DNT +tags: + - DNT + - HTTP + - ヘッダー + - リファレンス +browser-compat: http.headers.DNT +translation_of: Web/HTTP/Headers/DNT +--- +{{HTTPSidebar}}{{Deprecated_header}} + +**`DNT`** (**D**o **N**ot +**T**rack) リクエストヘッダーは、ユーザーのトラッキングの設定を示します。これにより、ユーザーはパーソナライズされたコンテンツではなく、プライバシーを優先するかどうかを指定できます。 + +<table class="properties"> + <tbody> + <tr> + <th scope="row">ヘッダー種別</th> + <td>{{Glossary("Request header", "リクエストヘッダー")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name", "禁止ヘッダー名")}}</th> + <td>はい</td> + </tr> + </tbody> +</table> + +## 構文 + +``` +DNT: 0 +DNT: 1 +DNT: null +``` + +## ディレクティブ + +- 0 + - : ユーザーは対象のサイトでトラッキングを許可している。 +- 1 + - : ユーザーは対象のサイトでトラッキングを拒否している。 +- null + - : ユーザーはトラッキングに関する設定を指定していない。 + +## 例 + +### JavaScript から Do Not Track の状態を読み取る + +ユーザーの DNT 設定は {{domxref("Navigator.doNotTrack")}} プロパティを使用して JavaScript から読み取ることもできます。 + +```js +navigator.doNotTrack; // "0" or "1" +``` + +## 仕様書 + +{{Specifications}} + +## ブラウザーの互換性 + +{{Compat}} + +## 関連情報 + +- {{domxref("Navigator.doNotTrack")}} +- {{HTTPHeader("Tk")}} ヘッダー +- [Wikipedia の Do Not Track](https://en.wikipedia.org/wiki/Do_Not_Track) +- [What Does the "Track" in "Do Not Track" Mean? – EFF](https://www.eff.org/deeplinks/2011/02/what-does-track-do-not-track-mean) +- [donottrack.us](https://donottrack.us/) +- DNT ブラウザー設定のヘルプ: + - [Firefox](https://www.mozilla.org/en-US/firefox/dnt/) + - [Chrome](https://support.google.com/chrome/answer/2790761) diff --git a/files/ja/web/http/headers/expect-ct/index.html b/files/ja/web/http/headers/expect-ct/index.html index e815e30946..d402887ddb 100644 --- a/files/ja/web/http/headers/expect-ct/index.html +++ b/files/ja/web/http/headers/expect-ct/index.html @@ -6,16 +6,33 @@ tags: - Reference - ヘッダー - レスポンスヘッダー +browser-compat: http.headers.Expect-CT translation_of: Web/HTTP/Headers/Expect-CT --- <p>{{HTTPSidebar}}</p> -<p><code>Expect-CT</code> ヘッダーは、サイトが認証透過性の要件の報告や強制に参加して、サイトの不正な認証情報が通知されない状態を防ぐことができます。</p> +<p><code>Expect-CT</code> ヘッダーは、サイトが<a href="/ja/docs/Web/Security/Certificate_Transparency">証明書の透明性</a>の要件の報告や強制に参加して、サイトの不正な認証情報の使用が通知されない状態を防ぐことができます。</p> + +<p>CT の要件は、以下のいずれかの仕組みで満たすことができます。</p> + +<ul> + <li>個々のログで発行された署名付き証明書のタイムスタンプを埋め込めるようにするための X.509v3 証明書の拡張</li> + <li>ハンドシェイク中に送信される <code>signed_certificate_timestamp</code> 型の TLS 拡張</li> + <li>OCSP ステープリング (つまり、 <code>status_request</code> TLS 拡張) に対応し、 <code>SignedCertificateTimestampList</code> を提供すること</li> +</ul> <div class="note"> <p>サイトが <code>Expect-CT</code> ヘッダーを有効にすると、ブラウザーが<strong><a href="https://www.certificate-transparency.org/known-logs">公開 CT ログ</a></strong>に現れるサイトのすべての認証情報をチェックするよう要求します。</p> </div> +<div class="notecard note"> + <p><strong>メモ:</strong> ブラウザーは、 HTTP では <code>Expect-CT</code> ヘッダーを<strong>無視</strong>し、 HTTPS 接続でのみ効果を発揮します。</p> +</div> + +<div class="notecard note"> +<p><strong>メモ:</strong> <code>Expect-CT</code> は 2021 年 6 月に廃止される可能性が高いです。 2018 年 5 月以降、新しい証明書は既定で SCT に対応することが期待されています。 2018 年 3 月以前の証明書は 39 ヶ月の有効期限が認められていましたが、それらが 2021 年 6 月にすべて失効します。</p> +</div> + <table class="properties"> <tbody> <tr> @@ -29,43 +46,48 @@ translation_of: Web/HTTP/Headers/Expect-CT </tbody> </table> -<h2 id="Syntax" name="Syntax">構文</h2> +<h2 id="Syntax">構文</h2> <pre>Expect-CT: report-uri="<uri>", enforce, max-age=<age></pre> -<h2 id="Directives" name="Directives">ディレクティブ</h2> +<h2 id="Directives">ディレクティブ</h2> <dl> - <dt>max-age</dt> + <dt><code>max-age</code></dt> <dd> <p><code>Expect-CT</code> ヘッダーフィールドを受信した後で、ユーザーエージェントがメッセージを受信したホストを、既知の Expect-CT ホストと見なすべき時間を秒数で指定します。</p> - <p>キャッシュが表現可能な値よりも大きな値を受信した場合や、計算でオーバーフローが発生した場合、キャッシュは値を 2147483648 (2^31) または使用している表現方法で最も大きな整数値とみなします。</p> + <p>キャッシュが表現可能な値よりも大きな値を受信した場合や、計算でオーバーフローが発生した場合、キャッシュは値を 2,147,483,648 (2^31) または使用している表現方法で最も大きな整数値とみなします。</p> </dd> - <dt>report-uri="<uri>" {{optional_inline}}</dt> + <dt><code>report-uri="<uri>"</code> {{optional_inline}}</dt> <dd> - <p>ユーザーエージェントが Expect-CT の失敗を報告する URI を指定します。</p> - <code>enforce</code> ディレクティブと <code>report-uri</code> ディレクティブが両方ともある場合、設定は "enforce-and-report" の設定と呼ばれ、ユーザーエージェントに認証透過性ポリシーに従い、違反を報告することを指示します。 - - <p> </p> - </dd> - <dt>enforce {{optional_inline}}</dt> + <p>ユーザーエージェントが <code>Expect-CT</code> の失敗を報告する URI を指定します。</p> + <code>enforce</code> ディレクティブと <code>report-uri</code> ディレクティブが両方ともある場合、設定は "enforce-and-report" の設定と呼ばれ、ユーザーエージェントに証明書の透明性ポリシーに従い、違反を報告することを指示します。</dd> + <dt><code>enforce</code> {{optional_inline}}</dt> <dd> - <p>ユーザーエージェントに (報告するだけでなく) 認証透過性ポリシーに従い、ユーザーエージェントが認証透過性ポリシーに違反するコネクションを拒否するよう指示します。</p> + <p>ユーザーエージェントに (報告するだけでなく) 証明書の透明性ポリシーに従い、ユーザーエージェントが証明書の透明性ポリシーに違反するコネクションを拒否するよう指示します。</p> - <p><code>enforce</code> ディレクティブと <code>report-uri</code> ディレクティブが両方ともある場合、設定は "enforce-and-report" の設定と呼ばれ、ユーザーエージェントに認証透過性ポリシーに従い、違反を報告することを指示します。</p> + <p><code>enforce</code> ディレクティブと <code>report-uri</code> ディレクティブが両方ともある場合、設定は "enforce-and-report" の設定と呼ばれ、ユーザーエージェントに証明書の透明性ポリシーに従い、違反を報告することを指示します。</p> </dd> </dl> -<h2 id="Example" name="Example">例</h2> +<h2 id="Example">例</h2> -<p>以下の例は認証透過性を24時間強制し、違反を foo.example に報告することを示します。</p> +<p>以下の例は証明書の透明性を 24 時間強制し、違反を <code>foo.example</code> に報告することを示します。</p> <pre>Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report"</pre> -<h2 id="Specifications" name="Specifications">仕様書</h2> +<h2 id="Notes">メモ</h2> + +<p>信頼ストアに手動で追加されたルート CA は、 <code>Expect-CT</code> の報告/強制を上書きし、抑制します。</p> + +<p>ブラウザーは、サイトが証明書の透明性要件を満たす証明書を提供できることを「証明」しない限り、 <code>Expect-CT</code> ポリシーを記憶しません。ブラウザーは、どの CT ログが証明書のログとして信頼できるとみなされるかについて、独自の信頼モデルを実装しています。</p> + +<p>Chrome のビルドは、インストールのビルド日から 10 週間後に <code>Expect-CT</code> ポリシーの施行を停止するように設計されています。</p> + +<h2 id="Specifications">仕様書</h2> <table class="standard-table"> <thead> @@ -76,12 +98,12 @@ translation_of: Web/HTTP/Headers/Expect-CT </thead> <tbody> <tr> - <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-expect-ct-07">Internet Draft</a></td> + <td><a href="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-expect-ct-08">Internet Draft</a></td> <td>Expect-CT Extension for HTTP</td> </tr> </tbody> </table> -<h2 id="Browser_compatibility" name="Browser_compatibility">ブラウザーの対応</h2> +<h2 id="Browser_compatibility">ブラウザーの互換性</h2> -<p>{{Compat("http.headers.Expect-CT")}}</p> +<p>{{Compat}}</p> diff --git a/files/ja/web/http/headers/index.html b/files/ja/web/http/headers/index.html deleted file mode 100644 index f1b18ac9db..0000000000 --- a/files/ja/web/http/headers/index.html +++ /dev/null @@ -1,461 +0,0 @@ ---- -title: HTTP ヘッダー -slug: Web/HTTP/Headers -tags: - - HTTP - - HTTP ヘッダー - - Networking - - Reference - - header - - ネットワーク - - ヘッダー - - リファレンス -translation_of: Web/HTTP/Headers ---- -<div>{{HTTPSidebar}}</div> - -<p><span class="seoSummary"><strong>HTTP ヘッダー</strong>により、クライアントやサーバーが HTTP リクエストやレスポンスで追加情報を渡すことができます。 HTTP ヘッダーは、大文字小文字を区別しないヘッダー名とそれに続くコロン (<code>:</code>)、 値で構成されます。</span>値の前にある{{Glossary("Whitespace", "ホワイトスペース")}}は無視されます。</p> - -<p>独自のヘッダーは、以前は <code>X-</code> 接頭辞を使用していましたが、この慣習は 2012 年 6 月に非推奨になりました。これは、 <a href="https://tools.ietf.org/html/rfc6648">RFC 6648</a> で非標準のフィールドが標準になったときに発生した不便さのためです。それ以外のヘッダーは <a class="external" href="http://www.iana.org/assignments/message-headers/perm-headers.html">IANA レジストリ</a> に収録されており、その基になったものは <a class="external" href="http://tools.ietf.org/html/rfc4229">RFC 4229</a> です。また IANA は <a class="external" href="http://www.iana.org/assignments/message-headers/prov-headers.html">新たに提案された HTTP ヘッダーのレジストリ</a> も管理しています。</p> - -<p>ヘッダーは、そのコンテキストに応じて分類できます。</p> - -<ul> - <li>{{Glossary("General header", "一般ヘッダー")}}: リクエストとレスポンスの両方に適用されますが、本文で転送されるデータとは関係ないものです。</li> - <li>{{Glossary("Request header", "リクエストヘッダー")}}: 読み込むリソースやリソースをリクエストしているクライアントに関する詳細な情報を持ちます。</li> - <li>{{Glossary("Response header", "レスポンスヘッダー")}}: レスポンスに関する追加情報、例えば場所や提供しているサーバーに関するものを保持します。</li> - <li>{{Glossary("Entity header", "エンティティヘッダー")}}: リソースの本体に関する情報、例えば<a href="/ja/docs/Web/HTTP/Headers/Content-Length">コンテンツの長さ</a>や <a href="/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME タイプ</a>などを持ちます。</li> -</ul> - -<p>またヘッダーは、{{Glossary("Proxy_server", "プロキシサーバー")}}がどのように処理するかに応じてグループ化されます。</p> - -<ul> - <li>{{ httpheader("Connection") }}</li> - <li>{{ httpheader("Keep-Alive") }}</li> - <li>{{ httpheader("Proxy-Authenticate") }}</li> - <li>{{ httpheader("Proxy-Authorization") }}</li> - <li>{{ httpheader("TE") }}</li> - <li>{{ httpheader("Trailer") }}</li> - <li>{{ httpheader("Transfer-Encoding") }}</li> - <li>{{ httpheader("Upgrade") }}.</li> -</ul> - -<dl> - <dt id="e2e">エンドツーエンドヘッダー</dt> - <dd>これらのヘッダーは、メッセージの最終的な宛先、すなわちリクエストならばサーバー、レスポンスならばクライアントに伝送し<em>なければなりません</em>。中間のプロキシはヘッダーを変更せずに再伝送しなければならず、またキャッシュには保存しなければなりません。</dd> - <dt id="hbh">ホップバイホップヘッダー</dt> - <dd>これらのヘッダーは単一のトランスポート層の接続にのみ意味を持ち、プロキシが再転送したり、キャッシュを行ったりしては<em>いけません</em>。なお、 {{httpheader("Connection")}} 一般ヘッダーを用いて設定する場合があるのはホップバイホップヘッダーのみです。</dd> -</dl> - -<h2 id="Authentication" name="Authentication">認証</h2> - -<dl> - <dt>{{HTTPHeader("WWW-Authenticate")}}</dt> - <dd>リソースへアクセスに使用すべき認証方法を定義します。</dd> - <dt>{{HTTPHeader("Authorization")}}</dt> - <dd>サーバーでユーザーエージェントを認証するための資格情報を持ちます。</dd> - <dt>{{HTTPHeader("Proxy-Authenticate")}}</dt> - <dd>プロキシサーバーの背後にあるリソースへアクセスできるようにするために使用すべき認証方法を定義します。</dd> - <dt>{{HTTPHeader("Proxy-Authorization")}}</dt> - <dd>プロキシサーバーでユーザーエージェントを認証するための資格情報を持ちます。</dd> -</dl> - -<h2 id="Caching" name="Caching">キャッシュ</h2> - -<dl> - <dt>{{HTTPHeader("Age")}}</dt> - <dd>オブジェクトがプロキシのキャッシュに存在する時間を秒数で表します。</dd> - <dt>{{HTTPHeader("Cache-Control")}}</dt> - <dd>リクエストおよびレスポンスで、キャッシュ機能に関するディレクティブです。</dd> - <dt>{{HTTPHeader("Clear-Site-Data")}}</dt> - <dd>リクエストしているウェブサイトに関連付けられたブラウズ用のデータ (クッキー、ストレージ、キャッシュ等) を消去します。</dd> - <dt>{{HTTPHeader("Expires")}}</dt> - <dd>レスポンスが陳腐化すると考えられる日時を表します。</dd> - <dt>{{HTTPHeader("Pragma")}}</dt> - <dd>リクエストからレスポンスへの流れの中でさまざまな影響がある、実装依存のヘッダーです。 <code>Cache-Control</code> ヘッダーが未実装である HTTP/1.0 キャッシュとの後方互換性のために使用します。</dd> - <dt>{{HTTPHeader("Warning")}}</dt> - <dd>起こりうる問題に関する一般警告情報です。</dd> -</dl> - -<h2 id="Client_hints" name="Client_hints">クライアントヒント</h2> - -<p>HTTP {{Glossary("Client_hints", "クライアントヒント")}}は策定中です。実際の文書は <a href="https://httpwg.org/http-extensions/client-hints.html">HTTP 作業グループのウェブサイト</a>にあります。</p> - -<dl> - <dt>{{HTTPHeader("Accept-CH")}} {{experimental_inline}}</dt> - <dd>サーバーはクライアントヒントに対応していることを、 <code>Accept-CH</code> ヘッダーフィールドまたは同等の <code>http-equiv</code> 属性が付いた HTML の <code><meta></code> 要素を使用して広報することができます (<a href="https://httpwg.org/http-extensions/client-hints.html#HTML5"><cite>[HTML5]</cite></a>)。</dd> - <dt>{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}</dt> - <dd>サーバーは、指定された期間サーバーがサポートする対応する一連のクライアントヒントを記憶するようクライアントに依頼し、そのサーバーのオリジンに対するその後のリクエストでクライアントヒントを配信できるようにすることができます (<a href="https://httpwg.org/http-extensions/client-hints.html#RFC6454"><cite>[RFC6454]</cite></a>)。</dd> - <dt>{{HTTPHeader("Early-Data")}} {{experimental_inline}}</dt> - <dd>リクエストが早期データを伝えていることを示します。</dd> - <dt>{{HTTPHeader("Content-DPR")}} {{experimental_inline}}</dt> - <dd>数値で、選択された画像レスポンスの CSS ピクセルに対する物理ピクセルの比を示します。</dd> - <dt>{{HTTPHeader("DPR")}} {{experimental_inline}}</dt> - <dd>数値で、現在のクライアントの端末ピクセル比 (DPR)、すなわち端末のレイアウトビューポート (<a href="https://httpwg.org/http-extensions/client-hints.html#CSS2"><cite>[CSS2]</cite></a> のセクション9.1.1) における、 CSS ピクセルに対する物理ピクセルの比 (<a href="https://httpwg.org/http-extensions/client-hints.html#CSSVAL"><cite>[CSSVAL]</cite></a> のセクション5.2) を示します。</dd> - <dt>{{HTTPHeader("Device-Memory")}} {{experimental_inline}}</dt> - <dd>技術的には Device Memory API の一部で、このヘッダーはクライアントが持つおよその RAM の量を表します。</dd> - <dt>{{HTTPHeader("Save-Data")}} {{experimental_inline}}</dt> - <dd>論理型で、ユーザーエージェントのデータ利用の削減についての設定を示します。</dd> - <dt>{{HTTPHeader("Viewport-Width")}} {{experimental_inline}}</dt> - <dd> - <div id="rfc.section.3.3.p.1"> - <p><code>Viewport-Width</code> リクエストヘッダーフィールドは数値で、レイアウトビューポートの幅を CSS ピクセル数で示します。指定されたピクセル数は、それ以上の最小の整数に丸められます (つまり切り上げ)。</p> - </div> - - <div id="rfc.section.3.3.p.2"> - <p><code>Viewport-Width</code> がメッセージ内に二回以上現れた場合、最後の値がそれ以前のすべての値を上書きします。</p> - </div> - </dd> - <dt>{{HTTPHeader("Width")}} {{experimental_inline}}</dt> - <dd> - <div id="rfc.section.3.2.p.1"> - <p><code>Width</code> リクエストヘッダーフィールドは数値で、要求するリソースの幅 (つまり画像の固有の寸法) を物理ピクセル数で示します。指定されたピクセル数は、それ以上の最小の整数に丸められます (つまり切り上げ)。</p> - </div> - - <div id="rfc.section.3.2.p.2"> - <p>要求するリソースの幅がリクエストの時点で不明である場合や、リソースが表示幅を持たない場合は、 <code>Width</code> ヘッダーフィールドは省略できます。 <code>Width</code> がメッセージ内に二回以上現れた場合、最後の値がそれ以前のすべての値を上書きします。</p> - </div> - </dd> -</dl> - -<h2 id="Conditionals" name="Conditionals">条件付き</h2> - -<dl> - <dt>{{HTTPHeader("Last-Modified")}}</dt> - <dd>リソースが最後に変更された日時であり、同じリソースの複数のバージョンを比較するために使用されます。 {{HTTPHeader("ETag")}} より正確さは低いのですが、環境によっては計算が容易です。{{HTTPHeader("If-Modified-Since")}} や {{HTTPHeader("If-Unmodified-Since")}} を使用する条件付きリクエストでは、リクエストの動作を変更するためにこの値を使用します。</dd> - <dt>{{HTTPHeader("ETag")}}</dt> - <dd>一意な文字列であり、リソースのバージョンを識別します。 {{HTTPHeader("If-Match")}} や {{HTTPHeader("If-None-Match")}} を使用する条件付きリクエストでは、リクエストの動作を変更するためにこの値を使用します。</dd> - <dt>{{HTTPHeader("If-Match")}}</dt> - <dd>リクエストを条件付きにして、保存されたリソースが指定した ETag のいずれかに一致する場合に限りメソッドを適用します。</dd> - <dt>{{HTTPHeader("If-None-Match")}}</dt> - <dd>リクエストを条件付きにして、保存されたリソースが指定した ETag のいずれかに一致<em>しない</em>場合に限りメソッドを適用します。これはキャッシュを更新する (安全なリクエスト向け)、あるいはすでにリソースが存在する場合に新しいリソースのアップロードを止めるために使用します。</dd> - <dt>{{HTTPHeader("If-Modified-Since")}}</dt> - <dd>リクエストを条件付きにして、エンティティが指定した日時より後に変更されている場合に限り転送するようリクエストします。キャッシュが期限切れである場合に限りデータを転送するために使用します。</dd> - <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt> - <dd>リクエストを条件付きにして、エンティティが指定した日時より後に変更されていない場合に限り転送するようリクエストします。これは、特定の範囲の新しい断片と古い断片の一貫性を保証する、あるいは既存の文書を変更するときに楽観的な並行性制御システムを実装するために使用します。</dd> - <dt>{{HTTPHeader("Vary")}}</dt> - <dd>新しいものを元のサーバーにリクエストするのではなく、キャッシュされたレスポンスが使用できるよう決定するために、リクエストヘッダーを一致させる方法を定めます。/dd></dd> -</dl> - -<h2 id="Connection_management" name="Connection_management">接続制御</h2> - -<dl> - <dt>{{HTTPHeader("Connection")}}</dt> - <dd>現在の転送が完了した後も、ネットワークコネクションを維持するかを制御します。</dd> - <dt>{{HTTPHeader("Keep-Alive")}}</dt> - <dd>持続的なコネクションをどれだけの期間維持するかを制御します。</dd> -</dl> - -<h2 id="Content_negotiation" name="Content_negotiation"><a href="/ja/docs/Web/HTTP/Content_negotiation">コンテンツネゴシエーション</a></h2> - -<dl> - <dt>{{HTTPHeader("Accept")}}</dt> - <dd>送り返すことができるデータの{{Glossary("MIME_type", "種類")}}をサーバーに通知します。</dd> - <dt>{{HTTPHeader("Accept-Charset")}}</dt> - <dd>どの{{Glossary("character encodings", "文字集合")}}をクライアントが理解できるかです。</dd> - <dt>{{HTTPHeader("Accept-Encoding")}}</dt> - <dd>送り返すリソースで使用できるエンコードアルゴリズム (一般的には<a href="/ja/docs/Web/HTTP/Compression">圧縮アルゴリズム</a>) をサーバーに通知します。</dd> - <dt>{{HTTPHeader("Accept-Language")}}</dt> - <dd>送り返すリソースで期待する自然言語をサーバーに通知します。これはヒントであり、必ずしもユーザーの完全な制御下にあるものではありません。サーバーはユーザーの選択 (ドロップダウンリストで選ぶ言語など) を明示的に上書きしないように、常に注意を払うべきです。</dd> -</dl> - -<h2 id="Controls" name="Controls">制御</h2> - -<dl> - <dt>{{HTTPHeader("Expect")}}</dt> - <dd>リクエストを適切に扱うためにサーバーが実行しなければならないと期待されていることを示します。</dd> - <dt>{{HTTPHeader("Max-Forwards")}}</dt> -</dl> - -<h2 id="Cookies" name="Cookies">クッキー</h2> - -<dl> - <dt>{{HTTPHeader("Cookie")}}</dt> - <dd>過去に {{HTTPHeader("Set-Cookie")}} ヘッダーでサーバーから送信されて保存している <a href="/ja/docs/Web/HTTP/Cookies">HTTP クッキー</a>を持ちます。</dd> - <dt>{{HTTPHeader("Set-Cookie")}}</dt> - <dd>サーバーからユーザーエージェントにクッキーを送信します。</dd> - <dt>{{HTTPHeader("Cookie2")}} {{obsolete_inline}}</dt> - <dd>過去に {{HTTPHeader("Set-Cookie2")}} ヘッダーでサーバーから送信された HTTP クッキーを伝えるために使われていましたが、仕様書から廃止されました。代わりに {{HTTPHeader("Cookie")}} を使用してください。</dd> - <dt>{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}</dt> - <dd>サーバーからユーザーエージェントに Cookie を送信するために使用されていましたが、仕様書から廃止されました。代わりに {{HTTPHeader("Set-Cookie")}} を使用してください。</dd> -</dl> - -<h2 id="CORS" name="CORS">オリジン間リソース共有 (CORS)</h2> - -<p><em>CORS についての詳細は、<a href="CORS">こちら</a>を参照してください。</em></p> - -<dl> - <dt>{{HTTPHeader("Access-Control-Allow-Origin")}}</dt> - <dd>レスポンスが共有可能かを示します。</dd> - <dt>{{HTTPHeader("Access-Control-Allow-Credentials")}}</dt> - <dd>credentials フラグが真であるときに、リクエストへのレスポンスを開示してよいかを示します。</dd> - <dt>{{HTTPHeader("Access-Control-Allow-Headers")}}</dt> - <dd>{{Glossary("Preflight_request", "プリフライトリクエスト")}}へのレスポンスで使用し、実際のリクエストを行うときに使用できる HTTP ヘッダーを指定します。</dd> - <dt>{{HTTPHeader("Access-Control-Allow-Methods")}}</dt> - <dd>プリフライトリクエストへのレスポンスで、リソースへアクセスするときに使用できるメソッドを指定します。</dd> - <dt>{{HTTPHeader("Access-Control-Expose-Headers")}}</dt> - <dd>ヘッダー名を羅列して、レスポンスの一部として開示できるヘッダーを示します。</dd> - <dt>{{HTTPHeader("Access-Control-Max-Age")}}</dt> - <dd>プリフライトリクエストの結果をキャッシュしてよい期間を示します。</dd> - <dt>{{HTTPHeader("Access-Control-Request-Headers")}}</dt> - <dd>実際のリクエストを行う際に使用する HTTP ヘッダーをサーバーがわかるようにするため、プリフライトリクエストを発信する際に使用します。</dd> - <dt>{{HTTPHeader("Access-Control-Request-Method")}}</dt> - <dd>実際のリクエストを行う際に使用する <a href="/ja/docs/Web/HTTP/Methods">HTTP メソッド</a> をサーバーがわかるようにするため、プリフライトリクエストを発信する際に使用します。</dd> - <dt>{{HTTPHeader("Origin")}}</dt> - <dd>どこから読み込みが発生したかを示します。</dd> - <dt>{{HTTPHeader("Timing-Allow-Origin")}}</dt> - <dd><a href="/ja/docs/Web/API/Resource_Timing_API">Resource Timing API</a> の機能を通じて受け取った属性の値を見ることができるオリジンを指定します。そうでなければオリジン間の制約によってゼロとして報告されます。</dd> -</dl> - -<h2 id="Do_Not_Track" name="Do_Not_Track">Do Not Track</h2> - -<dl> - <dt>{{HTTPHeader("DNT")}}</dt> - <dd>ユーザーのトラッキング設定を示します。</dd> - <dt>{{HTTPHeader("Tk")}}</dt> - <dd>対応するレスポンスのトラッキング状態を示します。</dd> -</dl> - -<h2 id="Downloads" name="Downloads">ダウンロード</h2> - -<dl> - <dt>{{HTTPHeader("Content-Disposition")}}</dt> - <dd>転送したリソースをインラインで表示すべきか (ヘッダーが存在しない場合の既定の動作)、またはダウンロードとして扱い、「名前を付けて保存」ウィンドウを表示すべきかを示します。</dd> -</dl> - -<h2 id="Message_body_information" name="Message_body_information">メッセージ本文の情報</h2> - -<dl> - <dt>{{HTTPHeader("Content-Length")}}</dt> - <dd>リソースの大きさを、バイト単位の10進数で示します。</dd> - <dt>{{HTTPHeader("Content-Type")}}</dt> - <dd>リソースのメディアタイプを示します。</dd> - <dt>{{HTTPHeader("Content-Encoding")}}</dt> - <dd>圧縮アルゴリズムを指定するために使用します。</dd> - <dt>{{HTTPHeader("Content-Language")}}</dt> - <dd>読者向けに言語を示すヘッダーであり、ユーザーが自身の好む言語に応じて区別することができます。</dd> - <dt>{{HTTPHeader("Content-Location")}}</dt> - <dd>返すデータの代替データの場所を示します。</dd> -</dl> - -<h2 id="Proxies" name="Proxies">プロキシ</h2> - -<dl> - <dt>{{HTTPHeader("Forwarded")}}</dt> - <dd>リクエストのパスにプロキシが関与したときに変更または遺失した、プロキシサーバーのクライアント側の情報を持ちます。</dd> - <dt>{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}</dt> - <dd>HTTP プロキシやロードバランサーを経由してウェブサーバーに接続するクライアントの、接続元 IP アドレスを識別します。</dd> - <dt>{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}</dt> - <dd>プロキシやロードバランサーに接続するクライアントがリクエストした、オリジナルのホストを示します。</dd> - <dt>{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}</dt> - <dd>クライアントがプロキシやロードバランサーに接続するために使用したプロトコル (HTTP または HTTPS) を識別します。</dd> - <dt>{{HTTPHeader("Via")}}</dt> - <dd>フォワードプロキシとリバースプロキシの両方が追加するヘッダーであり、リクエストヘッダーとレスポンスヘッダーのどちらでも見られます。</dd> -</dl> - -<h2 id="Redirects" name="Redirects">リダイレクト</h2> - -<dl> - <dt>{{HTTPHeader("Location")}}</dt> - <dd>ページのリダイレクト先の URL を示します。</dd> -</dl> - -<h2 id="Request_context" name="Request_context">リクエストコンテキスト</h2> - -<dl> - <dt>{{HTTPHeader("From")}}</dt> - <dd>リクエストを行うユーザーエージェントを操作している人間の、インターネット電子メールアドレスを持ちます。</dd> - <dt>{{HTTPHeader("Host")}}</dt> - <dd>サーバーのドメイン名 (バーチャルホスト向け) およびサーバーが待ち受けている TCP ポート番号 (省略可能) を指定します。</dd> - <dt>{{HTTPHeader("Referer")}}</dt> - <dd>現在リクエストしているページへリンクしていた、前のウェブページのアドレスです。</dd> - <dt>{{HTTPHeader("Referrer-Policy")}}</dt> - <dd>{{HTTPHeader("Referer")}} ヘッダーで送信するどのリファラー情報をリクエストに含めるかを制御します。</dd> - <dt>{{HTTPHeader("User-Agent")}}</dt> - <dd>リクエストを行うユーザーエージェントソフトウェアのアプリケーションタイプ、オペレーティングシステム、ベンダー、バージョンを、ネットワークプロトコルのピアが識別できるようにする文字列を持ちます。 <a href="/ja/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox ユーザーエージェント文字列リファレンス</a>もご覧ください。</dd> -</dl> - -<h2 id="Response_context" name="Response_context">レスポンスコンテキスト</h2> - -<dl> - <dt>{{HTTPHeader("Allow")}}</dt> - <dd>リソースがサポートする HTTP リクエストメソッドを示します。</dd> - <dt>{{HTTPHeader("Server")}}</dt> - <dd>リクエストを扱うサーバーが使用するソフトウェアの情報を持ちます。</dd> -</dl> - -<h2 id="Range_requests" name="Range_requests">範囲付きリクエスト</h2> - -<dl> - <dt>{{HTTPHeader("Accept-Ranges")}}</dt> - <dd>サーバーが範囲付きリクエストに対応するかどうか、対応していれば対応する場合は、範囲を表すことができる単位を示します。</dd> - <dt>{{HTTPHeader("Range")}}</dt> - <dd>サーバーが返すべきである文書の範囲を示します。</dd> - <dt>{{HTTPHeader("If-Range")}}</dt> - <dd>指定した ETag または日時がリモートのリソースにマッチする場合に限定した、条件付き range request を生成します。異なるバージョンのリソースから 2 つの範囲をダウンロードすることを防ぎます。</dd> - <dt>{{HTTPHeader("Content-Range")}}</dt> - <dd>部分的なメッセージが、メッセージ本文全体のどこに位置するかを示します。</dd> -</dl> - -<h2 id="Security" name="Security">セキュリティ</h2> - -<dl> - <dt>{{HTTPHeader("Cross-Origin-Embedder-Policy")}} ({{Glossary("COEP")}})</dt> - <dd>サーバーが指定された文書の埋め込み方針を宣言するために使います。</dd> -</dl> - -<dl> - <dt>{{HTTPHeader("Cross-Origin-Opener-Policy")}} ({{Glossary("COOP")}})</dt> - <dd>他のドメインがウィンドウを開いたり制御したりすることを防ぎます。</dd> -</dl> - -<dl> - <dt>{{HTTPHeader("Cross-Origin-Resource-Policy")}} ({{Glossary("CORP")}})</dt> - <dd>このヘッダーが適用されたリソースのレスポンスが他のドメインから読み取られるのを防ぎます。</dd> - <dt>{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})</dt> - <dd>ユーザーエージェントがページで読み込むことを許可するリソースを制御します。</dd> - <dt>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</dt> - <dd>ウェブの開発者がポリシーの効果を適用せずに監視することで、実験を行うことができます。これらの違反レポートは、 HTTP <code>POST</code> リクエストによって指定した URI へ送信される {{Glossary("JSON")}} 文書で構成されます。</dd> - <dt>{{HTTPHeader("Expect-CT")}}</dt> - <dd>サイトが証明書の透明性要件の報告や実施を選択できるようにします。これにより、そのサイトで不正な証明書の使用に気づかないことを防ぎます。サイトが Expect-CT ヘッダーを有効にした場合、そのサイトの証明書が公開CTログに表示されることを Chrome が確認するようにリクエストしています。</dd> - <dt>{{HTTPHeader("Feature-Policy")}}</dt> - <dd>自身のフレームまたはその中の iframe で、ブラウザーの機能を使用することを許可または拒否する仕組みを提供します。</dd> - <dt>{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})</dt> - <dd>HTTP の代わりに HTTPS による通信を強制します。</dd> - <dt>{{HTTPHeader("Upgrade-Insecure-Requests")}}</dt> - <dd>暗号化や認証されたレスポンスについて、クライアントの設定を表す信号をサーバーに送信して、{{CSP("upgrade-insecure-requests")}} ディレクティブを正しく扱うことができます。</dd> - <dt>{{HTTPHeader("X-Content-Type-Options")}}</dt> - <dd>ブラウザーで MIME スニッフィングを無効化して、{{HTTPHeader("Content-Type")}} で指定したタイプを強制的に使用させます。</dd> - <dt>{{HTTPHeader("X-Download-Options")}}</dt> - <dd>HTTP の <code><a href="https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/jj542450(v=vs.85)?#the-noopen-directive">X-Download-Options</a></code> ヘッダーは、ブラウザー (Internet Explorer) がアプリケーションからのダウンロードでファイルを「開く」の選択肢を表示しないようにし、アプリケーションのコンテキストで実行するアクセス権を得ることがないようにして、ファイルとすることでフィッシング詐欺を防止します。 (メモ: <a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/18488178/">MS Edge bug</a> に関連)</dd> - <dt>{{HTTPHeader("X-Frame-Options")}} (XFO)</dt> - <dd>ブラウザーがページを {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}}, {{HTMLElement("object")}} の内部に表示することを許可するかを示します。</dd> - <dt>{{HTTPHeader("X-Permitted-Cross-Domain-Policies")}}</dt> - <dd>クロスドメインポリシーファイル (<code>crossdomain.xml</code>) を許可するかどうかを指定します。このファイルは、 Adobe の Flash Player、Adobe Acrobat、Microsoft Silverlight、Apache Flex などのクライアントに、<a href="/ja/docs/Web/Security/Same-origin_policy">同一オリジンポリシー</a>によって制限されているドメイン間のデータを処理する許可を与えるポリシーを定義することができます。詳細については、 <a href="https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html">Cross-domain Policy File Specification</a> を参照してください。</dd> - <dt>{{HTTPHeader("X-Powered-By")}}</dt> - <dd>ホスティング環境やその他のフレームワークによって設定される可能性があり、アプリケーションや訪問者に有益ではない情報を含みます。潜在的な脆弱性が発現することを防ぐために、このヘッダーは設定しないでください。</dd> - <dt>{{HTTPHeader("X-XSS-Protection")}}</dt> - <dd>クロスサイトスクリプティングのフィルタリングを有効化します。</dd> -</dl> - -<h3 id="HTTP_Public_Key_Pinning_GlossaryHPKP">HTTP Public Key Pinning ({{Glossary("HPKP")}})</h3> - -<p>HTTP Public Key Pinning は非推奨となり、削除されて Certificate Transparency と {{HTTPHeader("Expect-CT")}} に置き換えられました。</p> - -<dl> - <dt>{{HTTPHeader("Public-Key-Pins")}}</dt> - <dd>偽造した証明書による {{Glossary("MITM")}} 攻撃の危険性を軽減するため、特定の暗号公開鍵とウェブサーバーを関連付けます。</dd> - <dt>{{HTTPHeader("Public-Key-Pins-Report-Only")}}</dt> - <dd>ピンニングに違反する場合でも、ヘッダーで指定した report-uri にレポートを送信して、クライアントからサーバーへの接続は許可します。</dd> -</dl> - -<h3 id="Fetch_metadata_request_headers" name="Fetch_metadata_request_headers">メタデータ読み取りリクエストヘッダー</h3> - -<dl> - <dt>{{HTTPHeader("Sec-Fetch-Site")}}</dt> - <dd>リクエスト開始元のオリジンと宛先のオリジンとの関係を示すリクエストヘッダーです。これは構造化ヘッダーで、値はトークンであり、取りうる値は <code>cross-site</code>, <code>same-origin</code>, <code>same-site</code>, <code>none</code> です。</dd> - <dt>{{HTTPHeader("Sec-Fetch-Mode")}}</dt> - <dd>サーバーへのリクエストモードを示すリクエストヘッダーです。これは構造化ヘッダーで、値はトークンであり、取りうる値は <code>cors</code>, <code>navigate</code>, <code>nested-navigate</code>, <code>no-cors</code>, <code>same-origin</code>, <code>websocket</code> です。</dd> - <dt>{{HTTPHeader("Sec-Fetch-User")}}</dt> - <dd>ナビゲーションリクエストがユーザー操作によって起動されたかどうかを示すリクエストヘッダーです。これは構造化ヘッダーであり、論理値で、取りうる値は <code>?0</code> ならば偽、 <code>?1</code> ならば真です。</dd> - <dt>{{HTTPHeader("Sec-Fetch-Dest")}}</dt> - <dd>リクエストの宛先を示すリクエストヘッダーです。これは構造化ヘッダーで、値はトークンであり、取りうる値は <code>audio</code>, <code>audioworklet</code>, <code>document</code>, <code>embed</code>, <code>empty</code>, <code>font</code>, <code>image</code>, <code>manifest</code>, <code>object</code>, <code>paintworklet</code>, <code>report</code>, <code>script</code>, <code>serviceworker</code>, <code>sharedworker</code>, <code>style</code>, <code>track</code>, <code>video</code>, <code>worker</code>, <code>xslt</code>, <code>nested-document</code> です。</dd> -</dl> - -<h2 id="Server-sent_events" name="Server-sent_events">Server-sent event</h2> - -<dl> - <dt>{{HTTPHeader("Last-Event-ID")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("NEL")}} {{experimental_inline}}</dt> - <dd>開発者がネットワークエラー報告ポリシーを宣言できるようにする仕組みを定義します。</dd> - <dt>{{HTTPHeader("Ping-From")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Ping-To")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Report-To")}}</dt> - <dd>警告やエラーを送信るためのブラウザーに対するサーバーのエンドポイントを指定するために使用します。</dd> -</dl> - -<h2 id="Transfer_coding" name="Transfer_coding">転送エンコーディング</h2> - -<dl> - <dt>{{HTTPHeader("Transfer-Encoding")}}</dt> - <dd>エンティティをユーザーへ問題なく転送できるエンコード形式を指定します。</dd> - <dt>{{HTTPHeader("TE")}}</dt> - <dd>ユーザーエージェントが進んで受け入れる転送エンコーディングを指定します。</dd> - <dt>{{HTTPHeader("Trailer")}}</dt> - <dd>送信者が chunk メッセージの終端に追加フィールドを含めることができます。</dd> -</dl> - -<h2 id="WebSockets" name="WebSockets">WebSocket</h2> - -<dl> - <dt>{{HTTPHeader("Sec-WebSocket-Key")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Sec-WebSocket-Extensions")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Sec-WebSocket-Accept")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Sec-WebSocket-Protocol")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Sec-WebSocket-Version")}}</dt> - <dd>...</dd> -</dl> - -<h2 id="Other" name="Other">その他</h2> - -<dl> - <dt>{{HTTPHeader("Accept-Push-Policy")}} {{experimental_inline}}</dt> - <dd>クライアントはリクエストに対して求めるプッシュポリシーを、リクエスト内で <code><a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00#section-3.1">Accept-Push-Policy</a></code> ヘッダーフィールドを送信することで表現することができます。</dd> - <dt>{{HTTPHeader("Accept-Signature")}} {{experimental_inline}}</dt> - <dd>クライアントは <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.7">Accept-Signature</a></code> ヘッダーフィールドを送信して、利用可能な署名を利用する意図を示したり、対応している署名の種類を示したりすることができます。</dd> - <dt>{{HTTPHeader("Alt-Svc")}}</dt> - <dd>このサービスにたどり着く他の方法のリストに使用します。</dd> - <dt>{{HTTPHeader("Date")}}</dt> - <dd>メッセージを生成した日時です。</dd> - <dt>{{HTTPHeader("Large-Allocation")}}</dt> - <dd>読み込み中のページは大量の割り当てが必要であることをブラウザーに伝えます。</dd> - <dt>{{HTTPHeader("Link")}}</dt> - <dd><code><a href="https://tools.ietf.org/html/rfc5988#section-5">Link</a></code> エンティティヘッダーフィールドは、 HTTP ヘッダー内の1つ以上のリンクを記述する方法を提供します。意味的には HTML の {{HTMLElement("link")}} 要素と等価です。</dd> - <dt>{{HTTPHeader("Push-Policy")}} {{experimental_inline}}</dt> - <dd><code><a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00#section-3.2">Push-Policy</a></code> はリクエストを処理するときのプッシュ通知に関するサーバーの動作を定義します。</dd> - <dt>{{HTTPHeader("Retry-After")}}</dt> - <dd>後続のリクエストを行う前に、ユーザーエージェントがどれだけの期間待つべきかを示します。</dd> - <dt>{{HTTPHeader("Signature")}} {{experimental_inline}}</dt> - <dd><code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.1">Signature</a></code> ヘッダーフィールドは、交換のための署名のリストを伝え、それぞれはその署名の権威を決定して、そして更新する方法についての情報を伴います。</dd> - <dt>{{HTTPHeader("Signed-Headers")}} {{experimental_inline}}</dt> - <dd><code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.5.1.2">Signed-Headers</a></code> ヘッダーフィールドは、シグネチャに含めるためのレスポンスヘッダーフィールドの順序付きリストを識別します。</dd> - <dt>{{HTTPHeader("Server-Timing")}}</dt> - <dd>指定されたリクエストとレスポンスのサイクルについて、１つ以上のメトリクス又は説明を通信します。</dd> - <dt>{{HTTPHeader("Service-Worker-Allowed")}}</dt> - <dd><a href="https://w3c.github.io/ServiceWorker/#service-worker-script-response">サービスワーカースクリプトのレスポンス</a>にこのヘッダを含めることで、<a href="https://w3c.github.io/ServiceWorker/#path-restriction">パス制限</a>を解除するために使用します。</dd> - <dt>{{HTTPHeader("SourceMap")}}</dt> - <dd>生成されたコードと <a href="/ja/docs/Tools/Debugger/How_to/Use_a_source_map">ソースマップ</a> を関連付けます。</dd> - <dt>{{HTTPHeader("Upgrade")}}</dt> - <dd>Upgrade ヘッダーフィールドに関連する RFC 文書は <a href="https://tools.ietf.org/html/rfc7230#section-6.7">RFC 7230, section 6.7</a> です。標準仕様では、現在のクライアント、サーバー、トランスポート層プロトコル接続で別のプロトコルへ更新または変更するための規則を定めています。例えば、このヘッダー標準ではサーバーが Upgrade ヘッダーフィールドを認めて実装すると決める前提で、クライアントが HTTP 1.1 から HTTP 2.0 へ変更することを可能にします。どちらの相手も、 Upgrade ヘッダーフィールドで指定された要件を受け入れる必要はありません。これはクライアントのヘッダーでもサーバーのヘッダーでも使用できます。Upgrade ヘッダーフィールドを指定した場合は、更新オプションを指ヘッダーonnection ヘッダーフィールドも送信者が送信しなければなりません。Connection ヘッダーフィールドについて、詳しくは <a href="https://tools.ietf.org/html/rfc7230#section-6.1">前述の RFC のセクション 6.1</a> をご覧ください。</dd> - <dt>{{HTTPHeader("X-DNS-Prefetch-Control")}}</dt> - <dd>ユーザーがたどるであろうリンクや、ドキュメントが参照する画像、 CSS、 JavaScript などのリソースのドメイン名解決をブラウザーが事前に行う機能である、 DNS プリフェッチを制御します。</dd> - <dt>{{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("X-Pingback")}} {{non-standard_inline}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("X-Requested-With")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("X-Robots-Tag")}}{{non-standard_inline}}</dt> - <dd><code><a href="https://developers.google.com/search/reference/robots_meta_tag#xrobotstag">X-Robots-Tag</a></code> ヘッダーは、一般の検索エンジンの結果でウェブページをどのように索引付けをするかを示します。このヘッダーは <code><meta name="robots" content="..."></code> と等価です。</dd> - <dt>{{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}}</dt> - <dd>使用する文書モードを示すために Internet Explorer で使用されています。</dd> -</dl> - -<h2 id="Contributing" name="Contributing">協力</h2> - -<p><a href="/ja/docs/MDN/Contribute/Howto/Document_an_HTTP_header">新しい項目を書いたり</a>、既存のものを改善したりすることにご協力ください。</p> - -<h2 id="See_also" name="See_also">関連情報</h2> - -<ul> - <li><a href="https://en.wikipedia.org/wiki/List_of_HTTP_header_fields">Wikipedia の HTTP ヘッダーの一覧のページ</a></li> - <li><a href="https://www.iana.org/assignments/message-headers/perm-headers.html">IANA レジストリ</a></li> - <li><a href="https://httpwg.org/specs/">HTTP Working Group</a></li> -</ul> diff --git a/files/ja/web/http/headers/index.md b/files/ja/web/http/headers/index.md new file mode 100644 index 0000000000..a2239ea7e0 --- /dev/null +++ b/files/ja/web/http/headers/index.md @@ -0,0 +1,401 @@ +--- +title: HTTP ヘッダー +slug: Web/HTTP/Headers +tags: + - HTTP + - HTTP ヘッダー + - Networking + - Reference + - header + - ネットワーク + - ヘッダー + - リファレンス +translation_of: Web/HTTP/Headers +--- +{{HTTPSidebar}} + +**HTTP ヘッダー**により、 HTTP リクエストやレスポンスでクライアントやサーバーが追加情報を渡すことができます。 HTTP ヘッダーは、大文字小文字を区別しないヘッダー名とそれに続くコロン (`:`)、 値で構成されます。値の前にある{{Glossary("Whitespace", "ホワイトスペース")}}は無視されます。 + +私的な独自のヘッダーは、以前は `X-` 接頭辞を使用していましたが、この慣習は 2012 年 6 月の [RFC 6648](https://datatracker.ietf.org/doc/html/rfc6648) で非推奨になりました。これは、標準外のフィールドが標準になったときに発生する不便さのためです。それ以外のヘッダーは [IANA レジストリー](https://www.iana.org/assignments/message-headers/perm-headers.html)に収録されており、その基になったものは [RFC 4229](https://datatracker.ietf.org/doc/html/rfc4229) です。また IANA は[新たに提案された HTTP ヘッダーのレジストリー](https://www.iana.org/assignments/message-headers/prov-headers.html)も管理しています。 + +ヘッダーは、そのコンテキストに応じて分類できます。 + +- {{Glossary("Request header", "リクエストヘッダー")}}は、読み込むリソースについての情報や、そのリソースをリクエストしているクライアントに関する詳細な情報を持ちます。 +- {{Glossary("Response header", "レスポンスヘッダー")}}は、レスポンスに関する追加情報、例えば場所や提供しているサーバーに関する情報を保持します。 +- {{Glossary("Representation header", "表現ヘッダー")}}は、リソースの本体に関する情報、例えば [MIME タイプ](/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types)や適用されるエンコード／圧縮方式などについての情報を持ちます。 +- {{Glossary("Payload header","ペイロードヘッダー")}}は、転送されるデータの表現から独立した情報、例えばコンテンツの長さや転送に使われるエンコード方式などを持ちます。 + +またヘッダーは、{{Glossary("Proxy_server", "プロキシーサーバー")}}がどのように扱うかに応じてグループ化されます。 + +- {{ httpheader("Connection") }} +- {{ httpheader("Keep-Alive") }} +- {{ httpheader("Proxy-Authenticate") }} +- {{ httpheader("Proxy-Authorization") }} +- {{ httpheader("TE") }} +- {{ httpheader("Trailer") }} +- {{ httpheader("Transfer-Encoding") }} +- {{ httpheader("Upgrade") }} ([プロトコルのアップグレードの仕組み](/ja/docs/Web/HTTP/Protocol_upgrade_mechanism)も参照) + +<!----> + +- エンドツーエンドヘッダー + - : これらのヘッダーは、メッセージの最終的な宛先、すなわちリクエストならばサーバー、レスポンスならばクライアントに伝送し*なければなりません*。中間のプロキシーはヘッダーを変更せずに再伝送しなければならず、またキャッシュには保存しなければなりません。 +- ホップバイホップヘッダー + - : これらのヘッダーは単一のトランスポート層の接続にのみ意味を持ち、プロキシーが再転送したり、キャッシュを行ったりしては*いけません*。なお、 {{httpheader("Connection")}} ヘッダーを用いて設定する場合があるのはホップバイホップヘッダーのみです。 + +## 認証 + +- {{HTTPHeader("WWW-Authenticate")}} + - : リソースへアクセスに使用すべき認証方法を定義します。 +- {{HTTPHeader("Authorization")}} + - : サーバーでユーザーエージェントを認証するための資格情報を持ちます。 +- {{HTTPHeader("Proxy-Authenticate")}} + - : プロキシーサーバーの背後にあるリソースへアクセスできるようにするために使用すべき認証方法を定義します。 +- {{HTTPHeader("Proxy-Authorization")}} + - : プロキシーサーバーでユーザーエージェントを認証するための資格情報を持ちます。 + +## キャッシュ + +- {{HTTPHeader("Age")}} + - : オブジェクトがプロキシーのキャッシュに存在する時間を秒数で表します。 +- {{HTTPHeader("Cache-Control")}} + - : リクエストおよびレスポンスで、キャッシュ機能に関するディレクティブです。 +- {{HTTPHeader("Clear-Site-Data")}} + - : リクエストしているウェブサイトに関連付けられた閲覧用のデータ (クッキー、ストレージ、キャッシュなど) を消去します。 +- {{HTTPHeader("Expires")}} + - : レスポンスが古くなると考えられる日時を表します。 +- {{HTTPHeader("Pragma")}} + - : リクエストからレスポンスへの流れの中でさまざまな影響がある、実装依存のヘッダーです。 `Cache-Control` ヘッダーが未実装である HTTP/1.0 キャッシュとの後方互換性のために使用します。 +- {{HTTPHeader("Warning")}} + - : 起こりうる問題に関する一般警告情報です。 + +## クライアントヒント + +HTTP の{{Glossary("Client_hints", "クライアントヒント")}}とは、端末の種類やネットワークの状態など、クライアントに関する有用な情報を提供する一連のリクエストヘッダーのことで、サーバーはこれらの条件に合わせて提供するコンテンツを最適化することができます。 + +サーバーは、 {{HTTPHeader("Accept-CH")}} を使用して、クライアントが関心を持っているクライアントヒントヘッダーを積極的に要求します。クライアントは、要求されたヘッダーを後続のリクエストに含めることがあります。 + +- {{HTTPHeader("Accept-CH")}} {{experimental_inline}} + - : サーバーはクライアントヒントに対応していることを、 `Accept-CH` ヘッダーフィールドまたは HTML の `<meta>` 要素の [`http-equiv`](/en-US/docs/Web/HTML/Element/meta#attr-http-equiv) 属性で同等の指定をすることで広報することができます。 +- {{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}} {{deprecated_inline}} + - : サーバーは、指定された期間サーバーが対応する一連のクライアントヒントを記憶するようクライアントに依頼し、そのサーバーのオリジンに対するその後のリクエストでクライアントヒントを配信できるようにすることができます。 + +クライアントヒントの様々なカテゴリーを以下に示します。 + +### 端末クライアントヒント + +- {{HTTPHeader("Content-DPR")}} {{deprecated_inline}}{{experimental_inline}} + - : 数値で、選択された画像レスポンスの CSS ピクセルに対する物理ピクセルの比を示します。 +- {{HTTPHeader("Device-Memory")}} {{deprecated_inline}}{{experimental_inline}} + - : 技術的には [Device Memory API](/ja/docs/Web/API/Device_Memory_API) の一部で、このヘッダーはクライアントが持つおよその RAM の量を表します。 +- {{HTTPHeader("DPR")}} {{deprecated_inline}}{{experimental_inline}} + - : クライアントの端末ピクセル比 (DPR)、すなわち CSS ピクセルあたりの物理ピクセル数を示します。 +- {{HTTPHeader("Viewport-Width")}} {{deprecated_inline}}{{experimental_inline}} + - : 数値で、レイアウトビューポートの幅を CSS ピクセル数で示します。指定されたピクセル数は、それ以上の最小の整数に丸められます (つまり切り上げ)。 +- {{HTTPHeader("Width")}} {{deprecated_inline}}{{experimental_inline}} + - : `Width` リクエストヘッダーフィールドは数値で、要求するリソースの幅 (つまり画像の自身の寸法) を物理ピクセル数で示します。 + +### ネットワーククライアントヒント + +ネットワーククライアントヒントにより、サーバーはネットワークの帯域やレイテンシーに基づいて、どの情報を送るかを選択することができます。 + +- {{HTTPHeader("Downlink")}} + - : サーバーに対するクライアントのコネクションのおよその帯域を、 Mbps で表します。これは [Network Information API](/ja/docs/Web/API/Network_Information_API) の一部です。 +- {{HTTPHeader("ECT")}} + - : {{Glossary("effective connection type", "有効接続種別")}} (「ネットワークプロファイル」) は、そのコネクションのレイテンシーや帯域に最も近いものです。これは [Network Information API](/ja/docs/Web/API/Network_Information_API) の一部です。 +- {{HTTPHeader("RTT")}} + - : アプリケーション層のラウンドトリップ時間 (RTT) をミリ秒で表し、これにはサーバーの処理時間も含みます。これは [Network Information API](/ja/docs/Web/API/Network_Information_API) の一部です。 +- {{HTTPHeader("Save-Data")}} {{experimental_inline}} + - : 論理型で、ユーザーエージェントのデータ利用の削減についての設定を示します。 + +## 条件付き + +- {{HTTPHeader("Last-Modified")}} + - : リソースが最後に変更された日時であり、同じリソースの複数のバージョンを比較するために使用されます。 {{HTTPHeader("ETag")}} より正確さは低いのですが、環境によっては計算が容易です。{{HTTPHeader("If-Modified-Since")}} や {{HTTPHeader("If-Unmodified-Since")}} を使用する条件付きリクエストでは、リクエストの動作を変更するためにこの値を使用します。 +- {{HTTPHeader("ETag")}} + - : 一意な文字列であり、リソースのバージョンを識別します。 {{HTTPHeader("If-Match")}} や {{HTTPHeader("If-None-Match")}} を使用する条件付きリクエストでは、リクエストの動作を変更するためにこの値を使用します。 +- {{HTTPHeader("If-Match")}} + - : リクエストを条件付きにして、保存されたリソースが指定した ETag のいずれかに一致する場合に限りメソッドを適用します。 +- {{HTTPHeader("If-None-Match")}} + - : リクエストを条件付きにして、保存されたリソースが指定した ETag のいずれかに一致*しない*場合に限りメソッドを適用します。これはキャッシュを更新する (安全なリクエスト向け)、あるいはすでにリソースが存在する場合に新しいリソースのアップロードを止めるために使用します。 +- {{HTTPHeader("If-Modified-Since")}} + - : リクエストを条件付きにして、そのリソースが指定した日時より後に変更されている場合に限り転送するようリクエストします。キャッシュが期限切れである場合に限りデータを転送するために使用します。 +- {{HTTPHeader("If-Unmodified-Since")}} + - : リクエストを条件付きにして、そのリソースが指定した日時より後に変更されていない場合に限り転送するようリクエストします。これは、特定の範囲の新しい断片と古い断片の一貫性を保証する、あるいは既存の文書を変更するときに楽観的な並行性制御システムを実装するために使用します。 +- {{HTTPHeader("Vary")}} + - : 新しいものを元のサーバーにリクエストするのではなく、キャッシュされたレスポンスが使用できるよう決定するために、リクエストヘッダーを一致させる方法を定めます。/dd> + +## 接続制御 + +- {{HTTPHeader("Connection")}} + - : 現在の転送が完了した後も、ネットワークコネクションを維持するかを制御します。 +- {{HTTPHeader("Keep-Alive")}} + - : 持続的なコネクションをどれだけの期間維持するかを制御します。 + +## コンテンツネゴシエーション + +[コンテンツネゴシエーション](/ja/docs/Web/HTTP/Content_negotiation)ヘッダーです。 + +- {{HTTPHeader("Accept")}} + - : 送り返すことができるデータの{{Glossary("MIME_type", "種類")}}をサーバーに通知します。 +- {{HTTPHeader("Accept-Encoding")}} + - : 送り返すリソースで使用できるエンコードアルゴリズム (一般的には<a href="/ja/docs/Web/HTTP/Compression">圧縮アルゴリズム</a>) をサーバーに通知します。 +- {{HTTPHeader("Accept-Language")}} + - : 送り返すリソースで期待する自然言語をサーバーに通知します。これはヒントであり、必ずしもユーザーの完全な制御下にあるものではありません。サーバーはユーザーの選択 (ドロップダウンリストで選ぶ言語など) を明示的に上書きしないように、常に注意を払うべきです。 + +## 制御 + +- {{HTTPHeader("Expect")}} + - : リクエストを適切に扱うためにサーバーが実行しなければならないと期待されていることを示します。 +- {{HTTPHeader("Max-Forwards")}} + - : TBD + +## クッキー + +- {{HTTPHeader("Cookie")}} + - : 過去に {{HTTPHeader("Set-Cookie")}} ヘッダーでサーバーから送信されて保存している [HTTP クッキー](/ja/docs/Web/HTTP/Cookies)を持ちます。 +- {{HTTPHeader("Set-Cookie")}} + - : サーバーからユーザーエージェントにクッキーを送信します。 +- {{HTTPHeader("Cookie2")}} {{deprecated_inline}} + - : 過去に {{HTTPHeader("Set-Cookie2")}} ヘッダーでサーバーから送信された HTTP クッキーを伝えるために使われていましたが、仕様書から廃止されました。代わりに {{HTTPHeader("Cookie")}} を使用してください。 +- {{HTTPHeader("Set-Cookie2")}} {{deprecated_inline}} + - : サーバーからユーザーエージェントにクッキーを送信するために使用されていましたが、仕様書から廃止されました。代わりに {{HTTPHeader("Set-Cookie")}} を使用してください。 + +## CORS + +*CORS についての詳細は、[こちら](CORS)を参照してください。* + +- {{HTTPHeader("Access-Control-Allow-Origin")}} + - : レスポンスが共有可能かを示します。 +- {{HTTPHeader("Access-Control-Allow-Credentials")}} + - : credentials フラグが真であるときに、リクエストへのレスポンスを開示してよいかを示します。 +- {{HTTPHeader("Access-Control-Allow-Headers")}} + - : {{Glossary("Preflight_request", "プリフライトリクエスト")}}へのレスポンスで使用し、実際のリクエストを行うときに使用できる HTTP ヘッダーを指定します。 +- {{HTTPHeader("Access-Control-Allow-Methods")}} + - : プリフライトリクエストへのレスポンスで、リソースへアクセスするときに使用できるメソッドを指定します。 +- {{HTTPHeader("Access-Control-Expose-Headers")}} + - : ヘッダー名を羅列して、レスポンスの一部として開示できるヘッダーを示します。 +- {{HTTPHeader("Access-Control-Max-Age")}} + - : プリフライトリクエストの結果をキャッシュしてよい期間を示します。 +- {{HTTPHeader("Access-Control-Request-Headers")}} + - : 実際のリクエストを行う際に使用する HTTP ヘッダーをサーバーがわかるようにするため、プリフライトリクエストを発信する際に使用します。 +- {{HTTPHeader("Access-Control-Request-Method")}} + - : 実際のリクエストを行う際に使用する [HTTP メソッド](/ja/docs/Web/HTTP/Methods)をサーバーがわかるようにするため、プリフライトリクエストを発信する際に使用します。 +- {{HTTPHeader("Origin")}} + - : どこから読み込みが発生したかを示します。 +- {{HTTPHeader("Timing-Allow-Origin")}} + - : [Resource Timing API](/en-US/docs/Web/API/Resource_Timing_API) の機能を通じて受け取った属性の値を見ることができるオリジンを指定します。そうでなければオリジン間の制約によってゼロとして報告されます。 + +## ダウンロード + +- {{HTTPHeader("Content-Disposition")}} + - : 転送したリソースをインラインで表示すべきか (ヘッダーが存在しない場合の既定の動作)、またはダウンロードとして扱い、「名前を付けて保存」ウィンドウを表示すべきかを示します。 + +## メッセージ本文の情報 + +- {{HTTPHeader("Content-Length")}} + - : リソースの大きさを、バイト単位の10進数で示します。 +- {{HTTPHeader("Content-Type")}} + - : リソースのメディア種別を示します。 +- {{HTTPHeader("Content-Encoding")}} + - : 圧縮アルゴリズムを指定するために使用します。 +- {{HTTPHeader("Content-Language")}} + - : 読者向けに言語を示すヘッダーであり、ユーザーが自身の好む言語に応じて区別することができます。 +- {{HTTPHeader("Content-Location")}} + - : 返すデータの代替データの場所を示します。 + +## プロキシー + +- {{HTTPHeader("Forwarded")}} + - : リクエストのパスにプロキシーが関与したときに変更または遺失した、プロキシーサーバーのクライアント側の情報を持ちます。 +- {{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}} + - : HTTP プロキシーやロードバランサーを経由してウェブサーバーに接続するクライアントの、接続元 IP アドレスを識別します。 +- {{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}} + - : プロキシーやロードバランサーに接続するクライアントがリクエストした、オリジナルのホストを示します。 +- {{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}} + - : クライアントがプロキシーやロードバランサーに接続するために使用したプロトコル (HTTP または HTTPS) を識別します。 +- {{HTTPHeader("Via")}} + - : フォワードプロキシーとリバースプロキシーの両方が追加するヘッダーであり、リクエストヘッダーとレスポンスヘッダーのどちらでも見られます。 + +## リダイレクト + +- {{HTTPHeader("Location")}} + - : ページのリダイレクト先の URL を示します。 + +## リクエストコンテキスト + +- {{HTTPHeader("From")}} + - : リクエストを行うユーザーエージェントを操作している人間の、インターネット電子メールアドレスを持ちます。 +- {{HTTPHeader("Host")}} + - : サーバーのドメイン名 (バーチャルホスト向け) およびサーバーが待ち受けている TCP ポート番号 (省略可能) を指定します。 +- {{HTTPHeader("Referer")}} + - : 現在リクエストしているページへリンクしていた、前のウェブページのアドレスです。 +- {{HTTPHeader("Referrer-Policy")}} + - : {{HTTPHeader("Referer")}} ヘッダーで送信するどのリファラー情報をリクエストに含めるかを制御します。 +- {{HTTPHeader("User-Agent")}} + - : リクエストを行うユーザーエージェントソフトウェアのアプリケーションタイプ、オペレーティングシステム、ベンダー、バージョンを、ネットワークプロトコルのピアが識別できるようにする文字列を持ちます。 [Firefox ユーザーエージェント文字列リファレンス](/ja/docs/Web/HTTP/Headers/User-Agent/Firefox)もご覧ください。 + +## レスポンスコンテキスト + +- {{HTTPHeader("Allow")}} + - : リソースがサポートする HTTP リクエストメソッドを示します。 +- {{HTTPHeader("Server")}} + - : リクエストを扱うサーバーが使用するソフトウェアの情報を持ちます。 + +## 範囲付きリクエスト + +- {{HTTPHeader("Accept-Ranges")}} + - : サーバーが範囲付きリクエストに対応するかどうか、対応していれば対応する場合は、範囲を表すことができる単位を示します。 +- {{HTTPHeader("Range")}} + - : サーバーが返すべきである文書の範囲を示します。 +- {{HTTPHeader("If-Range")}} + - : 指定した ETag または日時がリモートのリソースにマッチする場合に限定した、条件付き range request を生成します。異なるバージョンのリソースから 2 つの範囲をダウンロードすることを防ぎます。 +- {{HTTPHeader("Content-Range")}} + - : 部分的なメッセージが、メッセージ本文全体のどこに位置するかを示します。 + +## セキュリティ + +- {{HTTPHeader("Cross-Origin-Embedder-Policy")}} (COEP) + - : サーバーが指定された文書の埋め込み方針を宣言するために使います。 +- {{HTTPHeader("Cross-Origin-Opener-Policy")}} (COOP) + - : 他のドメインがウィンドウを開いたり制御したりすることを防ぎます。 +- {{HTTPHeader("Cross-Origin-Resource-Policy")}} (CORP) + - : このヘッダーが適用されたリソースのレスポンスが他のドメインから読み取られるのを防ぎます。 +- {{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}}) + - : ユーザーエージェントがページで読み込むことを許可するリソースを制御します。 +- {{HTTPHeader("Content-Security-Policy-Report-Only")}} + - : ウェブの開発者がポリシーの効果を適用せずに監視することで、実験を行うことができます。これらの違反レポートは、 HTTP `POST` リクエストによって指定した URI へ送信される {{Glossary("JSON")}} 文書で構成されます。 +- {{HTTPHeader("Expect-CT")}} + - : サイトが証明書の透明性要件の報告や実施を選択できるようにします。これにより、そのサイトで不正な証明書の使用に気づかないことを防ぎます。サイトが Expect-CT ヘッダーを有効にした場合、そのサイトの証明書が公開CTログに表示されることを Chrome が確認するようにリクエストしています。 +- {{HTTPHeader("Feature-Policy")}} + - : 自身のフレームまたはその中の iframe で、ブラウザーの機能を使用することを許可または拒否する仕組みを提供します。 +- {{HTTPHeader("Origin-Isolation")}} {{experimental_inline}} + - : ウェブアプリケーションをオリジンから独立させるための仕組みを提供します。 +- {{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}}) + - : HTTP の代わりに HTTPS による通信を強制します。 +- {{HTTPHeader("Upgrade-Insecure-Requests")}} + - : 暗号化や認証されたレスポンスについて、クライアントの設定を表す信号をサーバーに送信して、{{CSP("upgrade-insecure-requests")}} ディレクティブを正しく扱うことができます。 +- {{HTTPHeader("X-Content-Type-Options")}} + - : ブラウザーで MIME スニッフィングを無効化して、{{HTTPHeader("Content-Type")}} で指定したタイプを強制的に使用させます。 +- {{HTTPHeader("X-Download-Options")}} + - : HTTP の [`X-Download-Options`](<https://docs.microsoft.com/ja-jp/previous-versions/windows/internet-explorer/ie-developer/compatibility/jj542450(v=vs.85)?#the-noopen-directive>) ヘッダーは、ブラウザー (Internet Explorer) がアプリケーションからのダウンロードでファイルを「開く」の選択肢を表示しないようにし、アプリケーションのコンテキストで実行するアクセス権を得ることがないようにして、ファイルとすることでフィッシング詐欺を防止します。 (メモ: [MS Edge bug](https://developer.microsoft.com/ja-jp/microsoft-edge/platform/issues/18488178/) に関連) +- {{HTTPHeader("X-Frame-Options")}} (XFO) + - : ブラウザーがページを {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}}, {{HTMLElement("object")}} の内部に表示することを許可するかを示します。 +- {{HTTPHeader("X-Permitted-Cross-Domain-Policies")}} + - : クロスドメインポリシーファイル (`crossdomain.xml`) を許可するかどうかを指定します。このファイルは、 Adobe の Flash Player、Adobe Acrobat、Microsoft Silverlight、Apache Flex などのクライアントに、[同一オリジンポリシー](/ja/docs/Web/Security/Same-origin_policy)によって制限されているドメイン間のデータを処理する許可を与えるポリシーを定義することができます。詳細については、 [Cross-domain Policy File Specification](https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html) を参照してください。 +- {{HTTPHeader("X-Powered-By")}} + - : ホスティング環境やその他のフレームワークによって設定される可能性があり、アプリケーションや訪問者に有益ではない情報を含みます。潜在的な脆弱性が発現することを防ぐために、このヘッダーは設定しないでください。 +- {{HTTPHeader("X-XSS-Protection")}} + - : クロスサイトスクリプティングのフィルタリングを有効化します。 + +### HTTP Public Key Pinning (HPKP) + +{{Glossary("HPKP", "HTTP Public Key Pinning")}} は非推奨となり、削除されて Certificate Transparency と {{HTTPHeader("Expect-CT")}} に置き換えられました。 + +- {{HTTPHeader("Public-Key-Pins")}} + - : 偽造した証明書による {{Glossary("MITM")}} 攻撃の危険性を軽減するため、特定の暗号公開鍵とウェブサーバーを関連付けます。 +- {{HTTPHeader("Public-Key-Pins-Report-Only")}} + - : ピンニングに違反する場合でも、ヘッダーで指定した report-uri にレポートを送信して、クライアントからサーバーへの接続は許可します。 + +## メタデータ読み取りリクエストヘッダー + +{{Glossary("Fetch metadata request header", "メタデータ読み取りリクエストヘッダー")}}は、リクエストが発生したときのコンテキストに関する情報を提供します。これによりサーバーは、リクエストがどこから来たのか、リソースがどのように使用されるのかに基づいて、リクエストを許可すべきかどうかを判断することができます。 + +- {{HTTPHeader("Sec-Fetch-Site")}} + - : リクエスト開始元のオリジンと宛先のオリジンとの関係を示すリクエストヘッダーです。これは構造化ヘッダーで、値はトークンであり、取りうる値は `cross-site`, `same-origin`, `same-site`, `none` です。 +- {{HTTPHeader("Sec-Fetch-Mode")}} + - : サーバーへのリクエストモードを示すリクエストヘッダーです。これは構造化ヘッダーで、値はトークンであり、取りうる値は `cors`, `navigate`, `nested-navigate`, `no-cors`, `same-origin`, `websocket` です。 +- {{HTTPHeader("Sec-Fetch-User")}} + - : ナビゲーションリクエストがユーザー操作によって起動されたかどうかを示すリクエストヘッダーです。これは構造化ヘッダーであり、論理値で、取りうる値は `?0` ならば偽、 `?1` ならば真です。 +- {{HTTPHeader("Sec-Fetch-Dest")}} + - : リクエストの宛先を示すリクエストヘッダーです。これは構造化ヘッダーで、値はトークンであり、取りうる値は `audio`, `audioworklet`, `document`, `embed`, `empty`, `font`, `image`, `manifest`, `object`, `paintworklet`, `report`, `script`, `serviceworker`, `sharedworker`, `style`, `track`, `video`, `worker`, `xslt` です。 + +## Server-sent event + +- {{HTTPHeader("Last-Event-ID")}} + - : TBD +- {{HTTPHeader("NEL")}} {{experimental_inline}} + - : 開発者がネットワークエラー報告ポリシーを宣言できるようにする仕組みを定義します。 +- {{HTTPHeader("Ping-From")}} + - : TBD +- {{HTTPHeader("Ping-To")}} + - : TBD +- {{HTTPHeader("Report-To")}} + - : 警告やエラーを送信るためのブラウザーに対するサーバーのエンドポイントを指定するために使用します。 + +## 転送エンコーディング + +- {{HTTPHeader("Transfer-Encoding")}} + - : エンティティをユーザーへ問題なく転送できるエンコード形式を指定します。 +- {{HTTPHeader("TE")}} + - : ユーザーエージェントが進んで受け入れる転送エンコーディングを指定します。 +- {{HTTPHeader("Trailer")}} + - : 送信者が chunk メッセージの終端に追加フィールドを含めることができます。 + +## WebSocket + +- {{HTTPHeader("Sec-WebSocket-Key")}} + - : TBD +- {{HTTPHeader("Sec-WebSocket-Extensions")}} + - : TBD +- {{HTTPHeader("Sec-WebSocket-Accept")}} + - : TBD +- {{HTTPHeader("Sec-WebSocket-Protocol")}} + - : TBD +- {{HTTPHeader("Sec-WebSocket-Version")}} + - : TBD + +## その他 + +- {{HTTPHeader("Accept-Push-Policy")}} {{experimental_inline}} + - : クライアントはリクエストに対して求めるプッシュポリシーを、リクエスト内で [`Accept-Push-Policy`](https://datatracker.ietf.org/doc/html/draft-ruellan-http-accept-push-policy-00#section-3.1) ヘッダーフィールドを送信することで表現することができます。 +- {{HTTPHeader("Accept-Signature")}} {{experimental_inline}} + - : クライアントは [`Accept-Signature`](https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.7) ヘッダーフィールドを送信して、利用可能な署名を利用する意図を示したり、対応している署名の種類を示したりすることができます。 +- {{HTTPHeader("Alt-Svc")}} + - : このサービスにたどり着く他の方法のリストに使用します。 +- {{HTTPHeader("Date")}} + - : メッセージを生成した日時です。 +- {{HTTPHeader("Early-Data")}} {{experimental_inline}} + - : このリクエストが TLS early data で送信されたことを示します。 +- {{HTTPHeader("Large-Allocation")}} + - : 読み込み中のページは大量の割り当てが必要であることをブラウザーに伝えます。 +- {{HTTPHeader("Link")}} + - : [`Link`](https://datatracker.ietf.org/doc/html/rfc5988#section-5) エンティティヘッダーフィールドは、 HTTP ヘッダー内の1つ以上のリンクを記述する方法を提供します。意味的には HTML の {{HTMLElement("link")}} 要素と等価です。 +- {{HTTPHeader("Push-Policy")}} {{experimental_inline}} + - : [`Push-Policy`](https://datatracker.ietf.org/doc/html/draft-ruellan-http-accept-push-policy-00#section-3.2)はリクエストを処理するときのプッシュ通知に関するサーバーの動作を定義します。 +- {{HTTPHeader("Retry-After")}} + - : 後続のリクエストを行う前に、ユーザーエージェントがどれだけの期間待つべきかを示します。 +- {{HTTPHeader("Signature")}} {{experimental_inline}} + - : [`Signature`](https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.1) ヘッダーフィールドは、交換のための署名のリストを伝え、それぞれはその署名の権威を決定して、そして更新する方法についての情報を伴います。 +- {{HTTPHeader("Signed-Headers")}} {{experimental_inline}} + - : [`Signed-Headers`](https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.5.1.2) ヘッダーフィールドは、シグネチャに含めるためのレスポンスヘッダーフィールドの順序付きリストを識別します。 +- {{HTTPHeader("Server-Timing")}} + - : 指定されたリクエストとレスポンスのサイクルについて、１つ以上のメトリクスまたは説明を通信します。 +- {{HTTPHeader("Service-Worker-Allowed")}} + - : [パス正弦](https://w3c.github.io/ServiceWorker/#path-restriction)を解除するために、[サービスワーカースクリプトのレスポンス](https://w3c.github.io/ServiceWorker/#service-worker-script-response)で使用します。 +- {{HTTPHeader("SourceMap")}} + - : 生成されたコードと <a href="/ja/docs/Tools/Debugger/How_to/Use_a_source_map">ソースマップ</a> を関連付けます。 +- {{HTTPHeader("Upgrade")}} + - : Upgrade ヘッダーフィールドに関連する RFC 文書は [RFC 7230, section 6.7](https://datatracker.ietf.org/doc/html/rfc7230#section-6.7) です。標準仕様では、現在のクライアント、サーバー、トランスポート層プロトコル接続で別のプロトコルへ更新または変更するための規則を定めています。例えば、このヘッダー標準ではサーバーが Upgrade ヘッダーフィールドを認めて実装すると決める前提で、クライアントが HTTP 1.1 から HTTP 2.0 へ変更することを可能にします。どちらの相手も、 Upgrade ヘッダーフィールドで指定された要件を受け入れる必要はありません。これはクライアントのヘッダーでもサーバーのヘッダーでも使用できます。Upgrade ヘッダーフィールドを指定した場合は、更新オプションを指ヘッダーonnection ヘッダーフィールドも送信者が送信しなければなりません。Connection ヘッダーフィールドについて、詳しくは[前述の RFC のセクション 6.1](https://datatracker.ietf.org/doc/html/rfc7230#section-6.1) をご覧ください。 +- {{HTTPHeader("X-DNS-Prefetch-Control")}} + - : ユーザーがたどるであろうリンクや、ドキュメントが参照する画像、 CSS、 JavaScript などのリソースのドメイン名解決をブラウザーが事前に行う機能である、 DNS プリフェッチを制御します。 +- {{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}} + - : TBD +- {{HTTPHeader("X-Pingback")}} {{non-standard_inline}} + - : TBD +- {{HTTPHeader("X-Requested-With")}} + - : TBD +- {{HTTPHeader("X-Robots-Tag")}}{{non-standard_inline}} + - : [`X-Robots-Tag`](https://developers.google.com/search/reference/robots_meta_tag#xrobotstag) ヘッダーは、一般の検索エンジンの結果でウェブページをどのように索引付けをするかを示します。このヘッダーは `<meta name="robots" content="...">` と等価です。 +- {{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}} + - : 使用する文書モードを示すために Internet Explorer で使用されています。 + +## 協力 + +[新しい記事を書いたり](/en-US/docs/MDN/Contribute/Howto/Document_an_HTTP_header)、既存のものを改善したりすることにご協力ください。 + +## 関連情報 + +- [Wikipedia の HTTP ヘッダーの一覧のページ](https://en.wikipedia.org/wiki/List_of_HTTP_header_fields) +- [IANA レジストリー](https://www.iana.org/assignments/message-headers/perm-headers.html) +- [HTTP Working Group](https://httpwg.org/specs/) diff --git a/files/ja/web/http/headers/x-content-type-options/index.html b/files/ja/web/http/headers/x-content-type-options/index.html deleted file mode 100644 index e62742b226..0000000000 --- a/files/ja/web/http/headers/x-content-type-options/index.html +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: X-Content-Type-Options -slug: Web/HTTP/Headers/X-Content-Type-Options -tags: - - HTTP - - HTTP ヘッダー - - Reference - - レスポンスヘッダー -translation_of: Web/HTTP/Headers/X-Content-Type-Options ---- -<div>{{HTTPSidebar}}</div> - -<p><code><strong>X-Content-Type-Options</strong></code> は HTTP のレスポンスヘッダーで、 {{HTTPHeader("Content-Type")}} ヘッダーで示された <a href="/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME タイプ</a>を変更せずに従うべきであることを示すために、サーバーによって使用されるマーカーです。これにより、<a href="/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types#MIME_sniffing">MIME タイプのスニッフィング</a>を抑止することができます。すなわち、ウェブマスターが自分が何をしているかを分かっていると言う手段です。</p> - -<p>このヘッダーは、コンテンツのスニッフィングにより、実行不可能な MIME タイプを実行可能な MIME タイプに変換してしまうという事故をウェブマスターが抑止するための方法として、マイクロソフトが IE 8 で導入したものです。それ以来、他のブラウザーは MIME スニッフィングのアルゴリズムがそれほど積極的ではなくても、このヘッダーを導入してきました。</p> - -<p>Firefox 72 から、 {{HTTPHeader("Content-type")}} が提供されている場合、 MIME スニッフィングの抑止が最上位の文書にも適用されるようになりました。これにより、 HTML のウェブページが <code>text/html</code> 以外の MIME タイプで提供されている場合、表示される代わりにダウンロードされることがあります。両方のヘッダーを正しく設定してください。</p> - -<p>サイトのセキュリティテスターは通常、このヘッダーが設定されていることを期待しています。</p> - -<p class="blockIndicator note">注: <code>X-Content-Type-Options</code> は、 <a href="https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff?"><code>nosniff</code> によるリクエストブロッキング</a>を<a href="https://fetch.spec.whatwg.org/#concept-request-destination">リクエスト先</a>が "<code>script</code>" と "<code>style</code>" の場合のみ適用します。しかし、 <a href="https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md#determining-whether-a-response-is-corb_protected">Cross-Origin Read Blocking (CORB)</a> 保護を HTML, TXT, JSON, XML の各ファイル (SVG <code>image/svg+xml</code> を除く) に対して有効にすることもできます。</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">ヘッダー種別</th> - <td>{{Glossary("Response header", "レスポンスヘッダー")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Forbidden header name", "禁止ヘッダー名")}}</th> - <td>いいえ</td> - </tr> - </tbody> -</table> - -<h2 id="Syntax" name="Syntax">構文</h2> - -<pre class="syntaxbox notranslate">X-Content-Type-Options: nosniff -</pre> - -<h2 id="Directives" name="Directives">ディレクティブ</h2> - -<dl> - <dt><code>nosniff</code></dt> - <dd>リクエスト先のタイプが以下の場合、リクエストをブロックします。 - <ul> - <li>"<code>style</code>" で MIME タイプが <code>text/css</code> でない、または</li> - <li>"<code>script</code>" で MIME タイプが <a href="https://html.spec.whatwg.org/multipage/scripting.html#javascript-mime-type">JavaScript の MIME タイプ</a>でない</li> - </ul> - </dd> - <dd>Cross-Origin Read Blocking (CORB) 保護を次の MIME タイプに対して有効にします。 - <ul> - <li><code>text/html</code></li> - <li><code>text/plain</code></li> - <li><code>text/json</code>, <code>application/json</code> またはその他の JSON 拡張を伴うタイプ: <code>*/*+json</code></li> - <li><code>text/xml</code>, <code>application/xml</code> またはその他の XML 拡張を伴うタイプ: <code>*/*+xml</code> (<code>image/svg+xml</code> を除く)</li> - </ul> - </dd> -</dl> - -<h2 id="Specifications" name="Specifications">仕様書</h2> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">仕様書</th> - <th scope="col">状態</th> - <th scope="col">備考</th> - </tr> - </thead> - <tbody> - <tr> - <td>{{SpecName("Fetch", "#x-content-type-options-header", "X-Content-Type-Options definition")}}</td> - <td>{{Spec2("Fetch")}}</td> - <td>初回定義</td> - </tr> - </tbody> -</table> - -<h2 id="Browser_compatibility" name="Browser_compatibility">ブラウザーの互換性</h2> - -<p>{{Compat("http.headers.X-Content-Type-Options")}}</p> - -<h3 id="Browser_specific_notes" name="Browser_specific_notes">ブラウザー固有の注意事項</h3> - -<ul> - <li>Firefox 72 は最上位文書で <code>X-Content-Type-Options: nosniff</code> を有効にします。</li> -</ul> - -<h2 id="See_also" name="See_also">関連情報</h2> - -<ul> - <li>{{HTTPHeader("Content-Type")}}</li> - <li>Microsoft による X-Content-Type-Options の <a href="https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/">元の定義</a></li> - <li>The <a href="https://observatory.mozilla.org/">Mozilla Observatory</a> tool testing the configuration (including this header) of Web sites for safety and security</li> - <li><a href="https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/">Mitigating MIME Confusion Attacks in Firefox</a></li> - <li><a href="https://fetch.spec.whatwg.org/#corb">Cross-Origin Read Blocking (CORB)</a></li> - <li><a href="https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md">Google Docs CORB explainer</a></li> -</ul> diff --git a/files/ja/web/http/headers/x-content-type-options/index.md b/files/ja/web/http/headers/x-content-type-options/index.md new file mode 100644 index 0000000000..d61b33f893 --- /dev/null +++ b/files/ja/web/http/headers/x-content-type-options/index.md @@ -0,0 +1,67 @@ +--- +title: X-Content-Type-Options +slug: Web/HTTP/Headers/X-Content-Type-Options +tags: + - HTTP + - HTTP ヘッダー + - Reference + - レスポンスヘッダー +browser-compat: http.headers.X-Content-Type-Options +translation_of: Web/HTTP/Headers/X-Content-Type-Options +--- +{{HTTPSidebar}} + +**`X-Content-Type-Options`** は HTTP のレスポンスヘッダーで、 {{HTTPHeader("Content-Type")}} ヘッダーで示された [MIME タイプ](/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types)を変更せずに従うべきであることを示すために、サーバーによって使用されるマーカーです。これにより、[MIME タイプのスニッフィング](/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing)を抑止することができます。言い替えれば、 MIME タイプを意図的に設定することができます。 + +このヘッダーは、 Microsoft が IE 8 において、コンテンツのスニッフィングにより、実行不可能な MIME タイプを実行可能な MIME タイプに変換してしまうという事故を抑止するためのとして導入したものです。それ以来、他のブラウザーは MIME スニッフィングのアルゴリズムにそれほど積極的ではなくても、このヘッダーを導入してきました。 + +Firefox 72 から、 {{HTTPHeader("Content-type")}} が提供されている場合、 MIME スニッフィングの抑止が最上位の文書にも適用されるようになりました。これにより、 HTML のウェブページが `text/html` 以外の MIME タイプで提供された場合、表示されるのではなくダウンロードされることがあります。両方のヘッダーを正しく設定してください。 + +サイトのセキュリティテスターは通常、このヘッダーが設定されていることを期待しています。 + +> **Note:** `X-Content-Type-Options` は、 [`nosniff` によるリクエストブロッキング](https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff?)を[リクエスト先](https://fetch.spec.whatwg.org/#concept-request-destination)が "`script`" と "`style`" の場合のみ適用します。しかし、 [Cross-Origin Read Blocking (CORB)](https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md#determining-whether-a-response-is-corb_protected) 保護を HTML, TXT, JSON, XML の各ファイル (SVG `image/svg+xml` を除く) に対して有効にすることもできます。</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">ヘッダー種別</th> + <td>{{Glossary("Response header", "レスポンスヘッダー")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name", "禁止ヘッダー名")}}</th> + <td>いいえ</td> + </tr> + </tbody> +</table> + +## 構文 + +``` +X-Content-Type-Options: nosniff +``` + +# ディレクティブ + +- `nosniff` + - : リクエスト先のタイプが `style` でありその MIME タイプが `text/css` ではない場合、または、タイプが `script` で MIME タイプが [JavaScript の MIME タイプ](https://html.spec.whatwg.org/multipage/scripting.html#javascript-mime-type)ではない場合にリクエストをブロックします。 + +## 仕様書 + +{{Specifications}} + +## ブラウザーの互換性 + +{{Compat}} + +### ブラウザー固有の注意事項 + +- Firefox 72 は最上位の文書で `X-Content-Type-Options: nosniff` を有効にします。 + +## 関連情報 + +- {{HTTPHeader("Content-Type")}} +- Microsoft による X-Content-Type-Options の [元の定義](https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/) +- [Mozilla Observatory](https://observatory.mozilla.org/) ツールによるウェブサイトの設定 (このヘッダーを含む) の安全性とセキュリティのテスト +- [Firefox における MIME 混同攻撃の緩和](https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/) +- [Cross-Origin Read Blocking (CORB)](https://fetch.spec.whatwg.org/#corb) +- [Google Docs CORB 解説書](https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md) diff --git a/files/ja/web/http/network_error_logging/index.html b/files/ja/web/http/network_error_logging/index.html new file mode 100644 index 0000000000..9ddd3ff8ff --- /dev/null +++ b/files/ja/web/http/network_error_logging/index.html @@ -0,0 +1,155 @@ +--- +title: Network Error Logging +slug: Web/HTTP/Network_Error_Logging +tags: + - Guide + - HTTP + - Network Error Logging + - Reference +translation_of: Web/HTTP/Network_Error_Logging +--- +<div>{{HTTPSidebar}}{{SeeCompatTable}}</div> + +<p>ネットワークエラーロギングは、HTTP の {{HTTPHeader("NEL")}} <em><a href="/ja/docs/Glossary/Response_header">レスポンスヘッダー</a></em>を使って設定できるメカニズムです。この実験的なヘッダーにより、ウェブサイトやアプリケーションは、対応しているブラウザーから、失敗した (必要であれば成功した) ネットワーク読み取りに関するレポートを受け取ることを選択することができます。</p> + +<p>レポートは、 {{HTTPHeader("Report-To")}} ヘッダーで定義された報告グループに送信されます。</p> + +<h2 id="Usage">使用方法</h2> + +<p>ウェブアプリケーションは、 <em><a href="/ja/docs/Glossary/Response_header">JSON エンコード</a></em>されたオブジェクトである NEL ヘッダーを使って、この動作を選択します。</p> + +<pre><a href="https://www.w3.org/TR/network-error-logging/#nel-response-header">NEL</a>: { "<a href="https://www.w3.org/TR/network-error-logging/#the-report_to-member">report_to</a>": "nel", + "<a href="https://www.w3.org/TR/network-error-logging/#the-max_age-member">max_age</a>": 31556952 } +</pre> + +<p>ブラウザーから安全と認識されたオリジンが必要です。</p> + +<p>以下のオブジェクトキーが NEL ヘッダーで指定されています。</p> + +<dl> + <dt>report_to</dt> + <dd> + <p>ネットワークエラーレポートの送信先となる <a href="/ja/docs/Web/API/Reporting_API">Reporting API</a> グループです。</p> + </dd> + <dt>max_age</dt> + <dd>ポリシーの有効期間を秒単位で指定します (HSTS ポリシーが時間制限されているのと同様の方法です)。参照される報告グループは、少なくとも NEL ポリシーと同程度の有効期間を持つ必要があります。</dd> + <dt>include_subdomains</dt> + <dd>true の場合、ポリシーは、ポリシーヘッダーが設定されているオリジンの下のすべてのサブドメインに適用されます。このオプションを有効にする場合は、サブドメインを含めるように報告グループを設定する必要があります。</dd> + <dt>success_fraction</dt> + <dd>0 と 1 の間の浮動小数点値で、報告するネットワーク要求が成功した割合を指定します。既定値は 0 で、JSON ペイロードにキーが存在しない場合、成功したネットワークリクエストは報告されません。</dd> + <dt>failure_fraction</dt> + <dd>0 と 1 の間の浮動小数点値で、報告する<strong>失敗した</strong>ネットワークリクエストの割合を指定します。既定値は 1 で、JSON ペイロードにキーが存在しない場合、失敗したすべてのネットワークリクエストが報告されます。</dd> +</dl> + +<p>上記のレポートグループは、 {{HTTPHeader("Report-To")}} ヘッダー内で通常の方法で定義されます。例えば下記のようになります。</p> + +<pre><a href="https://wicg.github.io/reporting/#report-to" id="ref-for-report-to①">Report-To</a>: { "<a href="https://wicg.github.io/reporting/#group" id="ref-for-group①">group</a>": "nel", + "<a href="https://wicg.github.io/reporting/#max-age" id="ref-for-max-age①">max_age</a>": 31556952, + "<a href="https://wicg.github.io/reporting/#endpoints" id="ref-for-endpoints②">endpoints</a>": [ + { "<a href="https://wicg.github.io/reporting/#url" id="ref-for-url②">url</a>": "https://example.com/csp-reports" } + ] } +</pre> + +<h2 id="Error_reports">エラーレポート</h2> + +<p>これらの例では、Reporting API のペイロード全体を示しています。最上位の <strong><code>"body"</code></strong> キーには、ネットワークエラーレポートが含まれています。</p> + +<h3 id="HTTP_400_Bad_Request_response">HTTP 400 (Bad Request) response</h3> + +<pre class="brush: js">{ + "age": 20, + "type": "network-error", + "url": "https://example.com/previous-page", + "body": { + "elapsed_time": 338, + "method": "POST", + "phase": "application", + "protocol": "http/1.1", + "referrer": "https://example.com/previous-page", + "sampling_fraction": 1, + "server_ip": "137.205.28.66", + "status_code": 400, + "type": "http.error", + "url": "https://example.com/bad-request" + } +} +</pre> + +<h3 id="DNS_name_not_resolved">DNS 名が未解決</h3> + +<p>なお、このレポートではフェーズが <code>dns</code> に設定されており、含めることのできる <code>server_ip</code> はありません。</p> + +<pre class="brush: js">{ + "age": 20, + "type": "network-error", + "url": "https://example.com/previous-page", + "body": { + "elapsed_time": 18, + "method": "POST", + "phase": "dns", + "protocol": "http/1.1", + "referrer": "https://example.com/previous-page", + "sampling_fraction": 1, + "server_ip": "", + "status_code": 0, + "type": "dns.name_not_resolved", + "url": "https://example-host.com/" + } +} +</pre> + +<p>ネットワークエラーの種類は、仕様で定義された以下の値のいずれかですが、ブラウザは独自のエラー種別を追加して送信することができます。</p> + +<dl> + <dt><code>dns.unreachable</code></dt> + <dd>ユーザーの DNS サーバーに到達できない</dd> + <dt><code>dns.name_not_resolved</code></dt> + <dd>ユーザーの DNS サーバーは応答したが、リクエストされた URI の IP アドレスに解決できなかった。</dd> + <dt><code>dns.failed</code></dt> + <dd>DNS サーバーへのリクエストが、以前のエラー (SERVFAIL など) でカバーされない理由で失敗した</dd> + <dt><code>dns.address_changed</code></dt> + <dd>セキュリティ上の理由から、オリジナルのレポートを配信したサーバーの IP アドレスが、エラー発生時の現在のサーバーの IP アドレスと異なる場合、レポートデータはこの問題に関する情報のみを含むようにダウングレードされ、タイプは <code>dns.address_changed</code> に設定されます。</dd> + <dt><code>tcp.timed_out</code></dt> + <dd>サーバーへの TCP コネクションがタイムアウトした</dd> + <dt><code>tcp.closed</code></dt> + <dd>TCP コネクションがサーバーから閉じられた</dd> + <dt><code>tcp.reset</code></dt> + <dd>TCP コネクションがリセットされた</dd> + <dt><code>tcp.refused</code></dt> + <dd>TCP コネクションがサーバーから拒否された</dd> + <dt><code>tcp.aborted</code></dt> + <dd>TCP コネクションが中止された</dd> + <dt><code>tcp.address_invalid</code></dt> + <dd>IP アドレスが無効である</dd> + <dt><code>tcp.address_unreachable</code></dt> + <dd>IP アドレスに到達できない</dd> + <dt><code>tcp.failed</code></dt> + <dd>TCP コネクションが直前のエラーによってカバーできない原因で失敗した</dd> + <dt><code>http.error</code></dt> + <dd>ユーザーエージェントがレスポンスの受信に成功したが、 <a href="https://datatracker.ietf.org/doc/html/rfc7231#section-6.5">4xx</a> または <a href="https://datatracker.ietf.org/doc/html/rfc7231#section-6.6">5xx</a> のステータスコードであった</dd> + <dt><code>http.protocol.error</code></dt> + <dd>コネクションが HTTP プロトコルエラーのために中止された</dd> + <dt><code>http.response.invalid</code></dt> + <dd>レスポンスが空であるか、 content-length が合っていないか、エンコーディングが正しくないか、その他の状況でユーザーエージェントがレスポンスを処理できなかった</dd> + <dt><code>http.response.redirect_loop</code></dt> + <dd>リクエストはリダイレクトループが検出されたため中止された</dd> + <dt><code>http.failed</code></dt> + <dd>コネクションは直前のエラーでカバーされなかった HTTP プロトコルのエラーで失敗した</dd> +</dl> + +<h2 id="Specifications">仕様書</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">仕様書</th> + </tr> + <tr> + <td><a href="https://w3c.github.io/network-error-logging/#introduction">Network Error Logging</a></td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">ブラウザーの互換性</h2> + +<p>{{Compat("http.headers.NEL")}}</p> diff --git a/files/ja/web/http/status/202/index.html b/files/ja/web/http/status/202/index.html deleted file mode 100644 index f4f6916f78..0000000000 --- a/files/ja/web/http/status/202/index.html +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: 202 Accepted -slug: Web/HTTP/Status/202 -tags: - - HTTP - - HTTP ステータスコード - - リファレンス -translation_of: Web/HTTP/Status/202 ---- -<div>{{HTTPSidebar}}</div> - -<p>HTTP <code><strong>202 Accepted</strong></code> レスポンスはリクエストを受け取ったが処理はされていない、ということを表すステータスコードです。これはコミットされていない、リクエストを処理した結果を示すレスポンスを、非同期で送信する方法がHTTPに存在しないことを意味しています。別のプロセスまたはサーバーがリクエストを処理する場合、またはバッチ処理の場合を想定しています。</p> - -<h2 id="ステータス">ステータス</h2> - -<pre class="syntaxbox">202 Accepted</pre> - -<h2 id="仕様">仕様</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">仕様</th> - <th scope="col">タイトル</th> - </tr> - <tr> - <td>{{RFC("7231", "202 Accepted" , "6.3.3")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> - </tr> - </tbody> -</table> - -<h2 id="参照">参照</h2> - -<ul> - <li>{{HTTPHeader("Accept")}}</li> -</ul> diff --git a/files/ja/web/http/status/202/index.md b/files/ja/web/http/status/202/index.md new file mode 100644 index 0000000000..863f9b6fe8 --- /dev/null +++ b/files/ja/web/http/status/202/index.md @@ -0,0 +1,31 @@ +--- +title: 202 Accepted +slug: Web/HTTP/Status/202 +tags: + - HTTP + - リファレンス + - ステータスコード + - 成功レスポンス +translation_of: Web/HTTP/Status/202 +--- +{{HTTPSidebar}} + +HTTP (HyperText Transfer Protocol) の **`202 Accepted`** レスポンスステータスコードは、リクエストを受け取ったが、処理が完了していないことを表します。実際には、処理はまだ始まっていない可能性もあります。そのリクエストは、実際に処理が行われたときに拒否される可能性があるため、最終的に処理されるかどうかはわかりません。処理が実際に行われたときに許可されないかもしれないからです。 + +202 はコミットするものではありません。つまり、 HTTP にはリクエストの処理結果を示す非同期レスポンスを後で送信する方法がありません。別のプロセスやサーバーがリクエストを処理する場合や、バッチ処理のためのものです。 + +## ステータス + +``` +202 Accepted +``` + +## 仕様書 + +| 仕様書 | 題名 | +| -------------------------------------------------------- | ------------------------------------------------------------- | +| {{RFC("7231", "202 Accepted" , "6.3.3")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | + +## 関連情報 + +- {{HTTPHeader("Accept")}} |