HTTPメッセージ

1.メッセージ・フロー

インバウンドとアウトバウンド:メッセージを1台のサーバに移動するのはインバウンドであり、すべての処理が完了した後、メッセージはユーザーエージェントに戻ってアウトバウンドである.

下りと上り:すべてのメッセージが下りに流れます.メールの送信先は受信者の上流です.

2.メッセージ構文

メッセージは、開始行、タイトル、および本文の3つのセクションで構成されます.開始行の説明これはメッセージで、タイトルバーには属性が含まれ、本文にはデータが含まれています.各行は改行文字列(CRLF)で終わります.

リクエストメッセージ

<메서드> <요청_URL> <버전>
<헤더>

<엔터티_본문>

レスポンスメッセージ

<버전> <상태_코드> <사유_구절>
<헤더>

<엔터티_본문>

3.方法

クライアントは、サーバがリソースに対して実行する操作を望んでいます.
メソッド説明メッセージは、文書を本明細書GETサーバにインポートする.HEADサーバは、ドキュメントのタイトルのみをインポートします.POSTサーバは、処理が必要なデータを送信します.ある場合は、要求メッセージの本文をPUTサーバに保存します.はい、TRACEメッセージがエージェントを介してサーバに到達するプロセスを追跡します.OPTIONSサーバがどのような方法を実行できるかを確認します.DELETEサーバからドキュメントを削除します.

3.1. PUTとPOST

PUTとPOSTの違いはIdempotentの概念を導入する必要がある.Idempotentはべき乗などの法則と呼ばれ,同じ演算を何度も繰り返すと同じ値が得られる.POSTは、クライアントがリソースの場所を指定していない場合にリソースを作成するための演算であり、有効ではありません.たとえば、生成されたItemのエンティティ本文が/itemに送信され、演算が実行されると、/item/1で新しいリソースが生成され、/item/2などの他の場所で新しいリソースが作成される場合があります.逆に、PUTはリソースの場所を明確に指定し、リクエストを送信してキャンセルします.例えば、同じItemを生成したエンティティ本文をitem/3に送信すれば、何度実行しても同じ結果が得られることが保証される.

3.2. TRACE Loopback

TRACEは、宛先サーバでのフォールバック診断の開始を要求する.リクエスト送信の最後のステップでは、サーバは受信したリクエストメッセージを本明細書に挿入してTRACE応答に戻ります.クライアントは、宛先サーバとの間のすべてのHTTPアプリケーションの要求/応答チェーンを追跡して、送信されたメッセージが破損または変更されたかどうかを判断します.もしそうであれば、どのような変更が発生しますか.

3.3. 拡張メソッド

拡張メソッドは、HTTP/1.1仕様で定義されていないメソッドです.HTTPは必要に応じて拡張することを目的としているため、新しい機能を追加しても、過去に実装されたソフトウェアにエラーが発生することはありません.

4.ステータスコード

リクエストで発生した3桁の数を説明します.

4.1. 情報(100～109)

情報性状態コードはHTTP/1.1に導入されている.それらは比較的新しいもので、複雑な挑戦に耐える価値があるかどうか.

4.2. 成功(200-299)

サーバには、対応する成功を表し、異なるタイプのリクエストに対応するステータスコードのセットがあります.
ステータスコードは、200個のリクエストが正常であることを意味します.エンティティ本文には、要求されたリソースが含まれています.201オブジェクトの生成を要求するために使用されます.202要求は受け入れられましたが、サーバはまだ操作を実行していません.203に含まれる情報は、元のサーバではなく、リソースのコピーから取得されます.204応答メッセージには、タイトルとステータスラインが含まれています.本文は含まれません.

4.3. リダイレクト(300~399)

リダイレクトステータスコードは、クライアントが関心を持っているリソースに異なる場所を使用するか、リソースの内容ではなく、他の代替応答を提供することを示します.
ステータスコードとは、300個のクライアントが同時に複数のリソースを指すURLを要求することである.リソースのリストを返します.301に要求されたURLが移動されたときに使用します.302に要求されたURLが一時的に移動されたときに使用します.303リソースは、他のURLからインポートする必要があることを示すために使用されます.304に要求されたリソースが最近変更されていない場合、これは、リソースが変更されていないことを意味する.305リソースは、プロキシを介してアクセスする必要があることを示すために使用される.307要求されたURLが一時的に移動されたときに使用される.
上記の表では、302、303、307のステータスコードの間に冗長性があることに気づくかもしれません.これらのステータスコードの使用方法は、主にHTTP/1.0およびHTTP/1.1アプリケーションがこれらのステータスコードを処理する方法が異なるため、わずかに異なる.
HTTP/1.0では、サーバは、POST要求に応答してGET要求を発行するために302ステータスコードを送信することができる.これは一時的なリダイレクトステータスコードと同様であり,混乱をもたらす.したがって、HTTP/1.1は、302状態コードではなく303状態コードを一時的なリダイレクトに使用することを要求する.サーバは、302ステータスコードをHTTP/1.0クライアントに保持して使用することができる.最終的に、サーバは、クライアントHTTPバージョンを確認して、応答を復元するのに最適なリカバリステータスコードを選択する必要があります.

4.4. クライアントエラー(400～499)

クライアント・サーバが処理できないコンテンツがたまに送信されます.
ステータスコードは、400個のクライアントが誤った要求を発行したことを示す.401リソースを取得する前に、クライアントによる自己検証を要求する応答および対応するヘッダが返される.サーバに403要求の拒否を通知するために使用される.404サーバは、要求されたURLを見つけることができない.このオプションを有効にします.405要求のURLについては、要求がサポートされていないメソッドである場合に使用します.408クライアントの要求が完了するのに時間がかかりすぎる場合、サーバはこのステータスコードを使用して応答し、接続を切断できます.

4.5. サーバエラー(500～599)

クライアントが正しい要求をしても、サーバ自体にエラーが発生することがあります.
ステータスコードとは、500台のサーバが要求を処理できないエラーに遭遇した場合に使用されます.502台のクライアントがサーバの能力を超えた要求を発行した場合に使用されます.503現在、サーバは要求を処理できませんが、後で使用できる場合があります.504は他のサーバに要求を送信し、応答を待っています.Outが発生した場合は、それを使用します.505サーバがプロトコルバージョンでサポートされていないか、サポートされたくないリクエストを受信した場合は、それを使用します.

5.タイトル

ヘッダとメソッドは、クライアントとサーバが何をしているかを決定するために使用されます.名前、コロン、オプションのスペース、値、CRLFの順に表示されるタイトルの数は0を超えています.

通常ヘッダ:要求と応答が表示されます.

要求タイトル:要求の追加情報を提供する.

応答ヘッダ:応答に関する追加情報を提供する.

エンティティヘッダー:本文のサイズ、コンテンツ、またはリソース自体を説明します.

拡張ヘッダー:説明で定義されていない新しいヘッダー.

6.ソース

[HTTP完全ガイド-Webがどのように動作するか]-プログラミングサイト