モザイクWebブラウザー

URLは、ユーザーがインターネット上のサイトを識別するためのトリッキーな方法であるとは想定されていませんでした。残念ながら、URNを標準化することはできませんでした。URNはより便利なネーミングシステムになる可能性があります。最新のURLシステムが十分であると信じることは、DOSコマンドラインを偶像化し、すべての人がコマンドラインの使用方法を学ぶ必要があると言う方法です。ウィンドウインターフェイスは、コンピューターを使いやすくし、より人気のあるものにするために考案されました。同じ考えから、Web上のサイトを判別するためのより良い方法に導かれるはずです。

-Dale Dougherty、 1996

「インターネット」という言葉の定義にはいくつかのオプションがあります。それらの1つは、コンピューターネットワークを介して接続されたコンピューターのシステムです。インターネットのこのバージョンは、1969年にARPANETが作成されて登場しました。 HTTP、HTML、およびWebブラウザを作成する前から、メール、ファイル、およびチャットはこのネットワークで機能していました。

1992年、Tim Berners-Leeは、私たちがインターネットと考えるものを生み出した3つの作品、HTTPプロトコル、HTML、およびURLを作成しました。彼の目標は、ハイパーテキストの概念を現実に変換することでした。簡単に言えば、ハイパーテキストとは、相互にリンクするドキュメントを作成する機能です。当時、ハイパーテキストの概念は、ハイパーメディアとともに、「ハイパー」という接頭辞を持つサイエンスフィクションの万能薬と考えられていました。

ハイパーテキストの重要な要件は、あるドキュメントから別のドキュメントにリンクできることです。当時、ドキュメントの保存には多くの形式が使用され、アクセスはGopherやFTPなどのプロトコルを介して行われていました。ティムは、プロトコル、インターネット上のホスト、およびそのホスト上の場所がリンクでエンコードされるように、ファイルにリンクする信頼できる方法を必要としていました。これは、1994年にRFCによって最初に公式に文書化されたURLです。

1992年3月のWorld-Wide Webの最初のプレゼンテーションで、Tim Berners-Leeはそれを「Universal Document Identifier」（UDI）と説明しました。他の多くの形式もこのような識別子と見なされました。

 protocol: aftp host: xxx.yyy.edu path: /pub/doc/README PR=aftp; H=xx.yy.edu; PA=/pub/doc/README; PR:aftp/xx.yy.edu/pub/doc/README /aftp/xx.yy.edu/pub/doc/README)

また、このドキュメントでは、URLでスペースをエンコードする必要がある理由について説明しています（20％）：

UDIはスペースの使用を避けます。スペースは禁止文字です。これは、行がメールなどのシステムで折り返されるときに余分なスペースが表示されることが多いため、または通常の列幅の調整が必要なため、および文字コードの変換中やアプリケーションからアプリケーションへのテキストの転送中にさまざまなタイプのスペースが変換されるためです。

URLは、各通信システムのコンテキストから以前に決定されたスキーム、ドメイン、ポート、資格情報、およびパスの組み合わせを参照するための省略された方法にすぎないことを理解することが重要です。

 scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

これにより、ハイパーテキストからさまざまなシステムにアクセスできるようになりましたが、今日では、ほとんどすべてがHTTPを介して送信されるため、おそらくこの形式はすでに冗長です。 1996年、ブラウザはすでにhttp://

およびwww.

追加しましたwww.

ユーザーのために（これらのURLを使った広告は本当に無意味になります）。

方法

「人々がURLの意味を理解できるか」という質問は意味がないと思います。祖父母に最終的にUNIXファイルシステムの規範を徹底的に調査させることは道徳的に受け入れられないと思います。

-イスラエルデルリオ、 1996

URLのパスを区切るスラッシュは、過去50年間にコンピューターを使用したことがある人なら誰でも知っています。階層ファイルシステム自体は、 MULTICSシステムに導入されました。その作成者は、順番に、1952年に行われたアルバートアインシュタインとの2時間の会話を参照しています。

MULTICSは、大なり記号（ >

）を使用してファイルパスコンポーネントを分離しました。例：

 >usr>bin>local>awk

これは完全に論理的ですが、残念なことに、Unixの連中はリダイレクトを示すために>

を使用することに決め、パスを区切るためにスラッシュ（ /

）を使用しました。

最高裁判所の判決におけるリンク切れ

間違った。今、私たちはお互いに同意していないことがはっきりとわかります。あなたと私

...

人として、私は異なる目的のために異なる基準を使用する権利を留保します。私は作品自体に、 そして特定の翻訳や特定のバージョンに名前を付けたいと思っています。あなたが提供するものよりも豊かな世界が欲しい。「ドキュメント」と「オプション」の2つのレベルのシステムに限定したくありません。

-ティムバーナーズリー、 1993

米国最高裁判所が参照するURLの半分はもう存在しません。あなたが2011年にアカデミックな仕事を読み、それが2001年に書かれたなら、高い確率でどんなURLも動作不能になるでしょう。

1993年に、多くの人がURLが消滅し、URNがそれを置き換えると熱心に信じていました。 Uniform Resource Nameは、URLとは異なり、変更または破損しないフラグメントへのパーマリンクです。ティムバーナーズリーは、 1991年に「緊急の必要性」と説明しました。

URNを作成する最も簡単な方法は、ページコンテンツの暗号化ハッシュを使用することurn:791f0de3cfffc6ec7a0aacda2b147839

。例： urn:791f0de3cfffc6ec7a0aacda2b147839

ただし、このハッシュは誰がどのようにこのハッシュを実際のコンテンツに変換するかを判断することができないため、Webコミュニティの基準を満たしていません。また、この方法では、コンテンツに影響を与えないファイルで頻繁に発生する形式の変更（たとえば、ファイルの圧縮）も考慮されていません。

1996年、Keefe Shaferと他のいくつかの専門家は、URLの破損の問題に対する解決策を提案しました。このソリューションへのリンクは現在機能していません。ロイフィールディングは、1995年7月に実装の提案を発表しました。リンクも壊れています。

Googleでこれらのページを見つけることができました。これにより、ページヘッダーが基本的に最新のURNになりました。 URN形式は1997年に完成し、それ以来ほとんど使用されていません。彼には興味深い実装があります。各URNは、特定のタイプのURNを変換できるauthority

と、 authority

理解できる形式の特定のドキュメント識別子の2つの部分で構成されます。たとえば、 urn:isbn:0131103628

は本を指定し、パーマリンクを形成します。パーマリンクは、ローカルのisbn

コンバーターによって（一連の）URLに変換されます。

検索エンジンの力を考えると、今日の最良のURN形式は、ファイルが過去のURLにリンクする単純な機能である可能性があります。検索エンジンがこの情報にインデックスを付け、ページに正しくリンクできるようにすることができます。

 <!-- On http://zack.is/history --> <link rel="past-url" href="http://zackbloom.com/history.html"> <link rel="past-url" href="http://zack.is/history.html">

リクエストパラメータ

application / x-www-form-urlencoded形式は、多くの点で異常なモンスターであり、長年のランダムな実装とトレードオフの結果、相互運用性に必要な一連の要件が生じました。しかし、これは間違いなく優れたアーキテクチャの例ではありません。

-WhatWG URL仕様

Webをしばらく使用している場合は、クエリパラメータに精通しています。これらはパスの後にあり、 ?name=zack&state=mi

ようなパラメーターをエンコードするために必要です。クエリがアンパサンド文字（ &

）を使用するのは奇妙に思えるかもしれません。アンパサンド文字（ &

）は、HTMLで特殊文字のエンコードに使用されます。 HTMLで記述した場合、アンパサンドをURLにエンコードし、 http://host/?x=1&y=2

をhttp://host/?x=1&y=2

またはhttp://host?x=1&y=2

変換する必要に直面した可能性が高いhttp://host?x=1&y=2

（具体的には、この混乱は常に存在していました）。

また、Cookieは似ているが異なる形式を使用していることに気づいたかもしれません： x=1;y=2

であり、HTML文字と競合しません。 W3Cはこのアイデアを忘れず、誰もがどのようにサポートするかを推奨しました;

、および1995年のクエリパラメータの

当初、URLのこの部分はインデックス検索のみに使用されていました。 Webは元々、素粒子に関与する物理学者間のコラボレーションの方法として作成されました（そしてその資金はこれに基づいていました）。これは、Tim Berners-Leeが本当に幅広いアプリケーションで通信システムを作成していることを知らなかったという意味ではありません。テーブルはおそらく物理学者にとって有用であるという事実にもかかわらず、彼は数年間テーブルのサポートを追加しませんでした。

いずれにせよ、物理学者は情報をエンコードおよびリンクする方法、およびこの情報を見つける方法を必要としていました。 Tim Berners-Leeは、このために<ISINDEX>

タグを作成しました。 <ISINDEX>

ページ<ISINDEX>

存在する場合、ブラウザはこのページで検索できることを知っていました。ブラウザに検索バーが表示され、ユーザーがサーバーにリクエストを送信できるようになりました。

リクエストはプラス記号（ +

）で区切られた一連のキーワードでした：

 http://cernvm/FIND/?sgml+cms

通常はインターネット上で発生するため、平方根を計算するための数値入力フィールドなど、行のすべてにタグを使用し始めました。すぐに、彼らはそのようなフィールドがあまりにも具体的であり、汎用タグ<input>

必要であるという事実を受け入れることを提案しました。

その文では、要求コンポーネントを区切るためにプラス記号が使用されましたが、それ以外はすべて最新のGET要求に似ています。

 http://somehost.somewhere/some/path?x=xxxx+y=yyyy+z=zzzz

全員がこれを承認したわけではありません。リンクの反対側での検索のサポートを示す方法が必要であると考える人もいました。

 <a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>

Tim Berners-Lee は、強く型付けされたクエリを定義する方法が必要だと考えました。

 <ISINDEX TYPE="iana:/www/classes/query/personalinfo">

過去を研究して、ある程度の確実性をもって言う準備ができています。より一般的な解決策が得られたことを嬉しく思います。

<INPUT>

作業は1993年1月に始まり、古いSGMLタイプに基づいていました。（残念ながら） <SELECT>

には独自のより広範な構造が必要であることが決定されました：

 <select name=FIELDNAME type=CHOICETYPE [value=VALUE] [help=HELPUDI]> <choice>item 1 <choice>item 2 <choice>item 3 </select>

興味があれば、はい、アイデアは新しい<option>

を作成する代わりに<li>

要素を再利用することでした。ただし、他の提案がありました。それらの1つでは、変数が置き換えられました。これは、現代のAngularに似ています。

 <ENTRYBLANK TYPE=int LENGTH=length DEFAULT=default VAR=lval> Prompt </ENTRYBLANK> <QUESTION TYPE=float DEFAULT=default VAR=lval> Prompt </QUESTION> <CHOICE DEFAULT=default VAR=lval> <ALTERNATIVE VAL=value1> Prompt1 ... <ALTERNATIVE VAL=valuen> Promptn </CHOICE>

この例では、タイプの指示に基づいて入力のタイプをチェックします。URLの文字列を置換するために、次のようなVAR

値がページで使用可能です。

 http://eager.io/apps/$appId

リクエストコンポーネントを区切るために、 =

ではなく@

を使用した追加の文：

 name@value+name@(value&value)

Mark Andrissen は、 Mosaicで既に実装したものに基づいた方法を提案しました。

 name=value&name=value&name=value

わずか2か月後、 Mosaicはmethod=POST

サポートをフォームに追加したため、最新のHTMLフォームが誕生しました。

もちろん、 Netscapeの Mark AndrissenもCookie形式を作成しました（異なる区切り記号を使用）。彼らの提案は非常に近視眼的であり、 Set-Cookie2

ヘッダーを作成する試みにSet-Cookie2

、Eager製品で対処しなければならない基本的な構造上の問題を作成しました。

フラグメント

URLの「＃」文字の後の部分は「フラグメント」と呼ばれます。フラグメントは最初の仕様以来URLの一部であり、ロードされたページの特定の場所へのリンクを作成するために使用されていました。たとえば、サイトにアンカーがある場合：

 <a name="bio"></a>

リンクを作成できます。

 http://zack.is/#bio

この概念は徐々に（アンカーだけでなく）すべての要素に拡張され、 name

代わりにid

属性に切り替えられました：

 <h1 id="bio">Bio</h1>

ティムバーナーズリーは、米国の郵便住所の形式との関係に基づいて、この記号を使用することを決定しました（ティム自身がイギリス人であるという事実にもかかわらず）。彼によると：

少なくとも米国では、住所は番号記号を使用して建物内のアパートまたは部屋の番号を示すことがよくあります。 12 Acacia Av＃12は、「Acacia Avenueにある建物12、およびこの建物にあるアパート12」を意味します。このシンボルは、そのような目的には自然に見えました。今日のhttp://www.example.com/foo#barは、「リソースhttp://www.example.com/fooで barと呼ばれる特定のビュー」を意味します。

Douglas Engelbartによって作成されたプライマリハイパーテキストシステムでも、このような目的で「＃」が使用されていました。これは偶然または偶発的な「アイデアの借用」である可能性があります。

フラグメントは、HTTPリクエストに具体的に含まれていません。つまり、それらはブラウザのみに存在します。この概念は、クライアント側のナビゲーションを実装するときが来たときに価値がありました（ pushStateが発明される前）。また、スニペットは、サーバーに送信せずにURLの状態を保存することを考えるとき、非常に役立ちました。これはどういう意味ですか？それを理解しましょう：

もぐら山と山

SGMLと同じくらい卑劣な、電子データを送信するため、つまりフォームやフォームを送信するために設計された標準があります。私が知っている唯一のこと：それはスペースのない後方へのFortranのように見えます。

-ティムバーナーズリー、 1993

インターネット標準に責任を負う組織は、HTTP 1.1の最終的な採用以降、特別なことを何もしていないと多くの人が感じていることです。 HTML 5が非常に普及するまで2002年にHTML 4.01でした。この期間は（私にとっては）XHTMLの暗黒時代としても知られています。現実には、標準の人々はめちゃくちゃ忙しかった 。それは彼らが最終的にあまり価値がないと判明したことをやっていたということです。

指示の1つは、セマンティックWebの作成でした。それは夢でした：リソース記述フレームワークを作成すること。（編集者注：フレームワークを作成したいチームから実行してください）。このようなフレームワークは、コンテンツに関するメタ情報を普遍的に記述することを可能にします。たとえば、Corvette Stingrayに関する美しいWebページを作成する代わりに、乗車中に与えられたスピード違反切符のサイズ、色、および数を記述したRDFドキュメントを作成します。

もちろん、これは悪い考えではありません。しかし、このフォーマットはXMLに基づいていたため、これは鶏と卵にとって大きな問題です。全世界を文書化する必要があり、この文書で有用なことを実行できるブラウザーが必要です。

しかし、この考えは少なくとも哲学的議論の条件を生み出した。このような紛争の少なくとも1つは少なくとも10年続き、巧妙なコードネーム「 httpRange-14 」で知られています。

httpRange-14の目標は、「URLとは何か」という根本的な質問に答えることです。 URLは常にドキュメントを参照していますか、それとも何かにリンクできますか？ URLは私のマシンにリンクできますか？

彼らはこの質問に少なくともある程度満足できるほど答えようとしませんでした。代わりに、303リダイレクトを使用する方法とタイミングに焦点を当て、リンク上にドキュメントがないことをユーザーに伝え、ドキュメントがある場所にリダイレクトします。また、フラグメントを使用して（「＃」の後の部分）ユーザーを関連データに誘導することができます。

実用的な現代人にとって、これらの質問はばかげているように見えるかもしれません。私たちの多くは、URLが何かに使用されることが判明した場合、そのために使用できるという事実に慣れています。そして、人々はあなたの製品を使用するかしないかのどちらかです。

しかし、セマンティックWebはセマンティクスにのみ関心がありました。

この特定のトピックは、2002年7月1日、2002年 7月15日、2002年 7月22日、2002年 7月29日、2002年 9月16日、および2005年中に少なくとも20回議論されました。 2005年の「 httpRange-14ソリューション」のおかげで議論は終了し、 2007年と2011年の苦情により再び戻ってきました。2012年には新しいソリューションのリクエストがオープンしました。問題は非常に適切な名前を持つ。発生しなかった唯一のことは、このセマンティックデータがどのURLでもWebに追加されなかったことです。

私たちの歴史の他の例と同様に、単純な基本認証は、ブラウザー開発者（Mosaic）にとって最も簡単に実装できました。したがって、開発者が独自の認証システムを作成するためのツールを入手するまで、基本認証が最初で唯一のソリューションでした。

Webアプリケーション

Webアプリケーションの世界では、Webの基礎がハイパーリンクであると想像するのは奇妙です。これは、あるドキュメントを別のドキュメントに接続する方法であり、時間の経過とともにスタイル、コード、セッション、認証を実行する能力を獲得し、最終的には70年代の多くの研究者が（失敗して）作成しようとした一般的なソーシャルコンピューターシステムになりました。

結論は、最新のプロジェクトやスタートアップと同じです。意味があるのは配布のみです。低品質の製品であっても、人々が使用することを行った場合、彼らはそれをあなたが望むものに変えるのを助けてくれます。一方で、もちろん、誰も製品を使用していない場合、その技術的な完成度は重要ではありません。数百万時間かかったツールは無数にありますが、それらを使用する人はまったくいません。

URL履歴、パート2：パス、フラグメント、要求と承認

方法

最高裁判所の判決におけるリンク切れ

リクエストパラメータ

フラグメント

もぐら山と山

ログイン

Webアプリケーション

More articles: