Loading article…
HTTP（Hypertext Transfer Protocol）は、分散型で協調的なハイパーメディア情報システムのためのインターネットプロトコルスイートのアプリケーション層プロトコルです。 [ 1 ] HTTPはワールドワイドウェブのデータ通信の基盤であり、ハイパーテキスト文書には、ユーザーがマウスのクリックやウェブブラウザの画面タップなどで簡単にアクセスできる他のリソースへのハイパーリンクが含まれています。
HTTPは、クライアント・サーバーモデルにおけるリクエスト・レスポンスプロトコルです。トランザクションは、クライアントがサーバーにリクエストを送信することから始まります。サーバーはリクエストを処理し、リクエストの処理状況を記述したレスポンスをクライアントに返します。レスポンスには、 HTMLドキュメントなどの要求されたリソースが含まれる場合もあります。
一般的なシナリオでは、Webブラウザがクライアントとして機能し、1つ以上のWebサイトをホストするWebサーバーがサーバーとして機能します。Webブラウザはユーザーエージェント（UA）の一例です。その他のユーザーエージェントには、検索エンジンが使用するインデックス作成ソフトウェア（Webクローラー）、音声ブラウザ、モバイルアプリ、およびWebコンテンツにアクセス、利用、表示するその他のソフトウェアが含まれます。
HTTPは、中間ネットワーク要素がクライアントとサーバー間の通信を改善または可能にするように設計されています。トラフィック量の多いWebサイトでは、応答時間を改善するために、上位サーバーに代わってコンテンツを配信するWebキャッシュサーバーが役立つことがよくあります。Webブラウザは、以前にアクセスしたWebリソースをキャッシュし、可能な限り再利用することで、ネットワークトラフィックを削減します。プライベートネットワーク境界にあるHTTPプロキシサーバーは、グローバルにルーティング可能なアドレスを持たないクライアントの通信を、外部サーバーとのメッセージを中継することで容易にします。
中間HTTPノード（プロキシサーバー、Webキャッシュなど）がその機能を果たすことができるように、HTTPヘッダー（HTTPリクエスト/レスポンスに含まれる）の一部はホップバイホップで管理されますが、その他のHTTPヘッダーはエンドツーエンドで管理されます（送信元クライアントとターゲットWebサーバーのみで管理されます）。
ウェブのリソースは、 Uniform Resource Locator (URL)によって特定され、 Uniform Resource Identifier (URI) スキームのhttpとhttpsが使用されます。URI はHTMLドキュメント内でハイパーリンクとしてエンコードされ、相互リンクされたハイパーテキストドキュメントを形成します。[ 2 ]
プロトコルは時間の経過とともに改訂されてきました。バージョンはHTTP/#（#はバージョン番号）という形式で表されます。この記事ではすべてのバージョンについて解説しますが、特にHTTP/0.9、HTTP/1.0、HTTP/1.1に重点を置いています。HTTP /2とHTTP/3については、別の記事で詳細に解説しています。
HTTP/1.0では、リソース要求ごとに同じサーバーへの個別のTCP接続が確立される。 [ 3 ]： §1.3
HTTP/1.1では、TCP接続を再利用して複数のリソース要求（HTMLページ、フレーム、画像、スクリプト、スタイルシートなど）を行うことができます。[ 4 ] : §9.1,9.3そのため、HTTP/1.1通信では、特にトラフィックが多い状況ではTCP接続の確立にかなりのオーバーヘッドが発生するため、レイテンシが少なくなります。[ 5 ]
HTTP/2で追加された機能強化により、HTTP/1.1通信よりもレイテンシが低減され、ほとんどの場合、高速化されます。HTTP/2では以下の機能がサポートされます。
HTTP/3は、TCPの代わりにQUICとUDPトランスポートプロトコルを使用します。使用されるのはIP層のみです（UDPはTCPと同様にIP層を基盤としています）。これにより、通信の平均速度がわずかに向上し、TCP接続の輻輳によって一時的にすべてのストリームのデータフローがブロックまたは遅延する問題（「ヘッドオブラインブロッキング」の一種）を回避できます。
HTTP/2 は、Web サイトの 71% [ 7 ] [ 8 ] (HTTP/2 34.1% + 下位互換性のある HTTP/3 36.9%) でサポートされており、ほぼすべての Web ブラウザ (ユーザーの 98% 以上) でサポートされています。[ 9 ]また、 TLS 1.2以降が必要なアプリケーション層プロトコルネゴシエーション(ALPN) 拡張機能[ 10 ]を使用したトランスポート層セキュリティ(TLS)上の主要な Web サーバーでもサポートされています。[ 6 ]
HTTP/3 は Web サイトの 40% で使用されており[ 11 ]、ほとんどの Web ブラウザでサポートされています。つまり、少なくとも部分的には、ユーザーの 97% がサポートしています。[ 12 ] HTTP/3 は、基盤となるトランスポート プロトコルとしてTCPの代わりにQUICを使用します。 HTTP/2 と同様に、プロトコルの以前のメジャー バージョンを廃止するものではありません。 2019 年に、HTTP/3 のサポートがCloudflareとChrome [ 13 ] [ 14 ]に初めて追加され、 Firefoxでも有効になりました。[ 15 ] HTTP/3 は、実際の Web ページのレイテンシが低く、HTTP/2 よりも高速に読み込まれ、場合によっては、現在でも一般的に有効になっている唯一のプロトコルである HTTP/1.1 よりも 3 倍以上高速です。[ 16 ]
HTTPの安全なバリアントであるHTTPSは、ウェブサイトの90.1%で使用されています。[ 17 ]
HTTP は、基盤となる信頼性の高いトランスポート層プロトコルを前提としています。[ 18 ] : §3.3 HTTP/3 以前の基盤プロトコルの標準的な選択は、伝送制御プロトコル(TCP) です。HTTP/3 は、信頼性の低いUser Datagram Protocol (UDP)の上に信頼性を提供するQUICと呼ばれる別のトランスポート層を使用します。HTTP/1.1 およびそれ以前のプロトコルは、マルチキャストおよびユニキャストの状況で、信頼性の低い通常の UDP 上で使用できるように適応され、HTTPMU および HTTPU を形成しています。これらは、通常ローカルエリアネットワークで実行される 2 つのプロトコルであるUPnPおよびSimple Service Discovery Protocol (SSDP)で使用されます。
HTTP はステートレスなアプリケーション レベルのプロトコルであり、クライアントとサーバー間でデータを交換するために信頼性の高いネットワーク トランスポート接続が必要です。[ 19 ] HTTP の実装では、TCP/IP接続はよく知られたポート(通常、接続が暗号化されていない場合はポート 80 、接続が暗号化されている場合はポート 443、 TCP および UDP ポート番号のリストも参照) を使用して使用されます。[ 18 ] : §4.2.1、4.2.2 HTTP/2 では、TCP/IP 接続と複数のプロトコル チャネルが使用されます。HTTP/3 では、 UDP 上のアプリケーション トランスポート プロトコルQUICが使用されます。
データは、セッション層トランスポート接続を介して交換される一連のリクエスト・レスポンスメッセージによって交換されます。 [ 19 ] HTTPクライアントは最初に、サーバーとの接続（実接続または仮想接続）を確立しようとします。ポートで待機しているHTTPサーバーは接続を受け入れ、クライアントからのリクエストメッセージを待ちます。クライアントはHTTPリクエストメッセージを送信します。サーバーはリクエストを受信すると、必要に応じてヘッダーとボディを含むHTTPレスポンスメッセージを返信します。このレスポンスメッセージのボディは通常、要求されたリソースですが、エラーメッセージやその他の情報が返される場合もあります。クライアントまたはサーバーは、いつでも、さまざまな理由で接続を閉じることができます。接続を閉じることは通常、最後のリクエストまたはレスポンスの1つ以上のHTTPヘッダーによって通知されます。[ 4 ] : §9.1
HTTP/0.9では、サーバーからの応答が送信されるとTCP/IP接続は必ず閉じられるため、永続的な接続は存在しません。
HTTP/1.0では、応答が送信された後、サーバーは必ずTCP/IP接続を閉じる必要があります。[ 3 ] [注2 ]
HTTP/1.1では、接続を複数のリクエスト/レスポンスで再利用できるように、キープアライブメカニズムが正式に導入されました。このような永続的な接続により、クライアントは最初のリクエスト送信後にTCP 3ウェイハンドシェイク接続を再ネゴシエートする必要がなくなるため、リクエストの遅延が大幅に軽減されます。また、TCPのスロースタートメカニズムにより、接続速度が時間とともに向上するという利点もあります。
HTTP/1.1では、クライアントが各応答を待つ前に複数のリクエストを送信できるようにすることで、永続接続使用時の遅延時間をさらに短縮するためにHTTPパイプライン機能が追加されました。しかし、この最適化は、一部のWebサーバーや多くのプロキシサーバー、特にクライアントとサーバー間のインターネット/イントラネットに配置された透過型プロキシサーバーがパイプラインリクエストを適切に処理しなかったため、安全とはみなされませんでした（最初のリクエストのみを処理して他のリクエストを破棄したり、最初のリクエストの後にデータが追加されたために接続を閉じたり、一部のプロキシが応答を順不同で返したりするなど）。そのため、HEADリクエストと一部のGETリクエスト（つまり、実際のファイルリクエストに限定され、クエリ文字列がコマンドとして使用されていないURLなど）のみが、安全かつ冪等なモードでパイプライン処理できました。パイプライン機能の有効化によって生じた問題に長年苦慮した後、この機能はまず無効化され、その後ほとんどのブラウザから削除されました。また、HTTP/2の採用が発表されたことも、パイプライン機能の削除理由の一つでした。
HTTP/2は、単一のTCP/IP接続を介して多数の同時リクエスト/レスポンスを多重化することにより、永続的な接続の利用範囲を拡大した。
HTTP/3はTCP/IP接続ではなく、QUIC + UDP接続を使用します。
HTTP/0.9では、要求されたリソースは常に全体が送信されていました。
HTTP/1.0では、条件付きGETリクエストを可能にするために、クライアントによってキャッシュされたリソースを管理するためのヘッダーが追加されました。
Content-Encoding、返されるコンテンツが圧縮されているかどうかを指定するために追加されました。Content-Length。クライアントは接続が閉じられた時点で転送が完了したと想定しますが、接続が途中で閉じられると、クライアントには部分的なコンテンツが残りますが、クライアントはそれが部分的であることに気づきません。HTTP/1.1が導入され、以降のバージョンでは以下の機能が追加されました。
HTTPはステートレスなプロトコルであるため、Webサーバーは複数のリクエストの間、各ユーザーに関する情報や状態を保持する必要はありません。Webアプリケーションがアプリケーションセッションを必要とする場合、 HTTPクッキー[ 21 ]、Webフォーム内の隠し変数、またはその他のメカニズムを介してそれを実装します。
通常、セッションを開始するには対話型のログインを行い、セッションを終了するにはユーザーによるログアウト要求を行います。これらの操作では、 HTTP認証ではなく、独自の認証メカニズムが使用されます。
HTTPは、基本アクセス認証やダイジェストアクセス認証など、複数の認証方式を提供しており、これらはチャレンジ・レスポンス方式で動作します。この方式では、サーバーが要求されたコンテンツを提供する前に、認証要求を識別して発行します。
HTTPは、拡張可能なチャレンジ・レスポンス認証スキームを介して、アクセス制御と認証のための一般的なフレームワークを提供します。これは、サーバーがクライアントのリクエストに異議を申し立てたり、クライアントが認証情報を提供したりするために使用できます。[ 18 ]
上記で説明した認証メカニズムはHTTPプロトコルに属し、クライアントおよびサーバーのHTTPソフトウェア（クライアントが1つ以上のWebリソースにアクセスする前に認証を要求するように構成されている場合）によって管理され、アプリケーションセッションを使用するWebアプリケーションによって管理されるものではありません。
HTTP認証仕様には、特定のルートURIに共通するリソースをさらに分割するための、実装固有の任意の構造を提供するレルムが含まれています。レルム値文字列が存在する場合、正規ルートURIと組み合わされて、チャレンジの保護空間コンポーネントが形成されます。これにより、サーバーは1つのルートURIの下に個別の認証スコープを定義できるようになります。[ 1 ]
暗号化された HTTP 接続を確立する最も一般的な方法はHTTPSです。[ 22 ]暗号化された HTTP 接続を確立する他の 2 つの方法も存在します。セキュア ハイパーテキスト転送プロトコル ( HTTPS)と、HTTP/1.1 Upgrade ヘッダーを使用してTLS へのアップグレードを指定する方法です。ただし、これらの 2 つのブラウザのサポートはほとんどありません。[ 23 ] [ 24 ] [ 25 ]
このセクションでは、HTTP/1.1 のメッセージについて説明します。後のバージョンであるHTTP/2 [ 26 ]およびHTTP/3では、バイナリ プロトコルが使用され、ヘッダーはHPACK [ 27 ]HEADERS (HTTP/2) または QPACK (HTTP/3) を使用して 1 つまたは 0 個以上のCONTINUATIONフレームにエンコードされます。これらはどちらも効率的なヘッダー圧縮を提供します。HTTP/1 のリクエスト行またはレスポンス行も、それぞれコロン ( ) で始まる複数の擬似ヘッダー フィールドに置き換えられています。:
最も基本的なレベルでは、メッセージはヘッダーとそれに続く本文で構成されます。
ヘッダーはASCIIテキストの行で構成され、各行はキャリッジリターンとラインフィードのシーケンスで終了します。リクエストヘッダーとレスポンスヘッダーのレイアウトは次のとおりです。
本文は、ASCII形式に限らず、あらゆる形式のデータで構成されます。Content-Typeメッセージにヘッダーフィールドがある場合は、その形式と一致する必要があります。本文は省略可能であり、つまり空白でも構いません。
HTTP/2以前は、 「エンティティ」という用語は、本文と、本文を記述するヘッダーフィールドを合わせたものを指していました。特に、すべてのヘッダーがエンティティの一部とみなされていたわけではありません。「エンティティヘッダー」という用語は、エンティティの一部とみなされるヘッダーを指し、本文自体が「エンティティ本文」と呼ばれることもありました。現代のドキュメントでは、 「エンティティ」という用語を使用せず、「本文」と「ヘッダー」という用語を使用しています。
ヘッダーフィールドは、含まれるメッセージに関するメタデータを表します。例としては、本文のエンコード方法（Content-Encodingによる）、セッションの検証とクライアントの識別（ブラウザの Cookie、IP アドレス、ユーザーエージェントなど）、またはその匿名性（VPN やプロキシによるマスキング、ユーザーエージェントのなりすましなど）、サーバーがデータをどのように処理すべきか（Do-Not-TrackやGlobal Privacy Controlなど）、ダウンロード中のドキュメントの経過時間（共有キャッシュに保持されていた時間）などが挙げられます。一般的に、ヘッダーフィールドの情報はソフトウェアによって使用され、ユーザーには表示されません。
ヘッダー フィールド行は、コロン区切りの名前と値のペアとしてフォーマットされます。名前の周囲に空白文字は使用できませんが、値の部分の先頭と末尾の空白文字は無視されます。完全に一致する必要があるメソッド名（大文字小文字を区別）とは異なり、[ 28 ]ヘッダー フィールド名は、各単語が大文字で表示されることが多いものの、大文字小文字を区別せずに一致します。[ 29 ]例えば、以下は と のヘッダー フィールドHostですAccept-Language。
ホスト: www.example.com Accept-Language: en
標準規格では、ヘッダーフィールドのサイズやメッセージ内のフィールド数に制限はありません。ただし、ほとんどのサーバー、クライアント、プロキシソフトウェアは、実用的およびセキュリティ上の理由から制限を設けています。たとえば、Apache 2.3サーバーはデフォルトで各フィールドのサイズを8190バイトに制限し、1つのリクエストには最大100個のヘッダーフィールドを含めることができます。[ 30 ]
RFC 7230 [ 31 ]で非推奨とされていますが、過去には、長い行をスペースまたはタブ文字で始まる継続行で複数の行に分割することができました。
クライアントからサーバーにリクエストが送信されます。開始行には、メソッド名、リクエストURI、プロトコルバージョンが各フィールド間に1つのスペースで区切られて含まれています。[ 32 ]次のリクエスト開始行は、メソッドGET、URI /customer/123、プロトコルバージョンを指定しますHTTP/1.1。
GET /customer/123 HTTP/1.1
リクエストヘッダーフィールドを使用すると、クライアントはリクエスト行を超えて追加情報を渡すことができ、リクエスト修飾子（プロシージャのパラメータと同様）として機能します。これらは、クライアント、ターゲットリソース、またはリクエストの想定される処理に関する情報を提供します。HTTP/1.1 プロトコルでは、を除くすべてのヘッダーフィールドはHostオプションです。
RFC 1945の HTTP/1.0 仕様以前の HTTP クライアントとの互換性を維持するために、パス名のみを含むリクエスト行がサーバーによって受け入れられます。[ 33 ]
プロトコルは、トランザクションをリソース上での操作として構成します。リソースが何を表すか（既存のデータか動的に生成されるデータか）は、サーバーの実装によって異なります。多くの場合、リソースはファイル、またはサーバー上で実行されている実行可能ファイルの出力に対応します。
リクエストは、リソースに対して実行される目的のアクションを分類するためのメソッド（非公式には動詞と呼ばれることもあります）を識別します。HTTP/1.0 仕様[ 3 ] : §8 では、GET、HEAD、POST メソッドが定義され、PUT、DELETE、LINK、UNLINK メソッドが追加メソッドとしてリストされています。しかし、HTTP/1.1 仕様[ 34 ] : §9では、PUT、DELETE、CONNECT、OPTIONS、TRACE の 5 つの新しいメソッドが追加されました。どのクライアントもどのメソッドでも使用でき、サーバーはメソッドの任意の組み合わせをサポートするように構成できます。メソッドが中間者にとって未知の場合、それは安全でない非冪等メソッドとして扱われます。定義できるメソッドの数に制限はないため、既存のインフラストラクチャを壊すことなく将来のメソッドを指定できます。たとえば、WebDAV では7 つの新しいメソッドが定義され、RFC 5789ではPATCHメソッドが指定されました。汎用ウェブサーバーは少なくともGETとHEADを実装する必要があり、その他のメソッドは仕様上オプションとみなされる。[ 18 ]： §9.1
メソッド名は大文字と小文字を区別します。[ 4 ]： §3 [ 18 ]： §9.1これは、大文字と小文字を区別しないHTTPヘッダーフィールド名とは対照的です。[ 18 ]： §6.3
Content-Length。リクエストメソッドが安全であるとは、そのメソッドを使用したリクエストがサーバーに意図的な影響を与えない場合を指します。GET、HEAD、OPTIONS、TRACE メソッドは安全なメソッドとして定義されています。つまり、安全なメソッドは読み取り専用として設計されています。ただし、安全なメソッドであっても、クライアントからは見えない副作用（リクエスト情報をログファイルに追加したり、広告アカウントに課金したりするなど）が発生する可能性があります。
対照的に、POST、PUT、DELETE、CONNECT、PATCHといったメソッドは安全ではありません。これらのメソッドはサーバーの状態を変更したり、メール送信などの他の影響を与える可能性があります。そのため、これらのメソッドは通常、準拠したWebロボットやWebクローラーでは使用されません。一方、準拠していない一部のロボットやクローラーは、状況や結果を考慮せずにリクエストを送信する傾向があります。
GETリクエストの安全性が規定されているにもかかわらず、実際にはサーバーによるGETリクエストの処理は技術的に制限されていません。不注意なプログラミングや意図的な不規則なプログラミングによって、GETリクエストがサーバー上で重大な変更を引き起こす可能性があります。これは、 Webキャッシュ、検索エンジン、その他の自動化されたエージェントがサーバー上で意図しない変更を行った場合に発生する問題があるため、推奨されません。たとえば、Webサイトでは、 https://example.com/article/1234/deleteのようなURLを介してリソースを削除できますが、GETを使用しても、このURLが任意に取得されると、単に記事が削除されます。[ 39 ]適切にコーディングされたWebサイトでは、この操作にはDELETEまたはPOSTメソッドが必要であり、悪意のないボットはこれを行いません。
実際にこのようなことが起こった例の一つは、短命に終わったGoogle Web Acceleratorのベータ版で、ユーザーが閲覧しているページの任意のURLをプリフェッチし、レコードが自動的に一括変更または削除されるという事態が発生した。ベータ版は、最初のリリースからわずか数週間後に、広範な批判を受けて中止された。[ 40 ]
リクエストメソッドは、そのメソッドを使用した複数の同一のリクエストが単一のリクエストと同じ効果を持つ場合、冪等であると言えます。PUT メソッドと DELETE メソッド、およびセーフ メソッドは冪等であると定義されています。セーフ メソッドは、サーバーに一切影響を与えないことを意図しているため、自明に冪等です。一方、PUT メソッドと DELETE メソッドは、連続する同一のリクエストが無視されるため、冪等です。たとえば、Web サイトは、ユーザーの登録済みメールアドレスを変更する PUT エンドポイントを設定することができます。このエンドポイントが正しく設定されていれば、既に登録されているメールアドレスと同じメールアドレスに変更するよう要求するリクエスト（たとえば、リクエストが成功した後に重複して送信されるリクエスト）は効果がありません。同様に、特定のユーザーを削除する DELETE リクエストは、そのユーザーが既に削除されている場合は効果がありません。
一方、POST、CONNECT、PATCH メソッドは必ずしも冪等性を持つとは限らないため、同一の POST リクエストを複数回送信すると、サーバーの状態がさらに変更されたり、複数のメールが送信されるなどの別の影響が生じる可能性があります。場合によってはこれが望ましい結果となることもありますが、意図せず発生することもあります。たとえば、最初のクリックが処理されているという明確なフィードバックがない場合、ユーザーはボタンを再度クリックして、誤って複数の POST リクエストを送信してしまう可能性があります。Webブラウザは、ページの再読み込みによって POST リクエストが再送信される可能性がある場合に、ユーザーに警告するアラート ダイアログボックスを表示することがありますが、POST リクエストが複数回送信されないように処理するのは、一般的に Web アプリケーションの役割です。
メソッドが冪等であるかどうかは、プロトコルやウェブサーバーによって強制されるものではないことに注意してください。例えば、GETリクエストなどのリクエストによってデータベースへの挿入やその他の冪等でない操作がトリガーされるウェブアプリケーションを作成することは十分に可能です。しかし、推奨事項に反してそのようなことを行うと、ユーザーエージェントが同じリクエストを繰り返しても安全だと誤って判断した場合、望ましくない結果を招く可能性があります。
リクエストメソッドがキャッシュ可能であるとは、そのメソッドによるリクエストに対するレスポンスを将来の再利用のために保存できる場合を指します。GET、HEAD、POSTメソッドはキャッシュ可能であると定義されています。
一方、PUT、DELETE、CONNECT、OPTIONS、TRACE、およびPATCHメソッドはキャッシュできません。
サーバーからクライアントに応答が送信されます。応答の開始行は、プロトコル バージョン、ステータス コード、およびオプションで理由フレーズで構成され、フィールドは単一のスペース文字で区切られています。[ 4 ]： §2.1次の応答の開始行は、プロトコル バージョンHTTP/1.1、ステータス コード400、および理由フレーズを指定しますBad Request。
HTTP/1.1 400 不正なリクエスト
レスポンスヘッダーフィールドを使用すると、サーバーはステータス行以外に追加情報を渡すことができ、レスポンス修飾子として機能します。これらのフィールドは、サーバーに関する情報、またはターゲットリソースや関連リソースへのさらなるアクセスに関する情報を提供します。各レスポンスヘッダーフィールドには定義済みの意味があり、リクエストメソッドやレスポンスステータスコードの意味によってさらに詳細化できます。
ステータスコードは、サーバーがクライアントのリクエストを満たそうとした際の処理結果を表す、3桁の10進整数値です。一般的に、クライアントは主にステータスコードに基づいて、次にレスポンスヘッダーフィールドに基づいてレスポンスを処理します。クライアントはサーバーが報告するすべてのステータスコードを理解できるとは限りませんが、最初の桁で示されるクラスを理解し、認識できないコードはそのクラスのx00コードと同等として扱う必要があります。クラスは以下のとおりです。
標準の理由フレーズはあくまで推奨事項です。Webサーバーは、ローカライズされた同等のフレーズを使用することが許可されています。ステータスコードが問題を示している場合、ユーザーエージェントは問題の性質に関する詳細情報を提供するために、理由フレーズをユーザーに表示することがあります。また、標準では、ユーザーエージェントが理由フレーズを解釈しようと試みることも許可されていますが、標準ではステータスコードは機械可読、理由フレーズは人間可読であると明示的に規定されているため、これは賢明ではないかもしれません。
以下は、www.example.comのポート 80 にあるサーバーに対する HTTP/1.1 のリクエスト/レスポンス トランザクションの例です。HTTP/1.0 では、一部のヘッダーが欠落している点を除けば、同じメッセージが使用されます。HTTP/2 と HTTP/3 では、リクエスト/レスポンスのメカニズムは同じですが、HTTP ヘッダーの表現方法が異なります。
以下は本文のないリクエストです。開始行、6つのヘッダーフィールド、および空白行で構成され、それぞれがキャリッジリターンとラインフィードシーケンスで終了します。ヘッダーフィールドは、単一のIPアドレスを共有する複数のDNSHost名を区別し、名前ベースの仮想ホスティングを可能にします。HTTP/1.0ではオプションですが、HTTP/1.1では必須です。
GET / HTTP / 1.1 Host : www.example.com User-Agent : Mozilla/5.0 Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language : en-GB,en;q=0.5 Accept-Encoding : gzip, deflate, br Connection : keep-alive上記の表現では（この wiki の制限のため）明確ではありませんが、末尾の空白行によって 2 つの行末シーケンスで終了します。文字のストリームとして表現すると、上記の短縮版では、<CRLF>行末シーケンスを表すことでこれがより明確になりますGET / HTTP/1.1<CRLF>Host: www.example.com<CRLF><CRLF>。
次の応答では、ETag（エンティティタグ）ヘッダーフィールドを使用して、要求されたリソースのキャッシュされたバージョンがサーバー上のリソースの現在のバージョンと同一かどうかを判断します。Content-Typeヘッダーフィールドは、HTTPメッセージによって伝達されるデータのインターネットメディアタイプをContent-Length指定し、その長さをバイト単位で示します。HTTP/1.1ウェブサーバーは、 を含めることで、リソースのバイト範囲の要求に応答する機能を公開しますAccept-Ranges: bytes。これは、クライアントがサーバーから送信されたリソースの特定の部分[ 41 ]のみを必要とする場合に便利です。これはバイトサービングと呼ばれます。Connection: closeが送信されると、ウェブサーバーはこの応答の転送終了後すぐにTCP接続を閉じます。 [ 4 ]： §9.1
ヘッダーフィールドのほとんどはオプションですが、一部は必須です。Content-Lengthレスポンスボディにヘッダーがない場合、HTTP/1.0 ではエラーとみなされますが、HTTP/1.1 ではヘッダーTransfer-Encoding: chunkedが存在する場合はエラーにならない場合があります。チャンク転送エンコーディングでは、コンテンツの終了を示すためにチャンクサイズ 0 を使用します。HTTP/1.0 の古い実装の中には、レスポンスの開始時にボディの長さが不明な場合にヘッダーを省略しContent-Length、サーバーがソケットを閉じるまでクライアントへのデータ転送を継続するものがありました。
Content-Encoding: gzipクライアントに対し、本文がgzipアルゴリズムに従って圧縮されていることを通知します。
HTTP / 1.1 200 OK Date : Mon, 23 May 2005 22:38:34 GMT Content-Type : text/html; charset=UTF-8 Content-Length : 155 Last-Modified : Wed, 08 Jan 2003 23:11:55 GMT Server : Apache/1.3.3.7 (Unix) (Red-Hat/Linux) ETag : "3f80f-1b6-3e1cb03b" Accept-Ranges : bytes Connection : close<html> <head> <title>サンプルページ</title> </head> <body> <p>こんにちは、世界。これは非常にシンプルなHTMLドキュメントです。</p> </body> </html>
ティム・バーナーズ＝リーとCERNの彼のチームは、HTTP、HTML、WebサーバーとWebブラウザと呼ばれるクライアントユーザーインターフェースの関連技術を発明したとされています。バーナーズ＝リーは、1989年に初めて提案され、現在ワールドワイドウェブとして知られる「ワールドワイドウェブ」プロジェクトという、彼のもう一つのアイデアの普及を支援するためにHTTPを設計しました。HTTPの開発は1989年に開始され、最初のHTTPバージョンである0.9を使用するクライアントとサーバーの動作を説明する簡単な文書にまとめられました。[ 42 ]このバージョンはその後開発され、最終的に公開版の1.0になりました。[ 43 ]初期のHTTP Request for Comments （RFC）文書の開発は、インターネット技術タスクフォース（IETF）とワールドワイドウェブコンソーシアム（W3C）の協調作業で数年後に開始され、その後作業はIETFに移りました。
最初のウェブサーバーは1990年に稼働しました。[ 44 ] [ 45 ]使用されたプロトコルにはGETというメソッドが1つしかなく、サーバーからページを要求するものでした。[ 46 ]サーバーからの応答は常にHTMLページでした。[ 42 ]
1991年、HTTPの最初の公式文書版が700語未満のプレーンテキストとして作成され、このバージョンはHTTP/0.9と名付けられました。これはGETメソッドのみをサポートし、クライアントはサーバーからHTMLドキュメントを取得することしかできず、他のファイル形式や情報のアップロードはサポートしていませんでした。[ 42 ]
1992年以降、基本プロトコルの進化を次の完全版に向けて規定する新しい文書が作成されました。この文書は、バージョン0.9の単純なリクエスト方式と、クライアントHTTPバージョンを含む完全なGETリクエストの両方をサポートしていました。これは、HTTP/1.0の最終作業に先立つ、数多くの非公式HTTP/1.0ドラフトの最初のものでした。[ 43 ]
HTTPプロトコルの新しい機能が必要であり、それらを公式RFC文書として完全に文書化する必要があると決定した後、1995年初頭に、HTTPワーキンググループ（HTTP WG、デイブ・ラゲット が率いる）が設立され、プロトコルを標準化し、拡張された操作、拡張されたネゴシエーション、より豊富なメタ情報、追加のメソッドとヘッダーフィールドを追加することでより効率的になったセキュリティプロトコルと結び付けることを目的としていました。[ 47 ] [ 48 ]
HTTPワーキンググループは、1995年中にプロトコルの新バージョンであるHTTP/1.0とHTTP/1.1を改訂して公開する予定だったが、多くの改訂があったため、そのスケジュールは1年以上続いた。[ 49 ]
HTTPワーキンググループは、HTTP-NG（HTTP Next Generation）と呼ばれる、パフォーマンスや低遅延応答など、以前のバージョンに残っていたすべての問題を解決する、はるか未来のHTTPバージョンを策定することも計画していたが、この作業は数年後にようやく開始され、結局完了することはなかった。
1996年5月、RFC 1945 [ 3 ]が、それまでの4年間、多くのウェブブラウザやウェブサーバーで使用されていたHTTP/1.0のプレスタンダードドラフトの最終版として公開されました。
1996年初頭、開発者たちは、今後策定されるHTTP/1.1仕様の草案を利用して、HTTP/1.0プロトコルの非公式な拡張機能（キープアライブ接続など）を製品に組み込み始めた。[ 20 ]
1996 年初頭から、主要な Web ブラウザと Web サーバー開発者も、標準以前の HTTP/1.1 ドラフト仕様で規定された新機能の実装を開始しました。新しいバージョンのブラウザとサーバーのエンドユーザーによる採用は急速に進みました。1996 年 3 月、ある Web ホスティング会社は、インターネットで使用されているブラウザの 40% 以上が仮想ホスティングを有効にするために新しい HTTP/1.1 ヘッダー「Host」を使用しており、1996 年 6 月までに、同社のサーバーにアクセスするすべてのブラウザの 65% が標準以前の HTTP/1.1 に準拠していると報告しました。[ 50 ]
1997年1月、RFC 2068 [ 51 ]がHTTP/1.1仕様として正式にリリースされました。
1999年6月、RFC 2616 [ 34 ]がリリースされ、以前の（廃止された）HTTP/1.1仕様に基づくすべての改善と更新が盛り込まれた。
以前の HTTP ワーキンググループの 1995 年の計画を引き継ぎ、1997 年にHTTP-NG ワーキンググループが結成され、HTTP-NG (HTTP New Generation) と呼ばれる新しい HTTP プロトコルの開発に着手しました。新しいプロトコルでは、単一の TCP/IP 接続内で HTTP トランザクションの多重化を使用するためのいくつかの提案/ドラフトが作成されましたが、1999 年にグループは活動を停止し、技術的な問題を IETF に引き継ぎました。[ 52 ]
2007年にIETF HTTPワーキンググループ（HTTP WG bisまたはHTTPbis）が再始動し、まず以前のHTTP/1.1仕様を改訂および明確化し、次に将来のHTTP/2仕様（httpbisと命名）を作成および改良することになった。[ 53 ] [ 54 ]
2009年、Googleはブラウザとサーバー間のウェブトラフィックを高速化するために開発したバイナリプロトコルであるSPDYを発表しました。多くのテストで、SPDYの使用はHTTP/1.1の使用よりも実際に高速でした。SPDYはGoogleのChromiumに統合され、その後他の主要なウェブブラウザにも統合されました。[ 55 ]単一のTCP接続上でHTTPストリームを多重化するというアイデアの一部は、W3C HTTP-NGワーキンググループの作業を含むさまざまなソースから取り入れられました。
2012年、HTTPワーキンググループ（HTTPbis）は新しいプロトコルの必要性を発表し、当初はSPDYの側面を検討し[ 56 ] [ 57 ]、最終的にSPDYから新しいプロトコルを派生させることを決定した[ 58 ] 。2015年5月、HTTP/2はRFC 7540として公開された[ 59 ]。このプロトコルは、すでにSPDYをサポートしていたWebブラウザによってすぐに採用され、Webサーバーではよりゆっくりと採用された。
2014年6月、HTTPワーキンググループはRFC 2616を廃止する更新された6部構成のHTTP/1.1仕様をリリースしました[ 34 ]。
2014年に、HTTP/0.9はHTTP/1.1（およびそれ以降）をサポートするサーバーでは非推奨となりました。[ 60 ] : §付録A
HTTP/0.9はリクエストのヘッダーフィールドをサポートしていなかったため、名前ベースの仮想ホスト（Hostヘッダーフィールドの検査によるリソースの選択）をサポートする仕組みがありません。名前ベースの仮想 ホストを実装しているサーバーは、HTTP/0.9のサポートを無効にする必要があります。HTTP/0.9のように見えるリクエストのほとんどは、実際にはクライアントがリクエストターゲットを適切にエンコードできなかったために発生した、構造が不適切なHTTP/1.xリクエストです。
2016年以降、多くのプロダクトマネージャーやユーザーエージェント（ブラウザなど）およびウェブサーバーの開発者は、主に以下の理由から、HTTP/0.9プロトコルのサポートを段階的に廃止し、廃止する計画を立て始めています。[ 66 ]
2022年現在、HTTP/0.9のサポートは公式には完全に廃止されておらず、多くのWebサーバーやブラウザで（サーバー応答のみ）依然として利用可能ですが、通常は無効化されています。HTTP/0.9の廃止にどれくらいの時間がかかるかは不明です。
2020年にHTTP/3の最初のドラフトが公開され、主要なウェブブラウザとウェブサーバーが採用を開始しました。2022年6月6日、IETFはHTTP/3をRFC 9114 [ 67 ]として標準化しました。
2022年6月、RFC文書が公開され、以前の文書の多くが非推奨となり、いくつかの軽微な変更が導入され、HTTPセマンティクスの説明が別の文書にリファクタリングされました。
{{cite web}}: CS1 maint: url-status (リンク)リソースを更新するアクションにGETを使用することです。[...] この問題は、Google Web Acceleratorがリリースされた2005年にRailsの注目を集めました。
