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

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

ハイパーテキスト転送プロトコル
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 / 2を使用したWebSocketのブートストラップ(2018)
  • RFC  8740 HTTP / 2:HTTP / 2でのTLS1.3の使用(2020)
によって開発された最初はCERN ; IETFW3C
紹介された1991 ; 31年前 (1991)

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

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

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

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

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

HTTPSという名前の安全な亜種は、76%以上のWebサイトで使用されています。[7]

HTTP / 2は、HTTPのセマンティクスを「ネットワーク上」でより​​効率的に表現したもので、2015年に公開されました。45%以上のWebサイトで使用されています。[8]現在、ほぼすべてのWebブラウザー(ユーザーの96%[ 9 ]TLS 1.2または新しいものが必要です。[11] [12]

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

技術概要

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

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

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

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

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

HTTPは、インターネットプロトコルスイートのフレームワーク内で設計されたアプリケーション層プロトコルです。その定義は、基礎となる信頼性の高いトランスポート層プロトコル[20]を前提としているため、伝送制御プロトコル(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では、リソース要求ごとに同じサーバーへの個別の接続が確立されます。[21]

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

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

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

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

したがって、 HTTP / 2通信では、HTTP / 1.1通信よりもはるかに短い遅延が発生し、ほとんどの場合、さらに高速になります。

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

歴史

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

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

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

バージョン 導入された年 現在のステータス
HTTP / 0.9 1991 廃止
HTTP / 1.0 1996年 廃止
HTTP / 1.1 1997年 標準
HTTP / 2 2015年 標準
HTTP / 3 2020 下書き
HTTP / 0.9
1991年に、最初に文書化された公式バージョンのHTTPは、700語未満の長さのプレーンなドキュメントとして作成され、このバージョンはHTTP /0.9と名付けられました。HTTP / 0.9はGETメソッドのみをサポートし、クライアントはサーバーからHTMLドキュメントのみを取得できますが、他のファイル形式や情報のアップロードはサポートしていません。[3]
HTTP /1.0-ドラフト
1992年以降、次のフルバージョンに向けた基本プロトコルの進化を指定する新しいドキュメントが作成されました。0.9バージョンの単純なリクエストメソッドと、クライアントHTTPバージョンを含む完全なGETリクエストの両方をサポートしていました。これは、HTTP /1.0の最終作業に先行する多くの非公式HTTP / 1.0ドラフトの最初のものでした。[4]
W3CHTTPワーキンググループ
HTTPプロトコルの新機能が必要であり、公式RFCとして完全に文書化する必要があると判断した後、 1995年の初めに、プロトコルの標準化と拡張を目的としてHTTPワーキンググループ(HTTP WG、Dave Raggettが主導)が設立されました。拡張された操作、拡張されたネゴシエーション、より豊富なメタ情報を備え、追加のメソッドとヘッダーフィールドを追加することでより効率的になったセキュリティプロトコルと結び付けられています[29] [30]
HTTP WGは、1995年内に新しいバージョンのプロトコルをHTTP /1.0およびHTTP / 1.1として改訂および公開することを計画していましたが、多くの改訂があったため、そのタイムラインは1年以上続きました。[31]
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プロトコルの非公式な拡張機能(つまり、キープアライブ接続など)を製品に含めるようになりました。[32]
HTTP / 1.1
1996年の初めから、主要なWebブラウザとWebサーバーの開発者も、先行標準のHTTP /1.1ドラフト仕様で指定された新機能の実装を開始しました。新しいバージョンのブラウザとサーバーのエンドユーザーによる採用は急速でした。1996年3月、あるWebホスティング会社は、インターネットで使用されているブラウザの40%以上が、仮想ホスティングを有効にするために新しいHTTP /1.1ヘッダー「Host」を使用したと報告しました。同じウェブホスティング会社は、1996年6月までに、サーバーにアクセスするすべてのブラウザの65%が標準前のHTTP /1.1に準拠していると報告しました。[33]
1997年1月、RFC2068がHTTP / 1.1仕様として正式にリリースされました 
1999年6月に、RFC 2616がリリースされ、以前の(廃止された)HTTP /1.1仕様に基づくすべての改善と更新が含まれるようになりました。 
W3CHTTP-NGワーキンググループ
以前のHTTPワーキンググループの古い1995年の計画を再開し、1997年にHTTP-NG(HTTP New Generation)という名前の新しいHTTPプロトコルを開発するためにHTTP-NGワーキンググループが結成されました。単一のTCP / IP接続内でHTTPトランザクションの多重化を使用する新しいプロトコルについて、いくつかの提案/ドラフトが作成されましたが、1999年に、グループは技術的な問題をIETFに渡す活動を停止しました。[34]
IETFHTTPワーキンググループが再開されました
2007年に、IETF HTTPワーキンググループ(HTTP WG bisまたはHTTPbis)が再開され、最初に以前のHTTP / 1.1仕様を改訂および明確化し、次に将来のHTTP / 2仕様(httpbisという名前)を作成および改良しました。[35]

[36]

HTTP /1.1最終更新
2014年6月、HTTPワーキンググループは、 RFC2616を廃止する更新された6部構成のHTTP / 1.1仕様をリリースしまし 
  • 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年、民間企業であるG ​​oogleは、 SPDYという名前の新しいHTTPバイナリプロトコルを開発してテストしたことを発表しました暗黙の目的は、Webトラフィックを大幅に高速化することでした(特に将来のWebブラウザとそのサーバー間)。
SPDYは、多くのテストでHTTP / 1.1よりもはるかに高速であったため、Chromiumにすぐに採用され、その後、他の主要なWebブラウザーに採用されました。[37]
単一のTCP / IP接続を介したHTTPストリームの多重化に関するアイデアのいくつかは、W3C HTTP-NGワーキンググループの作業を含む、さまざまなソースから得られました。
HTTP / 2
2012年1月から3月に、HTTPワーキンググループ(HTTPbis)は、おそらくSPDYのアイデアと作業を考慮して、新しいHTTP / 2プロトコルに焦点を合わせ始める必要があることを発表しました(HTTP / 1.1仕様の改訂を終える間)。[38] [39]
新しいバージョンのHTTPを開発するために何をすべきかについて数か月後、それをSPDYから派生させることが決定されました。[40]
2015年5月、HTTP / 2はRFC7540として公開され、すでにSPDYをサポートしているすべてのWebブラウザーですぐに採用され、Webサーバーではゆっくりと採用されました。 
HTTP /0.9の非推奨
RFC 7230付録-Aでは、HTTP / 1.1バージョン(およびそれ以降)をサポートするサーバーではHTTP /0.9が非推奨になりました。[41] 

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

2016年以降、多くの製品マネージャーとユーザーエージェント(ブラウザーなど)およびWebサーバーの開発者は、主に次の理由により、HTTP /0.9プロトコルのサポートを徐々に廃止および却下する計画を開始しました。[42]
  • それは非常に単純なので、RFCドキュメントを書くことすら誰も気にしないので明らかに時代遅れです(元のドキュメントしかありません)。[3]
  • HTTPヘッダーがなく、他の多くの機能も欠けているため、セキュリティ上の理由から今日では本当に必要です。
  • 1999..2000以降、実際には使用されていません(HTTP /1.0およびHTTP / 1.1のため)。
  • 非常に古いネットワークハードウェア、つまりルーターなどでのみランダムに使用されているようです。

【注2】

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

HTTPデータ交換

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

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

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

持続的接続

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

HTTP / 1.0では、RFC 1945に記載されているように、TCP / IP接続は、応答が送信された後、常にサーバーによって閉じられる必要があります。[注3]

HTTP / 1.1では接続を複数の要求/応答に再利用できるように、keep-alive-mechanismが正式に導入されました。このような持続的接続は、最初の要求が送信された後にクライアントが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
HTTP / 1.0は、条件付きGET要求を許可するために、クライアントによってキャッシュされたリソースを管理するためのヘッダーを追加しました。実際には、サーバーは、最後に変更された時刻がクライアントに認識されていない場合、またはGET要求への最後の完全な応答以降に変更された場合にのみ、要求されたリソースのコンテンツ全体を返す必要があります。これらのヘッダーの1つである「Content-Encoding」は、リソースの返されたコンテンツが圧縮されているかどうかを指定するために追加されました
リソースのコンテンツの全長が事前にわからなかった場合(つまり、動的に生成されたためなど)、ヘッダー"Content-Length: number"はHTTPヘッダーに存在せず、クライアントは、サーバーが接続を閉じたときにコンテンツが完全に送信されました。このメカニズムでは、リソース転送が正常に完了したものと中断されたものを区別できませんでした(サーバー/ネットワークエラーなどが原因)。
HTTP / 1.1
導入されたHTTP / 1.1:
  • キャッシュされたリソースの条件付き取得をより適切に管理するための新しいヘッダー。
  • チャンク転送エンコーディング。サーバーがコンテンツの長さを事前に知らない場合でも(つまり、動的に生成されるためなど)、コンテンツを確実に送信するために、コンテンツをチャンクでストリーミングできるようにします。
  • バイト範囲サービング。クライアントはリソースの1つ以上の部分(バイト範囲)のみを要求でき(つまり、コンテンツ全体の最初の部分、中間または最後の部分など)、サーバーは通常送信します。要求された部分のみ。これは、コンテンツの一部のみを表示するか、ブラウザによってすでに表示されている部分に動的に追加する必要がある場合(つまり、最初または次のn個のコメントのみ)、中断されたダウンロードを再開するのに役立ちます(ファイルが非常に大きい場合)。時間、帯域幅、システムリソースなどを節約するために、Webページ)。
HTTP / 2、HTTP / 3
HTTP / 2とHTTP / 3はどちらも、上記のHTTP /1.1の機能を維持しています。

HTTP認証

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

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

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

認証レルム

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

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

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

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

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

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

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

構文のリクエスト

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

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


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

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

メソッドのリクエスト

telnetを使用して行われたHTTP / 1.1リクエスト。要求メッセージ、応答ヘッダーセクション、および応答本文が強調表示されます。

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

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

得る
GETメソッドは、ターゲットリソースがその状態の表現を転送することを要求します。GETリクエストはデータを取得するだけで、他の効果はありません。(これは他の一部のHTTPメソッドにも当てはまります。)[2]変更を加えずにリソースを取得するには、ブックマークと共有を可能にし、GET応答をキャッシュに適格にするURLを介してアドレス指定できるため、GETがPOSTよりも優先されます。 、したがって、帯域幅を節約できます。W3Cは、この区別に関するガイダンス原則を公開しており、「Webアプリケーションの設計は、上記の原則だけでなく、関連する制限によっても通知される必要があります」と述べています。[54]参照以下の安全な方法
HEADメソッドは、GETリクエストの場合と同様に、ターゲットリソースがその状態の表現を転送することを要求しますが、表現データは応答本文に含まれていません。これは、表現全体を転送することなく、応答ヘッダーの表現メタデータを取得するのに役立ちます。用途には、ステータスコードを介してページが利用可能かどうかを確認したり、ファイルのサイズをすばやく確認したりすることが含まれますContent-Length)。
役職
POSTメソッド、ターゲットリソースが、ターゲットリソースのセマンティクスに従って、要求に含まれる表現を処理することを要求します。たとえば、インターネットフォーラムへのメッセージの投稿、メーリングリストへの登録、またはオンラインショッピングトランザクションの完了に使用されます。[55]
置く
PUTメソッドは、ターゲットリソースがその状態を作成するか、要求に含まれる表現によって定義された状態で更新することを要求します。POSTとの違いは、クライアントがサーバー上のターゲットの場所を指定することです。[56]
消去
DELETEメソッドは、ターゲットリソースがその状態を削除することを要求します。
接続
CONNECTメソッドは、仲介者が要求ターゲットによって識別されたオリジンサーバーへのTCP / IPトンネルを確立することを要求します。これは、 TLSを使用して1つ以上のHTTPプロキシを介した接続を保護するためによく使用されます[57] [58] [59] HTTPCONNECTメソッドを参照してください
オプション
OPTIONSメソッドは、ターゲットリソースがサポートするHTTPメソッドを転送することを要求します。これは、特定のリソースの代わりに「*」を要求することにより、Webサーバーの機能をチェックするために使用できます。
痕跡
TRACEメソッドは、ターゲットリソースが受信した要求を応答本文に転送することを要求します。そうすることで、クライアントは、仲介者によって行われた変更または追加(ある場合)を確認できます。
パッチ
PATCHメソッド、要求に含まれる表現で定義された部分的な更新に従って、ターゲットリソースがその状態を変更することを要求します。これにより、ファイルまたはドキュメントの一部を完全に転送せずに更新することで、帯域幅を節約できます。[60]

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

リクエストメソッドのプロパティ
リクエスト方法 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を使用しても任意にフェッチされた場合、単に記事を削除します。[62]

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

べき等メソッド

リクエストメソッドは、そのメソッドを使用する複数の同一のリクエストが、そのような単一のリクエストと同じ意図された効果を持つ場合、べき等ですメソッド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応答メッセージ

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

応答構文

サーバーは、次の内容で構成される応答メッセージをクライアントに送信します。 [47]

HTTP / 1.1 200 OK
  • 0個以上の応答ヘッダーフィールド。それぞれ、大文字と小文字を区別しないフィールド名、コロン、オプションの先頭の空白、フィールド値、オプションの末尾の空白で構成され、キャリッジリターンと改行で終わります。例:
コンテンツタイプ: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トランザクションの例です。[注5] [注6]

クライアントリクエスト

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")の後に空白行が続くため、要求はそれぞれ次の形式の行の両端で終了します。キャリッジリターンとそれに続く改行ヘッダー値は、単一のIPアドレスを共有するさまざまなDNS"Host: hostname"名を区別し、名前ベースの仮想ホスティングを可能にします。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"を指定し、その長さをバイト単位で示します。HTTP / 1.1 Webサーバーは、フィールドを設定することにより、ドキュメントの特定のバイト範囲の要求に応答する機能を公開しますこれは、クライアントがサーバーから送信されるリソースの特定の部分[64]のみを持つ必要がある場合に役立ちます。これは、バイトサービングと呼ばれます。送信されると、WebサーバーがTCPを閉じることを意味します"Content-Length""Accept-Ranges: bytes""Connection: close"この応答の転送の終了直後の接続。[22]

ほとんどのヘッダー行はオプションですが、一部は必須です。エンティティ本体を含む応答でヘッダー"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です。[65]暗号化されたHTTP接続を確立するための他の2つの方法も存在します。SecureHypertextTransferProtocolと、HTTP / 1.1Upgradeヘッダーを使用してTLSへのアップグレードを指定します。ただし、これら2つのブラウザのサポートはほとんどありません。[66] [67] [68]

同様のプロトコル

も参照してください

メモ

  1. ^ 実際には、これらのストリームは、同時要求/応答を多重化するための複数のTCP / IPサブ接続として使用されるため、サーバー側の実際のTCP / IP接続の数がクライアントあたり2..8から1に大幅に削減され、一度に提供されるより多くのクライアント。
  2. ^ 2021年、HTTP / 0.9のサポートは正式に廃止されることはなく、通常は無効になっている場合でも、多くのWebサーバーおよびブラウザー(サーバー応答のみ)に引き続き存在します。HTTP /0.9を廃止するのにどれくらいの時間がかかるかは不明です。
  3. ^ 1996年後半以降、人気のあるHTTP / 1.0ブラウザおよびサーバーの一部の開発者(特にHTTP / 1.1のサポートも計画していた開発者)は、(非公式の拡張機能として)一種のキープアライブメカニズムを(新しいものを使用して)展開し始めました。 HTTPヘッダー)TCP / IP接続を要求/応答のペアよりも多く開いたままにして、複数の要求/応答の交換を高速化するため。[32]
  4. ^ a b HTTP / 2とHTTP / 3は、HTTPメソッドとヘッダーの表現が異なります。
  5. ^ HTTP / 1.0には、いくつかのヘッダーが欠落していることを除いて、同じメッセージがあります。
  6. ^ HTTP / 2とHTTP / 3は同じリクエスト/レスポンスメカニズムを使用しますが、HTTPヘッダーの表現が異なります。

参考文献

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

外部リンク