記事ディレクトリ
1. HTTPの概要
(1) HTTPの概念
目標: HTTP の概念を理解する
1. HTTPの概念
HTTPとはHyperText Transfer Protocolの略で、ハイパーテキスト転送プロトコルのことです。これはリクエスト/レスポンス プロトコルです。クライアントはサーバーとの接続を確立した後、サーバーにリクエストを送信できます。このリクエストは HTTP リクエストと呼ばれます。サーバーはリクエストを受信した後に応答します。これは HTTP レスポンスと呼ばれます。 . .
2. HTTPプロトコルの特徴
(1) C/Sモード
HTTP プロトコルは、クライアント (ブラウザは Web クライアント)/サーバー モードをサポートします。
(2) シンプルで速い
クライアントがサーバーにサービスを要求するときは、要求メソッドとパスを送信するだけで済みます。一般的に使用されるリクエスト メソッドには、GET、POST などが含まれます。リクエスト メソッドが異なれば、クライアントとサーバー間の接続の種類も異なります。HTTPは比較的シンプルなため、HTTPサーバーのプログラムサイズが小さく、通信速度が非常に速いです。
(3) 柔軟な対応
HTTP ではあらゆるタイプのデータの送信が許可され、送信されるデータのタイプは Content-Type によってマークされます。
(4) ステートレス
HTTP はステートレス プロトコルです。ステートレスとは、プロトコルにトランザクション処理用のメモリ容量がないことを意味し、後続の処理で以前の情報が必要な場合は再送信する必要があり、接続ごとに送信されるデータ量が増加する可能性があります。
(2) HTTP1.0とHTTP1.1
目的: HTTP 1.0 と HTTP1.1 の特徴と違いを理解する
1. HTTPの開発
HTTP は誕生以来、多くのバージョンを経てきましたが、その中で最も古いバージョンは 1990 年にリリースされた HTTP 0.9 です。その後、HTTP をさらに改良するために、1996 年に HTTP バージョン 1.0 がリリースされ、1997 年に HTTP バージョン 1.1 がリリースされました。HTTP 0.9 のバージョンは古いため、ここではあまり説明しません。
2. HTTP1.0の概要
(1) HTTP1.0の定義
HTTP 1.0 プロトコルに基づくクライアントとサーバー間の対話プロセスでは、接続の確立、要求情報の送信、応答情報の返送、接続の終了という 4 つの手順を実行する必要があります。
(2) HTTP1.0のデメリット
クライアントはサーバーとの接続を確立した後、一度に 1 つの HTTP リクエストのみを処理できます。コンテンツが豊富な Web ページの場合、この通信方法には明らかに欠陥があります。
たとえば、HTTP 1.0 プロトコルに基づく HTML コード スニペット
<html>
<body>
<img src="/image01.jpg">
<img src="/image02.jpg">
<img src="/image03.jpg">
</body>
</html>
3. HTTP1.1 の概要
HTTP 1.0 クライアントとサーバー間の対話に時間がかかるという上記の欠点を克服するために、HTTP 1.1 バージョンが登場しました。永続的な接続をサポートしています。つまり、複数の HTTP 要求と応答を TCP 接続で送信できるため、接続の確立と終了の消費量と遅延を削減します。
4. HTTPメッセージ
目標: HTTP メッセージの構成を理解する
(1) HTTPメッセージの概念
ユーザーがブラウザで URL アドレスにアクセスするか、Web ページ上のハイパーリンクをクリックするか、Web ページ上のフォームを送信すると、ブラウザはリクエスト データ、つまり HTTP リクエスト メッセージをサーバーに送信します。サーバーはリクエスト データを受信すると、処理されたデータを HTTP 応答メッセージとしてクライアントに送信します。HTTP リクエスト メッセージと HTTP レスポンス メッセージを総称して HTTP メッセージと呼びます。
(2) ブラウザを使用して HTTP メッセージを表示する
Google Chrome のアドレスバーに www.baidu.com と入力して Baidu ホームページにアクセスし、F12 キーを押して開発者ツールのデバッグ ページにアクセスすると、[ネットワーク] のリクエスト情報欄にリクエストされた URL アドレスが表示されます。
2.HTTPリクエスト情報
(1) HTTPリクエスト行
目標: HTTP のリクエスト行について理解する
1.HTTPリクエストライン
HTTP リクエスト行は、リクエスト メッセージの最初の行にあります。これには、リクエスト メソッド、リソース パス、使用される HTTP バージョンの 3 つの部分が含まれます。具体例: GET /index.html HTTP/1.1 GET はリクエスト メソッドです、
index.html は要求されたリソース パス、HTTP/1.1 は通信に使用されるプロトコル バージョンです。リクエスト行の各部分はスペースで区切る必要があり、キャリッジ リターンとライン フィードで終わる必要があることに注意してください。
2.HTTPリクエストメソッド
リクエストメソッドの意味
GET リクエストラインの URI で識別されるリソースを取得するリクエスト
POST 指定されたリソースにデータを送信し、サーバーに処理をリクエストします (フォームの送信やファイルのアップロードなど)。 HEAD リクエストの
応答ヘッダーを取得します。 URI で識別されるリソース
PUT Web ページを配置します URL の場所を指定します (アップロード/移動)
DELETE URI で識別されるリソースの削除をサーバーに要求します TRACE サーバーに
受信した要求情報の返送を要求します (主にテストまたは診断に使用されます)
CONNECT 将来の使用のために予約
OPTIONS サーバーのパフォーマンスのクエリまたはリソース関連情報のクエリのリクエスト オプションと要件
1) GETメソッド
ユーザーがブラウザのアドレス バーに URL アドレスを直接入力するか、Web ページ上のハイパーリンクをクリックすると、ブラウザは GET メソッドを使用してリクエストを送信します。Web ページ上のフォームのメソッド属性が「GET」に設定されている場合、またはメソッド属性が設定されていない場合 (デフォルト値は GET)、ユーザーがフォームを送信すると、ブラウザーも GET メソッドを使用してフォームを送信します。リクエスト。
ブラウザがリクエストしたURLにパラメータ部分がある場合、ブラウザが生成するリクエストメッセージでは、リクエストラインのリソースパスにパラメータ部分が追加されます。
URLアドレス：http://www.lzy.cn/javaForum?name=howard&pwd=123456、「?」以降の内容はパラメータ情報です。パラメーターはパラメーター名とパラメーター値で構成され、等号 (=) を使用して接続されます。URL アドレスに複数のパラメータがある場合は、「&」で区切ります。
ブラウザがリクエスト メッセージをサーバーに送信すると、アクセスする URI リソースにパラメータ部分が追加されます: GET /javaForum?name=howard&pwd=123456. GET メソッドを使用して送信されるデータの量は制限されており、最大でも 2KB を超えることはできません。
(2) POSTメソッド
Web ページ上のフォームのメソッド属性が「POST」に設定されている場合、ユーザーがフォームを送信すると、ブラウザは POST メソッドを使用してフォームのコンテンツを送信し、フォームの要素とデータをURL アドレスにパラメーターとして渡すのではなく、HTTP メッセージのエンティティ コンテンツとしてサーバーを指定します。さらに、POST を使用してサーバーにデータを送信する場合、Content-Type ヘッダーは自動的に「application/x-www-form-urlencoded」に設定され、Content-Length ヘッダーは自動的にアプリケーションの長さに設定されます。エンティティのコンテンツ。
POST /javaForum HTTP/1.1
Host: www.lzy.cn
Content-Type: application/x-www-form-urlencoded
Content-Length: 22
name=howard&pwd=123456
(2) HTTPリクエストヘッダ
目標: HTTP リクエスト ヘッダーについて理解する
1.HTTPリクエストヘッダー
HTTP リクエスト メッセージでは、リクエスト行の後にいくつかのリクエスト ヘッダーが続きます。要求ヘッダーは主に、クライアントが受信できるデータ型、圧縮方法、言語、要求されたハイパーリンクが属するページの URL アドレスなどの追加情報をサーバーに配信するために使用されます。
Host: localhost:8080
Accept: image/gif, image/x-xbitmap, *
Referer: http://localhost:8080/lzy/
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; GTB6.5; CIBA)
Connection: Keep-Alive
Cache-Control: no-cache
2. HTTPリクエストヘッダフィールド
ヘッダー フィールドの説明
Accept ヘッダー フィールドは、クライアント プログラム (通常はブラウザ) が処理できる MIME (MultiPurpose Internet Mail Extension) タイプを示すために使用され、Accept-Charset ヘッダー フィールドは、クライアント プログラムで使用される文字セットをサーバーに通知するために使用されます
。 Accept
-Encoding Accept-Encoding ヘッダー フィールドは、クライアントがデコードできるデータ エンコード方式を指定するために使用されます。ここでのエンコード方式は通常、特定の圧縮方式を指します。Accept-Language ヘッダー フィールドは、どの国を指定するかに使用されます
。言語ドキュメント
認可 クライアントがパスワードで保護された Web ページにアクセスすると、Web サーバーは 401 応答ステータス コードと WWW-Authenticate 応答ヘッダーを送信し、クライアントは Authorization リクエスト ヘッダーを使用してProxy-Authorization ヘッダー フィールドの役割は、
Proxy-Authorization リクエスト ヘッダーがサーバーからプロキシに送信される検証情報であることを除いて、基本的に Authorization ヘッダー フィールドと同じです。サーバー。Host
ヘッダー フィールドは、リソースが配置されているホスト名とポート番号を指定するために使用されます。If
-Match、クライアントがサーバーからこの Web ページを再度要求するときに、If-Match ヘッダー フィールドを使用してファイルを添付できます以前にキャッシュされたエンティティ タグの内容 このリクエストは条件付きリクエストとみなされます
If-Modified-Since If-Modified-Since リクエスト ヘッダーの機能は If-Mach と似ていますが、GMT 形式の時間範囲値が次のとおりである点が異なります
。サーバーがコンテンツの一部とドキュメントのコンテンツ範囲のみを返す必要があることを指定するために使用されます。これは、より大きなドキュメントのアップロードを再開する場合に非常に役立ちます。
If-Range If-Range ヘッダー フィールドは、Range ヘッダー フィールドと一緒にのみ使用できます。その値は、エンティティ タグまたは GMT 形式の時刻です。Max-Forward は、現在のリクエストが通過できるプロキシ サーバーの数を指定します
。プロキシ サーバーを通過するたびに、この値はちょうどマイナス 1
Referer Referer ヘッダー フィールドは非常に便利で、Web サイトの訪問者が Web サイトにどのように移動するかを追跡するために Web サイト管理者によってよく使用されます。同時に、Referer ヘッダー フィールドは
、Web サイトでのホットリンクを防ぐためにも使用できます。ブラウザと、ブラウザまたは他のクライアント プログラムで使用されるバージョン サーバーがブラウザの種類ごとに異なるコンテンツを返すためのブラウザ レンダリング エンジン、ブラウザ言語など
(1) Acceptリクエストヘッダフィールド
Accept ヘッダー フィールドは、クライアント プログラム (通常はブラウザ) が処理できる MIME (MultiPurpose Internet Mail Extensions) タイプを示すために使用されます。たとえば、ブラウザとサーバーの両方が png タイプの画像をサポートしている場合、ブラウザは image/png を含む Accept ヘッダー フィールドを送信でき、サーバーは Accept ヘッダーに MIME タイプ image/png が含まれていることを確認します。これは img に含まれる可能性があります。 Web ページの要素。png タイプのファイルを使用します。MIME タイプには多くの種類があり、たとえば、Accept ヘッダー フィールドの値として次の MIME タイプを使用できます。
Accept: text/html、クライアントが HTML テキストの受け入れを希望していることを示します。
Accept: image/gif、クライアントが GIF 画像形式のリソースを受け入れることを希望していることを示します。
Accept: image/*。クライアントが画像形式のすべてのサブタイプを受け入れることができることを示します。
Accept: /、クライアントがすべての形式のコンテンツを受け入れることができることを示します。
1
2
3
4
(2) Accept-Encoding リクエストヘッダフィールド
Accept-Encoding ヘッダー フィールドは、クライアントがデコードできるデータのエンコード方式を指定するために使用され、ここでのエンコード方式は通常、特定の圧縮方式を指します。Accept-Encoding ヘッダー フィールドでは、カンマで区切って複数のデータ エンコード方式を指定できます。具体例: Accept-Encoding: gzip、compress gzip
および compress は、最も一般的なデータ エンコード方式です。より大きなエンティティ コンテンツを送信する前に圧縮およびエンコードすると、ネットワーク帯域幅と送信時間を節約できます。このリクエスト ヘッダーを受信した後、サーバーは指定された形式の 1 つを使用して元のドキュメント コンテンツを圧縮およびエンコードし、それを応答メッセージのエンティティ コンテンツとしてクライアントに送信し、Content-Encoding 応答ヘッダーでそのコンテンツがどこにあるかを示します。エンティティのコンテンツは、使用される圧縮エンコード形式です。ブラウザーは、そのようなエンティティ コンテンツを受信した後、それを逆解凍する必要があります。
(3)ホストリクエストヘッダフィールド
Host ヘッダー フィールドは、リソースが配置されているホスト名とポート番号を指定するために使用されます。形式は、リソースの完全な URL のホスト名とポート番号と同じです。具体例: Host: www.lzy.cn : 80 は、ブラウザがサーバーに接続するときにデフォルトで使用されるポートです
。ポート番号は 80 なので、「www.lzy.cn」の後のポート番号情報「:80」は省略できます。HTTP 1.1 では、Web サーバーがクライアントがアクセスする仮想サーバーをホスト内のホスト名に基づいて区別できるように、ブラウザーおよび他のクライアントによって送信される各リクエスト メッセージにホスト リクエスト ヘッダー フィールドを含める必要があることに注意してください。ヘッダーフィールド。ブラウザが Web サイトにアクセスすると、アドレス バーの URL アドレスに基づいて、対応するホスト リクエスト ヘッダーが自動的に生成されます。
(4) If-Modified-Since リクエストヘッダフィールド
If-Modified-Since リクエスト ヘッダーは、その値が GMT 形式の時刻である点を除いて、If-Mach と似ています。If-Modified-Since リクエスト ヘッダーはリクエスト条件とみなされ、サーバー内のドキュメントの変更時刻が If-Modified-Since リクエスト ヘッダーで指定された時刻よりも新しい場合にのみ、サーバーはドキュメントのコンテンツを返します。それ以外の場合、サーバーは、ドキュメントのコンテンツをブラウザに返さずに、ブラウザによってキャッシュされたドキュメントが最新であることを示す 304 (Not Modified) ステータス コードを返します。このとき、ブラウザは以前にキャッシュされたドキュメントを引き続き使用します。これにより、ブラウザとサーバー間の通信データ量をある程度削減でき、通信効率が向上します。
(5) リファラーリクエストヘッダーフィールド
ブラウザからサーバーに送信されるリクエストは、ブラウザに URL アドレスを直接入力することによって行うことも、Web ページ上のハイパーリンクをクリックすることによって行うこともできます。URL アドレスがブラウザのアドレス バーに直接入力される最初の状況では、ブラウザは Referer リクエスト ヘッダーを送信しません。たとえば、2 番目のケースでは、ページにリモート サーバーを指すハイパーリンクが含まれており、このハイパーリンクをクリックしてサーバーに GET リクエストを送信すると、ブラウザは送信されるリクエスト メッセージに Referer ヘッダー フィールドを含めます: Host: www. lzy.cn:80
Referer ヘッダー フィールドは非常に便利で、Web サイト訪問者が Web サイトにどのように移動するかを追跡するために Web サイト管理者によってよく使用されます。同時に、Referer ヘッダー フィールドを使用して、Web サイトでのホットリンクを防ぐこともできます。
ホットリンクとは何ですか? Web サイトのホームページに画像情報を表示したいが、その画像リソースが Web サイトのサーバーにない場合、HTML ファイル内のタグを使用して他の Web サイトの画像リソースにリンクし、閲覧者に表示します。これがホットリンクです。Web サイトにホットリンクを設定すると、自身の Web サイトへのアクセス数が増加しますが、リンク先 Web サイトのサーバーへの負荷が増大し、その正当な利益が損なわれます。したがって、Web サイトは自身のリソースを保護するために、Referer ヘッダーを使用して現在の Web ページまたはリソースへのリンク先を検出し、このサイト上のリンクを経由しないアクセスを検出すると、アクセスをブロックしたりジャンプしたりすることができます。指定したページへ。
(6) User-Agent リクエストヘッダフィールド
User-Agent は中国語でユーザーエージェント、略して UA と呼ばれ、オペレーティングシステムとバージョン、ブラウザとバージョン、ブラウザレンダリングエンジン、ブラウザが使用するブラウザを指定するために使用されます。サーバーがブラウザの種類ごとに異なるコンテンツを返すように、他のクライアント プログラム、ブラウザ言語などを設定します。
Google Chrome によって生成される User-Agent リクエスト情報の例: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/110.0.0.0 Safari/537.36 上記のリクエスト ヘッダーでは、
User-エージェント ヘッダー フィールドには、最初に Mozilla のバージョンがリストされ、次にオペレーティング システムのバージョン (Windows NT 10.0 は Windows 10 を意味します)、ブラウザのエンジン名 (AppleWebKit/537.36)、ブラウザのバージョン (Chrome/110.0.0.0 Safari/ 537.36) がリストされます。
3. HTTPレスポンス情報
(1) HTTPレスポンスステータス行
目標: HTTP 応答ステータス行の 3 つの部分を理解する
1. HTTP 応答ステータス行
HTTP 応答ステータス行は応答メッセージの最初の行にあり、HTTP バージョン、成功またはエラーを示す整数コード (ステータス コード)、およびステータス コードを説明するテキスト情報の 3 つの部分で構成されます。
HTTP 応答ステータス行の具体例: HTTP/1.1 200 OK
HTTP/1.1 は通信に使用されるプロトコルのバージョン、200 はステータス コード、OK はステータスの説明で、クライアント要求が成功したことを示します。リクエスト行の各部分はスペースで区切る必要があり、キャリッジ リターンとライン フィードで終わる必要があることに注意してください。
2.HTTPステータスコード
ステータス コードは 3 桁で構成され、リクエストが理解されたか満たされたかを示します。HTTP 応答ステータス コードの最初の桁は応答のカテゴリを定義し、次の 2 桁には特定の分類はありません。最初の数値には 5 つの値が可能です。
3. Web開発における一般的なステータスコード
ステータス コードの説明
200 は、サーバーがクライアントの要求を正常に処理したことを示します。クライアントのリクエストは成功し、応答メッセージは通常のリクエスト結果
302 を返します。これは、リクエストされたリソースは一時的に別の URI からのリクエストに応答しますが、リクエスタは今後のリクエストに対して元の場所を使用し続ける必要があることを意味します。たとえば、リクエストのリダイレクトでは、一時 URI は、レスポンス 304 の Location ヘッダー フィールドが指すリソースである必要があります。
クライアントにキャッシュされたドキュメントがある場合、リクエスト メッセージに If-Modified-Since リクエスト ヘッダーが追加されます。 If-Modified-Since で指定された時間の後に要求されたドキュメントが変更された場合にのみ、サーバーは新しいドキュメントを返す必要があることを示します。ステータス コード 304 は、クライアントのキャッシュされたバージョンが最新であり、クライアントは引き続きそれを使用する必要があることを示します。
それ以外の場合、サーバーは、要求されたリソースが見つからないことを示すステータス コード 200 および 404 とともに、要求されたドキュメントを返します。たとえば、サーバー上に存在しない Web ページにアクセスすると、多くの場合、このステータス コード
500 が返されます。これは、サーバーにエラーがあり、クライアントの要求を処理できないことを意味します。ほとんどの場合、エラーはサーバーの CGI、ASP、JSP、およびその他のプログラムで発生し、通常、サーバーは対応するメッセージで特定のエラー情報を提供します。
2) HTTP レスポンスヘッダー
目標: HTTP 応答ヘッダーについて理解する
1.HTTPレスポンスヘッダー
HTTP 応答メッセージの最初の行は応答ステータス行で、その後にいくつかの応答ヘッダーが続きます。サーバーは、サービス プログラム名、要求されたリソースに必要な認証方法、およびサービス プログラム名などの追加情報を応答ヘッダーを通じてクライアントに送信します。クライアントが要求したリソースの最後の部分、変更時刻、リダイレクト アドレス、その他の情報。
HTTPレスポンスヘッダの具体例
Server: Apache-Coyote/1.1
Content-Encoding: gzip
Content-Length: 80
Content-Language: zh-cn
Content-Type: text/html; charset=GB2312
Last-Modified: Mon, 06 Jul 2020 07:47:47 GMT
Expires: -1
Cache-Control: no-cache
Pragma: no-cache
2. HTTP レスポンスヘッダフィールドのヘッダフィールドの説明
Accept-Range は、サーバーが Range リクエスト ヘッダー フィールドを使用してクライアントのリソース要求を受け入れるかどうかを示すために使用されます。Age は、
現在の Web ページ ドキュメントがクライアントまたはプロキシ サーバーにキャッシュできる有効時間を示すために使用されます。設定値Etag
エンティティ コンテンツの特性を表すタグ情報をクライアントに送信するために使用されます。これらのタグ情報はエンティティ タグと呼ばれます。リソースの各バージョンのエンティティ タグは異なります。エンティティ タグは、エンティティ タグの下にあるエンティティを決定するために使用できます。異なるタイミングで取得した同じリソースパス 内容が同じかどうか
Location は、クライアントに要求されたドキュメントの新しいアドレスを取得するように通知するために使用されます 値は、絶対パスを使用した URL アドレスです
Retry-After と組み合わせて使用できます503 ステータス コードを使用して、リクエストをいつ再送信できるかをクライアントに伝えます。また、任意の 3xx ステータス コードと組み合わせて使用して、リダイレクト処理の最小遅延時間をクライアントに伝えることもできます。Retry-After ヘッダー フィールドの値は、GMT 形式の時刻、または秒単位の時刻数値です。Server は、
サーバー ソフトウェア製品の名前を指定するために使用されます。Vary は、
応答に影響する要求ヘッダー フィールドを指定するために使用されます。サーバーによって生成されたコンテンツ
WWW-Authenticate という名前 クライアントがパスワードで保護された Web ページ ファイルにアクセスすると、サーバーは応答メッセージ内の 01 (未認証) 応答ステータス コードと WWW-Authenticate 応答ヘッダーを送り返します。クライアントは、Authorization リクエスト ヘッダーで WWW-Authoricate を使用する必要があります。レスポンス ヘッダーで指定された認証方法は、ユーザー名とパスワード情報を提供します。Proxy
-Authenticate Proxy-Authenticate ヘッダー フィールドは、プロキシ サーバーのユーザー情報検証用です。使用方法は同様です。 WWW-Authenticate ヘッダー フィールドに追加します。Refresh は、
ページを自動的に更新する時間をブラウザに伝えるために使用されます。その値は秒単位の時間数です。
Content-Disposition ブラウザーが応答のエンティティ コンテンツを直接処理しないことをサーバーが望んでいるが、ユーザーが応答のエンティティ コンテンツをファイルに保存することを選択できるようにする場合は、Content-Disposition ヘッダー フィールドを使用する必要があります。 。
(1) 位置応答ヘッダーフィールド
Location ヘッダー フィールドは、要求されたドキュメントの新しいアドレスを取得するようにクライアントに通知するために使用され、その値は絶対パスを使用した URL アドレスです。Location 応答ヘッダー フィールドの例: Location: http://www.lzy.edu.cn
Location ヘッダー フィールドは、ほとんどの 3xx ステータス コードで使用され、新しいアドレス要求ドキュメントに自動的に再接続するようにクライアントに通知します。現在の応答はクライアントにコンテンツを直接返さないため、Location ヘッダーを使用する HTTP メッセージにはエンティティ コンテンツが含まれるべきではありません。Location と Content-Type の 2 つのヘッダー フィールドを HTTP メッセージ ヘッダーに同時に出現させることはできないことがわかります。 。
(2) サーバーレスポンスヘッダフィールド
Server ヘッダー フィールドは、サーバー ソフトウェア製品の名前を指定するために使用されます。具体例: Server: Apache-Coyote/1.1
(3) リフレッシュレスポンスヘッダフィールド
Refresh ヘッダー フィールドは、ページを自動的に更新する時間をブラウザに指示するために使用されます。その値は秒単位の数値です。具体例: Refresh: 3。上記の Refresh ヘッダー フィールドは、ブラウザに自動的に更新するよう指示するために使用されます
。 3 秒後にページが表示されます。このページを更新してください。
Refresh ヘッダー フィールドの時間値の後に URL パラメータを追加することもできます。時間値と URL はセミコロン (;) で区切られており、指定された時間値の後に他の Web ページにジャンプするようにブラウザに指示するために使用されます。 。たとえば、3 秒後に www.itcast.cn Web サイトにジャンプするようにブラウザに指示します。具体例: Refresh: 3;url=http://www.lzy.edu.cn
(4) Content-Disposition レスポンスヘッダフィールド
Content-Disposition ヘッダー フィールドは HTTP 標準仕様では定義されておらず、RFC2183 から借用されています。RFC2183 では、Content-Disposition により、受信側プログラムがデータ コンテンツを処理する方法が指定されます。インラインとアタッチメントという 2 つの標準的な方法があります。インラインは直接処理を意味しますが、アタッチメントでは、ユーザーが介入して受信側プログラムがデータ コンテンツを処理する方法を制御する必要があります。HTTP アプリケーションでは、添付ファイルのみが Content-Disposition の標準的な方法です。ファイル名パラメータは添付後に指定することもできます。filename パラメータ値は、エンティティ コンテンツを保存するためにブラウザが使用することをサーバーが推奨するファイル名です。ブラウザは、filename パラメータ値のディレクトリ部分を無視し、パラメータの最後の部分のみをファイル名として取得する必要があります。Content-Disposition を設定する前に、必ず Content-Type ヘッダー フィールドを設定してください。
Content-Type: application/octet-stream
Content-Disposition: attachment; filename=lee.zip