HTTPの説明:ハイパーテキスト転送プロトコル、パート1

これは、「何でもプログラムする方法:インターネット」という大きなシリーズの一部です。

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

最近の私たちの多くは、私たちのお気に入りのウェブページを指し示すURLの接頭辞にはあまり注意を払っていません。私たちが当然受けている近代的な魔法のようなものです。 実際、多くのブラウザでは、Webを完全に閲覧する際に「http://」または「https://」が表示されなくなりました。 しかし、Webブラウザを使ってTim-Berners Leeが彼の精神的なハイパーテキストプロジェクトと題したように “World Wide Web”をブラウズするとき、私たちはHTTP URIスキームとその結果のプロトコルを常に使います。 (URIやURIスキームが何であるかわからないのですが、私は、URI、URL、URN、およびURIの解剖学におけるそれぞれのコンポーネントをすべて説明したチュートリアルを持っています)。 どういう意味ですか?

ハイパーテキストとは何ですか?

ハイパーテキストは、従来のテキストと一体的に関連する抽象概念です。 英語の接頭語としての “Hyper-“は、古典的なIPA:/hupér/、またはより現代的なIPA:/hypér/で与えられているように、ギリシャ語の “ὑπρρ“に由来します。 ラテン語では「超」という言葉を思い浮かべるかもしれません。ドイツ語ではニーチェ哲学のような接頭辞「ユーバー」を考えるかもしれません。 この関係はニーチェの使用と同様であり、単純な人間性を超越した高級人であり、ハイパーテキストは超越したテキストであり、書かれたテキストの制約、特に線形性をもっています。

これを達成するための最も重要な方法は、テキストとグラフィックの両方のコンテンツに「ハイパーリンク」(既知のように)を埋め込むことができることで、別のコンテンツとの関係があります。 この埋め込まれたリンクと対話することによって、読者は適切な情報にすぐにアクセスでき、いくつかの芸術的な用途では、他の「経路」が足で議論されているものにアクセスすることができます。 単純な接触、選択、または「クリック」であっても、テキストおよびメディアとの「対話」能力は、そのようなリンクをテキストに埋め込む能力にとって不可欠であり、それゆえ我々が知っているハイパーテキストは表示されなければならない そのような相互作用が可能なデバイス上に存在する。

たとえば、Vannevar Bush(出版された「memex」は、1939年のMechanization and the Record(1939年)で、後に再編され、1945年7月のThe Atlanticで出版された記事として展開された) 「私たちが考えるように」と題された)。 Vannevarは当時の科学の破壊的な業績に懸念を表明した(現代の出来事は、Vannevarがマンハッタン計画の開始と初期の行政に関与していた広島と長崎の原爆であった)。理解とその他のそのようなのれん。これは情報の爆発につながり、情報の爆発を招き、その性質が科学的な追求を妨げたり妨げたりする可能性があります。彼は基本的に、関係を使ってさまざまなレコードを(マイクロフィルム)一緒に関連付けることができる家具のようなデバイスを想像しました。そして、人々はリレーショナルリンクを通してレコード間を行き来する「トレイル」を熟読して作り出すことができます。彼はまた、ある記憶から別の記憶に情報を転送する何らかの方法を想像しました。彼の希望は、「まったく新しい形の百科事典が出現し、それを通って走っている関連性のあるトレイルのメッシュで準備が整えられていて、そこに落ち込んで準備が整った」 (「われわれが考えるように」)マシンの知識をより使いやすくして、特定の集合的な記憶を提案しただけでなく、おなじみの音ですか? (考えてみてください:Wikipedia)あなたは、コードを使って、マシンに “ランダム”で、あるいはトレイルの構築に、情報をジャンプしてプルアップするよう指示することができます。私へのハイパーリンクのように聞こえる。

しかし、1945年からかなり急速に進歩し、1968年12月9日、Douglas Engelbartは、ACM / IEEE-コンピュータ協会のサンフランシスコで開催されたフォールジョイントコンピュータ会議で、「すべてのデモの母親」を務めました。 このデモでは、90分のライブプレゼンテーションで、コンピュータマウス、ビットマップディスプレイ、それらのウィンドウ、グラフィックス、ハイパーテキスト、ビデオ会議、ダイナミックファイルリンク、リビジョンコントロール、コラボレーションリアルタイムエディタを紹介しました。 このすべては、NLS(oN-Line System)と呼ばれる単一のシステムで実証されました。 このデモンストレーションは、Xeroxがグラフィカルユーザーインターフェイスに対して行った仕事を開始し、1980年代にApple MacintoshとMicrosoft Windowsオペレーティングシステムの両方に大きな影響を与えました。 このデモンストレーションは1968年に行われたことを覚えておいてください。デモ前には、ダグラスをコンピュータ科学界の多くが「クラックポット」と見なしていました。 (すべてのデモの母親 – その時より150年先)。

これらの美しい機械が登場すると、潜在的に記憶が可能になるかもしれません! そのため、CERNの科学者、ティム・バーナーズ・リー(Tim Berners-Lee)は、1989年に「WorldWideWeb」という新しいプロジェクトを提案しました。 その考えは、学術機関で働く物理学者の間で、シンプルで即時の情報共有を提供するシステムを構築できるということでした。 彼が書きました:

ハイパーテキストは、ユーザが自由に閲覧できるノードのウェブとして様々な種類の情報にリンクしてアクセスする方法です。 潜在的に、HyperTextは、レポート、メモ、データベース、コンピュータ文書、オンラインシステムのヘルプなど、多くの大きなクラスの格納された情報に単一のユーザーインターフェイスを提供します。 実験で必要とされる情報アクセスの要件の分析を含む、CERNで既に利用可能な機械保存された情報のいくつかの異なるサーバーを組み込むための簡単なスキームの実装を提案します…我々が呼び出すハイパーテキストの世界へのアクセスを提供するプログラム ブラウザ。 – T. Berners-Lee、R. Cailliau、1990年11月12日、CERN

最後に1992年に、Lynxは初期のインターネットウェブブラウザとして生まれました。 インターネット上のどこにいてもドキュメントにアクセスできるドキュメント内にハイパーテキストリンクを提供する能力は、インターネット上でのWebの作成を開始しました。 実際、Lynxは私のローカルライブラリでダイヤルできるACLIN端末システムの一部として初めて使用した初めてのWebブラウザでした。 実際には、実際には、私はtelnetでLynxを起動し、次にMUCKと興味のあるMUDに移動するためにACLINライブラリ800番号システムを使いました…それはAOLの前の外の世界への私の唯一の接続でした!

現在、2017年、ダグラスのアイデアと発明が、ゼロックス・アルトから非常に人気のあるアップル・マッキントッシュにパーソナル・コンピューティングの世界に浸透した後、このインタラクティブ機能のハイパーテキストは、一般的にコンピュータで実現されます。スクリーンはハイパーテキストを表示し、 埋め込みリンクを選択して操作するために、 そして、リンク自体は、memexが提供する機能を提供しています。ワールドワイドウェブと呼ばれる一種の情報インテリジェンスで世界中のさまざまなソースから情報を引き出しています

ただし、注意してください! ハイパーテキストをHTMLとして混同しないでください。 ハイパーテキストは、HTMLがハイパーテキストマークアップ言語である様々な方法でリンクされたコンテンツの抽象的なアイデアです。 HTMLは情報をハイパーテキストシステムにフォーマットするための多くの手段の1つです。

ワールドワイドウェブはハイパーテキストシステムです

あなたが見ると分かるように、World Wide Webとなるのは、究極のHyperTextシステムです。 あなたは、HTMLやHTTPなどのWorld Wide WebやHyperText技術を使用して、このページと画像やその他の魔法を含むすべてのコンテンツを単純に表示するだけです。 Vannevarの夢が現実になったようだが、私たちは現在、社会や個人が理解できる方法で、ますます爆発的な情報を活用している。

コンピュータ間通信

私たちが知っているように、Webの不可欠な要素の1つは、あるマシンから別のマシンに通信する能力です。 つまり、このWebページの情報をあなたのコンピュータ(wunk.me)から手に入れておくにはどうすればいいですか? このページは、HTML(ハイパーテキストマークアップ言語)、CSS(カスケードスタイルシート)、JS(JavaScript)、および多数の画像で構成されています。 どのようにこれらのファイルは、これらのすべてのデータは私のウェブサイトが(倉庫サーバーファームのどこかのサーバー上の)どこからでもあなたのコンピュータに存在するので、あなたはそれを見ることができますか?

コンピュータネットワーキングは、非常に複雑で詳細なトピックであるため、プロトコルやさまざまなメカニズムがどこに入って来ているのか、どのように伝えるのかを正確に特定するのは難しいです。 一言で言えば、私たちが一般的に知っているインターネットは、必ずしもそうではなく、インターネットプロトコルスイートとも呼ばれるTCP / IP(Transmission Control Protocol / Internet Protocol)と総称される技術上で動作します。 それは、「前」に応じて、もう一方の「上」に動作する「レイヤー」に分割されます。 これは、基本的にリンク層、次にインターネット層、次にトランスポート層、そして最後にアプリケーション層で始まります。 各レイヤーは、コンピュータをリンクし、ネットワーク内のあるノードからネットワーク内の別のノードにメッセージを送信することを処理します。

今日、HTTPについては、ありがたいことに、アプリケーション層のみを使用して焦点を合わせます。 これは、アプリケーションが単に別のマシンのポートに接続し、自動的にそのポートにデータを送信し、そのポートが「自動的に」その情報を受信し、そのポートでリッスンしているプログラム 与えられたデータを処理する。 この層の最もインタラクティブな例とベアボーンの例は、基本的なTelnet接続です。 コマンドラインを使用して特定のポートに「Telnet」し、文字を入力して戻ると、その文字がそのコンピュータのポートに送信されます。 HTTPはこのタイプの接続で動作し、後で表示するには実際にWebサーバーのポート(wunk.me:80など)へのTelnet接続を確立し、手動でHTTP要求を入力し、生データHTTP あなたの端末画面に返信してください。 これは本質的にあなたのウェブブラウザが「舞台裏で」行うものです。

プロトコルとは何ですか?

プロトコルはさまざまな方法で考えることができます。コンピュータネットワーク通信の観点からのプロトコルは、与えられたデータの形式、提示の順序、およびそのデータを解釈するために生成されたアルゴリズムに関する単なる合意である。プロトコルは必ずしも実際に通信されているものに関わるものではありませんが、場合によってはそうではありますが、何かが伝達される方法にもっと焦点を当てています。ある意味では、書かれた言語はプロトコルの形式です。言葉の順序と各言語の音の意味は異なります。また、2人が同じ言語を話すことに同意しない限り、単純なままにしておくと通信が行われません。または、あなたとあなたの親友が、お互いにメッセージを送信したいと決めているが、その間に他の誰かがそれらのメッセージを読むことを望まないとします。したがって、あなたは暗号化方法を使用することに決めました。メッセージを送る前にあなたのメッセージを壊してしまいます。受信側のあなたの友人は、メッセージを解読するアルゴリズムまたは方法を持っています。メッセージなしでは何も意味しません。この意味では、通信プロセスに暗号化のプロトコルがあります。

プロトコルはこのコンテキストの外にも存在することができ、実際にコンピュータと中間ハードウェアにポイントAからポイントBへの1つのメッセージを渡す方法を伝えるのに役立ちます。この場合、合意はどのように与えられたデータがマシン間で 電話オペレーターが早い時期に2つの当事者を接続するために従ったルールのように。

あなたが見ることができるように、プロトコルは通信プロセスのカプセル化であり、実際にはそれらが計算プロセスのカプセル化であるという意味でプログラミング言語と比較することができます。 私は抽象的であることが最高ですが、理論的には、プログラミング言語がプロトコルの文脈の外で何ができるのかを考えれば、崩れ始めます。

HTTP、HyperText Transfer Protocolは、送信者または受信者にさまざまな情報を伝える特定の書式設定規則で構成されています。 HTTPでは、「クライアント」が別のマシンに要求を送信します。 そのマシンである “サーバー”は、受信した要求を処理し、クライアントに応答を返します。 この場合、要求と応答は、HTML、CSS、JS、JPG、PNGなどを含むファイルなど、取得する情報の一部と関係しています。

サーバーとクライアント:コンピュータの関係

私は、コンピュータネットワーキングや通信プロトコルで頻繁に話題になっている「クライアント/サーバ」関係についてコメントしています。 しばらくの間、私は、コンピュータがサーバかクライアントのどちらかが非常に混乱しているかどうかの曖昧なアイデンティティを発見しました。 1つは、コンテキストに応じて役割が変わる可能性があり、場合によってはサーバーがクライアントとして機能し、クライアントがサーバーとして機能する可能性があることを理解できませんでした。 または、1台のコンピュータがサーバーとクライアントの両方になる可能性があります。 これをクリアしましょう…

私は最終的に「サーバ」と「クライアント」の面で、実際には単一のコミュニケーションをどのように考えているかを理解しています。 すなわち、コミュニケーションのあらゆるインスタンスは、誰が/何がサーバであり、誰が/何をクライアントにするかを確立する。 ほとんどの閉じられた会話、特にHTTPが要求または応答のいずれかである場合、情報の要求(基本的には質問)を送信し、他のエンティティは応答で質問に答えます。 情報の要求を送信するエンティティ(または動作の要求)は、任意の通信内のクライアントであり、情報を含む応答を送信するエンティティは、任意の通信内のサーバです。 これは以下の画像で要約できます:

実際には、HTTPの場合、APACHEやNGINX、Lighty(lighttp)などの「サーバー」と呼ばれるソフトウェアプログラムをコンピュータ上にセットアップし、それを使用して他の人にウェブページを「提供」します。 HTTP(ブラウザーとRESTクライアント)を使用してこれらのサーバーにアクセスするプログラムは、通常は独自のサーバーも実行しません。ほとんどの場合、常にクライアントとして機能します。 しかし、私はサーバーとクライアントを考えると、誰が情報(または行動)を要求しているのか、誰が応答やフィードバックを提供しているのか、自分自身に尋ねるだけです。

HTTPの多くの面

HTTP自体には複数のバージョンがあり、通常はHTTP /#と入力して表示されます。 HTTPについて言及するときに参照しているドキュメントは、URIチュートリアルのように、今日最も幅広く使用されているHTTP(HTTP / 1.1)の第2から最終バージョンを最終的に定義したRFCです。 これらはRFC7230(メッセージ構文とルーティング)、RFC7231(セマンティクスとコンテンツ)、RFC7232(条件付き要求)、RFC7233(範囲要求)、RFC7234(キャッシュ)、RFC7235(認証)です。 これらの文書は、インターネットの仕組みと標準を定義するのに役立つ「コメントの要求」と呼ばれています。 また、RFC7231に記載されているHTTP / 2仕様もあり、幅広いサポートを受けるために現在HTTPの最終版でもあります。

HTTPの背後に焦点を当てたアイデアは、HyperTextシステム(World Wide Web)のリソースを取得/送信/実行するためのプロトコルであるということです。 これらのリソースは、Uniform Resource Locators(またはURL)を使用して識別および特定されます。 URLは、Uniform Resource Identifierスキーム “http”と “https”を使用します。 URI、スキーム、およびそれらの構造の詳細については、以前のチュートリアルを参照してください。

ここでは、HTTP / 1.0の改訂版であるHTTP / 1.1を取り上げます。 両者の最大の相違点は、HTTP / 1.0では、すべてのリソース要求(CSSファイル、イメージソースファイル、JSファイルなど)ごとにサーバーに別々の接続が行われることです。 各接続が処理時間の点で高価であるTCP接続の確立を必要とするので、完全な「ページ」をロードする。 HTTP / 1.1では、一度確立されたクライアントとサーバーの接続は、追加のファイルをダウンロードするために複数回使用できます。 複数の接続を開くことなく、待ち時間を最小限に抑えます。

HTTPのアイデア

HTTPの設計の哲学を支配する考え方は複数あります。 これらのアイデアの一部は、プロセスとフォーマットの一部の名前だけで、HTTPが持つコンテキストやコンテキストの不備を管理するものもあります。

ヘッダーとペイロード

HTTPリクエストとレスポンスは、ヘッダーとコンテンツという2つのセクションに分割されます。 ヘッダは、バージョン、メソッド、URL、ステータス/エラーコードなどのリクエストとレスポンスにおけるすべてのHTTP関連情報です。コンテンツ、またはエンティティとして知られているものは、任意のリソース 。 たとえば、JPGファイルを要求し、ヘッダに200 OKのステータスコードを持つHTTPメッセージを返し、JPGファイルを構成する美しい1と0をコンテンツ(またはエンティティ)に返します。 あるいは、私はwunk.meにリクエストします.HTTPレスポンスのペイロード/コンテンツ/エンティティで、すべてのHTMLが自分のホームページを構成しています。

無国籍

HTTPはステートレスなプロトコルです。 これは、任意の要求または応答が有する唯一のコンテキストが、それに対応する応答または要求であることを意味する。 それでおしまい。 1つの要求または応答は、後の要求で記憶または考慮されなければならないデータを設定することができない。

たとえば、定義どおりに1つのHTTPリクエストを送信してサーバーにログインした後で、追加の情報を追加せずにすべてのHTTPリクエストでこれを実行したことを自動的に知ることはできません。

しかし、私はそれを行うことができます! あなたは言う。 まあ、一種。 ブラウザーやその他の技術は、純粋なHTTP標準の一部ではなく、他のRFCで定義されているCookieなど、これを中心にさまざまな方法を開発しています。 しかし、クッキーを持っている場合、ブラウザはHTTPリクエストごとにそのクッキー情報をサーバーに送信します。 これは、HTTPレルムでは、HTTP要求でそれ自体を再記述することなく、もはや存在しないからです。 すべてのリクエストは空白のスレートで、コンテキストはありません。これはステートレスです。

HTTPセッション

ステートレスであるにもかかわらず、HTTPセッションなどがあります。 セッションは、一連のネットワーク要求 – 応答トランザクションによって定義されます。 HTTPクライアントは、特定のポート(80または8080など)の特定のホストへの要求を開始し、もう一方のサーバーは要求をリスンして受信します。 サーバーはこの要求を処理し、ステータス行とそれ自身のメッセージを返します。 最初から最後まで、これはHTTPセッションです。

HTTP / 1.1で持続的な接続または永続的な接続が導入されていると、クライアントは要求があるたびに接続を終了するのではなく、接続が開いている間にさらにHTTP要求を行うことがあります。 接続が閉じられると、HTTPセッションは終了します(私の意見では)。

リクエストメソッド

HTTPリクエストが形成されるとき、その最も重要な情報の1つは、URLの使用によるリソースの識別です。 2番目に重要な情報は、特定されたリソースに影響を与える「動詞」または「アクション」です。 これらは一般に「メソッド」と呼ばれています(プログラミングの傾向には、クラスのメソッドのように考えることができます)。 HTTP / 1.0ではGET、POST、およびHEADメソッドが定義されていましたが、HTTP / 1.1ではOPTIONS、PUT、DELETE、TRACE、およびCONNECTも追加されました。 技術的には、定義できるメソッドの数に制限はなく、実際にはWebDAV自体に7つの新しいメソッドが定義されています。 どのクライアントでも任意の方法を使用することができ、任意のサーバーはあらゆる理想的な方法の組み合わせをサポートできます。 私は以下の方法に行きます:

  • GET – このメソッドは、指定されたURLの指定された表現が要求されていることを指定します。 仕様によると、GETリクエストメソッドはデータを取得するだけです。 つまり、サーバーにGETメソッド要求を発行すると、サーバー側のリソースやその他の関連するデータを変更する副作用があってはなりません。
  • POST – このメソッドは、要求されたリソースに対して実際にデータをサーバーに渡します。 たとえば、リソースはコメントスレッドであり、そのコメントスレッドリソースへのPOSTメソッド要求はスレッドに新しいコメントを追加します。 別の例は、JPGイメージをInstagramユーザープロファイルに含むPOSTメソッド要求であり、JPGイメージをそのユーザーのアカウントの下の別のリソースにする。 通常、Webフォームからサーバー上のデータ処理プロセスにデータを送信するために使用されます。
  • HEAD – このメソッドはGETとまったく同じですが、HTMLやJPGファイルなどのリソースの表現である応答全体を取得するのではなく、メッセージのHTTP応答部分のみを取得します。 ファイル全体を尋ねることなく、HTTPメタ情報を確認することができます。 20 MBの地図画像を転送することなく、マップ画像上でHTTP情報を探したい場合に便利です。
  • PUT – (HTTP / 1.1で追加されました)ここでのアイデアは、特定のURIの下でコンテンツ内のデータを「アップロード」または格納する要求であるということです。 URIが既に存在するリソースを参照している場合は、変更されます。 URIがサーバー上の何かに解決されない場合、サーバーはおそらくそのリソースを作成し、指定されたURIで参照します。
  • DELETE – (HTTP / 1.1で追加されました)これはかなり自明です。 PUTと同様に、この場合は削除するURIを指定します。 すなわち、その記録はすべて消去され、その記憶または表現はもはや存在しない。
  • OPTIONS – (HTTP / 1.1で追加)OPTIONSメソッド要求は、サーバーが特定のURLに対してサポートするHTTPメソッドを返します。 たとえば、特定のURLでサーバーがPUTまたはPOST要求に応答するかどうかを判断してから、それらの要求を必ず送信しようとします。
  • TRACE – (HTTP / 1.1で追加)この方法の背後にあるアイデアは、メッセージがインターネット上をルーティングされた後、エンドポイントサーバーが何を受信しているかを見たい場合があるということです。 この方法では、受信した要求を送信者に再印刷またはエコーして、間にあるすべてのマシンによって変更または追加が行われたかどうかをクライアントが確認できるようにします。
    • 重要なセキュリティ情報:TRACEメソッドは、クロスサイトトレーシング攻撃と呼ばれるもので使用できます。 これは、悪意のあるユーザーにさまざまなオンラインリソースへのアクセスを公開し、許可する脆弱性であり、したがって、運用準備が整っているすべての公開サーバー(これはMicrosoft IISサーバー上に存在するTRACKメソッドを含む)でTRACEを無効にする必要があります。
  • PATCH – (RFC5789で追加されました)これは、リソースを上書きするのではなく、部分的な変更だけを適用するという点を除いて、PUTメソッドに多少似ています。 したがって、あるものを変更しますが、他のものは変更しないでください。 これは、リソースを取得し、変更して、リソースを元に戻すのと同じようになります。
  • CONNECT – (HTTP / 1.1で追加)この方法は、より技術的でネットワークに富んでいます。 これは、要求接続を透過的なTCP / IPトンネルに変換する方法です。 これは通常、暗号化されていないプロキシを介してSSL通信(Secure Sockets Layer)を容易にするために行われます。

どこでもHTTPサーバーが期待されているのは、汎用サーバーのベースラインがGETおよびHEADメソッドを実装することだということです。 さらに、thehyはOPTIONSメソッドにも対応したり実装したりすることで、彼らにはGETとHEADだけがあることを伝えることができます。

設計と実装において重要なHTTP要求メソッドに関連するいくつかの概念があります。

  • 安全性 – 安全で安全でないと定義されているメソッドがあります。安全性の基準は、いくつかの方法が情報検索専用に設計されているという事実に基づいている。これは、要求しているURLが何であれ、サーバー上のリソースに何も起こらないようにするか、またはネットワーク上でその表現を送信する以外に何も起こらないことを意味します。これらのメソッドには、HEAD、GET、OPTIONS、TRACEなどがあります。これは安全と呼ばれています。なぜなら、任意の種類のランダムなGETリクエストを任意にサーバーに作成し、サーバーの状態を何も追跡して何も中断されることはないからです。残念なことに、この安全性は仕様では要求されておらず、これらの条件の安全性はすべての実装で保証されていません。しかし、一般的に、そうでなければ、Webスパイダー/ロボット/クローラーはGETリクエスト後にサイトを索引付けする要求を出すことができず、大混乱を引き起こすことはありません。同様に、安全でないメソッドには、POST、PUT、DELETE、およびPATCHが含まれます。これらは受信/実行がサーバーまたはそれ以外に副作用を引き起こす可能性があるため、この点では安全でないとみなされます。これらのメソッドは、参照するリソースを変更できる何かをすることを意図しています。たとえば、複数の異なるファイルを同じURIにプットすると、そのリソースの上書きが連続して行われ、最後にアップロードされたファイルのみが返されます。
  • 偶然性 – メソッドPUTとDELETEは冪等であることを意味します。この文脈における冪等性とは、同じ結果を同じ操作を2回「適用」する能力を指します。私はWikipediaを引用しています:「単項演算(または関数)は、任意の値に2回適用されたときは、一度適用されたときと同じ結果を出すとき、つまりƒ(ƒ(x))≡ƒ(x例えばabs(abs(x))≡abs(x)の絶対値関数は冪等である。これは、基本的には、これらのメソッドで複数の同一のリクエストを作成する場合は、1つのリクエストを行ったようになります。サーバーから同じ応答が得られるわけではありませんが、問題のリソースに関してはサーバーで同じ結果が得られます。行内の2つの同一のDELETEメソッド要求は、指定されたリソースを1回だけ削除する必要があります(すでに削除されているため、何も削除されません)。行内の2つの同一のPUTメソッド要求は、サーバ上の2つの別々のファイルではなく、1つのリソース表現(例えばJPGイメージ)を有する1つのURLを生成するはずである。 HTTPはステートレスなので、GET、HEAD、OPTIONS、およびTRACEメソッドも冪等である。

    POSTメソッドは冪等ではありません! それは偶然になる可能性がありますが、絶対に保証はありません。 これは、複数の同一のPOSTリクエストが必ずしも同じ結果で終わるとは限らないことを意味します。 例えば、ブログにコメントを残すという副作用を引き起こすPOSTリクエストは、再度送信された場合、同じコメントを再度投稿します。 適切な保護がなければ、「今すぐ購入!」をクリックしてください。 あなたのクレジットカードを2回請求するPOSTリクエストが発生することがあります。 これは、POSTリクエストを再ロードする必要があるときにブラウザに何度も警告を表示して、POSTリクエストを再度送信する必要がある理由です。 アプリケーション自体は、これらの不幸な間違いを処理するために書かれていますが、しばしばありますが、重要な考慮事項です。

  • 実装 – 残念なことに、上記の安全基準とイデモポテンス基準は、決して強制されません。 これは、間違ったプログラマーが、GETリクエストであらゆる種類の奇妙な副作用を引き起こす可能性のあるサーバーを作成したり、PUTリクエストごとに古いものを上書きせずに追加ファイルを置くことができることを意味します。 プログラマは、自分のシステムの正しさを保証し、ユーザが大いに怒らないことを前提とした何かを構築することを確実にする必要があります。

ステータスコード

HTTP応答は実際にはHTTP要求とは技術的に異なる形式になっています。 レスポンスのHTTPヘッダーで定義されたメソッドの代わりに、HTTPステータスコードと呼ばれるものがあります。 これはHTTP / 1.0以来のことです。 あなたは非常に頻繁にこれらのステータスコードの中で最も頻繁に見てきました。特にインターネットの初期の段階では、404となっています。ステータスコードは基本的に3桁の数字の後にフレーズ(理由フレーズ)を続けたものです。 したがって、私たちの次の例では、おそらく404 Not Foundがよく見受けられました。 特に403 Forbiddenを楽しんでいます。 うーん、verboten!

コードの最初の桁がステータスコードの分類を決定します。 こうすることで、多くの標準化されたステータスコードが存在しますが、カスタムステータスコードを使用できます。 より可能性の高いアプリケーションは、プログラマーの裁量でその場所またはアプリケーションに適用可能な等価物で「理由フレーズ」をカスタマイズすることです。 これは主に、HTTP応答のステータスコードがマシンと人間の両方で読み取られることを目的としているためです.3桁のコードはコンピュータ/プログラム用であり、理由句は人間向けです。

最も一般的に使用されるコードは、200 OKステータスコードであり、すべてが正しく動作し、リダイレクトまたはエラーがないことを示します。 3桁のコードは599になり、次のように分類されます。

  • 1XX – 情報レスポンス
  • 2XX – 成功した回答
  • 3XX – リダイレクション通知
  • 4XX – クライアントエラー
  • 5XX – サーバーエラー

仲介者

HTTP要求が渡されて最終的に宛先を見つけるためにインターネットに送信されると、最終的な場所に到達する前にHTTPに関して特定の目的を果たす他のサーバを通過する可能性があります。 3つの一般的なHTTP仲介者には、「プロキシ」、「ゲートウェイ」、および「トンネル」が含まれます。 単一の仲介装置は、要求に応じて任意の時点でプロキシ、ゲートウェイ、またはトンネルとして機能する可能性があるため、これらはマシン全体に束縛されません。 これらの仲介者はこの記事の範囲を超えており、ネットワーキングとネットワーク設定の方法論にもっと取り込まれています。 ネットワークプロトコルの「下位層」(上を参照)で動作し、知識や許可なしにトラフィックをフィルタリングまたはリダイレクトするネットワーク仲介者が第4の種類の仲介者です。 これは、HTTP標準の観点からみた中間者攻撃である。

キャッシング

クライアント、サーバ、仲介者などは、適切なHTTP応答およびそのペイロードをキャッシュするためにキャッシュシステムを使用することができる。 キャッシュに適していると思われるものと、これらのキャッシュにアクセスできるタイミングは、実際にはHTTPヘッダーのメタ情報によって決まります(下記参照)。 サーバーはHTTPトンネルとして機能している間はキャッシュできません(上記参照)。 これらのキャッシュは、チェーンの任意のステップに存在することができ、クライアント装置自体にも存在し、一般的に見える画像および他のそのようなリソースをキャッシュすることさえできる。 この目的は、ネットワークトラフィックを削減し、コンテンツ配信を高速化し、新しい情報のためにネットワーク負荷を分散させることです。

認証

認証は、基本的には、あなたがあなたが誰かであることを証明している資格情報を提供しているか、少なくともURIによって識別されるリソースを表示して操作する権限を持っていることを証明しています。 HTTP経由で利用できる認証スキームは複数あり、1つは基本アクセス認証で、もう1つはダイジェストアクセス認証です。どちらもチャレンジレスポンスシステムで動作しますが、基本的にサーバーはチャレンジ(一般的にはユーザー名とパスワード)を発行し、チャレンジが満たされると要求が処理され、処理されます。これらは2つの認証スキームの例ですが、HTTPはアクセス制御と認証のための一般的なフレームワークも提供します。また、公開鍵や秘密鍵を使用して独自の手段とアクセス制御の方法を構築することもよくありますが、これはおそらくWeb上の多くのHTTPサービスで見られました。チャレンジ・レスポンス・スキームは、一般的なフレームワークであり、基本とダイジェスト以外のスキームを実装できるように拡張可能です。

HTTP認証には、認証レルムというものもあります。 これらは少し難解ですが、サーバーは1つのURIに対して別々のスコープを実装でき、レルム値の文字列の存在に応じて同じURLの異なるログイン画面を想像できるように基本的に許可します。 このタイプの認証は、この入門記事の範囲から多少外れています。

結論

これは、HTTPプロトコルチュートリアルのパート1のためです。 ここでは、HTTPの基本概念とそれが扱う情報の種類について説明しました。 しかし、HTTPリクエストやレスポンスの具体的な実装については触れていません。 これらの要求と応答には、コンテンツの長さ、コンテンツタイプ、キャッシング、ルーティングなどに関連する多くの “メタデータ”または特定のHTTPメッセージに関連するデータがあります。これらはヘッダーデータフィールドと呼ばれます。 次の部分では、HTTPとこれらのヘッダーデータフィールドの正確な書式設定について掘り下げます。 ありがとう!

あなたが私の執筆を感謝するなら、私のパトロンを通して私を支えてください。( パトロン )

毎月コミットメントがあなたの路地を上回っていない場合は、いつでも「コーヒーを買う」ことができます。

photo credit: Kevin Baird 8493 UX / multimedia bookshelf via photopin (license)

Liked it? Take a second to support kadar on Patreon!

あわせて読みたい

コメントを残す

%d人のブロガーが「いいね」をつけました。