【コンピュータネットワーク注意事項5】アプリケーション層(2) HTTPメッセージ

HTTPメッセージフォーマット

HTTP プロトコルのリクエスト メッセージとレスポンス メッセージの構造は基本的に同じで、次の 4 つの部分で構成されます。

• ① 開始行: リクエストまたはレスポンスの基本情報を記述します。
• ② ヘッダフィールドセット (header) :key-valueメッセージをより詳細に説明するためのフォームを使用します。
• ③空行+CRLF復帰改行
• ④ メッセージボディ（body）：実際に送信されるデータ。必ずしもプレーンテキストである必要はなく、写真やビデオなどのバイナリデータでも構いません。

HTTP は「プレーン テキスト」プロトコルであるため、ヘッダー データは ASCII テキストであり、肉眼で簡単に読み取ることができます。

リクエストメッセージの形式:

応答メッセージの形式:

注: RFC 2616 (HTTP/1.1) によると、ヘッダー フィールドでは、フィールド値の前に 1 つ以上のスペースをオプションで使用できますが、フィールド名およびフィールド名とフィールド名の間にスペースを使用することはできません。:。このため、ブラウザ開発者ツールや一部のパケット キャプチャ ツールによって取得される HTTP パケットは、スペースが含まれた読みやすいバージョンになっています。

リクエストメッセージのリクエスト行

リクエスト行では、クライアントがサーバー側リソースでどのように操作したいかを簡単に説明します。

リクエスト行は、リクエストメソッド+ URI + +バージョン番号+の 3 つの部分で空格構成されます。空格CRLF回车换行

• ① リクエストメソッド: GET / POSTなどのリソースの操作方法を示す動詞です。
• ② リクエストターゲット: リクエストターゲットのパス、通常はURIで、リクエストメソッドによって操作されるリソースをマークします。
• ③ バージョン番号: HTTP/1.1 など、メッセージで使用されるHTTP プロトコルのバージョンを示します。

これら 3 つの部分は通常、スペースで区切られます。

URI : ユニフォームリソース識別子 (Uniform Resource Identifier)

応答メッセージのステータス行

ここでは、「応答ライン」ではなく、サーバーの応答のステータスを意味する「ステータスライン」と呼ばれます。

ステータス行は、バージョン番号+ 空格+ステータス コード+ 空格+理由+の 3 つの部分で構成されます。CRLF回车换行

• ① バージョン番号:メッセージで使用されるHTTP プロトコルのバージョン(HTTP/1.1 など) を示します。
• ② ステータスコード: 200-成功、500-サーバーエラー、404-リソースが存在しないなど、処理の結果を示す 3 桁の数字。
• ③ 理由説明: デジタルステータスコードを補足し、理由を理解するためのより詳細な説明文です。

ヘッダーフィールド

HTTP プロトコルでは、さまざまな機能を実装するために多数のヘッダー フィールドが指定されていますが、それらは基本的に次の 4 つのカテゴリに分類できます。

• ① 共通フィールド: リクエスト ヘッダーとレスポンス ヘッダーの両方に表示できます。例Date:Connection

• ② リクエスト フィールド: リクエスト情報や追加の追加条件をさらに記述するためにリクエスト ヘッダーにのみ表示できます ( など) Host。Accept

• ③ 応答フィールド: 応答ヘッダーにのみ表示され、応答メッセージの情報を補足します (例:Serverなど)。

• ④Entityフィールド：実際には一般的なフィールドですが、本文の付加情報を具体的に記述します。たとえば、Content-Length待ってください

HTTP メッセージの解析と処理は、実際にはヘッダー フィールドの処理が主であり、ヘッダー フィールドを理解することは、HTTP メッセージを理解することも意味します。

よく使用されるヘッダー フィールド - ホスト フィールド

• ホストはリクエスト フィールドであり、リクエスト ヘッダーにのみ表示できます。

• Host は、HTTP/1.1仕様で指定する必要がある唯一のフィールドでもあります。つまり、要求ヘッダーに Host がない場合、これはエラー メッセージです。

• [ホスト]フィールドは、実際には、このリクエストをどのホストで処理する必要があるかをサーバーに伝えます。
  
  

よく使用されるヘッダー フィールド - ユーザー エージェント フィールド

• User-Agent は、リクエスト ヘッダーにのみ表示されるリクエスト フィールドです。

• 文字列を使用してHTTPリクエストを開始したクライアントを説明し、サーバーはそれを使用して、このブラウザに最適なページを返すことができます。
  
  

よく使用されるヘッダー フィールド - 日付フィールド

• Date フィールドは一般的なフィールドですが、通常は応答ヘッダーに表示され、HTTP メッセージが作成された時刻を示します。クライアントはこの時刻を他のフィールドと組み合わせて使用​​して、キャッシュ戦略を決定できます。

よく使用されるヘッダーフィールド - サーバーフィールド

• Server フィールドは応答フィールドであり、応答ヘッダーにのみ表示できます。現在 Web サービスを提供しているソフトウェアの名前とバージョン番号をクライアントに伝えます。

• サーバーの情報の一部が外部に公開されるため、サーバー フィールドは表示する必要はありません。このバージョンにバグがある場合、ハッカーがそのバグを利用してサーバーを侵害する可能性があります。したがって、一部の Web サイトでは、応答ヘッダーにこのフィールドがないか、まったく無関係な説明情報が提供されます。

一般的に使用されるヘッダー フィールド - Content-Length フィールド

• 説明するエンティティ フィールドの 1 つはContent-Lengthです。これは、メッセージの本文の長さ、つまり、要求ヘッダーまたは応答ヘッダーの空白行の後のデータの長さを表します。

• サーバーはこのフィールドを確認すると、後に続くデータの量がわかり、それを直接受信できます。そのようなフィールドがない場合、本文は可変長であるため、チャンク方式を使用してチャンクで送信する必要があります。

本文関連のヘッダーフィールド

• Accept: クライアントが解析できるデータ型を示します。複数の型をカンマで区切ってリストできます。

• Accept-Encoding: クライアントがサポートする圧縮形式を示します。省略可能 (圧縮なし)

• Accept-Language: クライアントがサポートする言語

• Accept-Charset: 通常は送信されません。ブラウザは複数の文字セットをサポートします。

• Content-Type: 応答エンティティの真のタイプ。要求ヘッダーと応答ヘッダーに表示されます。

• Content-Encoding: サーバーは、応答エンティティに使用される圧縮アルゴリズムをクライアントに通知します。これは省略可能 (圧縮なし)

• Content-Language: 通常はサーバーによって送信されず、使用される言語を示します。通常、Content-Type: text/html; charset=utf-8 など、Content-Type の文字セットから推測できます。

• Transfer-Encoding: chunked: チャンク転送を示します。各チャンクには、長さヘッダーとデータ ブロックの 2 つの部分が含まれます。最後のチャンクの長さは、終了を示す 0、つまり「0\r\n\r\n」です。

  Transfer-Encoding: chunked フィールドと Content-Length フィールドは相互に排他的であり、これら 2 つのフィールドは応答メッセージ内に同時に出現することはできません。

本体データ型

HTTP で一般的に使用される 4 つのデータ タイプは次のとおりです: text、image、audio/video、application

type／subtype各主要カテゴリは、 「 」という文字列の形式で複数のサブカテゴリに細分化されます。

• ① :ハイパーテキスト、プレーンテキスト、スタイルシートなどtextのテキスト形式の読み取り可能なデータ。text/htmltext/plaintext/css

• ② : 、、などのimage画像ファイルimage/gifimage/jpegimage/png

• ③ :などaudio/videoの音声・映像データaudio/mpeg。video/mp4

• ⑤ application: 形式は固定されておらず、テキストまたはバイナリの場合があり、上位層のアプリケーションによって解釈される必要があります。一般的なものには、、、などが含まれapplication/jsonます。application/javascriptapplication/pdf

  データの型がわからない場合は、application/octet-stream不透明なバイナリ データを使用してください。

本体データの圧縮

圧縮アルゴリズム:

• ① gzip: GUN zip 圧縮形式、インターネット上で最も一般的な圧縮アルゴリズム
• ② deflate:zlib圧縮形式
• ③ br: http に特化して最適化された新しい圧縮アルゴリズム

対応するヘッダー フィールドを圧縮します。

• Accept フィールドは、クライアントが解析できるデータ型をマークします,。複数の型をリストするための区切り文字として使用でき、サーバーにより多くのオプションを提供できます。

  上の図の Accept フィールドは、サーバーに「私は HTML、json テキスト、webp および png 画像を理解できます。これら 4 つの形式でデータを提供してください。」と伝えます。

• Accept-Encoding フィールドは、クライアントがサポートする圧縮形式をマークします。

• Content-Encoding : サーバーは、Accept-Encodingフィールドに記述されている圧縮形式の 1 つを選択してデータを圧縮できます。使用される実際の圧縮形式は、応答ヘッダーのContent-Encodingフィールドに配置されます。
  
  

Accept-EncodingとContent-Encoding はどちらも省略できます。つまり、圧縮は実行されません。

ボディーランゲージタイプ/文字セットエンコーディング

対応するヘッダーフィールド:

ただし、現在のブラウザは複数の文字セットをサポートしており、通常はAccept-Charset を送信せず、使用される言語は文字セットから推測できるため、サーバーはContent-Languageを送信しません。そのため、リクエスト ヘッダーには一般に Accept-Language フィールドのみが含まれます。 、応答ヘッダーには Content-Type フィールドのみが存在します。

ボディコンテンツの交渉による品質価値

HTTP プロトコルでのコンテンツ ネゴシエーションにAccept、Accept-Encoding、Accept-Languageおよびその他の要求ヘッダー フィールドを使用する場合、優先度を設定するための重みqを表す特別な "" パラメータを使用することもできます。ここでの ""は "品質" です。因子」の意味。q

重みの最大値は1、最小値は0.01、デフォルト値はであり1、値が の場合は0拒否を意味します。具体的な形式は、データ型または言語コードの後に​​「"」を追加し;、その後に「q=value"」を続けます。

これは、ブラウザがhtml最も重みが のファイル1、次にxml重みが のファイル、最後に重みが の任意0.9のデータ型を使用したいことを意味します。*/*0.8

サーバーはリクエスト ヘッダーを受信すると、重みを計算し、実際の状況に応じて HTML または XML を最初に出力します。

チャンク転送

「Transfer-Encoding: chunked」とは、メッセージのボディ部分を一度に送信せず、多数のチャンクに分割して一つずつ送信することを意味します。

注: 2 つのフィールド「Transfer-Encoding: chunked」と「Content-Length」は相互に排他的です。応答メッセージの長さは既知か不明 (チャンク化) であるため、これら 2 つのフィールドを応答メッセージ内に同時に表示することはできません。）。

範囲ごとにデータを取得する

• 応答メッセージに Accept-Range: bytes が表示され、サーバーがバイト単位の範囲データのフェッチをサポートしていることを示します。
• 範囲: bytes= <start>-<end>リクエスト メッセージに表示され、どのデータをフェッチするかを示します。
• Content-Range: <start>- <end>/total は応答メッセージに表示され、どのデータが送信されたかを示します。

主な用途: ブレークポイント再開ダウンロード、マルチスレッド ダウンロード。

HTTPリクエストメソッド

現在、HTTP/1.1 では 8 つのリクエスト メソッドが規定されており、すべての単語は大文字である必要があります。

• ① GET : リソースを取得します。これは、データの読み取りまたはダウンロードとして理解できます。
• ② HEAD : リソースのメタ情報を取得します。
• ③ POST : データをリソースに送信します。これはデータの書き込みまたはアップロードに相当します。
• ④ PUT : POST に似ています。
• ⑤ DELETE : リソースを削除します。
• ⑥ CONNECT : 特別な接続トンネルを確立します。
• ⑦ OPTIONS : リソースに対して実行できるメソッドをリストします。
• ⑧ TRACE : リクエストとレスポンスの伝送路をトレースします。

ゲットして向かう

• GETの意味は、サーバーからリソースの取得を要求することです。このリソースには、静的テキスト、ページ、画像、ビデオ、または PHP や Java によって動的に生成されたページや他の形式のデータが含まれます。

• HEADメソッドはGETメソッドに似ています。また、サーバーからリソースを要求します。サーバーの処理メカニズムは同じですが、サーバーは要求されたエンティティ データを返さず、「メタ情報」である応答ヘッダーのみを返します。リソースの「」。

たとえば、ファイルが存在するかどうかを確認したい場合は、 HEADリクエストを送信するだけでよく、 GETを使用してファイル全体を取得する必要はありません。別の例として、ファイルが最新バージョンであるかどうかを確認したい場合は、HEADも使用する必要があります。サーバーは応答ヘッダーでファイルの変更時刻を返します。

POST と PUT

• POSTも頻繁に使用されるリクエスト メソッドです。使用頻度はGETに次ぐはずです。適用シーンも豊富です。データをサーバーに送信する限り、POSTが主に使用されます。

• PUTはPOSTと似た機能を持ち、サーバーにデータを送信することもできますが、POSTとは微妙に異なり、通常POSTは「新規」と「作成」を意味し、PUTは「変更」と「更新」を意味します。

実際のアプリケーションでは、PUTが使用されることはほとんどありません。さらに、そのセマンティクスと機能がPOSTに非常に似ているため、一部のサーバーはPUTメソッドの使用を直接禁止し、データのアップロードにのみPOSTメソッドを使用します。

レスポンスステータスコード

RFC標準で現在指定されているステータス コードは3 桁であるため、値の範囲は次のとおりです。[000~999]

RFC標準では、ステータス コードを5 つのカテゴリに分類しています。番号の最初の桁は、 の代わりにカテゴリを示すために使用されます0~99。このように、実際に使用できるステータス コードの範囲は、[000~999]から大幅に狭められます[100~599]。

これら 5 つのカテゴリの具体的な意味は次のとおりです。

• 1xx: 現在のプロトコル処理が中間状態にあり、後続の操作が必要であることを示すプロンプト メッセージ。
• 2xx: 成功。メッセージは正しく受信され、処理されました。
• 3xx: リダイレクト、リソースの場所が変更されるため、クライアントはリクエストを再送信する必要があります。
• 4xx: クライアント エラー。リクエスト メッセージが正しくないため、サーバーはそれを処理できません。
• 5xx: サーバー エラー。サーバーがリクエストを処理中に内部エラーが発生しました。

ステータスコードの詳細

ステータスコード	ステータス情報	意味
100	続く	最初のリクエストは受け入れられたので、クライアントはリクエストの残りの送信を続ける必要があります。(HTTP 1.1 の新機能)
101	プロトコルの切り替え	サーバーはクライアントのリクエストに従い、別のプロトコル (HTTP 1.1 の新機能) に切り替えます。
102	処理	WebDAV (RFC 2518) によって拡張されたステータス コードで、処理が続行されることを示します。
200	わかりました	すべてが正常に動作し、GET および POST リクエストに対する応答ドキュメントが続きます。
201	作成した	サーバーがドキュメントを作成し、その URL が Location ヘッダーに指定されています。
202	承認されました	リクエストは受け入れられましたが、処理はまだ完了していません。
203	権限のない情報	ドキュメントは正常に返されましたが、ドキュメントのコピーが使用されているため、一部の応答ヘッダーが正しくない可能性があります (HTTP 1.1 の新機能)。
204	コンテンツなし	新しいドキュメントがなければ、ブラウザは元のドキュメントを表示し続ける必要があります。このステータス コードは、ユーザーがページを定期的に更新し、サーブレットがユーザーのドキュメントが十分に最新であると判断できる場合に役立ちます。
205	内容をリセットする	新しいコンテンツはありませんが、ブラウザは表示内容をリセットする必要があります。ブラウザーにフォーム入力コンテンツを強制的にクリアさせるために使用されます (HTTP 1.1 の新機能)。
206	部分的なコンテンツ	クライアントは Range ヘッダーを含む GET リクエストを送信し、サーバーがそれを完了します (HTTP 1.1 の新機能)。
207	マルチステータス	WebDAV (RFC 2518) によって拡張されたステータス コードは、後続のメッセージ本文が XML メッセージになり、前のサブリクエストの数に応じて一連の独立した応答コードが含まれる可能性があることを意味します。
300	複数の選択肢	クライアントが要求したドキュメントは複数の場所で見つかり、返されたドキュメント内にリストされます。サーバーがプリファレンスを提案したい場合は、Location 応答ヘッダーでそれを示す必要があります。
301	永久に移動されました	クライアントによって要求されたドキュメントは別の場所にあり、新しい URL は Location ヘッダーに指定されており、ブラウザーは自動的に新しい URL にアクセスする必要があります。
302	見つかった	301 と似ていますが、新しい URL は永続的な URL ではなく、一時的な代替として考慮される必要があります。HTTP 1.0 の対応するステータス情報は「一時的に移動」であることに注意してください。 このステータス コードが発生すると、ブラウザは新しい URL に自動的にアクセスできるため、便利なステータス コードです。 このステータス コードは 301 と同じ意味で使用できる場合があることに注意してください。たとえば、ブラウザが誤って http://host/~user (末尾のスラッシュがない) をリクエストした場合、サーバーによっては 301 が返されることもあれば、302 が返されることもあります。 厳密に言えば、元のリクエストが GET だった場合にのみ、ブラウザが自動的にリダイレクトすると想定することしかできません。307を参照してください。
303	その他を見る	301/302 と似ていますが、元のリクエストが POST だった場合、Location ヘッダーで指定されたリダイレクト ターゲット ドキュメントが GET (HTTP 1.1 の新機能) 経由でフェッチされる必要がある点が異なります。
304	変更されていません	クライアントはバッファリングされたドキュメントを持ち、条件付きリクエストを行います (通常は、クライアントが指定された日付より新しいドキュメントのみを必要とすることを示す If-Modified-Since ヘッダーを提供します)。サーバーは、バッファされた元のドキュメントが引き続き使用できることをクライアントに伝えます。
305	プロキシを使う	クライアントによって要求されたドキュメントは、Location ヘッダー (HTTP 1.1 の新機能) で指定されたプロキシ サーバーを通じて取得される必要があります。
306	スイッチプロキシ	最新バージョンの仕様では、306 ステータス コードは使用されなくなりました。
307	一時的なリダイレクト	302 (見つかった) と同じ。多くのブラウザは、元のリクエストが POST であったとしても、実際には POST リクエストに対する応答が 303 の場合にのみリダイレクトできるにもかかわらず、誤って 302 レスポンスでリダイレクトします。このため、HTTP 1.1 では、複数のステータス コードをより明確に区別するために 307 が追加されました。303 応答が発生した場合、ブラウザはリダイレクトされた GET および POST リクエストに従うことができますが、307 応答の場合、ブラウザは GET リクエストのリダイレクトにのみ従うことができます。(HTTP 1.1 の新機能)
400	要求の形式が正しくありません	リクエストで構文エラーが発生しました。
401	無許可	顧客がパスワードで保護されたページに不正にアクセスしようとしました。応答には WWW-Authenticate ヘッダーが含まれており、ブラウザーはそれに応じてユーザー名/パスワードのダイアログ ボックスを表示し、適切な Authorization ヘッダーを入力した後、再度要求を実行します。
402	支払いが必要	このステータス コードは、将来のニーズに備えて予約されています。
403	禁断	リソースが利用できません。サーバーはクライアントのリクエストを理解しますが、それを処理することを拒否します。通常、サーバー上のファイルまたはディレクトリのアクセス許可設定が原因で発生します。
404	見つかりません	指定された場所にリソースが見つかりません。これもよくある反応です。
405	許可されていないメソッド	リクエスト メソッド (GET、POST、HEAD、DELETE、PUT、TRACE など) は、指定されたリソースには適用できません。(HTTP 1.1 の新機能)
406	受け付けできません	指定されたリソースは見つかりましたが、その MIME タイプは、Accpet ヘッダー (HTTP 1.1 の新機能) でクライアントによって指定されたものと互換性がありません。
407	プロキシ認証が必要です	401 と同様に、クライアントが最初にプロキシ サーバーによって承認される必要があることを意味します。(HTTP 1.1 の新機能)
408	リクエストのタイムアウト	クライアントは、サーバーによって許可された待機時間中にリクエストを発行しませんでした。クライアントは後で同じリクエストを繰り返すことができます。(HTTP 1.1 の新機能)
409	対立	通常は PUT リクエストに関連します。リクエストはリソースの現在の状態と競合するため成功できません。(HTTP 1.1 の新機能)
410	消えた	要求されたドキュメントはもう利用できず、サーバーはどのアドレスにリダイレクトすればよいかわかりません。404 との違いは、407 を返すのはドキュメントが指定された場所から永久に離れたことを意味するのに対し、404 はドキュメントが不明な理由で利用できないことを意味することです。(HTTP 1.1 の新機能)
411	必要な長さ	クライアントが Content-Length ヘッダーを送信しない限り、サーバーはリクエストを処理できません。(HTTP 1.1 の新機能)
412	前提条件が失敗しました	リクエストヘッダーで指定された一部の前提条件が失敗しました (HTTP 1.1 の新機能)。
413	エンティティが大きすぎるリクエスト	ターゲット ドキュメントは、サーバーが現在処理できるサイズを超えています。サーバーが後でリクエストを処理できると判断した場合は、Retry-After ヘッダー (HTTP 1.1 の新機能) を提供する必要があります。
414	リクエスト URI が長すぎます	URI が長すぎます (HTTP 1.1 の新機能)。
415	サポートされていないメディア タイプ	現在要求されているメソッドと要求されたリソースについては、要求で送信されたエンティティがサーバーでサポートされている形式ではないため、要求は拒否されます。
416	要求された範囲が満たされません	サーバーは、リクエスト内でクライアントによって指定された Range ヘッダーを満たすことができません。(HTTP 1.1 の新機能)
417	期待は外れました	リクエスト ヘッダー Expect で指定された期待内容がサーバーによって満たされないか、サーバーがプロキシ サーバーであり、現在のルートの次のノードで Expect の内容を満たすことができないという明確な証拠があります。
421	インターネット アドレスからの接続が多すぎます	从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关 或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。
422	Unprocessable Entity	请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV）
423	Locked	当前资源被锁定。（RFC 4918 WebDAV）
424	Failed Dependency	由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。（RFC 4918 WebDAV）
425	Unordered Collection	在WebDav Advanced Collections 草案中定义，但是未出现在《WebDAV 顺序集协议》（RFC 3658）中。
426	Upgrade Required	客户端应当切换到TLS/1.0。（RFC 2817）
449	Retry With	由微软扩展，代表请求应当在执行完适当的操作后进行重试。
500	Internal Server Error	服务器遇到了意料不到的情况，不能完成客户的请求。
501	Not Implemented	服务器不支持实现请求所需要的功能。例如，客户发出了一个服务器不支持的PUT请求。
502	Bad Gateway	服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。
503	Service Unavailable	服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头。
504	Gateway Timeout	由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答。（HTTP 1.1新）
505	HTTP Version Not Supported	服务器不支持请求中所指明的HTTP版本。（HTTP 1.1新）
506	Variant Also Negotiates	由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。
507	Insufficient Storage	服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)
509	Bandwidth Limit Exceeded	服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。
510	Not Extended	获取资源所需要的策略并没有没满足。（RFC 2774）

HTTP 重定向

当一个客户端访问某个 URL 的时候，由于某种原因，服务端会告诉客户端需要重新访问另一个 URL，这就是重定向。

最常见的重定向状态码就是301和302，301俗称“永久重定向”（Moved Permanently）， 302 俗称“临时重定向”（“Moved Temporarily”） 。

“Location” 字段属于响应字段，必须出现在响应报文里。但只有配合 301/302 状态码才有意义，它标记了服务器要求重定向的 URL。

301 永久重定向

很多客户端记住的是原 URL，但是这个 URL在服务端已经不用了，此时请求服务器会返回 301，浏览器看到 301，就知道原来的 URL “过时”了，就会做适当的优化。比如刷新历史记录、更新书签，下次可能就会直接用新的 URL 访问，省去了再次跳转的成本。

302 临时重定向

302 俗称“临时重定向”（“Moved Temporarily”），意思是原 URL 处于“临时 维护”状态，新的 URL是起“顶包”作用的“临时工”。

浏览器看到 302，会认为原来的 URL 仍然有效，但暂时不可用，所以只会执行简单的跳转页面，不记录新的 URL，也不会有其他的多余动作，下次访问还是用原 URL。

比如，服务器中临时维护某个 URL，就可以返回 302 状态码。

URL 格式

URI 是统一资源标识符，URL 是统一资源定位符，URL 是 URI 的一种具体实现。

URL 格式：schema://host:port/path

• schema：协议名，表示资源应该使用哪种协议来访问。如 http、https
• 在 scheme 之后，必须是三个特定的字符 ://，它把 scheme 和后面的部分分离开
• host:port 在 :// 之后，是资源所在的主机名，即主机名加端口号
• path是资源在主机上的位置路径
• 有了协议名和主机地址、端口号，再加上后面标记资源所在位置的path，浏览器就可以连接服务器访问资源了。

查询参数：schema://host:port/path?key=value&key=value

• path 后面使用一个"?“分割开来，”?"后面的就是query查询参数部分，query部分是由“&”拼接的多个key=value键值对

画像を取得する際に、異なるサイズを指定したい場合、「プロトコル名+ホスト名+パス」という方法では対応できないため、URIの後に「クエリ」部分を設け、URIの後に「クエリ」を使用します。 path.?" で始まりますが、"?" は含まれておらず、リソースの追加要件を示しています。

フラグメントID:

URIで示されるリソース内の「アンカー」や「タグ」のことで、ブラウザはリソースを取得した後、それが示す場所に直接ジャンプできます。

ただし、フラグメント識別子はブラウザなどのクライアントによってのみ使用でき、サーバーからは見ることができません。つまり、ブラウザーが#fragmentを含む URI をサーバーに送信することはなく、サーバーがこの方法でリソース フラグメントを処理することはありません。

URLエンコード

URI には ASCII コードのみを使用できますが、英語以外の中国語、日本語などの言語を URI に使用したい場合はどうすればよいでしょうか。

また、一部の特殊な URI では、 「 」などの区切り文字として機能する文字が内外pathにquery出現するため、URI 解析エラーが発生します。この場合はどうすればよいでしょうか?@&?

URI では、ASCII コード以外の文字セットおよび特殊文字に対して特別な操作を実行して、それらを URI セマンティクスと競合しない形式に変換するエンコード メカニズムが導入されています。

URI エスケープのルールは少し「単純かつ粗雑」で、非 ASCII コードまたは特殊文字を 16 進バイト値に直接変換し、その前に「」を追加します%。

たとえば、スペースは「%20」としてエスケープされ、「?」は「 」としてエスケープされます%3F。中国語や日本語などは通常、UTF-8エンコードを使用してエスケープします。たとえば、「Galaxy」は「%E9%93%B6%E6%B2%B3」にエスケープされます。