Httpプロトコルは、サーバーと対話するための多くのメソッドを定義します。最も基本的なものは、GET、POST、PUT、およびDELETEの4つのタイプです。URLアドレスはネットワーク上のリソースを記述するために使用され、HTTPのGET、POST、PUT、およびDELETEは、このリソースのチェック、変更、追加、および削除の4つの操作に対応します。最も一般的な操作はGETとPOSTです。 。GETは通常、リソース情報の取得/クエリに使用され、POSTは通常リソース情報の更新に使用されます。
1.HTTPヘッダー情報の解釈
HTTPヘッダーフィールドには、一般ヘッダー、要求ヘッダー、応答ヘッダー、エンティティヘッダーの4つの部分が含まれます。各ヘッダーフィールドは、ドメイン名、コロン（:)、およびフィールド値で構成されます。
一般ヘッダー：クライアントとサーバーの両方で使用できるヘッダーであり、クライアント、サーバー、およびその他のアプリケーション間で、Dateヘッダーなどの非常に便利な一般機能を提供できます。
リクエストヘッダー：リクエストメッセージに固有です。Acceptヘッダーなど、クライアントが受信するデータの種類など、サーバーにいくつかの追加情報を提供します。
応答ヘッダー：クライアントは、サーバーヘッダーなど、カスタマーサービスが対話しているサーバーのタイプなどの情報を提供すると便利です。
エンティティヘッダー：エンティティ本体の処理に使用されるヘッダーを参照します。たとえば、エンティティヘッダーを使用して、Content-Typeヘッダーなどのエンティティ本体のデータタイプを記述することができます。
HTTP一般ヘッダー
一般ヘッダーフィールドには、要求メッセージと応答メッセージの両方でサポートされるヘッダーフィールドが含まれます。一般ヘッダーフィールドには、キャッシュヘッダーCache-Control、Pragma、および情報ヘッダーConnection、Date、Transfer-Encoding、Update、Viaが含まれます。
1、キャッシュ制御
Cache-Controlは、要求と応答が続くキャッシュメカニズムを指定します。要求メッセージまたは応答メッセージにCache-Controlを設定しても、別のメッセージ処理のキャッシュ処理は変更されません。リクエストのキャッシュ命令には、no-cache、no-store、max-age、max-stale、min-fresh、only-if-cachedが含まれ、応答メッセージの命令には、public、private、no-cache、no-store、 no-transform、must-revalidate、proxy-revalidate、max-age。各メッセージの指示の意味は次のとおりです。
no-cache：要求または応答メッセージをキャッシュできないことを示します。実際には、ローカルキャッシュに保存できますが、元のサーバーでの鮮度検証の前に、キャッシュがクライアントに提供することはできません。
no-store：機密情報が含まれている可能性があるため、キャッシュはドキュメントのすべてのトレースをストレージからできるだけ早く削除する必要があります。
max-age：キャッシュは、キャッシュ時間がmax-ageの指定された秒より長いドキュメントを返すことはできません。指定された秒を超えない場合、ブラウザーは対応する要求をサーバーに送信せず、データはキャッシュから直接返されます。この期間が過ぎると、サーバーはさらに送信されます。新しいデータを返すか、それともキャッシュによって提供されるかを決定します。max-staleコマンドも同時に送信された場合、使用期間が有効期限を超える可能性があります。
min-fresh：ドキュメントは、少なくとも指定された秒数の間、新鮮に保つ必要があります。また、鮮度の有効期間が現在のAgeとmin-freshの値の合計よりも大きいキャッシュされたオブジェクトが受け入れられます。
max-stale：クライアントが期限切れの応答メッセージを受信できることを示します。max-staleメッセージの値が指定されている場合、クライアントは、期限切れであるが指定された値内の応答メッセージを受信できます。
only-if-cached：コピーがキャッシュに存在する場合にのみ、クライアントはコピーを取得します。
パブリック：応答を任意のキャッシュ領域でキャッシュでき、キャッシュされたコンテンツを使用して任意のユーザーに応答できることを示します。
プライベート：単一ユーザーの応答メッセージの全体または一部を共有キャッシュで処理できず、キャッシュされたコンテンツは、以前にコンテンツを要求したユーザーへの応答にのみ使用できることを示します。
2、プラグマ
Pragmaヘッダーフィールドは、実装固有の命令を含むために使用されます。最も一般的に使用されるのはPragma：no-cacheです。HTTP / 1.1プロトコルでは、その意味はCache-Control：no-cacheと同じです。
3、接続
接続は、永続的な接続が必要かどうかを示します。サーブレットがここで値を「Keep-Alive」と見なす場合、またはリクエストがHTTP 1.1を使用することを確認する場合（HTTP 1.1はデフォルトで永続的な接続です）、ページに複数の要素が含まれている場合（HTTP 1.1はデフォルトで永続的な接続です）、永続的な接続を利用できます。 Applet、picture）、ダウンロードに必要な時間を大幅に短縮します。これを実現するには、サーブレットが応答でContent-Lengthヘッダーを送信する必要があります。これを実現する最も簡単な方法は、最初にコンテンツをByteArrayOutputStreamに書き込み、次にコンテンツが正式に書き込まれる前にそのサイズを計算することです。
閉じる：この要求への応答が完了したら切断し、この接続に対する後続の要求を待たないようにWEBサーバーまたはプロキシサーバーに指示します。
キープアライブ：この要求への応答が完了した後も接続を維持し、この接続に対する後続の要求を待つようにWEBサーバーまたはプロキシサーバーに指示します。
Keep-Alive：ブラウザが接続の維持を要求した場合、ヘッダーは、Keep-Alive：300のように、WEBサーバーが接続を維持すると予想される時間（秒単位）を示します。
4、日付
日付ヘッダーフィールドは、メッセージが送信された時刻を示します。応答の鮮度を評価するときにキャッシュが使用されるため、サーバー応答にはこのヘッダーを含める必要があります。時刻の記述形式はRFC822で定義されています。たとえば、Date：Mon、2001年12月31日04：25：57GMTです。日付で記述された時刻が世界標準を表す場合、現地時間に変換するときは、ユーザーのタイムゾーンを知る必要があります。
5、転送エンコーディング
WEBサーバーは、応答メッセージ本文（メッセージ本文内のオブジェクトではない）をエンコードする方法を示します。たとえば、チャンク化されているかどうかなどです。例：Transfer-Encoding：chunked
6、アップグレード
完全に異なる可能性のある別のプロトコルを指定できます。たとえば、HTTP / 1.1クライアントは、値が「HTTP / 1.1」のUpdateヘッダーを含むHTTP / 1.0要求をサーバーに送信して、クライアントがサーバーをテストできるようにすることができます。 HTTP / 1.1も使用していますか？
7、経由
クライアントからOCSまたは反対方向への応答が通過したプロキシサーバーと、それらが要求の送信に使用したプロトコル（およびバージョン）をリストします。
クライアントリクエストが最初のプロキシサーバーに到着すると、サーバーは送信されたリクエストにViaヘッダーを追加し、独自の関連情報を入力します。次のプロキシサーバーが最初のプロキシサーバーからリクエストを受信すると、自分で送信したリクエストに前のプロキシサーバーのリクエストのViaヘッダーをコピーし、自分の関連情報を後ろに追加します。OCSは、最後のプロキシサーバーのリクエストを受信すると、Viaヘッダーをチェックします。リクエストがたどったルートを知ってください。例：経由：1.0 236-81.D07071953.sina.com.cn：80（squid / 2.6.STABLE13）
HTTPリクエストヘッダー
リクエストヘッダーは、リクエストの送信者または送信者、リクエストの発信元、またはクライアントの設定と機能を示すために使用されます。サーバーは、要求ヘッダーで指定されたクライアント情報に基づいて、クライアントにより良い応答を提供しようとすることができます。リクエストヘッダーフィールドには、Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Rangeのフィールドを含めることができます。 、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。リクエストヘッダーフィールドの拡張には、両方の通信パーティがサポートする必要があります。サポートされていないリクエストヘッダーフィールドがある場合、通常はエンティティヘッダーフィールドとして扱われます。
8、受け入れる
WEBサーバーに、受け入れるメディアタイプ、/は任意のタイプ、type / *はこのタイプ、タイプ/サブタイプのすべてのサブタイプを意味することを伝えます。
9、Accept-Charset
ブラウザは、受信できる文字セットをサーバーに通知します。
10、Accept-エンコーディング
ブラウザは、受信するエンコード方式を宣言します。通常は、圧縮方式、圧縮をサポートするかどうか、およびサポートする圧縮方式（gzip、deflate）を指定します。
11、Accept-Language
ブラウザは、受信した言語を宣言します。言語と文字セットの違い：中国語は言語であり、中国語にはbig5、gb2312、gbkなどの複数の文字セットがあります。
12、承認
クライアントは、WEBサーバーからWWW-Authenticate応答を受信すると、このヘッダーを使用して、独自の認証情報でWEBサーバーに応答します。
13、If-Match
オブジェクトのETagが変更されていない場合、実際には、要求されたアクションを実行してドキュメントを取得する前に、オブジェクトが変更されていないことを意味します。
14、If-None-Match
オブジェクトのETagが変更された場合、実際には、要求されたアクションが実行されてドキュメントが取得される前に、オブジェクトも変更されたことを意味します。
15、If-Modified-Since
要求されたオブジェクトがヘッダーで指定された時間後に変更された場合、要求されたアクション（オブジェクトの返却など）が実行されます。それ以外の場合、コード304が返され、オブジェクトが変更されていないことをブラウザーに通知します。例：If-Modified-Since：Thu、10 Apr 2008 09:14:42 GMT
16、If-Unmodified-Since
ヘッダーで指定された時間が経過しても要求されたオブジェクトが変更されていない場合、要求されたアクション（オブジェクトの返却など）が実行されます。
17、If-Range
ブラウザは、要求したオブジェクトが変更されていない場合は欠落している部分を提供し、オブジェクトが変更されている場合はオブジェクト全体を提供することをWEBサーバーに通知します。ブラウザは、要求されたオブジェクトのETagまたは認識している最終変更時刻をWEBサーバーに送信して、オブジェクトが変更されたかどうかを判断できるようにします。常にレンジヘッドと一緒に使用してください。
18、範囲
ブラウザ（Flashgetマルチスレッドダウンロードなど）は、オブジェクトのどの部分をフェッチするかをWebサーバーに通知します。例：範囲：bytes = 1173546
19、プロキシ認証
プロキシサーバーはブラウザーに応答し、プロキシ認証情報を提供するように要求します。
20、プロキシ認証
ブラウザはプロキシサーバーの認証要求に応答し、独自のID情報を提供します。
21、ホスト
クライアントは、アクセスするWEBサーバーのドメイン名/ IPアドレスとポート番号を指定します。ホストなど：rss.sina.com.cn
22、リファラー
ブラウザは、現在のリクエストでURL / URLを取得したWebページのURLをWEBサーバーに示します。例：参照元：http：//www.ecdoer.com/
23、ユーザーエージェント
ブラウザはそのID（ブラウザの種類）を示します。例：ユーザーエージェント：Mozilla / 5.0（Windows; U; Windows NT 5.1; zh-CN; rv：1.8.1.14）Gecko / 20080404 Firefox / 2.0.0.14
HTTP応答ヘッダー
応答ヘッダーは、応答の送信者、応答者の機能、さらには応答に関連する特別な指示など、クライアントにいくつかの追加情報を提供します。これらのヘッダーは、クライアントが応答を処理し、将来、より適切な要求を行うのに役立ちます。応答ヘッダードメインには、Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticateが含まれます。応答ヘッダーフィールドの拡張には、両方の通信パーティがそれをサポートする必要があります。サポートされていない応答ヘッダーフィールドがある場合、通常はエンティティヘッダーフィールドとして扱われます。
24歳
プロキシサーバーは、独自のキャッシュエンティティを使用して要求に応答するときに、このヘッダーを使用して、エンティティが作成されてからの経過時間を示します。
25、サーバー
WEBサーバーは、それがどのソフトウェアとバージョンであるかを示します。例：サーバー：Apache / 2.0.61（Unix）
26、Accept-Ranges
WEBサーバーは、エンティティの一部（ファイルの一部など）を取得する要求を受け入れるかどうかを示します。bytes：受け入れることを意味し、none：受け入れないことを意味します。
27、変化する
WEBサーバーは、このヘッダーの内容を使用して、この応答で返されたオブジェクトを使用して後続の要求に応答できる条件をキャッシュサーバーに通知します。ソースWEBサーバーが最初の要求メッセージを受信した場合、その応答メッセージヘッダーは次のとおりです。Content-Encoding：gzip; Vary：Content-Encoding、その後、キャッシュサーバーは後続の要求メッセージのヘッダーを分析し、Accept-をチェックします。エンコード、前の応答のVaryヘッダーの値と一致しているかどうか、つまり、同じコンテンツエンコード方法を使用して、キャッシュサーバーが独自のキャッシュに圧縮されたエンティティで解凍する機能を持たないブラウザーに応答しないようにするかどうか。例：Vary：Accept-Encoding。
HTTPエンティティヘッダー
エンティティヘッダーは、オブジェクトタイプに関する情報から、リソースに使用できるさまざまな効果的な要求メソッドまで、エンティティとそのコンテンツに関する大量の情報を提供します。つまり、エンティティヘッダーは、受信者に何を処理しているかを伝えることができます。要求メッセージと応答メッセージの両方にエンティティ情報を含めることができます。エンティティ情報は通常、エンティティヘッダーフィールドとエンティティで構成されます。エンティティヘッダーフィールドには、エンティティに関する元の情報が含まれます。エンティティヘッダーには、情報ヘッダーAllowとLocation、およびコンテンツヘッダーContent-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-が含まれます。 Range、Content-Type、キャッシュヘッダーEtag、Expires、Last-Modified、extension-header。
28、許可する
サーバーがサポートするリクエストメソッド（GET、POSTなど）。
29、場所
クライアントがドキュメントを抽出するためにどこに行くべきかを示します。これは、リソースの場所（URL）の受信側を見つけるために使用されます。通常、場所は直接設定されませんが、HttpServletResponseのsendRedirectメソッドを介して設定されます。このメソッドは、ステータスコードも302に設定します。
30、コンテンツベース
本文の相対URLを解析するときに使用されるベースURL。
31、コンテンツエンコーディング
WEBサーバーは、応答でオブジェクトを圧縮するために使用する圧縮方法（gzip、deflate）を示します。例：Content-Encoding：gzip
32、コンテンツ言語
WEBサーバーは、主題を理解するときに使用するのに最適な自然言語をブラウザーに指示します。
33、コンテンツの長さ
WEBサーバーは、応答するオブジェクトの長さまたはサイズをブラウザーに通知します。例：Content-Length：26012
34、コンテンツ-場所
リソースの実際の場所。
35、コンテンツ-MD5
本体のMD5チェックサム。
36、コンテンツ範囲
エンティティヘッダーは、エンティティ全体の一部の挿入位置を指定するために使用され、エンティティ全体の長さも示します。サーバーがクライアントに部分的な応答を返す場合、応答の範囲とエンティティ全体の長さを記述する必要があります。一般的な形式：Content-Range：bytes-unitSPfirst-byte-pos-last-byte-pos / entity-legth。たとえば、送信ヘッダーの500バイトのサブフィールドの形式は次のとおりです。Content-Range：bytes0-499 / 1234 httpメッセージにこのセクションが含まれている場合（たとえば、範囲要求への応答または一連の重複する要求）、Content-Range送信範囲を示し、Content-Lengthは実際に送信されたバイト数を表します。
37、コンテンツタイプ
WEBサーバーは、応答するオブジェクトのタイプをブラウザーに通知します。例：Content-Type：application / xml
38、Etag
オブジェクト（URLなど）のタグ値です。htmlファイルなどのオブジェクトに関しては、変更してもEtagは変更されません。したがって、ETagの役割は、主にWEBの場合、Last-Modifiedの役割と同様です。サーバーは、オブジェクトが変更されたかどうかを判別します。たとえば、前回htmlファイルをリクエストすると、ETagが取得されます。今回もファイルをリクエストすると、ブラウザは以前に取得したETag値をWEBサーバーに送信し、WEBサーバーはこのETagを現在のファイルに関連付けます。 ETagが比較すると、ファイルが変更されたかどうかがわかります。
39、期限切れ
WEBサーバーは、エンティティがいつ期限切れになるかを示します。期限切れのオブジェクトは、WEBサーバーで有効性を確認した後でのみ、顧客の要求に応答するために使用できます。HTTP /1.0のヘッダーです。例：有効期限：2009年5月23日土曜日10:02:12 GMT
40、最終変更
WEBサーバーは、ファイルの最終変更時刻、動的ページの最終生成時刻など、オブジェクトの最終変更時刻を考慮します。例：最終更新日：2008年5月6日火曜日02:42:43 GMT
2.HTTPリクエストのヘッダー情報
1.HTTPリクエストメソッド
注：「GET」と「POST」が主に使用されます。
例：POST / test / tupian / cm HTTP / 1.1
3つの部分に分かれています：
（1）POST：HTTPリクエスト方式
（2）/ test / tupian / cm：Webサーバーのディレクトリアドレス（または命令）を要求します
（3）HTTP / 1.1：URI（Uniform Resource Identifier）とそのバージョン
注：Ajaxでは、対応するメソッド属性設定。
2、ホスト
説明：要求されたWebサーバーのドメイン名アドレス
3、ユーザーエージェント
説明：HTTPクライアントが実行しているブラウザータイプの詳細情報。このヘッダー情報を通じて、Webサーバーは現在のHTTP要求のクライアントブラウザータイプを判別できます。
例：ユーザーエージェント：Mozilla / 5.0（Windows; U; Windows NT 5.1; zh-CN; rv：1.8.1.11）Gecko / 20071127 Firefox / 2.0.0.11
4、受け入れる
説明：クライアントが受信できるコンテンツのタイプを指定します。コンテンツタイプの順序は、クライアントが受信する順序を示します。
例：Accept：text / xml、application / xml、application / xhtml + xml、text / html; q = 0.9、text / plain; q = 0.8、image / png、/ ; q = 0.5
備考：Prototyp（1.5）のAjaxコードパッケージでは、Acceptはデフォルトで「text / javascript、text / html、application / xml、text / xml、/」に設定されています。これは、Ajaxがデフォルトでサーバーから返されるJsonデータパターンを取得するためです。Ajaxコードでは、XMLHttpRequestオブジェクトのsetRequestHeader関数メソッドを使用して、これらのヘッダー情報を動的に設定できます。
5、Accept-Language
説明：返された情報を表示するためのHTTPクライアントブラウザーの優先言語を指定します。
例：Accept-Language：zh-cn、zh; q = 0.5ここではデフォルトで中国語です。
6、Accept-エンコーディング
説明：クライアントブラウザがサポートできる、Webサーバーから返されるコンテンツ圧縮エンコーディングのタイプを指定します。帯域幅を節約するために、サーバーが出力をクライアントに送信する前に圧縮できることを示します。ここで設定されているのは、クライアントブラウザがサポートできる戻り圧縮形式です。
インスタンス：Accept-Encoding：gzip、deflate
注：実際、多くのBaidu製品ラインでは、Apacheはページデータをクライアントに返す前にデータをgzip形式で圧縮します。
7、Accept-Charset
説明：ブラウザが受け入れることができる文字エンコーディングセット。
例：Accept-Charset：gb2312、utf-8; q = 0.7、*; q = 0.7
8、コンテンツタイプ
説明：このHTTPリクエストによって送信されたコンテンツタイプを表示します。通常、このプロパティは、投稿が送信されたときにのみ設定する必要があります。
フォーム例：コンテンツタイプ：application / x-www-form-urlencoded; charset：UTF-8
注：Content-Type属性の値は、次の2つのエンコードタイプにすることができます。
（1）「application / x-www-form-urlencoded」：フォームデータがサーバーに送信されるときに使用されるエンコードタイプ。デフォルトのデフォルト値は「application / x-www-form-urlencoded」です。ただし、このエンコード方法は、大量のテキスト、非ASCII文字を含むテキスト、またはバイナリデータをサーバーに送信する場合は非常に非効率的です。
（2）「multipart / form-data」：ファイルをアップロードする場合、使用するエンコードタイプは「multipart / form-data」である必要があります。これにより、テキストデータとバイナリデータのアップロードを送信できます。
単一データとして送信する場合は「application / x-www-form-urlencoded」を使用できます。ファイルを送信する場合は、「multipart / form-data」エンコードタイプを使用する必要があります。
Content-Type属性では、送信されたコンテンツの文字セット文字エンコーディングが引き続き指定されます。通常、設定されていません。送信されたデータをエンコードする文字がどの文字を使用しているかをWebサーバーに通知するだけです。
一般に、開発プロセスでは、フロントエンドエンジニアリングとバックエンドUIエンジニアが、送信後の送信に使用する文字エンコード形式について話し合い、バックエンドUIエンジニアが、送信されたデータを固定文字エンコードに従って解析します。したがって、ここで設定した文字セットはあまり効果がありません。
9、接続
説明：永続的な接続が必要かどうかを示します。Webサーバーがここで値を「Keep-Alive」と見なす場合、または要求がHTTP 1.1を使用することを確認する場合（HTTP 1.1はデフォルトで永続的な接続です）、ページに複数の要素が含まれている場合、永続的な接続を利用できます。 （例：Applet、写真）。これにより、ダウンロードに必要な時間が大幅に短縮されます。これを実現するには、Webサーバーはクライアントに返されるHTTPヘッダー情報でContent-Length（返されたメッセージ本文の長さ）ヘッダーを送信する必要があります。これを実現する最も簡単な方法は、最初にコンテンツをByteArrayOutputStreamに書き込み、次に正式に書き出すことです。コンテンツの前にそのサイズを計算します。
例：接続：キープアライブ
10、キープアライブ
説明：このHTTP接続のKeep-Alive時間を表示します。クライアントとサーバー間の接続を引き続き有効にします。サーバーへの後続の要求がある場合、Keep-Alive機能は接続の確立または再確立を回避します。以前は、HTTPリクエストはワンストップ接続でした。HTTP/ 1.1プロトコルの後、長い接続があります。つまり、指定されたキープアライブ時間内に接続が切断されません。
例：Keep-Alive：300
11、クッキー
注：HTTPリクエストが送信されると、リクエストされたドメイン名で保存されているすべてのCookie値が一緒にWebサーバーに送信されます。
12、リファラー
説明：URLが含まれ、ユーザーはURLで表されるページから現在要求されているページにアクセスします