HTTP
確認済み
ページは変更保留のため保護されています

HTTP
国際標準
開発者当初はCERN、IETF、W3C
導入1991 （1991年）
ウェブサイト httpwg.org/specs/

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

HTTPは、クライアント・サーバーモデルにおけるリクエスト・レスポンス・プロトコルです。トランザクションは、クライアントがサーバーにリクエストを送信することから始まり、サーバーはリクエストに応えようと試み、リクエストの処理内容を記述したレスポンスをクライアントに返します。レスポンスには、 HTMLドキュメントやその他のコンテンツなどのリクエストされたリソースがオプションで含まれます。

一般的なシナリオでは、ウェブブラウザがクライアントとして機能し、1つ以上のウェブサイトをホストするウェブサーバーがサーバーとして機能します。ウェブブラウザはユーザーエージェント（UA）の一例です。その他の種類のユーザーエージェントには、検索プロバイダー（ウェブクローラー）が使用するインデックス作成ソフトウェア、音声ブラウザ、モバイルアプリ、そしてウェブコンテンツにアクセス、利用、表示する その他のソフトウェアが含まれます。

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

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

ウェブリソースは、 httpとhttpsのUniform Resource Identifier（URI）スキームを使用して、 Uniform Resource Locator（URL）によって配置されます。URIはHTML文書内でハイパーリンクとしてエンコードされ、相互にリンクされたハイパーテキスト文書を形成します。[ 2 ]

バージョン

プロトコルは時間の経過とともに改訂されてきました。バージョンはHTTP/#で識別されます（#はバージョン番号）。この記事ではすべてのバージョンの側面を網羅していますが、主にHTTP/0.9、HTTP/1.0、HTTP/1.1について説明しています。HTTP /2とHTTP/3については、別の記事で詳細に 説明しています

バージョン 導入 ステータス
0.9 1991 廃止
1.0 1996 廃止
1.1 1997 標準
2 2015 標準
3 2022 標準

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はウェブサイトの71%でサポートされています[ 7 ] [ 8 ]（HTTP/2 34.1% + 後方互換性のあるHTTP/3 36.9%）また、ほぼすべてのウェブブラウザ（ユーザーの98%以上）でサポートされています[ 9 ] 。また、主要なウェブサーバーでは、アプリケーション層プロトコルネゴシエーション（ALPN）拡張機能を使用したトランスポート層セキュリティ（TLS）経由でサポートされています[ 10 ]（TLS 1.2以降が必要です）。[ 6 ]

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

HTTPの安全なバージョンであるHTTPSは、85%以上のウェブサイトで使用されています。[ 17 ]

テクノロジー

トランスポート層

HTTPは、基盤となる信頼性の高いトランスポート層プロトコルを前提としています。[ 1 ]：§3.3 HTTP/3より前の基盤プロトコルの標準的な選択肢は、伝送制御プロトコル（TCP）でした。HTTP/3は、信頼性の低いユーザーデータグラムプロトコル（UDP）の上に信頼性を提供する、QUICと呼ばれる別のトランスポート層を使用します。HTTP/1.1以前は、マルチキャストおよびユニキャストの状況で、信頼性の低い単純なUDP上で使用できるように適応されており、HTTPMUとHTTPUを形成しています。これらは、 通常ローカルエリアネットワークで実行される2つのプロトコルであるUPnPとSimple Service Discovery Protocol（SSDP）で使用されます

データ交換

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

接続を介した要求メッセージと応答メッセージ

データは、セッション層トランスポート接続によって交換される一連のリクエスト・レスポンス・メッセージを通じて交換されます。 [ 18 ] 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 リクエストを許可するために、クライアントによってキャッシュされたリソースを管理するためのヘッダーが追加されました。

  • サーバーは、クライアントがリソースの最終更新時刻を認識していない場合、または GET 要求に対する最後の完全な応答以降リソースが変更された場合にのみ、要求されたリソースのコンテンツ全体を返す必要があります。
  • Content-Encoding返されるコンテンツが圧縮されているかどうかを指定するためのヘッダーが追加されました。
  • コンテンツのサイズが事前にわからない場合（例えば、動的に生成される場合）、ヘッダーは含まれませんContent-Length。クライアントは接続が切断された時点で転送が完了したと想定しますが、接続が早期に切断された場合、クライアントはコンテンツが不完全であることに気付かず、転送が完了していない状態のままとなります。

導入された HTTP/1.1 以降のバージョンでは以下が提供されます。

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

アプリケーションセッション

ステートレスプロトコルであるHTTPは、ウェブサーバーが複数のリクエストの間、各ユーザーに関する情報やステータスを保持することを必要としません。ウェブアプリケーションがアプリケーションセッションを必要とする場合、 HTTP Cookie、[ 20 ] 、ウェブフォーム内の隠し変数、またはその他のメカニズム を介してそれを実装します

通常、セッションを開始するには対話型ログインが実行され、セッションを終了するにはユーザーによるログアウトが要求されます。これらの操作では、 HTTP認証ではなく、カスタム認証メカニズムが使用されます。

認証

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

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

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

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

暗号化された接続

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

メッセージフォーマット

Telnetを使用して行われたHTTP/1.1リクエスト。トランザクションの各部分は異なる色で表示されます。リクエストは赤、レスポンスヘッダーは紫、レスポンス本体は緑です

このセクションでは、HTTP/1.1のメッセージについて説明します。以降のバージョンであるHTTP/2 [ 25 ]およびHTTP/3では、バイナリプロトコルが採用されており、ヘッダーはHPACK [ 26 ]HEADERS (HTTP/2)またはQPACK (HTTP/3)を用いて、1つのフレームと0個以上のフレームにエンコードされます。HPACKはどちらも効率的なヘッダー圧縮を提供します。HTTP/1のリクエスト行またはレスポンス行も、コロン ( ) で始まる複数の疑似ヘッダーフィールドに置き換えられました。 CONTINUATION:

最高レベルでは、メッセージはヘッダーとそれに続く本文で構成されます。

ヘッダーはASCIIテキストの行で構成され、各行はキャリッジリターンとラインフィードのシーケンスで終了します。リクエストヘッダーとレスポンスヘッダーのレイアウトは次のとおりです

スタートライン
リクエストとレスポンスで異なる構造化データ。
ヘッダーフィールド
0 行以上のヘッダー フィールド行 (HTTP/1.1 の場合は少なくとも 1 行)。以下を参照してください。
空行
ヘッダーの終わりを示します。

本文

本文は、ASCIIに限らず、任意の形式のデータで構成されます。メッセージにヘッダーフィールドが含まれている場合、その形式はヘッダーフィールドで指定された形式と一致する必要がありますContent-Type。本文はオプションであり、空白にすることもできます

エンティティ

HTTP/2より前では、 「エンティティ」という用語は、ボディと、ボディを記述するヘッダーフィールドを意味していました。特に、すべてのヘッダーがエンティティの一部とは見なされていませんでした。「エンティティヘッダー」という用語は、エンティティの一部とみなされるヘッダーを指し、ボディはエンティティボディと呼ばれることもありました。 最近のドキュメントでは、 「エンティティ」を使用せずに「ボディ」と「ヘッダー」を使用しています

ヘッダーフィールド

ヘッダー フィールドは、その内容メッセージに関するメタデータを表します。たとえば、本文のエンコード方法 ( Content-Encoding経由)、クライアントのセッション検証および識別 (ブラウザー クッキー、IP アドレス、ユーザー エージェントなど) またはその匿名性 (VPN またはプロキシ マスキング、ユーザー エージェント スプーフィング)、サーバーのデータ処理方法 ( Do-Not-Trackまたはグローバル プライバシー コントロールなど)、ダウンロードされるドキュメントの経過時間 (共有キャッシュ内に存在していた時間) などがあります。一般に、ヘッダー フィールドの情報はソフトウェアによって使用され、ユーザーには表示されません。

ヘッダーフィールド行は、コロンで区切られた名前と値のペアとしてフォーマットされます。名前の前後に空白文字を入れることはできませんが、値の部分では先頭と末尾の空白文字は無視されます。メソッド名（大文字と小文字を区別）は完全に一致する必要がありますが、 [ 27 ]ヘッダーフィールド名は大文字と小文字を区別せずに一致しますが、多くの場合、各単語が大文字で表記されます。[ 28 ]例えば、以下はおよびのヘッダーフィールドHostですAccept-Language。 

ホスト: www.example.com Accept-Language: en

標準では、ヘッダーフィールドのサイズやメッセージ内のフィールド数に制限はありません。しかし、ほとんどのサーバー、クライアント、プロキシソフトウェアは、実用上およびセキュリティ上の理由から制限を設けています。例えば、Apache 2.3サーバーはデフォルトで各フィールドのサイズを8190バイトに制限しており、1つのリクエストに含まれるヘッダーフィールドは最大100個です。[ 29 ]

RFC 7230 [ 30 ]では非推奨となっているが、過去にはスペースやタブ文字で始まる継続行を使用して長い行を複数行に分割することが可能であった。

リクエスト

リクエストはクライアントからサーバーに送信されます。開始行には、メソッド名、リクエストURI、プロトコルバージョンが含まれ、各フィールドの間には1つのスペースが挿入されます。[ 31 ]次のリクエスト開始行は、メソッドGET、URI /customer/123、プロトコルバージョンHTTP/1.1を 指定しています

GET /customer/123 HTTP/1.1

リクエストヘッダーフィールドは、クライアントがリクエスト行を超えて追加情報を渡すことを可能にし、リクエスト修飾子として機能します（プロシージャのパラメータに似ています）。リクエストヘッダーフィールドは、クライアント、対象リソース、またはリクエストの想定される処理に関する情報を提供します。HTTP/1.1プロトコルでは、を除くすべてのヘッダーフィールドHostはオプションです

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

リソース

プロトコルは、トランザクションをリソースを操作するものとして構造化します。リソースが何を表すかは、既存のデータか動的に生成されるデータかによって、サーバーの実装に依存します。多くの場合、リソースはファイルまたはサーバー上で実行されている実行可能ファイルの出力に対応します

メソッド

リクエストは、リソースに対して実行される望ましいアクションを分類するためのメソッド（非公式には動詞と呼ばれることもあります）を識別します。HTTP/1.0仕様[ 3 ]：§8 では、GET、HEAD、POSTメソッドが定義され、PUT、DELETE、LINK、UNLINKメソッドが追加メソッドとしてリストされています。しかし、HTTP/1.1仕様[ 33 ]：§9 では、PUT、DELETE、CONNECT、OPTIONS、TRACEの5つの新しいメソッドが追加されました。どのクライアントも任意のメソッドを使用でき、サーバーは任意のメソッドの組み合わせをサポートするように設定できます。メソッドが中間者に認識されていない場合、安全でない非べき等メソッドとして扱われます。定義できるメソッドの数に制限はなく、既存のインフラストラクチャを壊すことなく将来のメソッドを指定できます。たとえば、WebDAVは7つの新しいメソッドを定義し、RFC 5789はPATCHメソッドを指定しました汎用ウェブサーバーは少なくともGETとHEADを実装する必要があり、その他のメソッドは仕様ではオプションとみなされている。[ 1 ]：§9.1  

メソッド名は大文字と小文字が区別されます。[ 4 ] : §3 [ 1 ] : §9.1 これは、大文字と小文字を区別しないHTTPヘッダーフィールド名とは対照的です。[ 1 ] : §6.3

GET
リクエストはリソースの表現を求めるものです。サーバーはデータの取得のみを行い、状態を変更してはなりません。[ 1 ]変更を加えずに取得する場合、 URLでアドレス指定できるGETはPOSTよりも優先されます。これによりブックマークや共有が可能になり、GETレスポンスはキャッシュの対象となり、帯域幅を節約できます。W3Cはこの区別に関するガイダンス原則を公開しており、「Webアプリケーションの設計は、上記の原則だけでなく、関連する制限事項も考慮する必要があります。」と述べています。 [ 34 ]

頭
このリクエストはGETに似ていますが、レスポンスのボディに表現データを含めない点が異なります。これは、表現全体を転送することなく、レスポンスヘッダー内の表現メタデータを取得するのに便利です。例えば、ステータスコードからページが利用可能かどうかを確認したり、ヘッダーフィールドからファイルサイズを取得したりといった用途がありますContent-Length。

POST
リクエストは、何らかの方法でリソースを処理するためのものです。例えば、インターネットフォーラムへのメッセージの投稿、メーリングリストへの登録、オンラインショッピングの取引の完了などに使用されます。[ 1 ]：§9.3.3

PUT
このリクエストは、リクエスト内の状態を使用してリソースを作成または更新するためのものです。POSTとの違いは、クライアントがサーバー上のターゲットの場所を指定することです。[ 1 ]：§9.3.4

削除
このリクエストはリソースを削除するためのものです。

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

オプション
このリクエストは、リソースでサポートされているHTTPメソッドのレポートです。特定のリソースの代わりに「*」をリクエストすることで、Webサーバーの機能を確認できます

トレース
受信したリクエストをレスポンスボディに含めてサーバーに応答するよう要求します。これにより、クライアントは中継サーバーによってどのような変更や追加が行われたか（もしあれば）を確認できます。デバッグに役立ちます

PATCH
このリクエストは、リクエスト内の部分的な状態に応じてリソースを変更します。PUTと比較して、リソースの表現全体ではなく一部だけを送信することで帯域幅を節約できます。[ 36 ]

リクエストメソッドのプロパティ
方法 RFC リクエストにはペイロード本体が ありますレスポンスにはペイロード本体 があります安全 べき等 キャッシュ可能
GET RFC  9110オプション はい はい はい はい
ヘッド RFC  9110オプション いいえ はい はい はい
ポスト RFC  9110はい はい いいえ いいえ はい
置く RFC  9110はい はい いいえ はい いいえ
削除する RFC  9110オプション はい いいえ はい いいえ
接続する RFC  9110オプション はい いいえ いいえ いいえ
オプション RFC  9110オプション はい はい はい いいえ
トレース RFC  9110いいえ はい はい はい いいえ
パッチ RFC  5789はい はい いいえ いいえ いいえ
安全なメソッド

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

一方、POST、PUT、DELETE、CONNECT、PATCHメソッドは安全ではありません。これらのメソッドは、サーバーの状態を変更したり、メールを送信するなどの影響を与える可能性があります。そのため、これらのメソッドは、準拠しているWebロボットやWebクローラーでは通常使用されません。準拠していない一部のメソッドは、コンテキストや結果を考慮せずにリクエストを送信する傾向があります。

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

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

べき等メソッド

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

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

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

キャッシュ可能なメソッド

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

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

レスポンス

レスポンスはサーバーからクライアントに送信されます。レスポンスの開始行は、プロトコルバージョン、ステータスコード、およびオプションで理由フレーズで構成され、各フィールドは1つのスペース文字で区切られます。[ 4 ]：§2.1 次のレスポンス開始行は、プロトコルバージョンHTTP/1.1、ステータスコード400、および理由フレーズBad Requestを 指定します

HTTP/1.1 400 不正なリクエスト

レスポンスヘッダーフィールドは、サーバーがステータスライン以外の追加情報を渡すことを可能にし、レスポンス修飾子として機能します。レスポンスヘッダーフィールドは、サーバーに関する情報、または対象リソースや関連リソースへのさらなるアクセスに関する情報を提供します。各レスポンスヘッダーフィールドは定義された意味を持ち、リクエストメソッドやレスポンスステータスコードのセマンティクスによってさらに詳細化されます。

ステータスコード

ステータスコードは、クライアントのリクエストを満たすためのサーバーの試みを示す3桁の10進整数値です。通常、クライアントは主にステータスコードに基づいてレスポンスを処理し、次にレスポンスヘッダーフィールドに基づいて処理します。クライアントはサーバーが報告するすべてのステータスコードを理解できるとは限りませんが、最初の桁で示されるクラスを理解し、認識できないコードをそのクラスのx00コードと同等に扱う必要があります。クラスは次のとおりです

1XX情報
リクエストを受信しました。処理を続行します。
2XX 成功
リクエストは正常に受信され、理解され、承認されました。
3XX リダイレクト
リクエストを完了するには、さらにアクションを実行する必要があります。
4XX クライアントエラー
クライアントが制御できる可能性のある問題のため、リクエストを処理できません
5XX サーバーエラー
サーバーは有効なリクエストを処理できませんでした。

理由フレーズ

標準的な理由フレーズは推奨事項に過ぎません。ウェブサーバーはローカライズされた同等のフレーズを使用することが許可されています。ステータスコードが問題を示している場合、ユーザーエージェントは問題の性質に関する詳細情報を提供するために、理由フレーズをユーザーに表示することがあります。標準では、ユーザーエージェントが理由フレーズを解釈することを許可していますが、標準ではステータスコードは機械可読であり、理由フレーズは人間が読めるものであると明示的に規定されているため、これは賢明ではない可能性があります。

例

以下は、 www.example.comのポート80にあるサーバーに対するHTTP/1.1のリクエスト・レスポンス・トランザクションを示しています。HTTP /1.0では、いくつかのヘッダーが欠落していることを除いて同じメッセージが使用されます。HTTP/2とHTTP/3では、同じリクエスト・レスポンス・メカニズムが使用されますが、HTTPヘッダーの表現が異なります

以下はボディのないリクエストです。開始行、6つのヘッダーフィールド、そして1つの空行で構成され、各フィールドはキャリッジリターンとラインフィードのシーケンスで終端されています。ヘッダーフィールドは、単一のIPアドレスを共有する複数のDNSHost名を区別し、名前ベースの仮想ホスティングを可能にします。HTTP/1.0ではオプションですが、HTTP/1.1では必須です。 

GET / HTTP / 1.1ホスト: www.example.comユーザーエージェント: 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接続: keep-alive

上記の表現では（このWikiの制限により）明確ではありませんが、末尾の空行によって2つの改行シーケンスが終了します。上記の短縮版を文字列として表現すると、<CRLF>改行シーケンスを表す次のようになりますGET / HTTP/1.1<CRLF>Host: www.example.com<CRLF><CRLF>。

以下のレスポンスでは、ETag（エンティティタグ）ヘッダーフィールドは、要求されたリソースのキャッシュバージョンがサーバー上のリソースの現在のバージョンと同一かどうかを判定するために使用されます。ヘッダーフィールドは、HTTPメッセージによって伝送されるデータのインターネットメディアタイプをContent-Type指定し、その長さをバイト単位で示します。HTTP/1.1ウェブサーバーは、バイト範囲のリソースに対するリクエストに応答する機能を を含めることで公開しています。これは、クライアントがサーバーから送信されたリソースの特定の部分[ 39 ]のみを必要とする場合に便利です。これはバイトサービングと呼ばれます。 が送信されると、ウェブサーバーはこのレスポンスの転送終了後すぐにTCP接続を閉じることを意味します。 [ 4 ] : §9.1 Content-LengthAccept-Ranges: bytesConnection: close

ヘッダーフィールドのほとんどはオプションですが、一部は必須です。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日付: 2005年5月23日(月) 22:38:34 GMTコンテンツタイプ: text/html; 文字セット=UTF-8コンテンツ長: 155最終更新日: 2003年1月8日(水) 23:11:55 GMTサーバー: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) ETag : "3f80f-1b6-3e1cb03b" Accept-Ranges :バイト接続: close< html > < head > < title >サンプルページ</ title > </ head > < body > < p > Hello World、これは非常にシンプルな HTML ドキュメントです。</ p > </ body > </ html >

類似プロトコル

Gopherプロトコル
1990年代初頭にHTTPに取って代わられたコンテンツ配信プロトコル
SPDYプロトコル
Googleで開発された HTTP の代替であり、HTTP/2に置き換えられました。
ジェミニプロトコル
プライバシー関連の機能を義務付ける、Gopherに着想を得たプロトコル

歴史

ティム・バーナーズ＝リー

ティム・バーナーズ＝リーとCERNの彼のチームは、HTTP、HTML、そしてウェブサーバーとウェブブラウザと呼ばれるクライアントユーザーインターフェースの関連技術を発明したとされています。バーナーズ＝リーは、1989年に最初に提案され、現在ワールドワイドウェブとして知られている「WorldWideWeb」プロジェクトという、彼のもう一つのアイデアの採用を促進するためにHTTPを設計しました。HTTPの開発は1989年に開始され、最初のHTTPバージョンである0.9を使用したクライアントとサーバーの動作を記述した簡単な文書にまとめられました。[ 40 ]このバージョンはその後開発され、最終的に公開バージョン1.0になりました。[ 41 ]初期のHTTP Request for Comments（RFC）文書の開発は、数年後、インターネット技術タスクフォース（IETF）とワールドワイドウェブコンソーシアム（W3C）の共同作業によって開始され、その後作業はIETFに移管されました

最初のウェブサーバーは1990年に稼働しました。[ 42 ] [ 43 ]使用されたプロトコルは、サーバーからページを要求するGETという1つのメソッドのみでした。[ 44 ]サーバーからの応答は常にHTMLページでした。[ 40 ]

HTTP/0.9

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

HTTP/1.0 ドラフト

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

W3C HTTPワーキンググループ

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

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

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

HTTP/1.0

1996年5月、RFC  1945 [ 3 ]は、過去4年間多くのウェブブラウザやウェブサーバーで既に使用されていたHTTP/1.0の準標準ドラフトの最終版として公開されました

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

HTTP/1.1

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

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

1999年6月に、以前の（廃止された）HTTP/1.1仕様に基づくすべての改良と更新を含む RFC  2616 [ 33 ]がリリースされました。

W3C HTTP-NGワーキンググループ

1995年に以前のHTTPワーキンググループの計画を再開し、1997年にHTTP-NGワーキンググループが結成されました。このグループは、HTTP-NG（HTTP New Generation）と呼ばれる新しいHTTPプロトコルを開発するために設立されました。単一のTCP/IP接続内でHTTPトランザクションを多重化する新しいプロトコルに関するいくつかの提案/草案が作成されましたが、1999年にグループは活動を中止し、技術的な問題をIETFに委ねました。[ 50 ]

IETF HTTPワーキンググループが再開

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

SPDY

2009年、Googleはブラウザとサーバー間のウェブトラフィックを高速化するために開発したバイナリプロトコル、SPDYを発表しました。多くのテストで、SPDYの使用はHTTP/1.1を使用するよりも実際に高速でした。SPDYはGoogleのChromiumに統合され、その後、他の主要なウェブブラウザにも統合されました。[ 53 ]単一のTCP接続を介してHTTPストリームを多重化するアイデアの一部は、W3C HTTP-NGワーキンググループの作業を含む、さまざまなソースから採用されました

HTTP/2

2012年、HTTPワーキンググループ（HTTPbis）は新しいプロトコルの必要性を発表しました。当初はSPDY [ 54 ] [ 55 ]の側面を考慮し、最終的にSPDYから新しいプロトコルを派生させることを決定しました[ 56 ] 。 2015年5月、HTTP/2はRFC  7540 [ 57 ]として公開されました。このプロトコルは、既にSPDYをサポートしていたウェブブラウザではすぐに採用されましたが、ウェブサーバーではゆっくりと採用されました

2014 年の HTTP/1.1 の更新

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

  • RFC  7230 –「ハイパーテキスト転送プロトコル（HTTP / 1.1）：メッセージ構文とルーティング」[ 58 ]廃止。
  • RFC  7231 – 「ハイパーテキスト転送プロトコル（HTTP / 1.1）：セマンティクスとコンテンツ」[ 59 ]廃止。
  • RFC  7232 –「ハイパーテキスト転送プロトコル（HTTP / 1.1）：条件付き要求」[ 60 ]廃止。
  • RFC  7233 –「ハイパーテキスト転送プロトコル（HTTP / 1.1）：範囲要求」[ 61 ]廃止。
  • RFC  7234 –「ハイパーテキスト転送プロトコル（HTTP/1.1）：キャッシュ」[ 62 ]廃止。
  • RFC  7235 –「ハイパーテキスト転送プロトコル（HTTP/1.1）：認証」[ 63 ]廃止。

HTTP/0.9の廃止

2014年、HTTP/1.1（およびそれ以降）をサポートするサーバーではHTTP/0.9が廃止されました。[ 58 ]：§付録A

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

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

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

2022年現在、HTTP/0.9のサポートは公式には完全に廃止されておらず、多くのウェブサーバーやブラウザでは、通常は無効化されているものの、サーバー応答のみに利用されています。HTTP/0.9の廃止にどれくらいの時間がかかるかは不明です。

HTTP/3

2020年にHTTP/3の最初のドラフトが公開され、主要なウェブブラウザとウェブサーバーが採用を開始しました。2022年6月6日、IETFはHTTP/3を RFC  9114 [ 65 ]として標準化しました

2022年のアップデートとリファクタリング

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

  • RFC  9110 –「HTTPセマンティクス」[ 1 ]インターネット標準97。
  • RFC  9111 –「HTTPキャッシング」[ 66 ]インターネット標準98。
  • RFC  9112 –「HTTP/1.1」[ 4 ]インターネット標準99。
  • RFC  9113 –「HTTP/2」[ 6 ]提案標準。
  • RFC  9114 – 「HTTP/3」[ 65 ]提案標準。 （上記のセクションも参照。）
  • RFC  9204 – 「QPACK: HTTP/3のフィールド圧縮」[ 67 ]提案標準。
  • RFC  9218 – 「HTTPの拡張可能な優先順位付けスキーム」[ 68 ]提案された標準。

参照

注記

  1. ^実際には、これらのストリームは複数のTCP/IPサブ接続として使用され、同時リクエスト/レスポンスを多重化します。これにより、サーバー側の実際のTCP/IP接続数がクライアントあたり2～8から1に大幅に削減され、より多くのクライアントに同時にサービスを提供できるようになります
  2. ^ 1996年後半から、HTTP/1.0対応ブラウザやサーバの開発者（特にHTTP/1.1のサポートも計画していた開発者）の中には、TCP/IP接続をリクエスト/レスポンスのペア以上開いたままにして、複数のリクエスト/レスポンスの交換を高速化するために、非公式の拡張機能として、新しいHTTPヘッダーを使用したキープアライブメカニズムのようなものを導入し始めた者もいた。 [ 19 ]

参考文献

  1. ^ a b c d e f g h i j k l m R. Fielding 、M. Nottingham、J . Reschke編（2022年6月）。HTTPセマンティクス。インターネット技術タスクフォース。doi : 10.17487/ RFC9110。ISSN 2070-1721。STD 97。RFC 9110 インターネット標準97。RFC 2818、7230、7231、7232、7233、7235、7538、7615、7694 を 廃止。RFC 3864を更新。​​​​​​​​​​​ ​​
  2. ^ T. Berners-Lee ; R. Fielding ; L. Masinter (2005年1月). Uniform Resource Identifier (URI): Generic Syntax . Network Working Group. doi : 10.17487/RFC3986 . STD 66. RFC 3986 .インターネット 標準66。RFC 2732、2396、1808を 廃止。RFC 6874、7320、8820 により更新。RFC 1738 を更新。​​​​
  3. ^ a b c d T Berners-Lee ; R. Fielding ; H. Frystyk (1996年5月). Hypertext Transfer Protocol -- HTTP/1.0 . Network Working Group. doi : 10.17487/RFC1945 . RFC 1945 .情報提供
  4. ^ a b c d e f R. Fielding 、M. Nottingham、 J . Reschke編（2022年6月）。HTTP /1.1。インターネット技術タスクフォース。doi : 10.17487/ RFC9112。ISSN 2070-1721。STD 99。RFC 9112 インターネット標準 99。 RFC  7230 は廃止されます。
  5. ^ 「Classic HTTP Documents」 . W3.org. 1998年5月14日. 2010年8月1日閲覧。
  6. ^ a b c M. Thomson; C. Benfield編 (2022年6月). HTTP/2 .インターネット技術タスクフォース. doi : 10.17487/RFC9113 . ISSN 2070-1721 . RFC 9113 . 提案された標準。RFC 8740、7540を 廃止し ます。
  7. ^ 「ウェブサイトにおけるHTTP/2の使用統計」 w3techs.com 2026年1月21日閲覧。
  8. ^ 「ウェブサイトにおけるHTTP/3の使用統計、2026年1月」 w3techs.com 2026年1月21日閲覧。
  9. ^ 「HTML5、CSS3などのサポートテーブルを使用できますか？」caniuse.com。2024年1月5日閲覧。
  10. ^ S. Friedl; A. Popov; A. Langley; E. Stephan (2014年7月).トランスポート層セキュリティ (TLS) アプリケーション層プロトコルネゴシエーション拡張.インターネット技術タスクフォース. doi : 10.17487/RFC7301 . ISSN 2070-1721 . RFC 7301 . 提案 された標準。RFC 8447 によって更新されました。
  11. ^ 「ウェブサイトにおけるHTTP/3の使用統計」 w3techs.com 2026年1月18日閲覧。
  12. ^ 「HTML5、CSS3などのテーブルをサポートできますか？」 canIuse.com 。2024年1月8日閲覧。
  13. ^ Cimpanu, Catalin (2019年9月26日). 「Cloudflare、Google Chrome、FirefoxがHTTP/3のサポートを追加」 . ZDNet . 2019年9月27日閲覧。
  14. ^ 「HTTP/3：過去、現在、そして未来」 . Cloudflareブログ. 2019年9月26日. 2019年10月30日閲覧。
  15. ^ 「Firefox NightlyがHTTP 3をサポート – 一般 – Cloudflareコミュニティ」 2019年11月19日。 2020年1月23日閲覧。
  16. ^ 「HTTP/3は高速です」。リクエストメトリクス。2022年7月1日閲覧。
  17. ^ 「ウェブサイトのデフォルトプロトコルhttpsの使用統計」 w3techs.com 2024年1月5日閲覧。
  18. ^ a b「接続、クライアント、およびサーバー」。RFC 9110、HTTPセマンティクス。3.3節。doi : 10.17487 / RFC9110。RFC 9110。
  19. ^ a b David Gourley、Brian Totty、Marjorie Sayer、Anshu Aggarwal、Sailu Reddy (2002). HTTP: The Definitive Guide. (「持続接続」の章からの抜粋) . O'Reilly Media, inc. ISBN 978-1-56592-509-02021年10月18日閲覧
  20. ^ Lee, Wei-Bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (2019-01-25). 「自己検証によるHTTP Cookieの安全かつ効率的な保護」 . International Journal of Communication Systems . 32 (2) e3857. doi : 10.1002/dac.3857 . S2CID 59524143 . 
  21. ^ Canavan, John (2001).ネットワークセキュリティの基礎. ノーウッド, MA: Artech House. pp.  82– 83. ISBN 978-1-58053-176-4。
  22. ^ザレフスキー、ミハル。「ブラウザセキュリティハンドブック」。2015年4月30日閲覧
  23. ^ 「Chromium Issue 4527: RFC 2817: HTTP/1.1内でのTLSへのアップグレードを実装する」 。 2015年4月30日閲覧。
  24. ^ 「Mozilla Bug 276813 – [RFE] HTTP 1.1のRFC 2817 / TLSアップグレードのサポート」 。 2015年4月30日閲覧。
  25. ^ HTTP/2 . 2022年6月. doi : 10.17487/RFC9113 . RFC 9113 .
  26. ^ Peon, R.; Ruellan, H. (2015年5月). HPACK: HTTP/2のヘッダー圧縮. doi : 10.17487/RFC7541 . RFC 7541 .
  27. ^ 「メソッド：概要」 . HTTPセマンティクス. 2022年6月. 9.1節. doi : 10.17487/RFC9110 . RFC 9110 .
  28. ^ 「フィールド名」 . HTTPセマンティクス. 2022年6月. sec. 5.1. doi : 10.17487/RFC9110 . RFC 9110 .
  29. ^ "core - Apache HTTP Server" . Httpd.apache.org. 2012年5月9日時点のオリジナルよりアーカイブ。2012年3月13日閲覧。
  30. ^ 「フィールド解析」 .ハイパーテキスト転送プロトコル（HTTP/1.1）：メッセージ構文とルーティング. 2014年6月. sec. 3.2.4. doi : 10.17487/RFC7230 . RFC 7230 .
  31. ^ 「メッセージフォーマット」 . RFC 9112: HTTP/1.1 . sec. 2.1. doi : 10.17487/RFC9112 . RFC 9112 .
  32. ^ “Apache Week. HTTP/1.1” . 2021年6月2日時点のオリジナルよりアーカイブ。2021年5月3日閲覧。090502 apacheweek.com
  33. ^ a b c R. Fielding ; J. Gettys; J. Mogul; H. Frystyk ; L. Masinter ; P. Leach; T. Berners-Lee (1999年8月). Hypertext Transfer Protocol -- HTTP/1.1 . Network Working Group. doi : 10.17487/RFC2616 . RFC 2616 .廃止。RFC 7230、7231、7232、7233、7234、7235  により廃止。RFC 2068 は廃止。RFC 2817、5785、6266、6585 により更新。​​​​​​​​​​​​​
  34. ^ Jacobs, Ian (2004). 「URI、アドレス指定可能性、そしてHTTP GETとPOSTの利用」 .技術アーキテクチャグループの調査結果. W3C . 2010年9月26日閲覧。
  35. ^ 「脆弱性ノート VU#150227: HTTPプロキシのデフォルト設定により、任意のTCP接続が許可される」 US -CERT 2002年5月17日 2007年5月10日閲覧。
  36. ^ L. Dusseault (2010年3月). HTTPのPATCHメソッド. Internet Research Task Force . doi : 10.17487/RFC5789 . ISSN 2070-1721 . RFC 5789 . 提案された標準
  37. ^ a bエディガー、ブラッド (2007年12月21日). 『Advanced Rails：記録的な速さで産業用Webアプリを構築する』O'Reilly Media, Inc. p. 188. ISBN 978-0-596-51972-8 よくある間違いは、リソースを更新するアクションにGETを使用することです。[...] この問題は、2005年にGoogle Web Acceleratorがリリースされたときに、Railsの注目を集めました
  38. ^ Cantrell, Christian (2005-06-01). 「Google Web Acceleratorから学んだこと」 . Adob​​e Blogs . Adob​​e. 2017年8月19日時点のオリジナルよりアーカイブ。 2018年11月19日閲覧。
  39. ^ Luotonen, Ari; Franks, John (1996年2月22日). HTTPのバイト範囲検索拡張. IETF. ID draft-ietf-http-range-retrieval-00.
  40. ^ a b c d Tim Berner-Lee (1991-01-01). 「1991年に定義されたオリジナルのHTTP」 . www.w3.org . World Wide Web Consortium . 2010年7月24日閲覧。
  41. ^ a b Tim Berner-Lee (1992). 「1992年に定義されたBasic HTTP」 . www.w3.org . World Wide Web Consortium . 2021年10月19日閲覧。
  42. ^ 「Webの発明、Webの歴史、Webを発明したのは誰か、ティム・バーナーズ＝リー、ロバート・カイユ、CERN、最初のWebサーバー」LivingInternet。2021年8月11日閲覧。
  43. ^ Berners-Lee, Tim (1990-10-02). 「daemon.c - TCP/IPベースのハイパーテキストサーバー」 . www.w3.org . 2021年8月11日閲覧。
  44. ^バーナーズ＝リー、ティム. 「ハイパーテキスト転送プロトコル」 .ワールド・ワイド・ウェブ・コンソーシアム. 2010年8月31日閲覧。
  45. ^ Raggett, Dave. 「Dave Raggettの略歴」ワールド・ワイド・ウェブ・コンソーシアム. 2010年6月11日閲覧。
  46. ^ Raggett, Dave; Berners-Lee, Tim. 「Hypertext Transfer Protocol Working Group」ワールド・ワイド・ウェブ・コンソーシアム. 2010年9月29日閲覧。
  47. ^ Raggett, Dave. 「HTTP WG計画」 . ワールド・ワイド・ウェブ・コンソーシアム. 2010年9月29日閲覧。
  48. ^ 「HTTP 1.1準拠ブラウザ」 . webcom.com . 1998年2月4日時点のオリジナルよりアーカイブ。2009年5月29日閲覧。
  49. ^ R. Fielding ; J. Gettys ; J. Mogul ; H. Frystyk ; T. Berners-Lee (1997年1月). Hypertext Transfer Protocol -- HTTP/1.1 . Network Working Group. doi : 10.17487/RFC2068 . RFC 2068 .廃止。RFC 2616  により廃止されました。
  50. ^ 「HTTP-NGワーキンググループ」 . www.w3.org . World Wide Web Consortium. 1997年. 2021年10月19日閲覧。
  51. ^ Web Administrator (2007). 「HTTPワーキンググループ」 . httpwg.org . IETF . 2021年10月19日閲覧。
  52. ^ Web Administrator (2007). 「HTTPワーキンググループ：httpbis憲章」 . datatracker.ietf.org . IETF . 2021年10月19日閲覧。
  53. ^ 「SPDY: より高速なウェブのための実験的プロトコル」 . dev.chromium.org . Google. 2009年11月1日. 2021年10月19日閲覧。
  54. ^ 「httpbisの再憲章」 IETF; HTTP WG. 2012年1月24日. 2021年10月19日閲覧。
  55. ^ IESG事務局長 (2012年3月19日). 「WGアクション：再憲章：ハイパーテキスト転送プロトコルBis（httpbis）」 IETF; HTTP WG . 2021年10月19日閲覧。
  56. ^ Ilya Grigorik; Surma (2019年9月3日). 「高性能ブラウザネットワーク：HTTP/2入門」 . developers.google.com . Google Inc. 2021年10月19日閲覧。
  57. ^ M. Belshe; R. Peon (2015年5月). M. Thomson (編).ハイパーテキスト転送プロトコル バージョン2 (HTTP/2) .インターネット技術タスクフォース. doi : 10.17487/RFC7540 . ISSN 2070-1721 . RFC 7540 . 提案 された標準。RFC 8740 によって更新されました。
  58. ^ a b R. Fielding、J. Reschke編（2014年6月）。「ハイパーテキスト転送プロトコル（HTTP/1.1）：メッセージ構文とルーティング」インターネット技術特別調査委員会。doi ：10.17487/ RFC7230。RFC 7230。廃止。RFC 9110 および9112 により廃止。RFC 8615 により更新。RFC 2145および2616は廃止 。RFC 2817 および2818を更新。 
  59. ^ R. Fielding、J. Reschke編（2014年6月）。「ハイパーテキスト転送プロトコル（HTTP/1.1）：セマンティクスとコンテンツ」インターネット技術タスクフォース。doi ：10.17487/ RFC7231。RFC 7231。廃止。RFC 9110  により廃止。RFC 2616 を廃止 。RFC 2817を 更新。
  60. ^ R. Fielding、J. Reschke編（2014年6月）。「ハイパーテキスト転送プロトコル（HTTP/1.1）：条件付きリクエスト」。インターネット技術タスクフォース。doi ：10.17487/ RFC7232。RFC 7232。廃止。RFC 9110 により 廃止。RFC 2616 より廃止。
  61. ^ R. Fielding、Y. Lafon、J. Reschke編（2014年6月）。ハイパーテキスト転送プロトコル（HTTP/1.1）：範囲要求。インターネット技術タスクフォース。doi ：10.17487/ RFC7233。RFC 7233。廃止。RFC 9110 により 廃止。RFC 2616 より廃止。
  62. ^ R. Fielding、M. Nottingham、J. Reschke (2014年6月).ハイパーテキスト転送プロトコル (HTTP/1.1): キャッシュ.インターネット技術タスクフォース. doi : 10.17487/RFC7234 . RFC 7234 .廃止。RFC 9111 により 廃止。RFC 2616 より廃止。
  63. ^ R. Fielding、J. Reschke編（2014年6月）。ハイパーテキスト転送プロトコル（HTTP/1.1）：認証。インターネット技術タスクフォース。doi ：10.17487/ RFC7235。RFC 7235。廃止。RFC 9110 により 廃止。RFC 2617、2616 より廃止。
  64. ^ Matt Menke (2016年6月30日). 「HTTP/0.9のサポートを廃止および削除する意向」 . groups.google.com . 2021年10月15日閲覧。
  65. ^ a b M. Bishop編 (2022年6月). HTTP/3 .インターネット技術タスクフォース. doi : 10.17487/RFC9114 . ISSN 2070-1721 . RFC 9114 . 提案された標準
  66. ^ R. Fielding 、M . Nottingham 、J. Reschke（2022年6月）。HTTPキャッシング。インターネット技術タスクフォース。doi : 10.17487/RFC9111。STD 98。RFC 9111インターネット標準 98。 RFC  7234 は廃止されます。
  67. ^ C. Krasic; M. Bishop (2022年6月). A. Frindell (編). QPACK: HTTP/3のフィールド圧縮.インターネット技術タスクフォース. doi : 10.17487/RFC9204 . ISSN 2070-1721 . RFC 9204 . 提案された標準
  68. ^奥 一穂 (K. Oku); L. Pardue (2022年6月). HTTPの拡張可能な優先順位付けスキーム.インターネット技術タスクフォース. doi : 10.17487/RFC9218 . ISSN 2070-1721 . RFC 9218 . 提案された標準
Wikibooksには、「通信ネットワーク/HTTPプロトコル」に関する書籍があります
ウィキメディア コモンズには、ハイパーテキスト転送プロトコルに関連するメディアがあります。
「 https://en.wikipedia.org/w/index.php?title=HTTP&oldid=1334566955#Response_message」より取得