Loading article…
HTTP (Hypertext Transfer Protocol) is an application layer protocol in the Internet protocol suite for distributed, collaborative, hypermedia information systems.[1] HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.
HTTP is a request–response protocol in the client–server model. A transaction starts with a client submitting a request to the server, the server attempts to satisfy the request and returns a response to the client that describes the disposition of the request and optionally contains a requested resource such as an HTML document or other content.
In a common scenario, a web browser acts as the client, and a web server, hosting one or more websites, is the server. A web browser is an example of a user agent (UA). Other types of user agent include the indexing software used by search providers (web crawlers), voice browsers, mobile apps, and other software that accesses, consumes, or displays web content.
HTTP is designed to permit intermediate network elements to improve or enable communications between clients and servers. High-traffic websites often benefit from web cache servers that deliver content on behalf of upstream servers to improve response time. Web browsers cache previously accessed web resources and reuse them, whenever possible, to reduce network traffic. HTTP proxy servers at private network boundaries can facilitate communication for clients without a globally routable address, by relaying messages with external servers.
To allow intermediate HTTP nodes (proxy servers, web caches, etc.) to accomplish their functions, some of the HTTP headers (found in HTTP requests/responses) are managed hop-by-hop whereas other HTTP headers are managed end-to-end (managed only by the source client and by the target web server).
A web resource is located by a uniform resource locator (URL), using the Uniform Resource Identifier (URI) schemes http and https. URIs are encoded as hyperlinks in HTML documents, so as to form interlinked hypertext documents.[2]
The protocol has been revised over time. A version is identified as HTTP/# where # is the version number. This article covers aspects of all versions but provides primary coverage for HTTP/0.9, HTTP/1.0, and HTTP/1.1. Separate articles cover HTTP/2 and HTTP/3 in detail.
In HTTP/1.0, a separate TCP connection to the same server is made for every resource request.[3]:§1.3
In HTTP/1.1, instead a TCP connection can be reused to make multiple resource requests (i.e. of HTML pages, frames, images, scripts, stylesheets, etc.).[4]:§9.1,9.3 HTTP/1.1 communications therefore experience less latency as the establishment of TCP connections presents considerable overhead, especially under high traffic conditions.[5]
Enhancements added with HTTP/2 allow for less latency and, in most cases, higher speeds than HTTP/1.1 communications. HTTP/2 adds support for:
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 サイトの 36.9% で使用されており[ 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は、ウェブサイトの85%以上で使用されています。[ 17 ]
HTTP presumes an underlying and reliable transport layer protocol.[18]:§3.3 The standard choice of the underlying protocol prior to HTTP/3 is Transmission Control Protocol (TCP). HTTP/3 uses a different transport layer called QUIC, which provides reliability on top of the unreliable User Datagram Protocol (UDP). HTTP/1.1 and earlier have been adapted to be used over plain unreliable UDP in multicast and unicast situations, forming HTTPMU and HTTPU. They are used in UPnP and Simple Service Discovery Protocol (SSDP), two protocols usually run on a local area network.
HTTP is a stateless application-level protocol and it requires a reliable network transport connection to exchange data between client and server.[19] In HTTP implementations, TCP/IP connections are used using well-known ports (typically port 80 if the connection is unencrypted or port 443 if the connection is encrypted, see also List of TCP and UDP port numbers).[18]:§4.2.1,4.2.2 In HTTP/2, a TCP/IP connection plus multiple protocol channels are used. In HTTP/3, the application transport protocol QUIC over UDP is used.
Data is exchanged through a sequence of request–response messages which are exchanged by a session layer transport connection.[19] An HTTP client initially tries to establish a connection, real or virtual, with a server. An HTTP server listening on the port accepts the connection and then waits for a client's request message. The client sends its HTTP request message. Upon receiving the request the server sends back an HTTP response message, which includes header(s) plus a body if it is required. The body of this response message is typically the requested resource, although an error message or other information may also be returned. At any time and for many reasons, either the client or server can close the connection. Closing a connection is usually advertised by one or more HTTP headers in the last request or response.[4]:§9.1
In HTTP/0.9, the TCP/IP connection is always closed after server response has been sent, so it is never persistent.
In HTTP/1.0, the TCP/IP connection should always be closed by server after a response has been sent.[3][note 2]
In HTTP/1.1, a keep-alive-mechanism was officially introduced so that a connection could be reused for more than one request/response. Such persistent connections reduce request latency perceptibly because the client does not need to re-negotiate the TCP 3-Way-Handshake connection after the first request has been sent. Another positive side effect is that, in general, the connection becomes faster with time due to TCP's slow-start-mechanism.
HTTP/1.1 added also HTTP pipelining in order to further reduce lag time when using persistent connections by allowing clients to send multiple requests before waiting for each response. This optimization was never considered really safe because a few web servers and many proxy servers, specially transparent proxy servers placed in Internet / Intranets between clients and servers, did not handle pipelined requests properly (they served only the first request discarding the others, they closed the connection because they saw more data after the first request or some proxies even returned responses out of order etc.). Because of this, only HEAD and some GET requests (i.e. limited to real file requests and so with URLs without query string used as a command, etc.) could be pipelined in a safe and idempotent mode. After many years of struggling with the problems introduced by enabling pipelining, this feature was first disabled and then removed from most browsers. Pipelining was also removed because of the announced adoption of HTTP/2.
HTTP/2 extended the usage of persistent connections by multiplexing many concurrent requests/responses through a single TCP/IP connection.
HTTP/3 does not use TCP/IP connections but QUIC + UDP.
In HTTP/0.9, a requested resource was always sent in its entirety.
HTTP/1.0 added headers to manage resources cached by a client in order to allow conditional GET requests.
Content-Encoding was added to specify whether the returned content is compressed.Content-Length would not be included. The client would assume that transfer was complete when the connection closed, but a premature close would leave the client with partial content yet the client would not know it's partial.HTTP/1.1 introduced and later versions provide:
As a stateless protocol, HTTP does not require the web server to retain information or status about each user for the duration of multiple requests. If a web application needs an application session, it implements it via HTTP cookies,[21] hidden variables in a web form or another mechanism.
Typically, to start a session, an interactive login is performed, and to end a session, a logout is requested by the user. These kind of operations use a custom authentication mechanism, not HTTP authentication.
HTTP provides multiple authentication schemes such as basic access authentication and digest access authentication which operate via a challenge–response mechanism whereby the server identifies and issues a challenge before serving the requested content.
HTTP provides a general framework for access control and authentication, via an extensible set of challenge–response authentication schemes, which can be used by a server to challenge a client request and by a client to provide authentication information.[18]
The authentication mechanisms described above belong to the HTTP protocol and are managed by client and server HTTP software (if configured to require authentication before allowing client access to one or more web resources), and not by the web applications using an application session.
The HTTP authentication specification includes realms that provide an arbitrary, implementation-specific construct for further dividing resources common to a given root URI. The realm value string, if present, is combined with the canonical root URI to form the protection space component of the challenge. This in effect allows the server to define separate authentication scopes under one root 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オプションです。
A request line containing only the path name is accepted by servers to maintain compatibility with HTTP clients before the HTTP/1.0 specification in RFC 1945.[33]
The protocol structures transaction as operating on resources. What a resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable running on the server.
A request identifies a method (sometimes informally called verb) to classify the desired action to be performed on a resource. The HTTP/1.0 specification[3]:§8 defined the GET, HEAD, and POST methods as well as listing the PUT, DELETE, LINK and UNLINK methods under additional methods. However, the HTTP/1.1 specification[34]:§9 added five new methods: PUT, DELETE, CONNECT, OPTIONS, and TRACE. Any client can use any method and the server can be configured to support any combination of methods. If a method is unknown to an intermediate, it will be treated as an unsafe and non-idempotent method. There is no limit to the number of methods that can be defined, which allows for future methods to be specified without breaking existing infrastructure. For example, WebDAV defined seven new methods and RFC 5789 specified the PATCH method. A general-purpose web server is required to implement at least GET and HEAD, and all other methods are considered optional by the specification.[18]:§9.1
Method names are case sensitive.[4]:§3[18]:§9.1 This is in contrast to HTTP header field names which are case-insensitive.[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.1200OKDate:Mon, 23 May 2005 22:38:34 GMTContent-Type:text/html; charset=UTF-8Content-Length:155Last-Modified:Wed, 08 Jan 2003 23:11:55 GMTServer:Apache/1.3.3.7 (Unix) (Red-Hat/Linux)ETag:"3f80f-1b6-3e1cb03b"Accept-Ranges:bytesConnection:close<html><head><title>An Example Page</title></head><body><p>Hello World, this is a very simple HTML document.</p></body></html>
Tim Berners-Lee and his team at CERN are credited with inventing HTTP, along with HTML and the associated technology for a web server and a client user interface called web browser. Berners-Lee designed HTTP in order to help with the adoption of his other idea: the "WorldWideWeb" project, which was first proposed in 1989, now known as the World Wide Web. Development of HTTP was initiated in 1989 and summarized in a simple document describing the behavior of a client and a server using the first HTTP version, named 0.9.[42] That version was subsequently developed, eventually becoming the public 1.0.[43] Development of early HTTP Request for Comments (RFC) documents started a few years later in a coordinated effort by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C), with work later moving to the 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の注目を集めました。
