[HTTP]HTTPメッセージはどんな内容を交換しますか?

5749 ワード
http-definition-guide http-message テキストリンク
HTTPメッセージフロー
どこへ流れていくの?
メッセージは一方向インバウンド方式で送信されます.
そしてstreamまで下流へ.
簡単に言えば、これは、以下に示すように、一方向にのみ流れることを意味する.
(クライアント->プロキシ->サーバ->プロキシ->クライアント)

リクエストとレスポンス
クライアントからサーバへのデータの送信を要求
サーバからクライアントにデータを送信することを応答と呼びます.
このリクエストとレスポンスは、開始行、タイトル、エンティティの本文から構成されます.
行、見出し、およびエンティティは改行で区切られます.

開始行または見出しとは異なり、本文は空であってもよいし、テキストまたはバイナリデータを含んでもよい.
リクエストメッセージ
要求メッセージの形式は次のとおりです.
<메서드> <요청 URL> <버전>
<헤더>

<엔터티 본문>
最初の行は、スペースで区切られたリクエスト行と呼ばれます.
要求ラインは、サーバがどのような操作を行うべきかを説明するために使用されます.
方法
クライアントは、サーバがリソースに対して実行する操作を望んでいます.(GET、POST、PUTなど)
  • GET
  • サーバインポート文書
  • HEAD
  • サーバは、ドキュメントヘッダのみを取得するが、エンティティ本文
    • には戻らない.
  • は、主に、リソースタイプまたはデータオブジェクトが存在するかどうか、変更されているかどうかを決定するために使用される.
  • を返すヘッダはGETと一致しなければならない(サーバはそれを保証しなければならない).
  • POST
  • サーバは、処理が必要なデータ
    • を送信する.
  • 要求本文を使用して、要求URLの名前に従って新しいドキュメントを作成するか、すでにURLがある場合は
    • に置き換える.
  • PUT
  • サーバに保存する要求メッセージ本文
  • は、入力データ(通常はHTMLフォームをサポートするために使用される)
    • を転送することを目的とする.
  • TRACE
  • メッセージがプロキシを介してサーバに到達するプロセスを追跡する
  • 主に診断に使用
  • TRACE要求は、エンティティ本文
    • を送信できません.
  • OPTIONS
  • サーバが変更できるメソッド
  • 応答プロンプトは、Allowヘッダとして使用することができる方法
    • である.
  • は、実際に
  • リソースにアクセスするのではなく、最適なリソースにどのようにアクセスするかを決定する方法をクライアントに提供する.
  • DELETE
  • サーバから文書
    • を削除する.
  • クライアントがDELETEリクエストを送信しても、必ずしも削除は保証されません.HTTP宣言により、サーバはクライアントに通知せずに要求を無視することができる.
    • このうち,GET,HEADなどの手法をセキュリティ手法と呼ぶ.これはGETまたはHEADメソッドを用いたHTTPリクエストの結果であり,サーバは何の役にも立たない.
    要求URL
    リソースへのurl.
    バージョン#バージョン#
    使用中のHTTPバージョン.
    HTTP/<메이저>.<마이너>
    これは、HTTPアプリケーションがプロトコルに従っているバージョンを相手に説明する方法です.
    応答のバージョン情報がHTTP/1.1である場合、応答はHTTP/1.1を理解できることを示す.(回答者はHTTP/1.1メッセージではありません.)
    たとえば、要求をHTTP/1.0に送信し、HTTP/1.1で応答を受信できます.
    カンマ(.)これは条件分離に基づいていると思います.
    例えば、HTTP/1.3のバージョンはHTTP/1.22より低い.3と22を比較しているので、22はもっと大きな数字です.
    見出し
    名前、コロン(:)、オプションのスペース、値、CRLFの順に表示されるゼロまたは複数のヘッダー.
    長さが長すぎる場合は、改行できます.この場合、少なくとも1つのTabまたはSpaceが必要です.
    HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
	Version 1.0
    サーバーヘッダーの値は「Test Server Version 1.0」です.
    タイトルは大きく4種類に分けられます.
    一般ヘッダー(General Headers)
  • クライアントおよびサーバ(さまざまな用途で使用可能)
    • たとえば、Dateは汎用ヘッダーです.リクエストヘッダ
  • 要求メッセージヘッダ
  • Ex.1)「関連を受け入れる」(Accept,Accept Languageなど)リーダーは、サーバに何ができるか、何がしたくないかを伝えることができます.
  • Ex.2)セキュリティヘッダの要求には、認証およびCookieが含まれる.
  • Ex.3)要求情報ヘッダ、条件ヘッダ等.
    • レスポンスヘッダ
  • クライアントに追加情報を提供するサーバ応答ヘッダ.
  • Ext)Retry-After、Set-Cookie、WWW-Authenticate、ProxyAuthenticate.
    • ソリッドヘッダ
  • HTTPメッセージエンティティのヘッダについて説明する.
  • リクエストと応答.
  • Allow、Location、コンテンツ関連(コンテンツタイプ、コンテンツ言語、コンテンツ長など)、Last Modified、Expires(キャッシュ関連).
    • エンティティ本文
    エンティティはメッセージングと考えられます.HTTPメッセージは、画像、ビデオ、HTMLドキュメント、およびソフトウェアアプリケーションを含む多くのデジタルデータを担持することができる.
    任意のデータ・ブロックが含まれます.エンティティ本文がなくても、HTTPヘッダの集合は常にCRLFで終わる必要があります.
    (場合によっては、これらのルールを守らない実施プログラムと互換性を保つために、最後のCRLFがなくてもメッセージを受け入れることができる必要がある.)
    レスポンスメッセージ
    応答メッセージのフォーマットは次のとおりです.
    <버전> <상태코드> <사유 구절>
<헤더>

<엔터티 본문>
    最初の行をレスポンス行と呼びます.すべてのフィールドはスペースで区切られています.
    実行結果のステータス情報と結果データをクライアントに返すために使用します.
    ステータスコード
    リクエスト中に何が起こったのかをクライアントに説明する数値(3ビット)コード.1番目の数字は一般分類を表します.
    (ステータスコードはMDNでかなり整理されており、単独で整理することはありません.)
    理由フレーズ
    思考文は人だけが読む.
    したがって、次の2つの文の意味はまったく異なるが、成功した同義語と見なさなければならない.
    HTTP/1.0 200 NOT OK
HTTP/1.0 200 OK
    HTTP宣言では、プライベート文の厳格なルールは提供されません.
    カスタムスタッズトーストを作成する方法
    どのようにUbuntuの正規インストールにWubiのインストールを変換するには?