Python インターフェイスの自動テストに不可欠な基盤である http プロトコルの詳細な説明

この記事では、python に関する関連知識を提供します。主に、インターフェイス自動化テストに必要な基盤である http プロトコルに関連する問題を紹介します。一緒に見てみましょう。みんなに役立つ、役に立つ。

推奨学習: Python ビデオ チュートリアル

HTTP プロトコルと特性

HTTP プロトコルを次のように扱う場合ある人を比較したい場合、この人を深く理解したい場合は、まず相手の性格特性などを理解する必要があります。では、HTTP プロトコルにはどのような特徴があるのでしょうか?一般に、次の機能があります:

• 1. 最初の機能: HTTP プロトコルはクライアント/サーバー モードをサポートします; HTTP プロトコルは A であるためです。 TCP および IP プロトコル クラスターのメンバーは、他のメンバー と同様に、クライアントとサーバー間の通信に使用されます。 クライアント/サーバー モード は、クライアントがサーバーにリクエストを送信することによって機能します。サーバーはリクエストに応答して応答サービスを実行します。すべての HTTP リクエストはクライアントからの通信を確立し、サーバーはクライアントのリクエストを受信する前に応答を送信しません。;これは特性の 1 つです。 HTTP プロトコルの 。

---

---

• 2. 2 番目の機能: シンプルかつ高速; お客様の場合クライアントがサーバーにサービスをリクエストする場合、リクエスト メソッドとパスを渡すだけで済みます。一般的に使用されるリクエスト メソッドは GET、HEAD、POST です (これら 3 つに加えて、あまり一般的ではないメソッドもあります) HTTP プロトコルのステータスとメッセージの構成については、興味のある友人が記事で展開できます); HTTP プロトコルの単純さにより、HTTP サーバーのプログラム サイズが小さいため、通信速度は非常に高速です。

---

• 3. 3 番目の機能: Flexible; 柔軟性がある理由は、HTTP ではあらゆる種類のデータ オブジェクトの送信が可能であるためです。タイプは次によって決定されますContent-Type コンテンツ タイプをマークし、複数のコンテンツ フォーマットの送信をサポートします。 (強力な互換性)

---

• 4. 4 番目の機能: 接続なし。ここでの接続なしは接続がないことを意味するのではなく、各接続がリクエストの処理のみに制限されます。サーバーはクライアントの要求を処理し、クライアントの応答を受信した後、接続を切断します。このような設計方法を採用することで、送信時間を短縮できます。
  • 展開: 一部の学生は、ページには多数の HTTP リクエストが含まれており、このように接続と切断を行ったり来たりするのは非常に非効率的であると考えるかもしれません。実際、初期にこれを行った理由は、インターネットで発生したものであり、サーバーは世界中からの数十万または数百万の Web ページへのアクセスを同時に処理する必要があったからです。ただし、各クライアント (またはブラウザ) とサーバー間のデータ交換は非常に断続的であるため、HTTP 送信はバースト的でタイムリーです。ほとんどのチャネルは実際にはアイドル状態で、理由もなく占有されます。リソースは比較的無駄です。したがって、HTTP の設計者は、この機能を意図的に使用して、 がリクエストされたときに接続を確立し、リクエストが完了したら接続を解放するプロトコルを設計しました。 他のクライアントにサービスを提供するためにリソースをできるだけ早く解放します。何があっても、同じクライアントに対しては一度に 1 つのリクエストのみが処理されるため、HTTP プロトコルのもう 1 つの利点もわかります。 これは非常に重要です。特定の。 (*^▽^*)

---

• 5. 最後の機能: ステートレス; ステートレスとは HTTP プロトコルにはメモリがありませんトランザクション処理の機能; ステータスがないということは、後続の処理で以前の情報が必要な場合にその情報を再送信する必要があり、接続ごとに送信されるデータ量が増加する可能性があることを意味します。一方、事前の情報が必要ない場合、サーバーはより速く応答します。

---

#PS: つまり、HTTP のこれらの機能には長所と短所の両方があります。

• 利点: 利点はサーバーを解放し、各リクエスト ポイントによって不必要な接続占有が発生しないことです。
• 欠点: 欠点は、各リクエストで大量の重複したコンテンツ情報が送信されることです。
• そこで、HTTP 接続を維持するための 2 つのテクノロジー、cookie と session が登場しました。

HTTP リクエストとレスポンス

HTTP プロトコルがリクエスト アンド レスポンス モードであることがわかったので、HTTP リクエストとレスポンスについて学びましょう。HTTP プロトコルから始めましょうリクエスト。

HTTP リクエスト

Request は、インターフェイスのアドレス (一般に URL とも呼ばれる) を含む、インターフェイスに送信されるデータ オブジェクトです。 、リクエスト メソッド (get、post...)、パラメータ、リクエスト ヘッダー (Headers)、Cookie、データなど...下の図を参照してください:

---

---

---

上の図のメッセージの内容は、HTTP プロトコルの典型的な post および get リクエスト メッセージです (get のリクエスト本文は無視してください) request message, That's what I made up.):

• #1. 最初の行はリクエスト行で、リクエストメソッド、リクエストURI、HTTPが含まれます。プロトコルとバージョン (2 行目のホスト属性が結合されて完全なリクエスト URL が形成されます)

• #2. 中間部分はメッセージ ヘッダーであり、いくつかの属性が含まれています。形式は図中の 属性名:属性値

  この形式です。サーバーはメッセージ ヘッダーに基づいてクライアント情報を取得します。

• 3. 下部はメッセージ本文であり、メッセージ本文とメッセージ ヘッダーの間には空行が必要です。図のような post リクエスト では、ページ フォームのコンポーネント値が、name=admin&passwd=123456 のような同様のキーと値のペアの形式でエンコードされ、このようなフォーマットされた文字列を形成する複数のリクエストパラメータを含むデータ。 (メッセージ本文がデータを送信できるだけでなく、リクエストされた URL は get リクエスト メソッド

  の際のパラメータの受け渡しもサポートします。)

---

ここで実行できます。主な情報がリクエスト メソッド、URL、メッセージの本文を通じて送信されることがわかりました。これもHTTPの特徴の1つで、シンプルで高速であると同時に、メッセージヘッダーにも多くの情報が含まれていることがわかりますので、これらを理解しておいてください。 HTTPプロトコルのステータスとメッセージの構成については、末尾のリクエストヘッダメッセージを参照してください。

---

HTTP レスポンス

HTTP リクエストについては理解できたので、レスポンスを見てみましょう。以下の図を参照してください:

---

応答メッセージのスタイルから、要求メッセージと似ていることがわかります。また、3 つの部分に分かれています。 : リクエストラインはレスポンスラインに対応し、リクエストヘッダはレスポンスヘッダに対応し、リクエストボディはレスポンスボディに対応します。

• #1. 応答行は、メッセージ プロトコル バージョンと応答ステータス コードの 2 つの部分に分かれています。
• 2. 応答ヘッダーは、サーバーの種類、対応するデータ型の応答時間などの複数のパラメーターにも分割されます。
• 3. 応答本文は本当に必要なものであり、リクエストの最終的な戻り内容です。このコンテンツは主に解析されます。たとえば、ページがリクエストされた場合、リクエストによって返される応答は比較的大きな HTML
になります。

---

HTTP リクエスト メソッドの分析

詳細については、記事「HTTP プロトコルのステータスとメッセージの構成」の HTTP リクエスト メソッド

を参照してください。 。

GET メソッド

GET メソッド は、URI

で識別されたリソースへのアクセスを要求するために使用されます。指定されたリソースはサーバーによって解析されます応答の内容を返します。 (下の図を参照)

---

---

#PSOT メソッド

POST メソッド および GET メソッド この関数は同様で、一般にエンティティの本文を送信するために使用されます。主な目的は応答本文の内容を取得することではなく、フォーム データを WEB サーバーに提供すること、特に大量のデータ バッチを提供することです。

POST メソッド は、実際には GET メソッド のいくつかの欠点を克服しています。POST リクエストを通じて、データは URL リクエストの一部ではありません。 WEBサーバーに標準データ形式として渡されるため、データの機密性が保てず、データ量が制限されるというGETメソッドの欠点も克服されます。

---

---

次に、あまり一般的ではない方法をいくつか紹介します。

PUT メソッド

• #クライアントからサーバーに転送されたデータは、指定されたドキュメントのコンテンツを置き換えます。
• PUT メソッドと POST メソッドの最大の違いは、PUT は冪等であるのに対し、POST は冪等ではないことです。したがって、転送リソースとして PUT メソッドを使用することが多くなります。
• PUT メソッドを有効にするには、アクセス許可の制御が必要です。そうでないと、悪意のあるペイロードを含む攻撃スクリプトがサーバーに送信されるなど、特定のセキュリティ リスクが発生します。

HEAD メソッド

• HEAD メソッドは GET メソッドとほぼ同じですただし、HEAD メソッドはメッセージ ヘッダーを要求するだけであり、返される応答にはヘッダーを取得するために使用される特定のコンテンツはありません。

DELETE メソッド

• 指定されたリソースの削除、つまりファイルの削除をサーバーに要求します。 (通常、このメソッドの権限はサーバーによって制御されます。そうでないと、重大なセキュリティ ホールが発生します。)

OPTIONS メソッド

• が使用されます。リクエストをクエリする URI で指定されたリソースでサポートされるメソッドは、リクエストされた URL がサポートできるメソッド を問い合わせます。

---

この方法は実際の業務で使用されることはほとんどなく、セキュリティ分野の攻撃者やペネトレーション テスト エンジニアによってよく使用されます。コレクション。

---

TRACE メソッド

は、主にテストまたは診断のために、サーバーが受信したリクエストをエコーするために使用されます。 (一般的には使用されません)
• は、セキュリティ分野のクロスサイト攻撃でよく使用されます。

CONNECT メソッド

クライアントによって要求されたリソースとの双方向通信チャネルを開くため、トンネルを構築するためにより頻繁に使用されます。 。 （プロキシを使用する場合の方法です）

HTTPステータスコードの詳しい説明

HTTPステータスコード

ブラウザを使用して行う場合WEB を送信する Web ページが配置されているサーバーがリクエストを送信するとき、サーバーがリクエストを受信して​​応答するとき。ブラウザは Web ページを受信して​​表示し、Web ページが配置されているサーバーは、ブラウザでのリクエストに応答するための HTTP ステータス コードを含むサーバー ヘッダーを返します。

HTTP ステータス コードの英語名は HTTP Status Code です。

以下は一般的な HTTP ステータス コードです。

200 - リクエスト成功
• 301 - リソース (Web ページなど) は別の URL
• # に永続的に転送されます##404 - 要求されたリソース (Web ページなど) が存在しません
• 500 - 内部サーバー エラー

HTTP ステータス コード分類

---

Category##1**情報、サーバーはリクエストを受信します要求者は操作の実行を続行する必要があります2** 成功、操作は正常に受信され、処理されました 3**再指示されました。リクエストを完了するにはさらにアクションが必要です。4**クライアント エラー。リクエストには構文が含まれています。エラーが発生したか、リクエストを完了できません5**サーバー エラー、サーバーがリクエストを処理中にエラーが発生しました

---

HTTP ステータス コード テーブル

Description

##100Continue101上位レベルのプロトコルにのみ切り替えることができます。たとえば、新しいバージョンの HTTP プロトコルに切り替えることができます 200201#202AcceptedAccepted。リクエストは受け入れられましたが、処理されていません非権限情報コンテンツなしコンテンツをリセットこのリターン コードを使用すると、ブラウザのフォーム フィールド部分コンテンツ複数の選択肢#301永久に移動しました。要求されたリソースは新しい URI に永続的に移動されました。返される情報には新しい URI が含まれ、 ブラウザは自動的に新しい URI にリダイレクトされます。今後の新しいリクエストでは、302 Temporarily Moved の代わりに新しい URI を使用する必要があります。 301と同じですね。ただし、リソースは一時的にのみ移動されます。クライアントは、他のアドレスを表示するには、元の URI##303See Other を引き続き使用する必要があります。 301と同じですね。 GET リクエストと POST リクエストを使用して、304未変更未変更を表示します。要求されたリソースは変更されていません。サーバーがこのステータス コードを返した場合、リソースは返されません。通常、クライアントは、指定された日付以降に変更されたリソースのみを返したいことを示すヘッダーを提供することで、アクセスされたリソースを キャッシュします。プロキシ未使用非推奨の HTTP ステータス コード307一時的なリダイレクト一時的なリダイレクト。 302と同じですね。 GET リクエストのリダイレクトを使用します#リクエストにはユーザー認証が必要です#405メソッドは許可されていませんクライアント リクエストのメソッドは禁止されています406受け入れられませんサーバーは、クライアントによって要求されたコンテンツ特性に基づいて要求を完了できません ##407 408 409410Web サイト デザイナーは、301 コードを通じてリソースの新しい場所を指定できます 411412413 接続を閉じることがあります。サーバーが一時的に処理できないだけの場合は、Retry-After 応答メッセージ #414Request-URI Too Largeサポートされていないメディア タイプリクエストされた範囲が満たされません#クライアントによってリクエストされた範囲が無効です417Expectation Failedサーバーは Expect リクエスト ヘッダー情報を満たすことができません500内部サーバー エラーサーバー内部エラー、リクエストを完了できません501実装されていませんサーバーは、要求された機能があり、要求を完了できません502不正なゲートウェイゲートウェイまたはプロキシとして機能するサーバーがリモートから無効な要求を受信しましたサーバー#過負荷またはシステムメンテナンスのため、サーバーは一時的にクライアントのリクエストを処理できません。遅延の長さは、サーバーの Retry-After ヘッダー情報に含めることができます。ゲートウェイとして機能するか、プロキシ サーバーが時間内にリモート サーバーからのリクエストを取得できませんでした505HTTP バージョンがサポートされていませんサーバー要求された HTTP プロトコルのバージョンをサポートしていないため、処理を完了できません Python ビデオ チュートリアル

ステータス コード	英語名	中国語の説明
	＃＃＃続く。クライアントは、リクエスト
プロトコルの切り替え	プロトコルの切り替えを続行する必要があります。サーバーはクライアントの要求に基づいてプロトコルを切り替えます。
OK	リクエストは成功しました。通常、GET および POST リクエストに使用されます。
Created	が作成されました。新しいリソースのリクエストと作成が正常に完了しました
		#203
非権限情報。リクエストは成功しました。ただし、返されたメタ情報は元のサーバー上にあるのではなく、コピー		204
コンテンツがありません。サーバーは正常に処理されましたが、コンテンツが返されませんでした。 Web ページを更新せずに、ブラウザーが現在のドキュメントを表示し続けるようにします。		205
コンテンツをリセットします。サーバーの処理は成功し、ユーザー端末 (ブラウザなど) はドキュメント ビューをリセットする必要があります。		206
部分コンテンツをクリアできます。サーバーは GET リクエストの一部を正常に処理しました。		300
複数の選択肢。要求されたリソースには複数の場所を含めることができるため、ユーザー端末 (例: ブラウザ) の選択に対してリソースの特性とアドレスのリストを返すことができます (例: ブラウザー)		永久に移動しました
		Found
プロキシを使用します。要求されたリソースにはプロキシ経由でアクセスする必要があります		306
	#401	Unauthorized
##402	支払いが必要です	将来の使用のために予約されています
403	禁止	サーバーは要求側クライアントからの要求を理解します、しかし、このリクエストの実行は拒否されました
404	Not Found	サーバーは、クライアントのリクエストに基づいてリソース (Web ページ) を見つけることができません。このコードを使用すると、Web サイト設計者は次のことができます。「要求したリソースが見つかりません」パーソナリティ ページを設定します
プロキシ認証が必要です	リクエストには 401 と同様にプロキシ認証が必要ですが、リクエスタは承認にプロキシを使用する必要があります
リクエストのタイムアウト	サーバーはクライアントから送信されたリクエストを待機しすぎたため、タイムアウトになりました
競合	サーバーは、クライアントの PUT リクエストを完了するときにこのコードを返す可能性があります。サーバーがリクエストを処理したときに競合が発生しました。
Gone	クライアントからリクエストされました リソースはもう存在しません。 410 は 404 とは異なります。リソースが完全に削除されている場合は、410 コードを使用できます。
Length Required	サーバーは、Content-Length なしではクライアントから送信されたリクエスト情報を処理できません
Precondition失敗	クライアント要求情報の前提条件エラー
要求エンティティが大きすぎます	サーバーは要求されたエンティティを処理できません。大きすぎるため、リクエストは拒否されます。クライアントからの継続的なリクエストを防ぐために、サーバーは
## が含まれます。 #要求された URI が長すぎるため (URI は通常 URL)、サーバーは処理できません		415
サーバーは処理できませんリクエストに添付されたメディア形式		416
	503	サービスが利用できません
	504	ゲートウェイ タイムアウト
	推奨学習:

以上がPython インターフェイスの自動テストに不可欠な基盤である http プロトコルの詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。