この記事では、http プロトコルのフロントエンドに関する常識的な問題について説明します。興味のある方は、

http

HTTP プロトコルのフロントエンドの常識

はじめにをご覧ください: http は tcp/ に基づいてデータを送信します。 ip 通信

Notes

http はコネクションレスです: 各接続は 1 つのリクエストのみを処理します。サーバーがリクエストを処理し、クライアントからの応答を受信した後、
http メディアは独立しています。クライアントとサーバーはデータ型の処理方法を認識しており、あらゆるデータは http を使用して送信できます。クライアントリクエストには、リクエスト行、リクエストヘッダー、空行およびリクエストデータが含まれます

http リクエストメソッド

http1.0 : get、post、head HTTP プロトコルのフロントエンドの常識

http1.1 では、delete、put、connect、tarce、options の 5 つの新しいリクエストメソッドが追加されています

method
description

get Initiateある特定のリソースへのリクエストデータ処理のために指定されたリソースにデータを送信します。データはリクエスト本文に含まれます。post リクエストは、新しいリソースを作成したり、既存のリソースを変更したりするために使用されます。ただし、リターンボディがない点が異なります。応答メッセージに含まれるヘッダーを取得しますconnecthttp1.1は、接続をパイプラインメソッドに変更できるプロキシサーバー用に予約されていますオプションサーバーによってサポートされているhttpメソッドを返します特定のリソースに対して、サーバーに「*」リクエストを送信するために使用されますサーバーの機能をテストするには

	post
put	指定されたリソースに最新のコンテンツをアップロードします
delete	指定されたリソースの削除をサーバーに要求します
trace	主にテストまたは診断のためにサーバーによって受信されたリクエスト


共通ヘッダーフィールドの意味の概要	ヘッダーとメソッドは連携して、クライアントとサーバーが実行できることを決定しますcommon comon commonヘッダーは、クライアントとサーバーの両方で使用される可能性がありますヘッダーヘッダー接続
Date	は日付とタイムスタンプを提供します
MIME-Version	最後に送信されたMIMEバージョンを提供します

Trailer

メッセージ送信がチャンクを使用する場合転送エンコーディング、これを使用できます。ヘッダーは、メッセージのトレーラー部分にあるヘッダーのセットをリストします

Transfer-Encoding

は、メッセージの信頼性の高い送信を保証するために、メッセージにどのようなエンコード方式が使用されているかを受信側に伝えます。メッセージ

UpdateVia メッセージが通過する中間ノード (エージェント、ゲートウェイ) を表示します

が送信されます送信者は、新しいバージョンまたはプロトコルを使用するために「アップグレード」する必要がある可能性があります

リクエストヘッダー

リクエストメッセージに特有の、クライアントが受信を希望するデータ型などの追加情報をサーバーに提供します

リクエストの情報ヘッダー

ヘッダー	説明
Client-Ip	クライアントを実行しているマシンのIPアドレスを入力します
From	クライアントユーザーの電子メールアドレスを入力します
ホスト	のアドレスとポート番号を入力しますリクエストを受信するサーバー
Referer	現在リクエストされている URL を含むドキュメントの URL を提供します
UA-color	クライアントモニターの表示色に関する情報を提供します
UA-CPU	クライアントの CPU タイプを提供します。また、メーカー
UA-Disp	は、クライアントの表示機能に関する情報を提供します
UA-OS	は、クライアントマシンで実行されているオペレーティングシステムとバージョンを提供します
UA-Pixels	クライアントディスプレイのピクセル情報を提供します
User-Agent	は、リクエストを送信するアプリケーションの名前をサーバーに通知します

Accept header

header	説明
Accept	送信できるメディアタイプをサーバーに伝える
Accept-Charset	送信できる文字セットをサーバーに伝える
Accept-Encoding	サーバーにどのメディアタイプを送信できるかを伝える送信できるエンコード方式
Accept-Language	は、サーバーが送信できる言語を伝えます
TE	どの拡張転送エンコーディングが使用できるかをサーバーに伝えます

条件付きリクエストヘッダー

ヘッダー	説明
期待	クライアント列を許可リクエストに必要なサーバーの動作
If-Match	エンティティタグがドキュメントの現在のエンティティタグと一致する場合、ドキュメントを取得します
If-Modify-Since	指定された日付以降にリソースが変更されている場合を除き、それ以外の場合はこのリクエストを制限します
If-None-Match	エンティティタグが一致しない場合ドキュメントの現在のエンティティ、ドキュメントを取得します
If-Range	ドキュメントへの変更を許可します範囲条件付きリクエスト
If-Unmodified-Since	特定の指定された日付以降にリソースが変更されていない場合それ以外の場合は、このリクエストを制限します
範囲	サーバーが範囲リクエストをサポートしている場合は、リソースの指定されたスコープをリクエストします

セキュリティリクエストはヘッダーによって制御されます

ヘッダーは	説明します
Authorization	には、自身を認証するためにクライアントからサーバーに提供されたデータが含まれています
Cookie	クライアントはそれを使用してトークンをサーバーに送信します。これは実際のセキュリティヘッダーではありません。これはセキュリティ機能を意味します
Cookie2	は、リクエスタがサポートするCookieのバージョンを示すために使用されます

プロキシリクエストヘッダー

Header	Description
マックスフォワード	サーバーへのパス上の他のプロキシまたはゲートウェイにリクエストが転送される最大回数———— TARCE メソッドで使用されます
Proxy-Authorization	Authorization ヘッダーと同じですが、このヘッダーはプロキシで認証するときに使用されます
Proxy-Connection	Connection ヘッダーと同じですが、このヘッダーはプロキシで認証するときに使用されます

プロキシとの接続を確立するときに使用されます

応答ヘッダー

応答メッセージには、クライアントに情報を提供するための独自のヘッダーのセットがあります

応答の情報ヘッダー

Header	Description
Age	(当初から作成開始) 応答期間
Publick	サーバーがそのリソースに対してサポートするリクエストメソッドのリスト
Retry-After	リソースが利用できない場合は、この日付または時刻に再試行します
サーバー	サーバーアプリケーションソフトウェアの名前とバージョン
タイトル	HTML文書の場合、HTML文書のソースによって与えられたタイトルです
警告	理由フレーズよりも詳細な警告レポート

ネゴシエーションヘッダー

ヘッダー	説明
Accept-Ranges	このリソースのサーバーによって受け入れられるデータタイプ
さまざまな	サーバービューその他のヘッダーリストは応答を変更します。つまり、これはヘッダーリストであり、サーバーはこれらのヘッダーの内容に基づいて最適なリソースバージョンを選択し、クライアントに送信します

セキュアレスポンスヘッダー

ヘッダー	説明
Proxy-Authenticate	プロキシからクライアントへのクエリリスト
Set-Cookie	は、実際のセキュリティヘッダーではありませんが、セキュリティ機能を意味します。サーバー経由でクライアントに署名するためのセキュリティトークンをクライアントに設定します
Set-Cookie2	Set-Cookieと同様
WWW-Authenticate	サーバーからクライアントのチャレンジリストへ

エンティティヘッダー

エンティティヘッダーはエンティティボディ部分のヘッダーに使用されます

コンテンツヘッダー

Header	Description
Content-Base	相対解析時に使用されるベースURL本文内の URL
Content-Enconding	主題に対して実行される任意のエンコード方法
Content-Language	主題を理解する際に使用する最も適切な自然言語
Content-Length	サブジェクトの長さまたはサイズ
Content -Location	リソースエンティティの場所
Content-MD5	本文のMD5チェックサム
Content-Range	によって表されるリソース範囲リソース全体のこのエンティティ
Content-Type	このトピックのオブジェクトタイプ

Entity Cache Header

ET agエンティティタグこのエンティティに関連付けられています有効期限がありますエンティティは存在しません有効です。元のソースからこのエンティティの日時を再度取得します Last-Modified このエンティティが最後に変更された日時ステータス

Description

ステータスコードはクライアントです。トランザクション結果を簡単に理解する方法を提供します

100-199

ステータスコード Reason Pフレーズ 100続行プロトコルの切り替え

意味

指示クライアントのリクエストの最初の部分を受け取りました。続行してください。このステータスコードを送信した後、サーバーはリクエストを受信した後に応答する必要があります 101

サーバーがクライアントの仕様に従って、Update ヘッダーにリストされているプロトコルにプロトコルを切り替えていることを示します

200-299: 成功ステータスコード

クライアントがリクエストを送信すると、これらのリクエストは通常成功します

CreatedAcceptedNon -信頼できる情報コンテンツをリセットPartail Content応答には、Content-Range、Date、ETag または Content-Location ヘッダーが含まれている必要があります

300-399: リダイレクトステータスコード

リダイレクトステータスコードは、クライアントに、関心のあるリソースにアクセスするために代替の場所を使用するように指示するか、リソースのコンテンツの代わりに代替応答を提供するように指示します。リソースが移動された場合は、リダイレクトステータスコードとオプションの Location ヘッダーを送信して、リソースが移動されたことと、リソースが現在どこにあるかをクライアントに通知します

ステータスコード	理由フレーズ	意味
200	OK	リクエストに問題はありません。エンティティのボディ部分には、リクエストされたリソースが含まれています。
は、サーバーからのオブジェクトリクエスト(PUTなど)を作成するために使用されます。応答にはリソースの URL を作成するためのさまざまな参照が含まれている必要があります。Location ヘッダーには最も具体的な参照が含まれています。サーバーはこのステータスを送信する前にオブジェクトを作成する必要があります		202
リクエストは受け入れられましたが、サーバーは何も操作を実行していません。サーバーがリクエストを完了するという保証はありません。それは、リクエストが受け入れられたときに、それが有効であるように見えることを意味するだけです。サーバーは、エンティティの本文にリクエストのステータスの説明を含める必要があり、おそらくリクエストが完了する時期の推定も含める必要があります (または、この情報を取得できる場所へのポインタを含める)		203
エンティティヘッダーに含まれる情報は、オリジンサーバーからではなく、リソースのコピーから取得されます。この状況は、中間ノードにリソースのコピーが存在するが、それによって送信されたリソースに関連するメタ情報 (ヘッダー) が検証できない、または検証されない場合に発生します。応答メッセージにはいくつかのヘッダーとステータス行が含まれますが、エンティティ本文は含まれません。主に、新しいドキュメントに変換せずにブラウザを更新するために使用されます (式ページの更新など)		205
主にブラウザで使用される別のコード。現在のページのすべての HTML タグをクリアするようにブラウザーに指示します		206
パーツまたは範囲リクエストを正常に実行します。クライアントが特別なヘッダーを通じてドキュメントの一部または範囲を取得できることは後で説明します。このステータスコードは、範囲リクエストが成功したことを示します

301 ステータスコードは似ていますが、クライアントは一時的にリソースを見つけるために Location ヘッダーに指定された URL を使用する必要があります。今後のリソースでは古い URL を使用する必要があります

ステータスコード	理由フレーズ	意味
300	複数の選択肢	このステータスコードは、クライアントリクエストが実際に複数のリソースを指す URL である場合に返されます。たとえば、サーバー上の HTML ドキュメントに中国語版と英語版がある場合です。このコードはオプションの列とともに返されます。これにより、ユーザーはリクエスト URL が移動されたときに使用したいものを選択できます
301	永久に移動	。応答の Loaction ヘッダーにはリソースが存在する URL が含まれています
302	Found	は 301 と似ていますが、クライアントは一時的な場所のリソースを取得するために Location ヘッダーで指定された URL を使用する必要があります。今後のリクエストでは古いリソースを使用できます
303	Set Ohter	は、リソースを取得するために別の URL を使用する必要があることをクライアントに伝えます。新しい URL リソースは、応答メッセージの Location ヘッダーにあります。その主な目的は、POST リクエストの応答でクライアントを特定のリソース
304	Not Modify	に誘導できるようにすることです。クライアントは、含まれているリクエストヘッダーを通じてリクエストを条件付きにすることができます。クライアントが GET リクエストを送信し、リソースが最近変更されていない場合、このステータスコードを使用して、リソースが変更されていないことを示すことができます。このステータスコードを含む応答には、エンティティ部分を含めることはできません。
305	Use Proxy	は、リソースがプロキシ経由でアクセスする必要があることを示すために使用されます。エージェントの場所は Location によって指定されます。クライアントは特定のリソースに関連してこの応答を解析し、すべてのリクエスト、さらにはリクエストを保持しているサーバーへのすべてのリクエストがこのプロキシを通じて行われたとは想定できないことに注意することが重要です。クライアントが誤ってプロキシによるリクエストへの介入を許可すると、破壊的な動作が発生し、セキュリティ漏洩の問題が発生する可能性があります
306	未使用	未使用
307	一時リダイレクト	と一時リダイレクト

🎜🎜

400-499: クライアントエラーステータスコード

クライアントは、不正な形式のリクエストメッセージ、または最も一般的には存在しない URL など、サーバーが処理できないものを送信することがあります

ステータスコード	理由フレーズ	意味
400	Bad Request	は、クライアントに不正なリクエストが送信されたことを伝えるために使用されます
401	Unauthorized	適切なヘッダーを使用して、このヘッダー、リソースへのアクセスを取得する前に、クライアントに自身の認証を要求します
402	Payment Required	ステータスコードは未使用です
403	Forbidden	は、リクエストがサーバーによって拒否されたことを説明するために使用されます。サーバーがリクエストを拒否する理由を説明する場合、それを説明するエンティティの本文部分を含めることができます。ただし、このステータスコードは通常、サーバーが理由を説明したくない場合に使用されます。
404	Not Found	は、サーバーが要求された URL を見つけられないことを説明するために使用されます。通常、クライアントアプリケーションがユーザーに
405	メソッドが許可されていない	を表示できるように、エンティティが含まれます。このステータスコードは、リクエストされた URL でサポートされていないメソッドでリクエストが送信されたときに使用されます。要求されたリソースでどのメソッドを使用できるかをクライアントに伝えるために、Allow ヘッダーを応答に含める必要があります
406	Not Acceptable	クライアントは、どのタイプのエンティティを受け入れるかを示すパラメータを指定できます。このコードは、クライアントが受け入れた URL に一致するリソースがサーバーにない場合に使用されます。通常、サーバーには、クライアントがリクエストを満たせない理由を理解できるようにいくつかのヘッダーが含まれます
407	プロキシ認証が必要です	401と似ていますが、リソースの認証を必要とするプロキシサーバーに使用されます
408	リクエストタイムアウト	クライアントのリクエストに時間がかかりすぎる場合、サーバーはこのステータスコードを返し、接続を閉じることができます。タイムアウトはサーバーごとに異なることがよくありますが、通常はすべての正当なサーバーにとって十分な長さです。
409	Conflict	は、リクエストがリソース上で何らかの競合を引き起こした可能性があることを示すために使用されます。競合の発生が懸念される場合、サーバーはこのステータスコードを送信できます。応答には競合を説明する本文が含まれている必要があります
410	Gone	は、サーバーがかつてこのリソースを所有していた点を除いて 404 に似ています。主に Web サイトのメンテナンスに使用され、リソースが削除されたときにサーバー管理者がクライアントに通知できるようにします
411	長さが必須	サーバーがリクエストメッセージに Content-length を含めることを要求する場合に使用されます
412	Precondition Falied	クライアントがリクエスト条件を送信し、条件の 1 つが失敗した場合に使用されます。クライアントに Expect ヘッダーが含まれる場合、条件付きリクエストを送信します
413	リクエストエンティティが大きすぎます	クライアントによって送信されたエンティティ本体部分がサーバーが処理できるか、処理したいよりも大きい場合にこのステータスコードを使用します
414	リクエスト URL が長すぎます	このステータスコードは、クライアントから送信されたリクエスト内のリクエスト URL がサーバーで処理できる長さ、またはサーバーが処理できる長さよりも長い場合に使用されます
415	サポートされていないメディアタイプ	サーバーはエンティティのコンテンツタイプを理解できない、またはクライアントがエンティティのコンテンツタイプを送信することをサポートできないため、このステータスコードを使用します
416	リクエスト範囲が満たされません	リクエストメッセージは、特定の範囲のリソースをリクエストするものであり、この範囲は無効な場合、または満たされない場合は、このステータスコード
417	Expection Failed	要求された Expect リクエストには期待値が含まれていますが、このステータスコードは、サーバーがこの期待値を満たすことができない場合に使用されます。プロキシまたは他の中間プログラムが、ソースサーバーがリクエストに対して失敗の予測を生成するという明確な証拠を持っている場合、このステータスコードを送信できます

500-599: サーバーエラーステータスコード

クライアントがリクエストを送信し、サーバー自体でエラーが発生する場合があります

ステータスコード	理由フレーズ	意味
500	内部サーバーエラー	このステータスコードは、サーバーがリクエストの処理を妨げるエラーに遭遇した場合に使用されます
501	未実装	このステータスコードは、クライアントがサーバーの範囲を超えてリクエストを送信する場合に使用されます機能コード
502	不正なゲートウェイ	プロキシまたはゲートウェイとして使用このステータスコードは、サーバーが応答チェーンの次のリンクから偽の応答を受信したときに使用されます
503	サービスが利用できません	サーバーが現在リクエストに対応できないが、将来はリクエストに対応できる可能性があることを示すために使用します。サーバーがリソースがいつ利用可能になるかを知っている場合、応答に Retry-after ヘッダーを含めることができます。
504	ゲートウェイタイムアウト	はステータスコード 408 と似ていますが、ここでは応答がゲートウェイまたはプロキシであり、別のプロキシを待機していますリクエストに応答中にサーバーがタイムアウトしました
505	HTTP バージョンがサポートされていません	サーバーは、サポートできない、またはサポートしたくないプロトコルバージョンを使用したリクエストを受信しました。このステータスを使用してくださいコード。一部のサーバーアプリケーションは、プロトコルの初期バージョンをサポートしないことを選択しています