From e4ef638f9e1155ddf8dca23d59085763666b2834 Mon Sep 17 00:00:00 2001 From: Masahiro FUJIMOTO Date: Sun, 1 Oct 2023 19:10:57 +0900 Subject: [PATCH] =?UTF-8?q?2023/04/11=20=E6=99=82=E7=82=B9=E3=81=AE?= =?UTF-8?q?=E8=8B=B1=E8=AA=9E=E7=89=88=E3=81=AB=E5=90=8C=E6=9C=9F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- files/ja/web/http/messages/index.md | 83 +++++++++++++++-------------- 1 file changed, 44 insertions(+), 39 deletions(-) diff --git a/files/ja/web/http/messages/index.md b/files/ja/web/http/messages/index.md index b0edff75aefefb..0e941452f7d08a 100644 --- a/files/ja/web/http/messages/index.md +++ b/files/ja/web/http/messages/index.md @@ -1,6 +1,8 @@ --- title: HTTP メッセージ slug: Web/HTTP/Messages +l10n: + sourceCommit: 0880a90f3811475d78bc4b2c344eb4146f25f66c --- {{HTTPSidebar}} @@ -9,22 +11,22 @@ HTTP メッセージは、サーバーとクライアントがデータを交換 HTTP メッセージは ASCII でエンコードされたテキスト情報で構成されており、複数の行にまたがります。HTTP/1.1 およびそれより前のバージョンのプロトコルでは、メッセージがコネクション内でそのまま送信されます。HTTP/2 では、人間が読める形式のメッセージを HTTP フレームに分割して、最適化やパフォーマンスの向上を実現します。 -ウェブ開発者やウェブ管理者がこれらテキスト形式の HTTP メッセージを作成することはめったにありません。ウェブブラウザー、プロキシ、ウェブサーバーといったソフトウェアが行います。それらは HTTP メッセージを設定ファイル (プロキシやサーバー)、API (ブラウザー)、あるいは他のインターフェイスによって提供します。 +ウェブ開発者やウェブ管理者がこれらテキスト形式の HTTP メッセージを作成することはめったにありません。ウェブブラウザー、プロキシー、ウェブサーバーといったソフトウェアが行います。それらは HTTP メッセージを設定ファイル（プロキシーやサーバー）、API （ブラウザー）、あるいは他のインターフェイスによって提供します。 -![From a user-, script-, or server- generated event, an HTTP/1.x msg is generated, and if HTTP/2 is in use, it is binary framed into an HTTP/2 stream, then sent.](httpmsg2.png) +![ユーザーやスクリプトやサーバーが生成したイベントから、 HTTP/1.x メッセージが生成され、 HTTP/2 を使用している場合は、 HTTP/2 ストリームにバイナリーフレーム化され、送信されます。](httpmsg2.png) -HTTP/2 のバイナリフレーム化方式は、適用される API や設定ファイルの変更を必要としないように設計されています。これはユーザーに対して透過的です。 +HTTP/2 のバイナリーフレーム化方式は、適用される API や設定ファイルの変更を必要としないように設計されています。これはユーザーに対して透過的です。 HTTP のリクエストやレスポンスは似た構造を共用しており、以下の要素で構成されます。 1. 実行するリクエスト、または成功か失敗かの状態を表す*開始行*。開始行は常に 1 行です。 -2. リクエストの詳細を示す、またはメッセージに含まれる本文を説明する、省略可能な *HTTP ヘッダー*一式。 +2. リクエストの詳細を示す、またはメッセージに含まれる本体を説明する、省略可能な *HTTP ヘッダー*一式。 3. リクエストのメタ情報がすべて送信されたことを示す空行。 -4. リクエストに関連付けられたデータ (HTML フォームの内容など)、あるいはレスポンスに関連付けられたドキュメントを含む、省略可能な*本文*。本文が存在することやそのサイズは、開始行や HTTP ヘッダーで指定します。 +4. リクエストに関連付けられたデータ (HTML フォームの内容など)、あるいはレスポンスに関連付けられたドキュメントを含む、省略可能な*本体*。本体が存在することやそのサイズは、開始行や HTTP ヘッダーで指定します。 -HTTP メッセージの開始行と HTTP ヘッダーは、まとめてリクエストの*ヘッド*として知られています。一方、ペイロードは*本文*として知られています。 +HTTP メッセージの開始行と HTTP ヘッダーは、まとめてリクエストの*ヘッド*として知られています。一方、ペイロードは*本体*として知られています。 -![Requests and responses share a common structure in HTTP](httpmsgstructure2.png) +![リクエストとレスポンスは HTTP で共通の構造を持っています。](httpmsgstructure2.png) ## HTTP リクエスト @@ -33,15 +35,18 @@ HTTP メッセージの開始行と HTTP ヘッダーは、まとめてリクエ HTTP リクエストは、アクションを始めるためにクラアントからサーバーへ送られます。その*開始行*には、3 つの要素が含まれています。 1. _[HTTP メソッド](/ja/docs/Web/HTTP/Methods)_。実行するアクションを表わす動詞 ({{HTTPMethod("GET")}}、{{HTTPMethod("PUT")}}、{{HTTPMethod("POST")}} など) または名詞 ({{HTTPMethod("HEAD")}}、{{HTTPMethod("OPTIONS")}})。例えば `GET` はリソースを取り込むこと、`POST` はデータをサーバーへ送信すること (リソースを作成または変更する、あるいは返送する一時的なドキュメントを生成する) ことを示します。 -2. _リクエスト対象_。通常は {{glossary("URL")}} ですが、プロトコル、ポート、ドメインの絶対パスは通常、リクエストの状況から明らかにされます。リクエスト対象の形式は、HTTP メソッドにより異なります。以下のような形式があります。 - - - 最後に `'?'` とクエリー文字列がある絶対パス。これは _origin form_ として知られているもっとも一般的な形式であり、`GET`、`POST`、`HEAD`、`OPTIONS` メソッドで使用します。 - `POST / HTTP/1.1 GET /background.png HTTP/1.0 HEAD /test.html?query=alibaba HTTP/1.1 OPTIONS /anypage.html HTTP/1.0` - - _absolute form_ として知られている完全な URL は、主にプロキシへ接続する際に `GET` で使用します。 - `GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1` - - ドメイン名とポート (省略可能。`':'` を前につける) で構成される、URL の authority の部分は _authority form_ と呼ばれます。これは `CONNECT` で HTTP トンネルを設定するときに限り使用されます。 +2. _リクエスト対象_。通常は {{glossary("URL")}} ですが、プロトコル、ポート番号、ドメインの絶対パスは通常、リクエストの状況から明らかにされます。リクエスト対象の形式は、HTTP メソッドにより異なります。以下のような形式があります。 + + - 最後に `'?'` とクエリー文字列がある絶対パス。これは*オリジン形式*とも呼ばれているもっとも一般的な形式であり、`GET`、`POST`、`HEAD`、`OPTIONS` メソッドで使用します。 + - `POST / HTTP/1.1` + - `GET /background.png HTTP/1.0` + - `HEAD /test.html?query=alibaba HTTP/1.1` + - `OPTIONS /anypage.html HTTP/1.0` + - 完全な URL は*絶対形式*とも呼ばれ、主にプロキシーへ接続する際に `GET` で使用します。 + `GET https://developer.mozilla.org/ja/docs/Web/HTTP/Messages HTTP/1.1` + - ドメイン名とポート（省略可能。`':'` を前につける）で構成される、URL の authority の部分は*認証形式*と呼ばれます。これは `CONNECT` で HTTP トンネルを設定するときに限り使用されます。 `CONNECT developer.mozilla.org:80 HTTP/1.1` - - 単なるアスタリスク (`'*'`) である _asterisk form_ は `OPTIONS` で使用されており、サーバー全体を表します。 + - 単純なアスタリスク (`'*'`) である*アスタリスク形式*は `OPTIONS` で使用され、サーバー全体を表します。 `OPTIONS * HTTP/1.1` 3. _HTTP バージョン_。これはメッセージの残りの部分の構造を定義しており、レスポンスで使用することを想定しているバージョンを示す役割もあります。 @@ -50,22 +55,22 @@ HTTP リクエストは、アクションを始めるためにクラアントか リクエストの [HTTP ヘッダー](/ja/docs/Web/HTTP/Headers) は、HTTP ヘッダーの一定の基本構造に従います。大文字・小文字を区別しない文字列の後にコロン (`':'`) と、ヘッダーに応じた構造の値が続きます。値を含むヘッダー全体は 1 行で構成されており、とても長くなる場合もあります。 -使用できるリクエストヘッダーは多数あります。これらはいくつかのグループに分類されます。 +様々なヘッダーがリクエストに現れることがあります。これらはいくつかのグループに分類されます。 -- *一般ヘッダー*は、 {{HTTPHeader("Via")}} など、メッセージ全体に適用されるものです。 -- *リクエストヘッダー*は、 {{HTTPHeader("User-Agent")}}, {{HTTPHeader("Accept-Type")}}, 指定するとリクエストを変更するもの ({{HTTPHeader("Accept-Language")}} など)、状況を示すもの ({{HTTPHeader("Referer")}} など)、条件を与えるもの ({{HTTPHeader("If-None")}} など) があります。 -- *エンティティヘッダー*は {{HTTPHeader("Content-Length")}} など、リクエストの本文に適用されます。当然ながら、リクエスト内に本文がない場合はこれらのヘッダーが送信されません。 +- {{glossary("General header", "一般ヘッダー")}}は、 {{HTTPHeader("Via")}} など、メッセージ全体に適用されるものです。 +- {{glossary("Request header", "リクエストヘッダー")}}は、 {{HTTPHeader("User-Agent")}}, {{HTTPHeader("Accept")}} などで、指定するとリクエストを変更するもの（{{HTTPHeader("Accept-Language")}} など）、状況を示すもの（{{HTTPHeader("Referer")}} など）、条件を制約するもの（{{HTTPHeader("If-None")}} など）があります。 +- {{glossary("Representation header", "表現ヘッダー")}}は {{HTTPHeader("Content-Type")}} など、メッセージデータの下の形式や適用されているエンコーディングを説明します（メッセージの本体がある場合のみ存在します）。 -![Example of headers in an HTTP request](http_request_headers2.png) +![HTTP リクエストのヘッダーの例](http_request_headers3.png) -### 本文 +### 本体 -リクエストの最後の部分が本文です。本文が存在しないリクエストもあります。リソースを取り込むリクエストである `GET`, `HEAD`, `DELETE`, `OPTIONS` は通常、本文は不要です。サーバー内のデータを更新するためにデータを送信するリクエストもあり、 `POST` リクエストでよくあります (HTML フォームのデータを持つ)。 +リクエストの最後の部分が本体 (body) です。本体が存在しないリクエストもあります。リソースを取り込むリクエストである `GET`, `HEAD`, `DELETE`, `OPTIONS` は通常、本体は不要です。サーバー内のデータを更新するためにデータを送信するリクエストもあり、 `POST` リクエストでよくあります（HTML フォームのデータを持つ）。 -本文は、大きく 2 種類に分類されます。 +本体は、大きく 2 種類に分類されます。 -- 単一リソースの本文。1 個のファイルで構成され、{{HTTPHeader("Content-Type")}} と {{HTTPHeader("Content-Length")}} の 2 つのヘッダーで定義されます。 -- [複数リソースの本文](/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data)。マルチパートの本文で構成され、それぞれが異なる情報を持ちます。これは主に、 [HTML フォーム](/ja/docs/Web/Guide/HTML/Forms)と関連付けられます。 +- 単一リソースの本体。1 個のファイルで構成され、{{HTTPHeader("Content-Type")}} と {{HTTPHeader("Content-Length")}} の 2 つのヘッダーで定義されます。 +- [複数リソースの本体](/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data)。マルチパートの本体で構成され、それぞれが異なる情報を持ちます。これは主に、 [HTML フォーム](/ja/docs/Learn/Forms)と関連付けられます。 ## HTTP レスポンス @@ -75,7 +80,7 @@ HTTP レスポンスの開始行は*ステータス行*と呼ばれ、以下の 1. _プロトコルバージョン_。通常 `HTTP/1.1` です。 2. _ステータスコード_。リクエストが成功したか失敗したかを示します。一般的なステータスコードは {{HTTPStatus("200")}}, {{HTTPStatus("404")}}, {{HTTPStatus("302")}} です。 -3. _ステータス文字列_。手短な単なる情報ですが、人間が HTTP メッセージを理解するのを助けるために、ステータスコードをテキストで説明します。 +3. _ステータステキスト_。手短な単なる情報ですが、人間が HTTP メッセージを理解するのを助けるために、ステータスコードをテキストで説明します。 一般的に、ステータス行は `HTTP/1.1 404 Not Found.` のようになります。 @@ -85,35 +90,35 @@ HTTP レスポンスの開始行は*ステータス行*と呼ばれ、以下の 使用できるレスポンスヘッダーは多数あります。これらはいくつかのグループに分類されます。 -- *一般ヘッダー*は {{HTTPHeader("Via")}} など、メッセージ全体に適用されるものです。 -- *レスポンスヘッダー*は {{HTTPHeader("Vary")}} や {{HTTPHeader("Accept-Ranges")}} など、ステータス行で伝えられないサーバーの追加情報を与えます。 -- *エンティティヘッダー*は {{HTTPHeader("Content-Length")}} など、レスポンスの本文に適用されます。通常、レスポンス内に本文がない場合はこのようなヘッダーは送信されません。 +- {{glossary("General header", "一般ヘッダー")}}は {{HTTPHeader("Via")}} など、メッセージ全体に適用されるものです。 +- {{glossary("Response header", "レスポンスヘッダー")}}は {{HTTPHeader("Vary")}} や {{HTTPHeader("Accept-Ranges")}} など、ステータス行で伝えられないサーバーの追加情報を与えます。 +- {{glossary("Representation header", "表現ヘッダー")}}は {{HTTPHeader("Content-Type")}} など、レスポンスの本体に適用されます。通常、レスポンス内に本体がない場合はこのようなヘッダーは送信されません。 -![Example of headers in an HTTP response](http_response_headers2.png) +![HTTP レスポンスヘッダーの例](http_response_headers2.png) -### 本文 +### 本体 -レスポンスの最後の部分が本文です。本文を持たないレスポンスもあります。 {{HTTPStatus("201")}} **`Created`** や {{HTTPStatus("204")}} **`No Content`** といったステータスコードのレスポンスは通常、本文がありません。 +レスポンスの最後の部分が本体です。本体を持たないレスポンスもあります。 {{HTTPStatus("201")}} **`Created`** や {{HTTPStatus("204")}} **`No Content`** といったステータスコードのレスポンスは通常、本体がありません。 -本文は、大きく 3 種類に分類されます。 +本体は、大きく 3 種類に分類されます。 -- 大きさが判明している 1 個のファイルで構成される、単一リソースの本文。 {{HTTPHeader("Content-Type")}} と {{HTTPHeader("Content-Length")}} の 2 つのヘッダーで定義されます。 -- 大きさが不明な 1 個のファイルで構成される、単一リソースの本文。 {{HTTPHeader("Transfer-Encoding")}} を `chunked` に設定して、 chunked 形式でエンコードされます。 -- [複数リソースの本文](/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data)。マルチパートの本文で構成され、それぞれが異なる情報のセクションを持ちます。これは比較的まれです。 +- 大きさが判明している 1 個のファイルで構成される、単一リソースの本体。 {{HTTPHeader("Content-Type")}} と {{HTTPHeader("Content-Length")}} の 2 つのヘッダーで定義されます。 +- 大きさが不明な 1 個のファイルで構成される、単一リソースの本体。 {{HTTPHeader("Transfer-Encoding")}} を `chunked` に設定して、 chunked 形式でエンコードされます。 +- [複数リソースの本体](/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data)。マルチパートの本体で構成され、それぞれが異なる情報のセクションを持ちます。これは比較的まれです。 ## HTTP/2 フレーム HTTP/1.x のメッセージには、パフォーマンスの欠点があります。 -- ヘッダーは本文と異なり、圧縮されません。 +- ヘッダーは本体と異なり、圧縮されません。 - あるメッセージと次のメッセージでヘッダーが酷似していることがよくありますが、それでも複数のコネクションにわたって繰り返されます。 - 多重化することができません。同じサーバーに対して複数のコネクションを開かなければなりません。また、ウォーム状態の TCP コネクションはコールド状態のコネクションより効率的です。 HTTP/2 は次の段階に進みました。 HTTP/1.x のメッセージを、ストリーム内に埋め込まれるフレームに分割します。データのフレームとヘッダーのフレームは区別され、ヘッダーの圧縮が可能になります。*多重化*と呼ばれる処理によって複数のストリームがまとめられ、下層の TCP コネクションの効率を向上させることができます。 -![HTTP/2 modify the HTTP message to divide them in frames (part of a single stream), allowing for more optimization.](binary_framing2.png) +![HTTP/2 は HTTP メッセージをフレーム（単一のストリームの一部）に分割するように変更し、より最適化できるようにします。](binary_framing2.png) -HTTP フレームは、ウェブ開発者によって透過的になります。これは HTTP/2 において、 HTTP/1.1 メッセージと基盤となるトランスポート層との間のさらなるステップです。 HTTP フレームを利用するためにウェブ開発者が使用する API を変更する必要はありません。ブラウザーとサーバーの両方で利用可能になれば、 HTTP/2 が有効になり使用されます。 +HTTP フレームは、ウェブ開発者に対しては透過的になります。これは HTTP/2 において、 HTTP/1.1 メッセージと基盤となるトランスポート層との間のさらなるステップです。 HTTP フレームを利用するためにウェブ開発者が使用する API を変更する必要はありません。ブラウザーとサーバーの両方で利用可能になれば、 HTTP/2 が有効になり使用されます。 ## まとめ