ウェブ

ウェブ

国際標準	RFC  1945 HTTP/1.0 RFC  9110 HTTPセマンティクス RFC  9111 HTTP キャッシュ RFC  9112 HTTP/1.1 RFC  9113 HTTP/2 RFC  7541 HTTP/2: HPACK ヘッダー圧縮 RFC  8164 HTTP/2: HTTP/2 のための日和見セキュリティ RFC  8336 HTTP/2: ORIGIN HTTP/2 フレーム RFC  8441 HTTP/2: HTTP/2 による WebSocket のブートストラップ RFC  9114 HTTP/3 RFC  9204 HTTP/3: QPACK: フィールド圧縮
開発者	当初はCERN、IETF、W3C
紹介された	1991年; 33年前 （1991年）
Webサイト	https://httpwg.org/specs/

HTTP（ハイパーテキスト転送プロトコル）は、分散型、協調型、ハイパーメディア情報システムのためのインターネットプロトコルスイートモデルのアプリケーション層プロトコルです。 ^{[1] HTTPは、}ワールドワイドウェブのデータ通信の基盤であり、ハイパーテキスト文書には、マウスのクリックやウェブブラウザでの画面のタップなどによりユーザーが簡単にアクセスできる他のリソースへのハイパーリンクが含まれています。

HTTPの開発は1989年にCERNのティム・バーナーズ＝リーによって開始され、最初のHTTPバージョン0.9を使用したクライアントとサーバーの動作を説明した簡単な文書にまとめられました。^[2]このバージョンはその後開発され、最終的に公開された1.0になりました。^[3]

初期の HTTP Requests for Comments (RFC) の開発は、数年後にInternet Engineering Task Force (IETF) とWorld Wide Web Consortium (W3C) の共同作業によって開始され、その後作業は IETF に移行しました。

HTTP/1は1996年に完成し、完全に文書化されました（バージョン1.0）。^[4] 1997年に進化し（バージョン1.1）、その後1999年、2014年、2022年に仕様が更新されました。^[5] HTTPSと呼ばれるその安全な変種は、85％以上のウェブサイトで使用されています。^[6]

2015年に公開されたHTTP/2は、HTTPのセマンティクスを「ネットワーク上で」より効率的に表現します。2024年8月現在、^[update]66.2%のウェブサイト^{[7] [8]}（35.3% HTTP/2 + 30.9% HTTP/3、下位互換性あり）でサポートされており、ほぼすべてのウェブブラウザ（ユーザーの98%以上）でサポートされています。^[9]また、主要なウェブサーバーでも、TLS（トランスポート層セキュリティ）を介してアプリケーション層プロトコルネゴシエーション（ALPN）拡張機能^[10]を使用してサポートされていますが、TLS 1.2以降が必要です。^{[11] [12]}

HTTP/2の後継であるHTTP/3は2022年に公開されました。 ^[13] 2024年2月現在、^[update]30.9%のウェブサイトで使用されており^[14]、ほとんどのウェブブラウザでサポートされています。つまり、（少なくとも部分的に）97%のユーザーがサポートしています。^{[15] HTTP/3は、基盤となるトランスポートプロトコルとして}TCPではなくQUICを使用します。HTTP/2と同様に、プロトコルの以前のメジャーバージョンを廃止するものではありません。HTTP/3のサポートは、最初にCloudflareとGoogle Chromeに追加され、^{[16] [17] 、} Firefoxでも有効になっています。^[18] HTTP/3は、サーバー上で有効になっている場合、実際のウェブページのレイテンシが低く、HTTP/2よりも高速に読み込まれ、HTTP/1.1（まだ一般的に有効になっているだけ）よりも3倍以上高速な場合もあります。^[19]

HTTP は、クライアント/サーバー モデルにおける要求/応答プロトコルとして機能します。たとえば、Web ブラウザーはクライアントになることができ、 1 つ以上のWeb サイトをホストするコンピューター上で実行されるWebサーバーというプロセスはサーバーになることができます。クライアントは、HTTP要求メッセージをサーバーに送信します。サーバーは、HTMLファイルやその他のコンテンツなどのリソースを提供したり、クライアントに代わってその他の機能を実行したりして、クライアントに応答メッセージを返します。応答には、要求に関する完了ステータス情報が含まれ、要求されたコンテンツがメッセージ本文に含まれることもあります。

Web ブラウザは、ユーザー エージェント(UA) の一例です。その他の種類のユーザー エージェントには、検索プロバイダー ( Web クローラー)が使用するインデックス作成ソフトウェア、音声ブラウザ、モバイル アプリ、Web コンテンツにアクセス、使用、表示するその他のソフトウェアなどがあります。

HTTP は、中間ネットワーク要素がクライアントとサーバー間の通信を改善または有効化できるように設計されています。トラフィックの多い Web サイトでは、上流サーバーに代わってコンテンツを配信して応答時間を改善するWeb キャッシュサーバーが役立つことがよくあります。Web ブラウザーは、以前アクセスした Web リソースをキャッシュし、可能な限り再利用してネットワーク トラフィックを削減します。プライベート ネットワーク境界にあるHTTPプロキシ サーバーは、メッセージを外部サーバーに中継することで、グローバルにルーティング可能なアドレスを持たないクライアントの通信を容易にすることができます。

中間 HTTP ノード (プロキシ サーバー、Web キャッシュなど) が機能を実行できるようにするために、一部のHTTP ヘッダー(HTTP 要求/応答内) はホップバイホップで管理されますが、他の HTTP ヘッダーはエンドツーエンドで管理されます(ソース クライアントとターゲット Web サーバーによってのみ管理されます)。

HTTPは、インターネットプロトコルスイートのフレームワーク内で設計されたアプリケーション層プロトコルです。その定義では、基盤となる信頼性の高いトランスポート層プロトコルを前提としています。^[20]最新バージョンのHTTP/3では、伝送制御プロトコル（TCP）は使用されなくなりましたが、古いバージョンの方がまだ多く使用されており、最も一般的にはTCPを使用しています。それらはまた、ユーザーデータグラムプロトコル（UDP）などの信頼性の低いプロトコルを使用するように適応されており、HTTP/3も（間接的に）常にHTTPUやシンプルサービス検出プロトコル（SSDP）でそれを基盤としています。

HTTP リソースは、Uniform Resource Identifiers (URI) スキームhttpおよびhttpsを使用して、 Uniform Resource Locator (URL)によってネットワーク上で識別され、配置されます。RFC 3986 で定義されているように、URI はHTMLドキュメント内でハイパーリンク としてエンコードされ、相互にリンクされたハイパーテキストドキュメントを形成します。

HTTP/1.0では、リソース要求ごとに同じサーバーへの個別のTCP接続が確立されます。 ^[21]

HTTP/1.1ではTCP接続を再利用して複数のリソースリクエスト（HTMLページ、フレーム、画像、スクリプト、スタイルシートなど）を行うことができます。^{[22] [23]}

そのため、HTTP/1.1通信では、特にトラフィック量が多い状況ではTCP接続の確立にかなりのオーバーヘッドがかかるため、遅延が少なくなります。 ^[24]

HTTP/2 は、同じクライアント サーバー モデルと同じプロトコル メソッドを維持するために以前の HTTP/1.1 を改訂したものですが、順序に次の違いがあります。

• メタデータ (HTTP ヘッダー) のテキスト表現ではなく圧縮されたバイナリ表現を使用するため、ヘッダーに必要なスペースが大幅に削減されます。
• アクセスされたサーバー ドメインごとに 2 ～ 8 個の TCP/IP 接続ではなく、1 個のTCP/IP (通常は暗号化された) 接続を使用します。
• TCP/IP接続ごとに1つ以上の双方向ストリームを使用し、HTTPリクエストとレスポンスを小さなパケットに分割して送信することで、HOLB（ヘッドオブラインブロッキング）の問題をほぼ解決します。^{[注 1]}
• プッシュ機能を追加して、新しいデータが利用可能になったときにサーバーアプリケーションがクライアントにデータを送信できるようにする（ポーリング方式を使用してクライアントがサーバーに定期的に新しいデータを要求することを強制しない）。^[25]

したがって、HTTP/2 通信では、HTTP/1.1 通信よりも遅延が大幅に少なくなり、ほとんどの場合、速度も速くなります。

HTTP/3 は、 TCP の代わりにQUIC + UDP トランスポート プロトコルを使用するために、以前の HTTP/2 を改訂したものです。そのバージョンより前は、TCP/IP 接続が使用されていましたが、現在は IP 層のみが使用されます (UDP は TCP と同様に、この層の上に構築されます)。これにより、通信の平均速度がわずかに向上し、すべてのストリームのデータ フローを一時的にブロックしたり遅くしたりする可能性のあるTCP 接続輻輳(非常にまれ) の問題が回避されます (別の形式の「ヘッド オブ ライン ブロッキング」)。

ハイパーテキストという用語は、 1965 年にテッド ネルソンがザナドゥ プロジェクトで作った造語です。このプロジェクトは、ヴァネヴァー ブッシュが1945 年に書いたエッセイ「As We May Think 」で述べた、マイクロフィルム ベースの情報検索および管理「memex 」システムの 1930 年代の構想に触発されたものです。ティム バーナーズ リーとCERNの彼のチームは、HTML や、 Web サーバーおよびWeb ブラウザーと呼ばれるクライアントユーザー インターフェイスの関連技術とともに、オリジナルの HTTP を発明したとされています。 バーナーズ リーは、彼の別のアイデアである「WorldWideWeb」プロジェクトの採用を促進するために HTTP を設計しました。このプロジェクトは 1989 年に初めて提案され、現在はWorld Wide Webとして知られています。

最初のウェブサーバーは1990年に稼働しました。^{[26] [27]}使用されたプロトコルには、サーバーからページを要求するGETという1つのメソッドしかありませんでした。^[28]サーバーからの応答は常にHTMLページでした。^[2]

1991年に、HTTPの最初の公式バージョンが700語未満のプレーンドキュメントとして文書化され、このバージョンはHTTP/0.9と名付けられました。このバージョンはGETメソッドのみをサポートし、クライアントはサーバーからHTMLドキュメントを取得することしかできず、他のファイル形式や情報のアップロードはサポートしていませんでした。^[2]

1992 年以降、基本プロトコルの次の完全バージョンに向けた進化を規定する新しいドキュメントが書かれました。このドキュメントは、バージョン 0.9 のシンプルなリクエスト メソッドと、クライアント HTTP バージョンを含む完全な GET リクエストの両方をサポートしました。これは、HTTP/1.0 の最終作業に先立つ多くの非公式 HTTP/1.0 ドラフトの最初のものでした。^[3]

HTTPプロトコルの新しい機能が必要であり、それらを公式RFCとして完全に文書化する必要があると決定した後、1995年初頭にHTTPワーキンググループ（HTTP WG、リーダーはDave Raggett）が結成され、拡張された操作、拡張されたネゴシエーション、より豊富なメタ情報、追加のメソッドとヘッダーフィールドを追加することでより効率的になったセキュリティプロトコルを備えたプロトコルの標準化と拡張を目的としていました。 [ ^{29] [30]}

HTTP WGは1995年中にプロトコルの新しいバージョンをHTTP/1.0およびHTTP/1.1として改訂して公開することを計画していましたが、多くの改訂があったため、そのタイムラインは1年以上続きました。^[31]

HTTP WG は、パフォーマンス、低遅延応答などに関する以前のバージョンで残っていたすべての問題を解決する HTTP-NG (HTTP Next Generation) と呼ばれる HTTP の遠い将来のバージョンを指定することも計画していましたが、この作業は数年後に開始され、完了することはありませんでした。

1996 年 5 月、RFC  1945 は、多くの Web ブラウザーや Web サーバーで既に使用されていた標準前の HTTP/1.0 ドラフトとして過去 4 年間使用されてきたものの最終的な HTTP/1.0 改訂版として公開されました。

1996年初頭、開発者は、今後のHTTP/1.1仕様のドラフトを使用して、HTTP/1.0プロトコルの非公式な拡張機能（キープアライブ接続など）を製品に組み込み始めました。^[32]

1996 年初頭から、主要な Web ブラウザと Web サーバ開発者も、標準前の HTTP/1.1 ドラフト仕様で指定された新機能の実装を開始しました。エンド ユーザーによる新しいバージョンのブラウザとサーバの採用は急速に進みました。1996 年 3 月、ある Web ホスティング会社は、インターネットで使用されているブラウザの 40% 以上が仮想ホスティングを有効にするために新しい HTTP/1.1 ヘッダー「Host」を使用しており、1996 年 6 月までに、そのサーバにアクセスするすべてのブラウザの 65% が標準前の HTTP/1.1 に準拠していると報告しました。^[33]

1997 年 1 月、RFC  2068 が HTTP/1.1 仕様として正式にリリースされました。

1999 年 6 月に、 以前の (廃止された) HTTP/1.1 仕様に基づくすべての改善と更新を組み込んだ RFC 2616 がリリースされました。

以前の HTTP ワーキング グループの 1995 年の古い計画を再開し、1997 年にHTTP-NG ワーキング グループが結成され、HTTP-NG (HTTP New Generation) という新しい HTTP プロトコルを開発しました。単一の TCP/IP 接続内で HTTP トランザクションの多重化を使用する新しいプロトコルの提案/ドラフトがいくつか作成されましたが、1999 年にグループは活動を中止し、技術的な問題を IETF に引き継ぎました。^[34]

2007年、IETF HTTPワーキンググループ（HTTP WG bisまたはHTTPbis）が再開され、第一に以前のHTTP/1.1仕様を改訂して明確化し、第二に将来のHTTP/2仕様（httpbisと命名）を記述して改良することとなった。^{[35] [36]}

2009年、民間企業のGoogleは、 SPDYという新しいHTTPバイナリプロトコルを開発し、テストしたことを発表しました。その暗黙の目的は、Webトラフィック（特に将来のWebブラウザとそのサーバー間）を大幅に高速化することでした。

SPDYは多くのテストでHTTP/1.1よりもはるかに高速であったため、すぐにChromiumに採用され、その後他の主要なウェブブラウザにも採用されました。^[37]

単一の TCP/IP 接続を介して HTTP ストリームを多重化するアイデアの一部は、W3C HTTP-NG ワーキング グループの作業を含むさまざまなソースから取得されました。

2012年1月から3月にかけて、HTTPワーキンググループ（HTTPbis）は、SPDYのアイデアや作業を考慮して、新しいHTTP/2プロトコルに注力する必要があると発表しました（HTTP/1.1仕様の改訂を完了させながら）。^{[38] [39]}

HTTPの新しいバージョンを開発するために何をすべきかについて数か月検討した後、それをSPDYから派生させることが決定されました。^[40]

2015 年 5 月に、HTTP/2はRFC 7540として公開され 、SPDY をすでにサポートしているすべての Web ブラウザーにすぐに採用され、Web サーバーにもゆっくりと採用されました。

2014 年 6 月、HTTP ワーキング グループは、 RFC 2616を廃止する 6 部構成の更新された HTTP/1.1 仕様をリリースしました 。

• RFC  7230、HTTP/1.1: メッセージ構文とルーティング
• RFC  7231、HTTP/1.1: セマンティクスとコンテンツ
• RFC  7232、HTTP/1.1: 条件付きリクエスト
• RFC  7233、HTTP/1.1: 範囲リクエスト
• RFC  7234、HTTP/1.1: キャッシュ
• RFC  7235、HTTP/1.1: 認証

RFC  7230付録A では、HTTP/1.1バージョン（およびそれ以降）をサポートするサーバーではHTTP/0.9は非推奨とされている。 ^[41]

HTTP/0.9 はリクエストのヘッダー フィールドをサポートしていなかったため、名前ベースの仮想ホスト (Host ヘッダー フィールドの検査によるリソースの選択) をサポートするメカニズムがありません。 名前ベースの仮想ホストを実装するサーバーは、 HTTP/0.9 のサポートを無効にする必要があります。HTTP/0.9 のように見えるリクエストのほとんどは、実際には、クライアントがリクエスト ターゲットを適切にエンコードできなかったために、不適切に構築された HTTP/1.x リクエストです。

2016年以降、多くのユーザーエージェント（ブラウザなど）やウェブサーバーのプロダクトマネージャーや開発者は、主に以下の理由から、HTTP/0.9プロトコルのサポートを段階的に廃止し、廃止する計画を立て始めています。^[42]

• 非常に単純なため、RFC文書は書かれていない（元の文書のみが存在する）^[2]
• HTTP ヘッダーがなく、最小限のセキュリティ上の理由で現在必要とされる他の多くの機能が欠けています。
• 1999 年から 2000 年以降は普及しておらず (HTTP/1.0 および HTTP/1.1 のため)、ルーターなどの一部の非常に古いネットワーク ハードウェアでのみ一般的に使用されています。

^{[注 2]}

2020 年にHTTP/3 の最初のドラフトが公開され、主要な Web ブラウザーと Web サーバーが採用し始めました。

2022年6月6日、IETFはHTTP/3をRFC  9114として標準化した^。[43]

2022 年 6 月に、一連の RFC が公開され、以前のドキュメントの多くが廃止され、いくつかの小さな変更が導入され、HTTP セマンティクスの説明が別のドキュメントにリファクタリングされました。

• RFC  9110、HTTP セマンティクス
• RFC  9111、HTTP キャッシュ
• RFC  9112、HTTP/1.1
• RFC  9113、HTTP/2
• RFC  9114、HTTP/3 (上記のセクションも参照)
• RFC  9204、QPACK: HTTP/3 のフィールド圧縮
• RFC  9218、HTTP の拡張可能な優先順位付けスキーム

HTTPはステートレスなアプリケーションレベルのプロトコルであり、クライアントとサーバーの間でデータを交換するために信頼性の高いネットワークトランスポート接続を必要とします。^[20] HTTP実装では、TCP/IP接続は既知のポート（通常、接続が暗号化されていない場合はポート80、接続が暗号化されている場合はポート443、TCPおよびUDPポート番号のリストも参照）を使用して使用されます。^{[44] [45]} HTTP/2では、TCP/IP接続と複数のプロトコルチャネルが使用されます。HTTP/3では、 UDP上の アプリケーショントランスポートプロトコルQUICが使用されます。

データは、セッション層トランスポート接続によって交換される一連の要求応答メッセージを通じて交換されます。 ^[20] HTTP クライアントは最初にサーバーに接続して接続 (実接続または仮想接続) を確立しようとします。そのポートで待機している HTTP(S) サーバーは接続を受け入れ、クライアントの要求メッセージを待ちます。クライアントは HTTP 要求メッセージを送信します。要求を受信すると、サーバーは HTTP 応答メッセージを返します。このメッセージには、必要に応じてヘッダーと本文が含まれます。この応答メッセージの本文は通常、要求されたリソースですが、エラー メッセージやその他の情報が返されることもあります。クライアントまたはサーバーはいつでも (さまざまな理由で) 接続を閉じることができます。接続を閉じることは通常、サーバーまたはクライアントに送信された最後の要求/応答メッセージ内の 1 つ以上の HTTP ヘッダーを使用して事前に通知されます。^[22]

HTTP/0.9では、サーバー応答が送信された後、TCP/IP 接続は常に閉じられるため、接続が永続的になることはありません。

HTTP/1.0では、RFC 1945に記載されているように、応答が送信された後、TCP/IP接続は常にサーバーによって閉じられる必要があります。^{[注 3]}

HTTP/1.1では、接続を複数のリクエスト/レスポンスに再利用できるように、キープアライブ メカニズムが正式に導入されました。このような永続的な接続により、最初のリクエストが送信された後にクライアントがTCP 3 ウェイ ハンドシェイク接続を再ネゴシエートする必要がなくなるため、リクエストの待ち時間が著しく短縮されます。もう 1 つのプラス効果は、TCP のスロー スタートメカニズムにより、一般に時間の経過とともに接続が高速化されることです。

HTTP/1.1 では、クライアントが各応答を待つ前に複数のリクエストを送信できるようにすることで、持続的な接続を使用する際の遅延時間をさらに短縮するためのHTTP パイプラインも追加されました。この最適化は、少数の Web サーバーと多くのプロキシ サーバー(特にクライアントとサーバー間のインターネット/イントラネットに配置された透過プロキシ サーバー) がパイプライン化されたリクエストを適切に処理しなかったため、本当に安全であるとは決して考えられませんでした (最初のリクエストのみを処理して他のリクエストを破棄したり、最初のリクエストの後にさらにデータがあったために接続を閉じたり、一部のプロキシが順序どおりに応答を返さなかったりしました)。このため、安全でべき等なモードでパイプライン化できるのは、HEAD リクエストと一部の GET リクエスト (つまり、実際のファイル リクエストに限定され、クエリ文字列をコマンドとして使用しないURLなど) のみでした。パイプラインを有効にすることで発生した問題に長年苦労した後、この機能は最初に無効化され、その後、HTTP/2 の採用が発表されたこともあり、ほとんどのブラウザーから削除されました。

HTTP/2 は、単一の TCP/IP 接続を介して多数の同時リクエスト/レスポンスを多重化することにより、永続的な接続の使用を拡張しました。

HTTP/3 はTCP/IP 接続ではなく QUIC + UDP を使用します (技術概要も参照)。

HTTP/0.9

要求されたリソースは常に完全に送信されました。

1.0 の

HTTP/1.0 では、条件付き GET リクエストを可能にするために、クライアントによってキャッシュされたリソースを管理するヘッダーが追加されました。実際には、サーバーは、クライアントがリソースの最終更新時刻を知らない場合、または GET リクエストへの最後の完全な応答以降に変更された場合にのみ、要求されたリソースのコンテンツ全体を返す必要があります。これらのヘッダーの 1 つである「Content-Encoding」は、返されたリソースのコンテンツが圧縮されているかどうかを指定するために追加されました。

リソースのコンテンツの合計長が事前にわからない場合 (動的に生成されるなど)、ヘッダーは"Content-Length: number"HTTP ヘッダーに存在せず、クライアントはサーバーが接続を閉じたときにコンテンツ全体が送信されたと想定します。このメカニズムでは、正常に完了したリソース転送と中断されたリソース転送 (サーバー/ネットワーク エラーなど) を区別できませんでした。

1.1 の

HTTP/1.1 が導入されました:

• キャッシュされたリソースの条件付き取得をより適切に管理するための新しいヘッダー。
• チャンク転送エンコーディングにより、サーバーが事前にコンテンツの長さを把握していない場合でも (動的に生成される場合など) 確実に送信できるように、コンテンツをチャンク単位でストリーミングできます。
• バイト範囲サービングでは、クライアントはリソースの 1 つまたは複数の部分 (バイトの範囲) (つまり、コンテンツ全体の最初の部分、中間または最後の部分など) のみを要求でき、サーバーは通常、要求された部分のみを送信します。これは、中断されたダウンロードを再開する場合 (ファイルが非常に大きい場合)、時間、帯域幅、システム リソースなどを節約するために、コンテンツの一部のみを表示する必要がある場合、またはブラウザーによって既に表示されている部分に動的に追加する必要がある場合 (つまり、Web ページの最初のコメントまたは次の n 件のコメントのみ) に役立ちます。

HTTP/2、HTTP/3

HTTP/2 と HTTP/3 はどちらも、HTTP/1.1 の上記の機能を保持しています。

HTTP は、チャレンジ レスポンス メカニズムを介して動作する基本アクセス認証やダイジェスト アクセス認証などの複数の認証スキームを提供します。これにより、サーバーは要求されたコンテンツを提供する前にチャレンジを識別して発行します。

HTTPは、チャレンジレスポンス認証方式の拡張セットを介して、アクセス制御と認証のための一般的なフレームワークを提供します。この認証方式は、サーバーがクライアントの要求にチャレンジするために使用したり、クライアントが認証情報を提供するために使用できます。^[1]

上記の認証メカニズムは HTTP プロトコルに属し、Web アプリケーション セッションを使用する Web アプリケーションではなく、クライアントおよびサーバーの HTTP ソフトウェアによって管理されます (1 つ以上の Web リソースへのクライアント アクセスを許可する前に認証を要求するように構成されている場合)。

HTTP 認証仕様では、特定のルートURIに共通するリソースをさらに分割するための、任意の実装固有の構成も提供されています。レルム値文字列が存在する場合、正規のルート URI と組み合わされて、チャレンジの保護空間コンポーネントが形成されます。これにより、サーバーは 1 つのルート URI の下に個別の認証スコープを定義できます。^[1]

HTTP はステートレス プロトコルです。ステートレス プロトコルでは、複数のリクエストの期間中、Web サーバーが各ユーザーに関する情報やステータスを保持する必要がありません。

一部のWebアプリケーションではユーザーセッションを管理する必要があるため、HTTPクッキー^[46]やWebフォーム内の隠し変数などを使用して状態、つまりサーバー側セッションを実装します。

アプリケーション ユーザー セッションを開始するには、 Web アプリケーションログインによる対話型認証を実行する必要があります。ユーザー セッションを停止するには、ユーザーがログアウト操作を要求する必要があります。これらの種類の操作では、HTTP 認証は使用されず、カスタム管理された Web アプリケーション認証が使用されます。

リクエストメッセージはクライアントからターゲットサーバーに送信されます。^{[注 4]}

クライアントはサーバーにリクエストメッセージを送信します。リクエストメッセージは以下のとおりです。 ^[47]

• リクエスト ライン。大文字と小文字を区別するリクエスト メソッド、スペース、リクエストされた URL、別のスペース、プロトコル バージョン、キャリッジ リターン、およびライン フィードで構成されます。例:

GET  /images/logo.png  HTTP / 1.1

• 0 個以上のリクエスト ヘッダー フィールド(HTTP/1.1 の場合は少なくとも 1 個以上のヘッダー)。各フィールドは、大文字と小文字を区別しないフィールド名、コロン、オプションの先頭の空白、フィールド値、オプションの末尾の空白で構成され、最後にキャリッジ リターンと改行が付きます。例:

ホスト: www.example.com
受け入れ言語: en

• 復帰と改行からなる空行。
• オプションのメッセージ本文。

HTTP/1.1 プロトコルでは、を除くすべてのヘッダー フィールドはHost: hostnameオプションです。

パス名のみを含むリクエスト行は、RFC  1945のHTTP/1.0仕様以前のHTTPクライアントとの互換性を維持するためにサーバーによって受け入れられます。 ^[48]

HTTP は、特定のリソースに対して実行する目的のアクションを示すメソッド (動詞と呼ばれることもありますが、仕様書のどこにも動詞については触れられていません) を定義します。このリソースが表すものが、既存のデータであるか動的に生成されるデータであるかは、サーバーの実装によって異なります。多くの場合、リソースはファイルまたはサーバー上にある実行可能ファイルの出力に対応します。HTTP/1.0 仕様^[49]では、GET、HEAD、POST メソッドが定義され、追加メソッドとして PUT、DELETE、LINK、UNLINK メソッドがリストされています。ただし、HTTP/1.1 仕様^[50]では、PUT、DELETE、CONNECT、OPTIONS、TRACE の 5 つの新しいメソッドが正式に定義され、追加されました。どのクライアントでもどのメソッドも使用でき、サーバーは任意のメソッドの組み合わせをサポートするように構成できます。メソッドが中間者に認識されていない場合は、安全でない非べき等メソッドとして扱われます。定義できるメソッドの数に制限はありません。これにより、既存のインフラストラクチャを壊すことなく将来のメソッドを指定できます。たとえば、WebDAV では7 つの新しいメソッドが定義され、RFC 5789 ではPATCHメソッド が指定されました。

メソッド名は大文字と小文字が区別されます。^{[51] [52]}これは、大文字と小文字を区別しないHTTPヘッダーフィールド名とは対照的です。^[53]

得る

GETメソッドは、ターゲットリソースにその状態の表現を転送するよう要求します。GETリクエストはデータのみを取得し、他の効果はありません。（これは他のHTTPメソッドにも当てはまります。）^{[1]変更を加えずにリソースを取得するには、} URLでアドレス指定できるGETがPOSTよりも好まれます。これにより、ブックマークと共有が可能になり、GET応答がキャッシュの対象となり、帯域幅を節約できます。W3Cはこの区別に関するガイダンス原則を公開しており、「Webアプリケーション設計は、上記の原則だけでなく、関連する制限にも基づいて行う必要があります。」と述べています。 ^[54]以下の安全な方法を参照してください。

頭

HEAD メソッドは、GET リクエストの場合と同様に、ターゲット リソースがその状態の表現を転送することを要求しますが、応答本体に表現データは含まれません。これは、表現全体を転送せずに、応答ヘッダー内の表現メタデータを取得するのに役立ちます。使用法としては、ステータス コードを通じてページが利用可能かどうかを確認したり、ファイルのサイズをすばやく見つけたりすることなどがあります( Content-Length)。

役職

POSTメソッドは、対象リソースがリクエストに含まれる表現をそのリソースのセマンティクスに従って処理することを要求します。たとえば、インターネットフォーラムにメッセージを投稿したり、メーリングリストに登録したり、オンラインショッピングの取引を完了したりするために使用されます。^[55]

置く

PUTメソッドは、ターゲットリソースがリクエスト内に含まれる表現によって定義された状態を作成または更新することを要求します。POSTとの違いは、クライアントがサーバー上のターゲットの場所を指定することです。^[56]

消去

DELETE メソッドは、ターゲット リソースの状態を削除するように要求します。

接続する

CONNECTメソッドは、中継者がリクエストターゲットで識別されるオリジンサーバーへのTCP/IPトンネルを確立することを要求します。これは、 TLSを使用して1つ以上のHTTPプロキシを介して接続を保護するためによく使用されます。^{[57] [58]} HTTP CONNECTメソッドを参照してください。

オプション

OPTIONS メソッドは、ターゲット リソースがサポートする HTTP メソッドを転送することを要求します。これを使用すると、特定のリソースの代わりに '*' を要求することで、Web サーバーの機能をチェックできます。

トレース

TRACE メソッドは、ターゲット リソースが受信したリクエストをレスポンス本文で転送するように要求します。これにより、クライアントは仲介者によって行われた変更や追加 (ある場合) を確認できます。

パッチ

PATCHメソッドは、リクエストに含まれる表現で定義された部分的な更新に従って、ターゲットリソースの状態を変更するように要求します。これにより、ファイルまたはドキュメント全体を転送せずに一部を更新することで帯域幅を節約できます。^[59]

すべての汎用ウェブサーバーは少なくともGETメソッドとHEADメソッドを実装する必要があり、他のメソッドは仕様ではオプションとみなされています。^[52]

リクエスト メソッドが安全であるのは、そのメソッドを使用したリクエストがサーバーに意図した効果をもたらさない場合です。GET、HEAD、OPTIONS、および TRACE メソッドは安全であると定義されています。つまり、安全なメソッドは読み取り専用であることが意図されています。安全なメソッドでも、リクエスト情報をログ ファイルに追加したり、広告アカウントに課金したりするなど、クライアントには見えない副作用が生じる可能性があります。

対照的に、POST、PUT、DELETE、CONNECT、および PATCH メソッドは安全ではありません。これらのメソッドは、サーバーの状態を変更したり、電子メールの送信などの他の効果をもたらす可能性があります。したがって、このようなメソッドは、準拠しているWeb ロボットや Web クローラーでは通常使用されません。準拠していない一部のメソッドは、コンテキストや結果を考慮せずにリクエストを行う傾向があります。

GETリクエストの安全性は規定されているものの、実際にはサーバーによるGETリクエストの処理は技術的にはまったく制限されていません。不注意または故意に不規則なプログラミングを行うと、GETリクエストによってサーバー上で重大な変更が発生する可能性があります。これは、 Webキャッシュ、検索エンジン、およびその他の自動化エージェントがサーバー上で意図しない変更を行った場合に問題が発生する可能性があるため、推奨されません。たとえば、Webサイトでは、https://example.com/article/1234/deleteなどのURLを介してリソースの削除を許可している場合があります。このURLを任意に取得すると、GETを使用しても、単に記事が削除されます。^[60]適切にコーディングされたWebサイトでは、このアクションにはDELETEまたはPOSTメソッドが必要ですが、悪意のないボットはこれを行いません。

実際に起こった例としては、短命だったGoogle Web Acceleratorのベータ版がある。このベータ版は、ユーザーが閲覧しているページ上の任意のURLをプリフェッチし、レコードを自動的に変更したり、大量に削除したりするものだった。このベータ版は、広範囲にわたる批判を受けて、最初のリリースからわずか数週間で停止された。^{[61] [60]}

リクエストメソッドがべき等であるとは、そのメソッドを使用した複数の同一リクエストが、単一のリクエストと同じ効果を持つ場合です。PUT メソッドと DELETE メソッド、および安全なメソッドはべき等であると定義されています。安全なメソッドは、サーバーにまったく影響を与えないことを意図しているため、自明にべき等です。一方、PUT メソッドと DELETE メソッドは、連続する同一リクエストが無視されるため、べき等です。たとえば、Web サイトは、ユーザーの記録された電子メール アドレスを変更するために PUT エンドポイントを設定する場合があります。このエンドポイントが正しく構成されていれば、ユーザーの電子メール アドレスを、すでに記録されている同じ電子メール アドレスに変更することを要求するリクエスト (成功したリクエストの後の重複したリクエストなど) は効果がありません。同様に、特定のユーザーを削除するリクエストは、そのユーザーがすでに削除されている場合は効果がありません。

対照的に、POST、CONNECT、および PATCH メソッドは必ずしもべき等ではないため、同一の POST 要求を複数回送信すると、サーバーの状態がさらに変更されたり、複数の電子メールが送信されるなどの他の影響が生じたりする可能性があります。これは、場合によっては望ましい効果ですが、誤って発生することもあります。たとえば、最初のクリックが処理中であるという明確なフィードバックがない場合、ユーザーはボタンを再度クリックして、誤って複数の POST 要求を送信する可能性があります。Web ブラウザーは、ページの再読み込みによって POST 要求が再送信される可能性がある場合にユーザーに警告するアラート ダイアログ ボックスを表示することがありますが、POST 要求を複数回送信してはならない場合の処理​​は、通常、Web アプリケーション次第です。

メソッドがべき等であるかどうかは、プロトコルや Web サーバーによって強制されるわけではないことに注意してください。たとえば、データベースの挿入やその他のべき等ではないアクションが GET やその他のリクエストによってトリガーされる Web アプリケーションを作成することは完全に可能です。ただし、推奨事項に反してこれを行うと、ユーザー エージェントが同じリクエストを繰り返すことが安全であると想定した場合 (実際には安全ではない場合)、望ましくない結果が生じる可能性があります。

リクエスト メソッドは、そのメソッドを使用したリクエストへの応答が将来の再利用のために保存される場合、 キャッシュ可能です。GET、HEAD、および POST メソッドはキャッシュ可能として定義されています。

対照的に、PUT、DELETE、CONNECT、OPTIONS、TRACE、および PATCH メソッドはキャッシュできません。

リクエスト ヘッダー フィールドを使用すると、クライアントはリクエスト ラインを超えて追加情報を渡すことができ、リクエスト修飾子として機能します (プロシージャのパラメーターと同様)。リクエスト ヘッダー フィールドは、クライアント、ターゲット リソース、またはリクエストの予想される処理に関する情報を提供します。

応答メッセージは、以前の要求メッセージに対する返答としてサーバーからクライアントに送信されます。^{[注 4]}

サーバーはクライアントに応答メッセージを送信します。応答メッセージは以下のとおりです。 ^[47]

• ステータスライン(プロトコル バージョン、スペース、応答ステータス コード、別のスペース、空の可能性のある理由フレーズ、キャリッジ リターン、およびライン フィードから構成されます)。例:

  HTTP / 1.1  200  OK
  

• 0 個以上の応答ヘッダー フィールド。各フィールドは、大文字と小文字を区別しないフィールド名、コロン、オプションの先頭の空白、フィールド値、オプションの末尾の空白で構成され、最後にキャリッジ リターンと改行が付きます。例:

  コンテンツタイプ: text/html
  

• 復帰と改行からなる空行。
• オプションのメッセージ本文。

HTTP/1.0 以降では、HTTP 応答の最初の行はステータス ラインと呼ばれ、数値のステータス コード(「 404 」など) とテキストの理由フレーズ(「見つかりません」など) が含まれます。応答ステータス コードは、サーバーがクライアントの対応する要求を理解して満たそうとした結果を表す 3 桁の整数コードです。クライアントが応答を処理する方法は、主にステータス コードによって決まり、次に他の応答ヘッダー フィールドによって決まります。クライアントは登録されているすべてのステータス コードを理解できるとは限りませんが、クラス (ステータス コードの最初の桁で指定) を理解し、認識できないステータス コードをそのクラスの x00 ステータス コードと同等として扱う必要があります。

標準の理由フレーズは推奨事項にすぎず、Web 開発者の裁量で「ローカルの同等物」に置き換えることができます。ステータス コードが問題を示している場合、ユーザー エージェントは、問題の性質に関する詳細情報を提供するために、理由フレーズをユーザーに表示する場合があります。標準では、ユーザー エージェントが理由フレーズを解釈することも許可されていますが、標準ではステータス コードは機械可読であり、理由フレーズは人間が判読可能であることが明示的に指定されているため、これは賢明ではない可能性があります。

ステータス コードの最初の桁はクラスを定義します。

1XX（情報提供）

リクエストを受信しました。処理を続行します。

2XX（成功）

リクエストは正常に受信され、理解され、受け入れられました。

3XX（リダイレクション）

リクエストを完了するには、さらにアクションを実行する必要があります。

4XX(クライアントエラー)

リクエストに不正な構文が含まれているか、リクエストを満たすことができません。

5XX(サーバーエラー)

サーバーは明らかに有効な要求を処理できませんでした。

レスポンス ヘッダー フィールドを使用すると、サーバーはステータス ラインを超えて追加情報を渡すことができ、レスポンス修飾子として機能します。サーバーに関する情報や、ターゲット リソースまたは関連リソースへのさらなるアクセスに関する情報を提供します。

各応答ヘッダー フィールドには定義された意味があり、リクエスト メソッドまたは応答ステータス コードのセマンティクスによってさらに細かく定義できます。

以下は、HTTP/1.1クライアントとwww.example.comのポート80で実行されているHTTP/1.1サーバー間のHTTPトランザクションの例です。^{[注5] [注6]}

GET  /  HTTP / 1.1
ホスト:  www.example.com
ユーザーエージェント:  Mozilla/5.0
受け入れ:  text/html、application/xhtml+xml、application/xml;q=0.9、image/avif、image/webp、*/*;q=0.8 受け入れ
言語:  en-GB、en;q=0.5
受け入れエンコード:  gzip、deflate、br
接続:  keep-alive

クライアント リクエスト (この場合は、リクエスト ラインと、ヘッダーのみに縮小できるいくつかのヘッダーから構成されます) の後には空白行が続きます。そのため、リクエストは、それぞれキャリッジ リターンとライン フィード"Host: hostname"の形式で、2 つの行末で終了します。ヘッダー値は、単一のIP アドレスを共有するさまざまなDNS名を区別し、名前ベースの仮想ホスティングを可能にします。HTTP/1.0 ではオプションですが、HTTP/1.1 では必須です。(「/」(スラッシュ) は通常、 /index.htmlファイルがあれば それを取得します。)"Host: hostname"

HTTP / 1.1  200  OK
日付:  2005 年 5 月 23 日月曜日 22:38:34 GMT
コンテンツ タイプ:  text/html; charset=UTF-8
コンテンツ長:  155
最終更新日:  2003 年 1 月 8 日水曜日 23:11:55 GMT
サーバー:  Apache/1.3.3.7 (Unix) (Red-Hat/Linux) 
ETag :  "3f80f-1b6-3e1cb03b"
受け入れ範囲: バイト
接続: 閉じる

< html > 
  < head > 
    < title >サンプルページ</ title > 
  </ head > 
  < body > 
    < p > Hello World、これは非常にシンプルな HTML ドキュメントです。</ p > 
  </ body > 
</ html >

ETag (エンティティタグ) ヘッダーフィールドは、要求されたリソースのキャッシュされたバージョンが、サーバー上のリソースの現在のバージョンと同一であるかどうかを判断するために使用されます。は、HTTPメッセージによって伝達されるデータのインターネットメディアタイプ"Content-Type"を指定し、はバイト単位での長さを示します。HTTP/1.1 Web サーバーは、フィールドを設定することで、ドキュメントの特定のバイト範囲に対する要求に応答する機能を公開します。これは、クライアントがサーバーから送信されたリソースの特定の部分^[62]のみを必要とする場合に便利です。これはバイトサービングと呼ばれます。が送信されると、 Web サーバーはこの応答の転送が終了した直後にTCP接続を閉じることを意味します。 ^[22]"Content-Length""Accept-Ranges: bytes""Connection: close"

ヘッダー行のほとんどはオプションですが、一部は必須です。"Content-Length: number"エンティティ本体を含む応答でヘッダーが欠落している場合、HTTP/1.0 ではエラーと見なされますが、ヘッダー"Transfer-Encoding: chunked"が存在する場合は HTTP/1.1 ではエラーにならない場合があります。チャンク転送エンコーディングでは、コンテンツの終わりを示すためにチャンク サイズ 0 を使用します。HTTP/1.0 の古い実装の中には"Content-Length"、応答の開始時に本体エンティティの長さが不明な場合にヘッダーを省略するものがあり、そのためサーバーがソケットを閉じるまでクライアントへのデータ転送が継続されていました。

A は、送信データの本体エンティティ部分が gzip アルゴリズムによって圧縮されていることをクライアントに通知するために使用できます。 "Content-Encoding: gzip"

暗号化されたHTTP接続を確立する最も一般的な方法はHTTPSです。^[63]暗号化されたHTTP接続を確立する他の2つの方法も存在します。セキュアハイパーテキスト転送プロトコルと、HTTP/1.1アップグレードヘッダーを使用してTLSへのアップグレードを指定する方法です。ただし、これら2つのブラウザサポートはほとんどありません。^{[64] [65] [66]}

• Gopher プロトコルは、 1990年代初頭に HTTP に置き換えられたコンテンツ配信プロトコルです。
• SPDYプロトコルは、Googleで開発された HTTP の代替であり、HTTP/2に置き換えられました。
• Gemini プロトコルは、プライバシー関連の機能を義務付ける Gopher に触発されたプロトコルです。

• InterPlanetary File System  – HTTPを置き換えることができる
• ファイル転送プロトコルの比較
• 制約付きアプリケーションプロトコル- HTTPと意味的に類似したプロトコルだが、UDPまたはUDPのようなメッセージを使用し、処理能力が制限されたデバイスを対象としている。HTTPとインターネットメディアタイプやウェブリンクなどの他のインターネット概念を再利用する（RFC 5988）^[67]
• コンテンツ交渉
• ダイジェストアクセス認証
• HTTP 圧縮
• HTTP/2 – IETFのハ​​イパーテキスト転送プロトコル（httpbis）ワーキンググループによって開発された^[36]
• HTTP ヘッダーフィールドのリスト
• HTTP ステータス コードのリスト
• 表現状態転送(REST)
• バリアントオブジェクト
• ワイヤレス アプリケーション プロトコル
• ウェブキャッシュ
• ウェブソケット

Wikibooks には、通信ネットワーク/HTTP プロトコルに関する書籍があります。

ウィキメディア・コモンズには、ハイパーテキスト転送プロトコルに関連するメディアがあります。

• 公式サイト
• GitHubの IETF HTTP ワーキング グループ
• 「HTTP の変更履歴」。W3.org。2010年 8 月 1 日閲覧。HTTP の詳細な技術史。
• 「HTTP の設計上の問題」。W3.org。2010年 8 月 1 日閲覧。プロトコルを設計していたときのバーナーズ＝リーによる設計上の問題。