HTTPプロトコルのメッセージ構造

HTTP プロトコル <2> メッセージ構造

HTTPメッセージの構造

リクエストメッセージ

HTTP リクエストメッセージの構造は次の部分で構成されます。

リクエストライン:

リクエスト行にはとが请求方法含まれます。目标 URL协议版本
これらはスペースで区切られ、復帰改行 (CRLF) で終了します。

格式：Method SP Request-URI SP HTTP-Version CRLF

例: GET /index.html HTTP/1.1

リクエスト方法

GET: サーバーからリソースを取得 (または取得) するために使用されます。

POST: データをサーバーに送信 (または送信) するために使用され、通常は新しいリソースを作成するために使用されます。
PUT: 指定された URL パスにあるリソースを置換するために使用され、リソースの作成または更新に使用できます。
OPTIONS: ターゲットリソースでサポートされているリクエストメソッド、許可されたリクエストヘッダー、およびその他の情報を取得するために使用されます。
HEAD: GET リクエストと似ていますが、GET リクエストと同じ応答ヘッダー情報のみを返し、応答本文は返されません。リソースのメタデータを取得するために使用されます。
DELETE: 指定されたリソースを削除するために使用されます。
TRACE: リクエストプロセス中にリレーサーバーによって行われたメッセージの変更を追跡するために使用され、問題のデバッグやトラブルシューティングによく使用されます。
PATCH: 既存のリソースに部分的な変更を加え、リソースの一部のみを更新するために使用されます。

これら8つのリクエスト方法については、後日別記事で詳しく紹介する予定です。

URL

URL は、Uniform Resource Locator の略語で、インターネット上のリソースを識別して検索するために使用されます。URL は、プロトコル、ホスト名、ポート番号、パス、クエリパラメータ、フラグメントなどの複数の部分で構成されます。

URL の一般的な構造は次のとおりです。

[协议]://[主机名或IP地址]:[端口号]/[路径]?[查询参数]#[片段]

具体的な説明は以下の通りです。

プロトコル: HTTP、HTTPS、FTP など、ネットワークで使用される通信プロトコルを示します。
ホスト名または IP アドレス: サーバーのアドレスを指定します。これはドメイン名または IP アドレスです。
ポート番号: オプションで、サーバー上のサービスがリッスンするポート番号を指定します。指定しない場合、プロトコルのデフォルトのポート番号がデフォルトで使用されます (例: HTTP のデフォルトは 80)。
パス: サーバー上のリソースのパスまたはフォルダー構造を指定します。
クエリパラメーター: オプション。追加のパラメーターをサーバーに渡すために使用されます。キーと値のペアの形式で表され、複数のパラメーターは「&」で区切られます。
フラグメント: オプション。リソースの特定の部分を表し、通常は Web ページ内で特定のアンカーの場所に移動するために使用されます。

URL の例をいくつか示します。

https://www.example.com/index.html
http://192.168.0.1:8080/api/users?sort=asc&page=1
ftp://ftp.example.com/files/document.pdf#page=10

URL は、ブラウザーで Web ページにアクセスしたり、サーバーからデータを取得したり、API リクエストを作成したりするために使用できます。URL のさまざまな部分を解析することにより、クライアントは必要なリソースを正確に見つけて要求することができます。

RULコーディングについても後ほど別記事で別途解説します。

プロトコルのバージョン

これは分かりやすいと思いますが、HTTPに対応したバージョン番号です。

リクエストヘッダー:

リクエストヘッダーには、キーと値のペアの形式で追加のリクエスト情報が含まれており、フィールドごとに 1 行、キャリッジリターンとラインフィード (CRLF) で終了します。

格式：Header-Name: Header-Value CRLF

例：

Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

リクエストヘッダーは、リクエストの属性、期待、認証などを記述するために HTTP リクエストでサーバーに送信される追加情報です。リクエストヘッダーは名前と値の形式で表現され、HTTP リクエストのヘッダー部分に配置されます。

一般的なリクエストヘッダーをいくつか示します。

ユーザーエージェント：
- リクエストを開始したユーザーエージェント (つまり、ブラウザ、クライアントプログラムなど) を識別します。サーバーはこれを使用して、さまざまなユーザーエージェントを識別します。
受け入れる：
- クライアントが受信できる応答コンテンツタイプを指定します。通常は MIME タイプ (text/html、application/json など) を指定します。
コンテンツタイプ：
- リクエスト本体コンテンツのメディアタイプを指定します。これは、リクエスト本体データの解析方法をサーバーに指示するために使用されます。
認可：
- 基本認証のユーザー名やパスワードなど、認証に使用される資格情報。
クッキー：
- ユーザーのセッション状態を追跡するために、リクエストで送信される前にサーバーからクライアントに送信される HTTP Cookie。
参照する：
- リクエストのソース URL、つまり前のページの URL を示します。一般的に、クロスサイトリクエストフォージェリ (CSRF) を防ぐために使用されます。
コンテンツの長さ：
- リクエスト本文の長さをバイト単位で指定します。リクエスト本文のサイズをサーバーに通知するために使用されます。
キャッシュ制御：
- 応答をキャッシュできるかどうか、キャッシュの有効期間などを示すなど、キャッシュ動作を制御するために使用されます。
ホスト：
- ターゲットサーバーのホスト名とポート番号を指定します。これは、サーバーが対応する Web サイトを見つけてリクエストを処理するために使用します。

上記は一般的なリクエストヘッダーの一部にすぎませんが、実際には、さまざまな情報を渡したり、特定の機能を実装したりするために使用できるリクエストヘッダーは他にもあります。

空行:

空行は、リクエストヘッダーとリクエスト本文を区切るために使用されます。これは、要求ヘッダーの終わりを示すキャリッジリターンとラインフィード (CRLF) 文字で構成されます。

リクエスト本文:

リクエスト本文はオプションであり、特定の状況でサーバーに追加データを送信するために使用されます。
リクエスト本文は、データまたは情報をサーバーに送信するための HTTP リクエストに含まれるオプションの部分です。リクエストボディは通常、POST や PUT などのリクエストメソッドに使用されます。

リクエスト本文には、フォームデータ、JSON データ、XML データ、ファイルなど、さまざまな種類のデータを含めることができます。データの形式とエンコーディングは通常、リクエストヘッダーの Content-Type フィールドによって指定されます。

一般的なリクエスト本文の例をいくつか示します。

フォームデータ:

name=John+Doe&[email protected]

name=John+Doe&[email protected]フォームデータの例です。これは、データをキーと値のペアにエンコードする一般的な方法で、フォームの送信や URL クエリパラメーターでよく使用されます。

この例には、2 つのキーと値のペアがあります。

name=John+Doeキーがname、値がであることを示しますJohn+Doe。は+スペースの URL エンコードです。

[email protected]キーがでemail、値がであることを示します[email protected]。

このフォームデータ形式は、HTTP POST リクエスト経由で使用されるか、クエリ文字列として URL に追加されるのが一般的です。実際のアプリケーションでは、このデータをリクエスト本文の一部としてサーバーに送信できます。

JSONデータ:

{
    
    
  "name": "John Doe",
  "email": "[email protected]"
}

リクエストボディの例では、{ "name": "John Doe", "email": "[email protected]" }例の JSON データです。JSON (JavaScript Object Notation) は、構造化データを表すために使用される一般的なデータ交換形式です。

{}この例では、データ全体が中括弧で囲まれたJSON オブジェクトです。このオブジェクトには、"name"とという 2 つのプロパティが含まれています"email"。

"name": "John Doe"属性のキーと値のペアを表します。属性名は"name"、値はで"John Doe"、名前が「John Doe」であることを示します。

"email": "[email protected]"また、属性のキーと値のペアも表します。属性名は"email"、値はで"[email protected]"、電子メールが「[email protected]」であることを示します。

JSON は、Web API データ送信、構成ファイル、非構造化データの保存など、多くのシナリオで使用される汎用データ形式です。JSON データを操作する場合、通常は、対応するパーサーまたはライブラリを使用して JSON を読み取り、生成し、解析します。

XML データ:

<person>
  <name>John Doe</name>
  <email>[email protected]</email>
</person>

<person>関連するフィールドまたは属性を含む XML データのルート要素です。

<name>John Doe</name><name>値「John Doe」を持つ名前フィールドを含む要素を表します。

<email>[email protected]</email><email>値「[email protected]」を持つ電子メールフィールドを含む要素を表します。

XML は eXtensible Markup Language の略称で、構造化データを表現するために使用されます。リクエストボディまたはレスポンスボディでは、XML 形式を使用してデータを送信および保存できます。

XML では、タグを使用してデータの構造と階層関係を記述します。<person>、<name>および<email>異なるタグに属し、データの異なる部分を定義するために使用されます。

たとえば、<person>要素全体を名前フィールドと電子メールフィールドを含む人の情報オブジェクトとして考えることができます。実際のニーズに応じて、さらに多くのフィールドとデータを XML 本文に追加できます。

XML は、データ交換、構成ファイル、Web サービスなどの多くのシナリオで使用される汎用データ表現形式です。XML データを操作する場合、通常は、対応するパーサーまたはライブラリを使用して XML を読み取り、解析します。

ファイルのアップロード:

------WebKitFormBoundaryABC123
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg

<binary data>

リクエストボディの例では、------WebKitFormBoundaryABC123異なるフィールドデータの開始位置と終了位置を識別するために使用されるフォームデータの区切り文字です。

Content-Disposition: form-data; name="file"; filename="example.jpg"フィールドデータを説明するために使用されるメタデータです。ここで、

form-dataこれがフォームデータフィールドであることを示します。

name="file"フィールドの名前が「ファイル」であることを示します。

filename="example.jpg"フィールド「example.jpg」に含まれるファイルの元のファイル名を表します。

Content-Type: image/jpeg指定されたフィールドに含まれるファイルタイプはimage/jpeg、JPEG 画像ファイルタイプです。

<binary data>実際のリクエスト本文にバイナリデータ、つまり実際のファイルコンテンツ (通常はファイルアップロードシナリオ) を含める必要があることを示します。

実際にファイルをアップロードするには、<binary data>ファイルのバイナリコンテンツに置き換える必要があります。通常、これらのバイナリデータはバイト単位で存在し、ファイルの内容はファイル読み取り操作を通じてバイナリとして読み取られ、リクエスト本文の対応する部分に配置されます。

リクエスト本文の内容と形式は、特定のアプリケーションのシナリオと要件によって異なることに注意してください。リクエストを送信するとき、ニーズに応じてリクエスト本文を設定し、サーバーがリクエスト本文を正しく解析して処理できるように、リクエストヘッダーの Content-Type フィールドを明確に指定できます。

リクエストを受信すると、サーバーはリクエスト本文を解析し、アプリケーションロジックに従って対応する処理を実行します。

応答メッセージ

HTTP 応答メッセージは、クライアントがリクエストを送信した後、サーバーからクライアントに返される応答状态码、响应头合計、および响应体その他の情報を含むデータです。HTTP 応答メッセージの一般的な構造は次のとおりです。

ステータス行:

ステータス行には协议版本、响应状态码との响应状态メッセージが含まれます。例えば：

HTTP/1.1 200 OK

プロトコルのバージョン

リクエストメッセージのプロトコルバージョンと同様に、どちらも http プロトコルを使用したバージョンを示します。

レスポンスステータスコード

応答ステータスコードは、要求処理の結果を表す HTTP 応答内の値で、要求の成功、失敗、またはその他の特殊な状況を示すために使用されます。各応答ステータスコードには、特定の意味とセマンティクスがあります。

HTTP プロトコルでは、一連の標準応答ステータスコードが定義されています。次に、一般的な応答ステータスコードとその意味をいくつか示します。

1xx: 情報

情報	説明する
100 継続	サーバーはリクエストの一部のみを受信しますが、サーバーがリクエストを拒否しなくなったら、クライアントはリクエストの残りの送信を続行する必要があります。
101 スイッチングプロトコル	サーバー変換プロトコル: サーバーはクライアントの要求に従い、別のプロトコルに変換します。

2xx:成功

情報	説明する
200 OK	リクエストは成功しました (その後に GET および POST リクエストに対する応答ドキュメントが続きます)。
201 件が作成されました	リクエストが作成され、新しいリソースが作成されます。
202 承認済み	処理要求は受け付けられましたが、処理が完了していません。
203 権限のない情報	ドキュメントは正常に返されましたが、ドキュメントのコピーが使用されたため、一部の応答ヘッダーが正しくない可能性があります。
204 コンテンツがありません	新しい書類はありません。ブラウザは元のドキュメントを表示し続ける必要があります。このステータスコードは、ユーザーがページを定期的に更新し、サーブレットがユーザーのドキュメントが十分に最新であると判断できる場合に役立ちます。
205 リセット内容	新しい書類はありません。ただし、ブラウザは表示内容をリセットする必要があります。ブラウザにフォーム入力コンテンツを強制的にクリアさせるために使用されます。
206 部分的なコンテンツ	クライアントは Range ヘッダーを含む GET リクエストを送信し、サーバーがそれを完了します。

3xx: リダイレクト

情報	説明する
300 の複数の選択肢	複数の選択肢。リンクされたリスト。ユーザーはリンクを選択して目的地に到達できます。最大 5 つのアドレスが許可されます。
301 永久に移動しました	リクエストされたページは新しい URL に移動されました。
302 件見つかりました	リクエストされたページは、新しい URL に一時的に移動されました。
303 その他を見る	要求されたページは別の URL で見つかります。
304 未変更	ドキュメントは期待どおりに変更されませんでした。クライアントはバッファリングされたドキュメントを持ち、条件付きリクエストを行います (通常は、クライアントが指定された日付より新しいドキュメントのみを必要とすることを示す If-Modified-Since ヘッダーを提供します)。サーバーは、バッファされた元のドキュメントが引き続き使用できることをクライアントに伝えます。
305 プロキシを使用する	クライアントによって要求されたドキュメントは、Location ヘッダーで指定されたプロキシサーバーを通じて取得される必要があります。
306未使用	このコードは以前のバージョンで使用されていました。現在は使用されていませんが、コードはまだ保持されています。
307 一時リダイレクト	リクエストされたページは一時的に新しい URL に移動されました。

4xx: クライアントエラー

情報	説明する
400不正な要求	サーバーはリクエストを理解できませんでした。
401 不正	要求されたページにはユーザー名とパスワードが必要です。
401.1	ログインに失敗しました。
401.2	サーバーの設定によりログインが失敗します。
401.3	リソースに対する ACL 制限により、許可が取得できません。
401.4	フィルターの承認に失敗しました。
401.5	ISAPI/CGI アプリケーションの認証に失敗しました。
401.7	アクセスは、Web サーバー上の URL 承認ポリシーによって拒否されます。このエラーコードは IIS 6.0 に固有です。
402 支払いが必要です	このコードはまだ利用できません。
403禁止します	要求されたページへのアクセスは禁止されています。
403.1	実行アクセスは禁止されています。
403.2	読み取りアクセスは禁止されています。
403.3	書き込みアクセスは禁止されています。
403.4	SSLが必要です。
403.5	SSL128が必要です。
403.6	IPアドレスが拒否されました。
403.7	クライアント証明書が必要です。
403.8	サイトへのアクセスが拒否されました。
403.9	ユーザーが多すぎます。
403.10	無効な構成です。
403.11	パスワードの変更。
403.12	マッピングテーブルへのアクセスが拒否されました。
403.13	クライアント証明書が取り消されました。
403.14	ディレクトリのリストを拒否します。
403.15	クライアントのアクセス許可を超えました。
403.16	クライアント証明書が信頼できないか無効です。
403.17	クライアント証明書の有効期限が切れているか、まだ有効ではありません。
403.18	要求された URL は現在のアプリケーションプールでは実行できません。このエラーコードは IIS 6.0 に固有です。
403.19	このアプリケーションプール内のクライアントに対して CGI を実行することはできません。このエラーコードは IIS 6.0 に固有です。
403.20	パスポートのログインに失敗しました。このエラーコードは IIS 6.0 に固有です。
404 Not Found	服务器无法找到被请求的页面。
404.0	（无）–没有找到文件或目录。
404.1	无法在所请求的端口上访问Web站点。
404.2	Web服务扩展锁定策略阻止本请求。
404.3	MIME映射策略阻止本请求。
405 Method Not Allowed	请求中指定的方法不被允许。
406 Not Acceptable	服务器生成的响应无法被客户端所接受。
407 Proxy Authentication Required	用户必须首先使用代理服务器进行验证，这样请求才会被处理。
408 Request Timeout	请求超出了服务器的等待时间。
409 Conflict	由于冲突，请求无法被完成。
410 Gone	被请求的页面不可用。
411 Length Required	"Content-Length"未被定义。如果无此内容，服务器不会接受请求。
412 Precondition Failed	请求中的前提条件被服务器评估为失败。
413 Request Entity Too Large	由于所请求的实体的太大，服务器不会接受请求。
414 Request-url Too Long	由于url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种情况。
415 Unsupported Media Type	由于媒介类型不被支持，服务器不会接受请求。
416 Requested Range Not Satisfiable	服务器不能满足客户在请求中指定的Range头。
417 Expectation Failed	执行失败。
423	锁定的错误。

5xx:服务器错误

消息	描述
500 Internal Server Error	请求未完成。服务器遇到不可预知的情况。
500.12	应用程序正忙于在Web服务器上重新启动。
500.13	Web服务器太忙。
500.15	不允许直接请求Global.asa。
500.16	UNC授权凭据不正确。这个错误代码为IIS 6.0所专用。
500.18	URL授权存储不能打开。这个错误代码为IIS 6.0所专用。
500.100	内部ASP错误。
501 Not Implemented	请求未完成。服务器不支持所请求的功能。
502 Bad Gateway	请求未完成。服务器从上游服务器收到一个无效的响应。
502.1	CGI应用程序超时。
502.2	CGI应用程序出错。
503 Service Unavailable	请求未完成。服务器临时过载或宕机。
504 Gateway Timeout	网关超时。
505 HTTP Version Not Supported	服务器不支持请求中指明的HTTP版本。

一般常用的状态码

200 OK：请求成功，服务器成功处理了请求并返回响应。
201 Created：请求成功，服务器成功处理请求并创建了新资源。
400 Bad Request：请求无效，服务器无法理解或处理请求。
401 Unauthorized：未授权，请求要求身份验证。
403 Forbidden：禁止访问，服务器拒绝请求的访问权限。
404 Not Found：资源不存在，请求的资源无法找到。
500 Internal Server Error：服务器内部错误，通常是服务器在处理请求时发生了错误。
503 Service Unavailable：服务不可用，服务器当前无法处理请求，可能因为过载或维护等原因。

响应状态

响应状态是指HTTP响应中的状态行，它包含了HTTP版本、响应状态码和响应状态消息。状态行有如下的一般结构：

HTTP/1.1 200 OK

具体解释如下：

HTTP/1.1：表示所使用的HTTP协议版本。
200：表示响应状态码，指示请求成功。
OK：表示响应状态消息，提供关于响应状态码的简短描述。

响应状态码用于指示服务器对请求的处理结果，响应状态消息则为状态码提供一些解释性的描述。

HTTP协议定义了一组标准的响应状态码（例如，200、404、500等），每个状态码都有特定的含义和语义。

通过查看响应的状态码和状态消息，客户端可以了解请求的处理结果和服务器返回的状态信息，以便采取相应的处理措施。

响应头（Response Headers）：

响应头包含响应报文的各种元数据信息。每行一个头部字段。

响应头（Response Headers）是HTTP响应中包含的元数据信息，用于提供关于响应的附加信息和配置参数。响应头以名称-值的形式表示，并位于HTTP响应的头部部分。

以下是一些常见的响应头：

Content-Type：指示响应主体的媒体类型，例如text/html、application/json等。
Content-Length：指示响应主体的长度（以字节为单位）。
Server：指示服务器的软件名称和版本。
Date：指示响应的日期和时间。
Cache-Control：用于控制缓存行为，例如指示是否可以缓存响应、缓存有效期等。
Set-Cookie：向客户端设置一个HTTP Cookie。
Location：指示客户端重定向到的URL。
Expires：指示响应的过期时间。
Etag：用于标识资源的特定版本。

这只是一小部分常见的响应头，实际上还有许多其他的响应头可以用于传递不同的信息和配置。

响应头提供了关于响应的重要信息，客户端可以根据响应头做出相应的处理。例如，根据Content-Type确定如何解析和处理响应主体的内容，根据Cache-Control确定是否从缓存中获取响应等。

空行（Blank Line）：

空行用于分隔头部和响应体，由一个回车换行符组成。

响应体（Response Body）：

响应体包含服务器返回的实际数据。响应体的内容根据Content-Type指定的媒体类型而定。例如，对于HTML内容，响应体可能包含HTML标记的文本或网页；对于JSON内容，响应体可能包含JSON格式的数据。

以下是一个示例的HTTP响应报文：

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Cache-Control: no-cache

<!DOCTYPE html>
<html>
<head>
    <title>Example</title>
</head>
<body>
    <h1>Hello, World!</h1>
</body>
</html>

在实际的开发中，通过解析HTTP响应报文，可以获取服务器返回的状态码、头部信息和响应体数据，并根据需要进行处理。