HTTP
チェック済み
ページは変更保留のため保護されています

HTTP
国際標準
開発者当初はCERN、IETF、W3C
紹介された1991 （1991年）
Webサイトhttpwg .org /仕様/

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 ]また、主要なウェブサーバーでは、TLS（トランスポート層セキュリティ）を介してアプリケーション層プロトコルネゴシエーション（ALPN）拡張機能を使用してサポートされています[ 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クッキー、[ 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プロトコルでは、<code><code><code><code>を除くすべてのヘッダーフィールドは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

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

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

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

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

消去
要求はリソースを削除することです。

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

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

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

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

リクエストメソッドのプロパティ
方法 RFC リクエストにはペイロード本体 がありますレスポンスにはペイロード本体 がある安全 べき等性 キャッシュ可能
得る 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 メソッドは、連続する同一リクエストが無視されるためべき等です。たとえば、Web サイトは、ユーザーの記録された電子メール アドレスを変更するために 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やウェブサーバーとウェブブラウザと呼ばれるクライアントユーザーインターフェースの関連技術を発明したとされています。バーナーズ＝リーは、彼のもう一つのアイデアである「WorldWideWeb」プロジェクトの普及を促進するためにHTTPを設計しました。このプロジェクトは1989年に初めて提案され、現在はワールドワイドウェブとして知られています。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 ]は、多くのウェブブラウザやウェブサーバーで既に使用されていたHTTP/1.0の事前標準ドラフトとして過去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 ]

スプディ

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/0.9はHTTP/1.1以降のバージョンをサポートするサーバーでは非推奨となりました。[ 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-0. 2021年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. ^ Zalewski, Michal. 「ブラウザセキュリティハンドブック」 . 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」から取得