ハイパーテキスト転送プロトコル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ハイパーテキスト転送プロトコル
HTTPロゴ.svg
国際標準RFC  1945 HTTP / 1.0 (1996)

RFC  2068 HTTP / 1.1 (1997)RFC 2616 HTTP / 1.1 (1999)RFC 7230 HTTP / 1.1:メッセージ構文とルーティング(2014)RFC 7231 HTTP / 1.1:セマンティクスとコンテンツ(2014)RFC 7232 HTTP / 1.1:条件付き要求( 2014)RFC 7233 HTTP / 1.1:範囲要求(2014)RFC 7234 HTTP / 1.1:キャッシング(2014)RFC 7235 HTTP / 1.1:認証(2014)RFC 7540 HTTP / 2 (2015)RFC 7541
 
 
 
 
 
 
 
 
 HTTP / 2:HPACKヘッダー圧縮(2015)RFC 8164 HTTP / 2:HTTP / 2のオポチュニスティックセキュリティ(2017)RFC 8336 HTTP / 2:ORIGIN HTTP / 2フレーム(2018)RFC 8441 HTTP / 2:HTTPを使用したWebSocketのブートストラップ/ 2 (2018)
 
 
 

RFC  8740 HTTP / 2:HTTP / 2でのTLS1.3の使用(2020)
によって開発された最初はCERN ; IETFW3C
紹介された1991 ; 30年前 (1991)

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

HTTPの開発は、1989年CERNのTim Berners-Leeによって開始され、0.9という名前の最初のHTTPプロトコルバージョンを使用したクライアントとサーバーの動作を説明する簡単なドキュメントにまとめられました。[2]

その最初のバージョンのHTTPプロトコルはすぐに、はるかに将来のバージョン1.0に向けた最初のドラフトであるより精巧なバージョンに進化しました。[3]

初期のHTTPRequests for Comments(RFC)の開発は数年後に開始され、インターネット技術特別調査委員会(IETF)とWorld Wide Web Consortium(W3C)による協調的な取り組みであり、その後、作業はIETFに移されました。

HTTP / 1は、1996年に完成し(バージョン1.0として)完全に文書化されました。[4] 1997年に(バージョン1.1として)進化し、1999年と2014年に仕様が更新されました。[5]

HTTPSという名前の安全なバリアントは、76%以上のWebサイトで使用されています。[6]

HTTP / 2は、HTTPのセマンティクスを「ネットワーク上で」より効率的に表現したもので、2015年に公開されました。 45%以上のWebサイトで使用されています。[7]それが現在ではほとんどすべてのWebブラウザ(ユーザーの96%)によってサポートされている[8]及び以上の主要Webサーバトランスポート層セキュリティ使用(TLS)アプリケーションレイヤプロトコルのネゴシエーション(ALPN)拡張子を[9]どこTLS 1.2または新しいものが必要です。[10] [11]

HTTP / 3は、HTTP / 2の後継として提案されています。[12] [13] Webサイトの20%以上で使用されています。[14]現在、多くのWebブラウザ(ユーザーの73%)でサポートされています。[15] HTTP / 3は、基盤となるトランスポートプロトコルTCPではなくQUIC使用します。HTTP / 2のように、それはプロトコルの以前のメジャーバージョンを時代遅れにしません。HTTP / 3のサポートがに追加されたのCloudFlareGoogle Chromeの、最初の[16] [17]ともで有効になっているFirefoxの[18]

技術概要

HTTPスキームとWWWドメイン名ラベルで始まるURL

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

Webブラウザーは、ユーザーエージェント(UA)の一例です他のタイプのユーザーエージェントには、検索プロバイダー(Webクローラー)、音声ブラウザーモバイルアプリ、およびWebコンテンツにアクセス、消費、または表示する他のソフトウェアによって使用されるインデックス作成ソフトウェアが含まれます。

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

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

HTTPは、インターネットプロトコルスイートのフレームワーク内で設計されアプリケーション層プロトコルです。その定義は、基礎となる信頼性の高いトランスポート層プロトコル[19]前提としているため、伝送制御プロトコル(TCP)が一般的に使用されます。ただし、HTTPはHTTPUSimple Service Discovery Protocol(SSDP)などのユーザーデータグラムプロトコル(UDP)などの信頼性の低いプロトコルを使用するように適合させることができます

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

ではHTTP / 1.0の別々の接続と同じサーバーには、すべてのリソース要求のために作られています。[20]

ではHTTP / 1.1の代わりにTCP接続は、複数のリソース要求を作るために再利用することができます(つまり、HTMLページ、フレーム、画像のスクリプトスタイルシートなど)。[21] [22]

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

HTTP / 2は、同じクライアントサーバーモデルと同じプロトコルメソッドを維持するための以前のHTTP / 1.1のリビジョンですが、次の順序で異なります。

  • テキストではなくメタデータ(HTTPヘッダー)の圧縮バイナリ表現を使用して、ヘッダーに必要なスペースを大幅に削減します。
  • 2..8 TCP / IP接続の代わりに、アクセスされたサーバードメインごとに単一のTCP / IP(通常は暗号化された)接続を使用する
  • TCP / IP接続ごとに1つ以上の双方向ストリームを使用します。HTTP要求と応答は分割され、小さなパケットで送信され、HOLB(行頭ブロッキング;注:実際にはこれらのストリームは複数として使用されます)の問題をほぼ解決します。同時要求/応答多重化するためのTCP / IPサブ接続。これにより、サーバー側の実際のTCP / IP接続の数がクライアントあたり2..8から1に大幅に削減され、より多くのクライアントに一度にサービスを提供できるようになります。
  • プッシュ機能を追加して、新しいデータが利用可能になるたびにサーバーアプリケーションがクライアントにデータを送信できるようにします(クライアントがポーリング方法を使用してサーバーに新しいデータを定期的に要求することを強制しません)。[24]

したがって、HTTP / 2通信では、HTTP / 1.1通信よりも待ち時間が大幅に短縮され、ほとんどの場合、速度がさらに向上します。

HTTP / 3は以前のHTTP / 2の改訂版であり、TCP / IP接続の代わりにQUIC + UDPトランスポートプロトコルを使用して、通信の平均速度をわずかに改善しTCP / IP接続の時折の(非常にまれな)問題回避します。すべてのストリームのデータフローを一時的にブロックまたは遅くする可能性のある輻輳(「行頭ブロッキング」の別の形式)。

歴史

ハイパーテキストという用語1965年ザナドゥプロジェクトテッドネルソンによって造られました。これは、1945年のエッセイ「考えてみるに」で説明されているマイクロフィルムベースの情報検索および管理「memex」システムに関するVannevarBushの1930年代のビジョンに触発されました。"。CERNのTimBerners-Leeと彼のチームは、HTMLと、WebサーバーおよびWebブラウザーと呼ばれるクライアントユーザーインターフェイスに関連するテクノロジとともに、元のHTTPを発明したことで評価されています。 Berners-Leeは、1989年に「WorldWideWeb」プロジェクトを最初に提案しました。、現在はワールドワイドウェブとして知られています

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

HTTP / 0.9
では1991 HTTPの最初の文書化の公式バージョンは、簡単な文書として書かれました。このバージョンはHTTP / 0.9に選ばれました。[2]

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

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

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

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

HTTP / 1.0
では1996年5月 RFC 1945は、すでに多くのWebブラウザとWebサーバによって使用された前の標準HTTP / 1.0-下書きとして、前の4年間に使用されていたものの、最終的なHTTP / 1.0の改訂として公開されました。  

1996年の初めに、開発者は、今後のHTTP / 1.1仕様のドラフトを使用して、HTTP / 1.0プロトコルの非公式の拡張機能(つまり、キープアライブ接続など)を製品に含めるようになりました。[31]

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

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

年6月1999年の RFC 2616は、前の(廃止)HTTP / 1.1の仕様に基づいて、すべての改善とアップデートが含まれるようにリリースされました。  

W3C HTTP-NG作業部会
の再開の前のHTTPワーキンググループの古い1995年計画、1997 HTTP-NGワーキンググループはHTTP-NG(HTTP新世代)という名前の新しいHTTPプロトコルを開発するために設立されました。単一のTCP / IP接続内でHTTPトランザクションの多重化を使用する新しいプロトコルについて、いくつかの提案/ドラフトが作成されましたが、1999年に、グループは技術的な問題をIETFに渡す活動停止しました[33]

IETF HTTPワーキンググループの再開
2007に、IETF HTTPワーキンググループ(HTTP WG bisまたはHTTPbis)が再開され、最初に以前のHTTP / 1.1仕様を改訂および明確化し、次に将来のHTTP / 2仕様(httpbisという名前)を作成および改良しました。[34] [35]

HTTP / 1.1の最終更新
2014年6月、HTTPワーキンググループは時代遅れ更新6部構成のHTTP / 1.1仕様にリリースRFC 2616 

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

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

SPDYは実際、多くのテストでHTTP / 1.1よりもはるかに高速であったため、Chromiumに急速に採用され、その後、他の主要なWebブラウザーに採用されました[36]

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

HTTP / 2
2012年1月から3月にHTTPワーキンググループ(HTTPbis)は、おそらくSPDYのために行われたアイデアと作業を考慮して、新しいHTTP / 2プロトコルに焦点を合わせ始める必要性を発表しました(HTTP / 1.1仕様の改訂を終える間) 。[37] [38]

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

2015年5月 HTTP / 2は、として出版されたRFC 7540としっかりすでにWebサーバによって、よりゆっくりとSPDYとをサポートするすべてのWebブラウザで採択されました。  

HTTP / 0.9の非推奨
2016年以降、多くの製品マネージャーとユーザーエージェント(ブラウザーなど)およびWebサーバーの開発者は、主に次の理由により、HTTP /0.9プロトコルのサポートを徐々に非推奨にして却下する計画を開始しました[40]

  • それは非常に単純なので、RFCドキュメントを書くことすら誰も気にしないので明らかに時代遅れです(元のドキュメントしかありません)。[2]
  • HTTPヘッダーがなく、他の多くの機能も欠けているため、セキュリティ上の理由から、今日では本当に必要です。
  • 1999..2000以降実際には使用されていません(HTTP /1.0およびHTTP / 1.1のため)。
  • 非常に古いネットワークハードウェア、つまりルーターなどでのみランダムに使用されているようです

注:2021年には、HTTP / 0.9のサポートは正式に廃止されておらず、多くのWebサーバーとブラウザー(サーバーの応答のみ)に(通常は無効になっている場合でも)まだ存在しているため、この却下にかかる時間は不明です。最初にユーザーエージェント(ブラウザなど)で完了し、次にWebサーバーで完了します。

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


HTTPマイルストーンバージョンの概要

バージョン
1991 HTTP / 0.9
1996年 HTTP / 1.0
1997年 HTTP / 1.1
2015年 HTTP / 2
2020年(ドラフト) HTTP / 3

HTTPデータ交換

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

接続を介した要求および応答メッセージ

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

持続的接続

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

ではHTTP / 1.0 RFC 1945に記載されているように、TCP / IPの接続は必ずしなければならない閉じた応答が送られた後、サーバーで。注:1996年後半以降、人気のあるHTTP / 1.0ブラウザーおよびサーバーの一部の開発者(特にHTTP / 1.1のサポートも計画していた開発者)は、(非公式の拡張機能として)一種のキープアライブメカニズムの展開を開始しました(新しいHTTPヘッダー)TCP / IP接続を要求/応答のペアよりも多く開いたままにして、複数の要求/応答の交換を高速化するため。[31]

ではHTTP / 1.1となるようキープアライブ・メカニズムが正式に導入された接続は、複数のリクエスト/レスポンスのために再利用できます。このような持続的接続は、最初の要求が送信された後にクライアントがTCP 3-Way-Handshake接続を再ネゴシエートする必要がないため、要求の待ち時間大幅に短縮します。もう1つのプラスの副作用は、一般に、TCPのスロースタートメカニズムにより、接続が時間とともに速くなることです。

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

HTTP / 2は、単一のTCP / IP接続を介して多数の同時要求/応答を多重化することにより持続的接続の使用を拡張しました

HTTP / 3はTCP / IP接続を使用しませんが、QUIC + UDPを使用します(技術概要も参照)。

コンテンツ検索の最適化

ではHTTP / 0.9要求されたリソースは、常に完全に送信されました。

HTTP / 1.0は条件付きGET要求を許可するために、クライアントによってキャッシュされたリソースを管理するためのヘッダー追加しました実際には、サーバーは、最後に変更された時刻がクライアントに認識されていない場合、またはGET要求への最後の完全な応答以降に変更された場合にのみ、要求されたリソースのコンテンツ全体を返す必要があります。

HTTP / 1.0は、リソースの返されたコンテンツが圧縮されているかどうかを指定するヘッダー「Content-Encoding」を追加しました

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

HTTP / 1.1は、キャッシュされたリソースの条件付き取得をより適切に管理するための新しいヘッダーを追加しました。

HTTP / 1.1では、チャンク転送エンコーディング導入され、サーバーがコンテンツの長さを事前に知らない場合でも(つまり、動的に生成されるなどの理由で)コンテンツを確実に送信するために、コンテンツをチャンクでストリーミングできるようになりました。

HTTP / 1.1は、バイト範囲サービングも追加しました。クライアントは、リソースの1つ以上の部分(バイト範囲)(つまり、コンテンツ全体の最初の部分、途中または最後の部分など)のみを要求できます。サーバーは通常、要求された部分のみを送信します。これは、コンテンツの一部のみを表示するか、ブラウザによってすでに表示されている部分に動的に追加する必要がある場合(つまり、最初または次のn個のコメントのみ)、中断されたダウンロードを再開するのに役立ちます(ファイルが非常に大きい場合)。時間、帯域幅、システムリソースなどを節約するために、Webページ)。

HTTP / 2HTTP / 3は、上記のHTTP /1.1の機能を維持しています。

HTTP認証

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

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

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

認証レルム

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

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

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

一部のWebアプリケーションは、ユーザーセッションを管理する必要があるため、たとえばHTTPCookieまたはWebフォーム内の非表示変数を使用して状態またはサーバー側セッション実装します

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

HTTP /1.1リクエストメッセージ

要求メッセージは、クライアントからターゲットサーバーに送信されます。

これは、HTTP / 1.1要求メッセージの簡単な紹介です(HTTP / 1.0で見られるものと同じ(多かれ少なかれ)セマンティクスを持っています)。

注:HTTP / 2とHTTP / 3は、HTTPメソッドとヘッダーの表現が異なります。

構文のリクエスト

クライアントは、次のもので構成される要求メッセージをサーバーに送信します。[45]

GET /images/logo.png HTTP/1.1
  • 0個以上のリクエストヘッダーフィールド(HTTP / 1.1の場合は少なくとも1つ以上のヘッダー)。それぞれ、大文字と小文字を区別しないフィールド名、コロン、オプションの先頭の空白、フィールド値、オプションの末尾の空白で構成され、末尾にキャリッジリターンとラインフィード。例:
Host: www.example.com
Accept-Language: en
  • キャリッジリターンとラインフィードで構成される空の行。
  • オプションのメッセージ本文


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

唯一のパス名を含む要求行は、クライアントでHTTP / 1.0仕様の前にHTTPとの互換性を維持するために、サーバによって受け入れられているRFC 1945[46] 

リクエストメソッド

telnetを使用して行われたHTTP / 1.1リクエスト。要求メッセージ、応答ヘッダ部と、レスポンスボディが強調表示されています。

HTTPは、識別されたリソースで実行する必要のあるアクションを示すメソッド(動詞と呼ばれることもありますが、仕様のどこに動詞について言及しておらず、OPTIONSまたはHEADも動詞はありません)を定義します。このリソースが表すものは、既存のデータであるか動的に生成されるデータであるかにかかわらず、サーバーの実装によって異なります。多くの場合、リソースは、サーバー上にある実行可能ファイルのファイルまたは出力に対応します。 HTTP / 1.0仕様[47]は、GET、HEAD、POSTメソッド、およびHTTP /1.1仕様[48]を定義しました5つの新しいメソッドを追加しました:PUT、DELETE、CONNECT、OPTIONS、およびTRACE。これらのドキュメントで指定することにより、それらのセマンティクスはよく知られており、依存することができます。すべてのクライアントは任意の方法を使用でき、サーバーは任意の方法の組み合わせをサポートするように構成できます。メソッドが中間者に知られていない場合、それは安全ではなく、べき等ではないメソッドとして扱われます。定義できるメソッドの数に制限はありません。これにより、既存のインフラストラクチャを壊すことなく、将来のメソッドを指定できます。たとえば、WebDAVは7つの新しいメソッドを定義し、RFC 5789には、指定されたPATCHの方法を。  

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

得る
GETメソッドは、ターゲットリソースがその状態の表現を転送することを要求します。GETリクエストはデータ取得するだけで、他の効果はありません。(これはまた、いくつかの他のHTTPメソッドの事実である。)[1] W3Cは、言って、この区別に関するガイダンスの原則を発表した「Webアプリケーションの設計は上記の原則によって、だけでなく、関連する制限によって知らされるべきです。」[52]以下の安全な方法を参照してください
HEADメソッドは、GETリクエストの場合と同様に、ターゲットリソースがその状態の表現を転送することを要求しますが、表現データは応答本文に含まれていません。これは、表現全体を転送することなく、応答ヘッダー内の表現メタデータを取得するのに役立ちます。
役職
POSTメソッドターゲットリソースがターゲットリソースのセマンティクスに従って要求で囲ま表現を処理することを要求します。たとえば、インターネットフォーラムへのメッセージの投稿メーリングリストへの登録、またはオンラインショッピングトランザクションの完了に使用されます[53]
置く
PUTメソッドは、ターゲットリソースがその状態を作成するか、要求に含まれる表現によって定義された状態で更新することを要求します。[54]
消去
DELETEメソッドは、ターゲットリソースがその状態を削除することを要求します。
接続
CONNECTメソッドは、仲介者が要求ターゲットによって識別されたオリジンサーバーへのTCP / IPトンネル確立することを要求します。これはTLSを使用して1つ以上のHTTPプロキシ介した接続を保護するためによく使用されます[55] [56] [57] HTTPCONNECTメソッドを参照してください
オプション
OPTIONSメソッドは、ターゲットリソースがサポートするHTTPメソッドを転送することを要求します。これは、特定のリソースの代わりに「*」を要求することにより、Webサーバーの機能をチェックするために使用できます。
痕跡
TRACEメソッドは、ターゲットリソースが受信した要求を応答本文で転送することを要求します。そうすることで、クライアントは、仲介者によって行われた変更または追加(ある場合)を確認できます。
パッチ
PATCHメソッドは、要求に含まれる表現で定義された部分的な更新に従って、ターゲットリソースがその状態を変更することを要求します。[58]

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

リクエストメソッドのプロパティ
リクエスト方法 RFC リクエストにはペイロード本文があります 応答にはペイロード本体があります 安全な べき等 キャッシュ可能
得る RFC  7231 オプション はい はい はい はい
RFC  7231 オプション 番号 はい はい はい
役職 RFC  7231 はい はい 番号 番号 はい
置く RFC  7231 はい はい 番号 はい 番号
消去 RFC  7231 オプション はい 番号 はい 番号
接続 RFC  7231 オプション はい 番号 番号 番号
オプション RFC  7231 オプション はい はい はい 番号
痕跡 RFC  7231 番号 はい はい はい 番号
パッチ RFC  5789 はい はい 番号 番号 番号

安全な方法

リクエストメソッドを使用したリクエストがサーバーに意図した影響を与えない場合、リクエストメソッドは安全です。メソッドGET、HEAD、OPTIONS、およびTRACEは、安全であると定義されています。言い換えると、安全なメソッドは読み取り専用であることが意図されていますただし、定義上、クライアントから要求されないため、ログファイルへの要求情報の追加広告アカウントへの請求などの副作用は除外されません。

対照的に、POST、PUT、DELETE、CONNECT、およびPATCHメソッドは安全ではありません。サーバーの状態を変更したり、電子メールの送信などの他の影響を及ぼしたりする場合があります。したがって、このような方法は通常、適合したWebロボットやWebクローラーでは使用されません。準拠していないものは、コンテキストや結果に関係なく要求を行う傾向があります。

GETリクエストの規定された安全性にもかかわらず、実際には、サーバーによるそれらの処理は技術的に制限されていません。したがって、不注意または意図的なプログラミングは、サーバーに重要な変更を引き起こす可能性があります。これは、Webキャッシュ検索エンジン、およびその他の自動エージェントに問題を引き起こし、サーバーに意図しない変更を加える可能性があるため、お勧めしません。たとえば、Webサイトでは、https://example.com/article/1234/deleteなどのURLを介してリソースを削除できます。これは、GETを使用しても任意にフェッチすると、記事を削除するだけです。[60]

実際に発生したこの一例は、ユーザーが表示しているページ上の任意のURLをプリフェッチし、レコードを自動的に変更または一括削除する、短命のGoogle WebAccelerator ベータ版でした。ベータ版は、広範な批判を受けて、最初のリリースからわずか数週間で一時停止されました。[61] [60]

べき等メソッド

リクエストメソッドは冪等、その方法では、複数の同一の要求が単一のそのような要求と同じ意図した効果を持っている場合。メソッドPUTとDELETE、および安全なメソッドはべき等として定義されます。

対照的に、POST、CONNECT、およびPATCHメソッドは必ずしもべき等ではないため、同一のPOST要求を複数回送信すると、サーバーの状態がさらに変更されたり、電子メールの送信などの影響があったりする可能性があります。これが望ましい場合もありますが、ユーザーが自分のアクションによって別のリクエストが送信されることに気付いていない場合や、最初のリクエストが成功。一方で、Webブラウザが表示されることが警告ダイアログボックスページをリロードすると、POSTリクエストを再提出することができる場所をいくつかのケースでは、ユーザーに警告するが、それは一般的にアップPOSTリクエストが複数回提出すべきではないハンドルケースへのWebアプリケーションにあります。

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

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

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

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

ヘッダーフィールドのリクエスト

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

HTTP /1.1応答メッセージ

応答メッセージは、以前の要求メッセージへの応答としてサーバーからクライアントに送信されます。

これは、HTTP / 1.1応答メッセージの簡単な紹介です(HTTP / 1.0で見られるものと同じ(多かれ少なかれ)セマンティクスを持っています)。

注:HTTP / 2とHTTP / 3は、HTTPステータスとヘッダーの表現が異なります。

応答構文

サーバーはクライアントに応答メッセージ送信します。これは次のもので構成されます。[45]

HTTP/1.1 200 OK
  • 0個以上の応答ヘッダーフィールド。それぞれ、大文字と小文字を区別しないフィールド名、コロン、オプションの先頭の空白、フィールド値、オプションの末尾の空白で構成され、キャリッジリターンと改行で終わります。例:
Content-Type: text/html
  • キャリッジリターンとラインフィードで構成される空の行。
  • オプションのメッセージ本文

応答ステータスコード

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

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

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

1XX (情報)
リクエストを受け取り、プロセスを続行します。
2XX (成功)
リクエストは正常に受信され、理解され、受け入れられました。
3XX (リダイレクション)
リクエストを完了するには、さらにアクションを実行する必要があります。
4XX (クライアントエラー)
要求に不正な構文が含まれているか、実行できません。
5XX (サーバーエラー)
サーバーは、明らかに有効な要求を実行できませんでした。

応答ヘッダーフィールド

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

各応答ヘッダーフィールドには定義された意味があり、要求メソッドまたは応答ステータスコードのセマンティクスによってさらに洗練されます。

要求/応答トランザクションのHTTP / 1.1の例

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

注:HTTP / 1.0には、いくつかのヘッダーが欠落していることを除いて、同じメッセージがあります。

注:HTTP / 2とHTTP / 3は同じ要求/応答メカニズムを使用しますが、HTTPヘッダーの表現が異なります。

クライアントリクエスト

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

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

サーバーの応答

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

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

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

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

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

暗号化された接続

暗号化されたHTTP接続を確立する最も一般的な方法はHTTPSです。[63]暗号化されたHTTP接続を確立するための他の2つの方法も存在します。SecureHypertextTransferProtocolと、HTTP / 1.1Upgradeヘッダー使用してTLSへのアップグレードを指定します。ただし、これら2つのブラウザのサポートはほとんど存在しません。[64] [65] [66]

同様のプロトコル

も参照してください

参考文献

  1. ^ a b フィールディング、ロイT。; ゲティス、ジェームズ; モーグル、ジェフリーC。; ニールセン、ヘンリク・フリスティク; マシンター、ラリー; リーチ、ポールJ。; バーナーズリー、ティム(1999年6月)。ハイパーテキスト転送プロトコル– HTTP /1.1IETF土井10.17487 / RFC2616RFC 2616
  2. ^ a b c d ティム・バーナー・リー(1991-01-01)。「1991年に定義された元のHTTP」www.w3.orgWorld WideWebコンソーシアム2010年724日取得
  3. ^ a b ティム・バーナー・リー(1992)。「1992年に定義された基本HTTP」www.w3.orgWorld WideWebコンソーシアム20211019日取得
  4. ^ RFC 1945その後、その仕様はHTTP /1.1によって克服されました。 
  5. ^ RFC 2068(1997年)は、によって廃止されたRFC 2616、同様に置換した1999年に、 RFC 7230 2014年。   
  6. ^ 「ウェブサイトのデフォルトプロトコルhttpsの使用統計」w3techs.com 2021-11-03を取得
  7. ^ 「ウェブサイトのためのHTTP / 2の使用統計」w3techs.com 2021-11-02を取得
  8. ^ 「HTML5、CSS3などのサポートテーブルを使用できますか」caniuse.com 2021-11-02を取得
  9. ^ 「トランスポート層セキュリティ(TLS)アプリケーション-層プロトコル交渉拡張」IETF。7月2014 RFC 7301 
  10. ^ Belshe、M。; ペオン、R。; Thomson、M。「ハイパーテキスト転送プロトコルバージョン2、TLS機能の使用」取得した2015年2月10日を
  11. ^ ベンジャミン、デビッド。「HTTP / 2でのTLS1.3の使用」tools.ietf.org 20206月2取得これにより、TLS 1.3を展開する際の障壁が低くなり、TLS1.2よりもセキュリティが大幅に向上します。
  12. ^ 司教、マイク(2021年2月2日)。「ハイパーテキスト転送プロトコルバージョン3(HTTP / 3)」tools.ietf.org 2021-04-07を取得
  13. ^ シンパヌ、カタリン。「HTTP-over-QUICはHTTP / 3 | ZDNetに名前が変更されます」ZDNet 20181119日取得
  14. ^ 「ウェブサイトのためのHTTP / 3の使用統計」w3techs.com 2021-11-02を取得
  15. ^ 「HTML5、CSS3などのサポートテーブルを使用できますか」caniuse.com 2021-11-02を取得
  16. ^ Cimpanu、カタリン(2019年9月26日)。「Cloudflare、Google Chrome、FirefoxはHTTP / 3サポートを追加します」ZDNet 2019年9月27日取得
  17. ^ 「HTTP / 3:過去、現在、そして未来」Cloudflareブログ2019-09-26 2019-10-30を取得しました
  18. ^ 「FirefoxNightlyはHTTP3-一般-Cloudflareコミュニティをサポートしています」2019-11-19 2020年1月23日取得
  19. ^ 「全体的な操作」RFC2616NS。12.秒 1.4。土井10.17487 / RFC2616RFC 2616
  20. ^ 「全体的な操作」RFC1945pp。6–8。1.3。土井10.17487 / RFC1945RFC 1945
  21. ^ a b c 「接続管理:接続」RFC 7230、HTTP / 1.1:メッセージの構文とルーティングpp。51–52。6.1。土井10.17487 / RFC7230RFC 7230
  22. ^ 「接続管理:永続性」RFC 7230、HTTP / 1.1:メッセージの構文とルーティングpp。52–53。6.3。土井10.17487 / RFC7230RFC 7230
  23. ^ 「クラシックHTTPドキュメント」W3.org。1998-05-14 2010年8月1日取得
  24. ^ 「HTTP / 2プロトコルの概要」RFC 7540、ハイパーテキスト転送プロトコルバージョン2(HTTP / 2)NS。5.秒 2.土井10.17487 / RFC7540RFC 7540
  25. ^ 「Webの発明、Webの歴史、Webを発明した人、Tim Berners-Lee、Robert Cailliau、CERN、最初のWebサーバー」LivingInternet 2021-08-11を取得
  26. ^ Berners-Lee、Tim(1990-10-02)。「daemon.c-ハイパーテキスト用のTCP / IPベースのサーバー」www.w3.org 2021-08-11を取得
  27. ^ バーナーズリー、ティム。「ハイパーテキスト転送プロトコル」World WideWebコンソーシアム取得した31年8月2010年
  28. ^ デーブ・ラゲット。「デーブ・ラゲットのバイオ」World WideWebコンソーシアム検索された11年6月2010年
  29. ^ デーブ・ラゲット; バーナーズリー、ティム。「ハイパーテキスト転送プロトコルワーキンググループ」World WideWebコンソーシアム取得した29年9月2010年
  30. ^ デーブ・ラゲット。「HTTPWGプラン」World WideWebコンソーシアム取得した29年9月2010年
  31. ^ a b David Gourley; ブライアン・トッティ; マージョリーセイヤー; Anshu Aggarwal; Sailu Reddy(2002)。「HTTP:決定的なガイド。(章の抜粋:「持続的接続」)」オライリーメディア株式会社 ISBN 978156592509020211018日取得
  32. ^ 「HTTP / 1.1」Webcom.com用語集エントリアーカイブされたオリジナルの2001年11月21日に2009年5月29日取得
  33. ^ 「HTTP-NGワーキンググループ」www.w3.orgワールドワイドウェブコンソーシアム。1997 20211019日取得
  34. ^ Web管理者(2007)。「HTTPワーキンググループ」httpwg.orgIETF 20211019日取得
  35. ^ Web管理者(2007)。「HTTPワーキンググループ:チャーターhttpbis」datatracker.ietf.orgIETF 20211019日取得
  36. ^ 「SPDY:より高速なWebのための実験的なプロトコル」dev.chromium.orgグーグル。2009-11-01 20211019日取得
  37. ^ 「httpbisの再チャーター」IETF; HTTPWG。2012-01-24 20211019日取得
  38. ^ IESG書記(2012-03-19)。「WGアクション:再チャーター:ハイパーテキスト転送プロトコルBis(httpbis)」IETF; HTTPWG 20211019日取得
  39. ^ Ilya Grigorik; スルマ(2019-09-03)。「高性能ブラウザネットワーキング:HTTP / 2の概要developers.google.comグーグル。取得しました。2021年10月19日
  40. ^ マットメンケ(2016-06-30)。「非推奨および削除の意図:HTTP /0.9サポート」groups.google.com 2021-10-15を取得
  41. ^ B 「クライアント/サーバーメッセージング」RFC 7230、HTTP / 1.1:メッセージの構文とルーティングpp。7–8。2.1。土井10.17487 / RFC7230RFC 7230
  42. ^ 「UniformResourceIdentifier:httpURIscheme」RFC 7230、HTTP / 1.1:メッセージの構文とルーティングpp。17–18。2.7.1。土井10.17487 / RFC7230RFC 7230
  43. ^ 「UniformResourceIdentifier:httpsURIスキーム」RFC 7230、HTTP / 1.1:メッセージの構文とルーティングpp。18–19。2.7.2。土井10.17487 / RFC7230RFC 7230
  44. ^ a b c フィールディング、ロイT。; Reschke、Julian F.(2014年6月)。ハイパーテキスト転送プロトコル(HTTP / 1.1):認証IETF。土井10.17487 / RFC7235RFC 7235
  45. ^ a b "メッセージ形式"RFC 7230:HTTP /1.1メッセージの構文とルーティングNS。19.秒 3.土井10.17487 / RFC7230RFC 7230
  46. ^ 「ApacheWeek。HTTP/ 1.1」 090502 apacheweek.com
  47. ^ バーナーズ-リー、ティム; フィールディング、ロイT。; ニールセン、ヘンリク・フリスティク。「メソッド定義」ハイパーテキスト転送プロトコル– HTTP /1.0IETF。pp。30–32。8.土井10.17487 / RFC1945RFC 1945
  48. ^ 「メソッド定義」RFC2616pp。51–57。9.土井10.17487 / RFC2616RFC 2616
  49. ^ 「メッセージフォーマット:開始行、要求行」RFC 7230、ハイパーテキスト転送プロトコル(HTTP / 1.1):メッセージの構文とルーティングpp.21-22。3.1.1。土井10.17487 / RFC7230RFC 7230
  50. ^ 「リクエストメソッド:概要」RFC 7231、ハイパーテキスト転送プロトコル(HTTP / 1.1):セマンティクスとコンテンツpp.21-22。4.1。土井10.17487 / RFC7231RFC 7231
  51. ^ 「メッセージフォーマット:ヘッダーフィールド」RFC 7230、ハイパーテキスト転送プロトコル(HTTP / 1.1):メッセージの構文とルーティングpp.21-22。3.2。土井10.17487 / RFC7230RFC 7230
  52. ^ ジェイコブス、イアン(2004)。「URI、アドレス指定可能性、およびHTTPGETとPOSTの使用」テクニカルアーキテクチャグループの検索W3C 取得した26年9月2010
  53. ^ 「POST」RFC2616NS。54.秒 9.5。土井10.17487 / RFC2616RFC 2616
  54. ^ 「PUT」RFC2616NS。55.秒 9.6。土井10.17487 / RFC2616RFC 2616
  55. ^ 「接続」ハイパーテキスト転送プロトコル– HTTP /1.1IETF。1999年6月。p。57.秒 9.9。土井10.17487 / RFC2616RFC 2616
  56. ^ Khare、Rohit; ローレンス、スコット(2000年5月)。HTTP /1.1内でのTLSへのアップグレードIETF。土井10.17487 / RFC2817RFC 2817
  57. ^ 「脆弱性に関する注意VU#150227:HTTPプロキシのデフォルト構成では任意のTCP接続が許可されます」US-CERT2002-05-17 2007年5月10日取得
  58. ^ Dusseault、リサ; Snell、James M.(2010年3月)。HTTPのPATCHメソッドIETF。土井10.17487 / RFC5789RFC 5789
  59. ^ 「方法」RFC2616NS。36.秒 5.1.1。土井10.17487 / RFC2616RFC 2616
  60. ^ a b Ediger、Brad(2007-12-21)。Advanced Rails:記録的な速さで強力なWebアプリを構築します。O'Reilly Media、Inc.p。188. ISBN 978-0596519728よくある間違いは、リソースを更新するアクションにGETを使用することです。[...]この問題は、Google WebAcceleratorがリリースされた2005年にRailsの世間の注目を集めました。
  61. ^ カントレル、クリスチャン(2005-06-01)。「GoogleWebアクセラレータから何を学びましたか?」アドビブログアドビ。アーカイブされたオリジナルの2017年8月19日に20181119日取得
  62. ^ Luotonen、Ari; フランク、ジョン(1996年2月22日)。HTTPへのバイト範囲取得拡張IETF。IDdraft-ietf-http-range-retrieval-00。
  63. ^ カナバン、ジョン(2001)。ネットワークセキュリティの基礎マサチューセッツ州ノーウッド:アーテックハウス。pp。82–83。ISBN 9781580531764
  64. ^ ミハウ・ザレフスキ。「ブラウザセキュリティハンドブック」取得した30年4月2015
  65. ^ 「ChromiumIssue4527:RFC 2817の実装:HTTP /1.1内でのTLSへのアップグレード」取得した30年4月2015
  66. ^ 「Mozillaバグ276813– [RFE]サポートRFC2817 / HTTP1.1のTLSアップグレード」取得した30年4月2015
  67. ^ ノッティンガム、マーク(2010年10月)。WebリンクIETF。土井10.17487 / RFC5988RFC 5988
  68. ^ 「ハイパーテキスト転送プロトコルBis(httpbis)–憲章」IETF。2012年。


外部リンク