[翻訳]”URL”の歴史 — Cloudflare Blog

The History of the URL — Cloudflare Tech Blog

40 min readApr 13, 2020

こちらは翻訳記事となります。原著者の許諾を得て翻訳・公開しております。

英語記事: The History of the URL
原文公開日: 2020/03/05
著者: Zack Bloom
URL: https://blog.cloudflare.com/the-history-of-the-url/

1982年1月11日、22 人のコンピュータ科学者が「コンピュータメール」(今日の電子メール）の問題を議論するために集まりました。議論の参加者にはサン・マイクロシステムズを作った人、Zork の開発者に NTP の開発者、そして政府に Unix の支払いをするように説得した人も含まれていました。

問題は単純で、 ARPANET にある455台のホストが制御不能に陥っていたのです。

この問題は、ARPANET がもともとの NCP プロトコルから、今日の”インターネット”と呼ばれる TCP/IP プロトコルに切り替えようとしたために発生しました。

この切り替えに伴い、多数の相互接続されたネットワーク（つまり「インター…ネット」ですね）が突如としてこの世に現れ、ARPANET が独自ドメインを解決し、そして他のネットワークが独自のドメインを解決するという、より「階層的」なドメインシステムが必要になりました。

当時の他のネットワークは、 ”COMSAT” や ”CHAOSNET” 、 ”UCLNET” に “INTELPOSTNET” など素晴らしい名前がつけられ、アメリカ中の大学や企業のグループによって維持されていました。

彼らは通信したいがために、電話会社から 56k 回線をリースし、ルーティングを行うために必要な PDP-11 を購入するほどでした。

ARPANET の設計ではもともと、ネットワーク上のすべてのホストをリストするファイルを、中央のネットワークインフォメーションセンター（NIC）で管理していました。

この HOSTS.TXT ファイルは、現在の Linux や OS Xシステムの /etc/hosts ファイルのようなものです。ネットワークを変更するたびに、NIC からのFTP 通信（ 1971 年に発明されたプロトコル）がネットワーク上のすべてのホストに対して必要になるので、インフラに大きな負荷がかかっていました。

もちろん、インターネット上にあるすべてのホストに単一のファイルリストがあれば、ホストを無限に拡張することはできません。当時は電子メールの問題が最優先でしたが、課題は主にホストの拡張性にあったのです。

最終的に至った結論は、必要なドメインまたはドメインセットだけを、外部に照会できる階層システムを作成することでした。

彼らは、現在の「 user @ host 」のメールボックス識別子を「 user@host.domain 」に拡張する必要があった、と結論づけています。「 domain 」が、ドメインの階層にあたります。

こうして、この世界にドメインという概念が誕生しました。

これらの決定が、ドメイン名への先見の明に基づいていたというのは幻想です。実際、彼らが選んだソリューションは、「既存システムでの実現難易度がもっとも低いもの」でした。

たとえば、1つの提案は、 <user>.<host> @<domain> となる電子メールアドレス形式でした。もしそれが採用されていたなら、あなたは zack.cloudflare@com 宛に私にメールを送ることになっていました。

UUCPとthe Bang Path

オペレーティングシステムの主な機能は、同じオブジェクトに対していくつかの異なる名前を定義することだと言われています。ネットワークプロトコルも同じような特徴を持っています。 — David D. Clark, 1982

別の提案では、感嘆符（ ! ）でドメインコンポーネントを分離する必要がありました。

たとえば、ARPANET 上の ISIA ホストに接続するために、!ARPA!ISIA に接続します。その後、ワイルドカード（*）を使用してホストを照会できるため、 !ARPA!* はすべての ARPANET ホストを返します。

このアドレス指定方法は、当時の標準のやり方に近く、それを維持するための試みでした。

感嘆符で区切られたホストのシステムといえば、1976年に開発された UUCP と呼ばれるデータ転送ツールにまでさかのぼります。OS XまたはLinux コンピューターであれば、今でも UUCP をインストールできることでしょう。

ARPANET は 1969 年に導入され、すぐに強力なコミュニケーションツールになりました…それにアクセスできる一部の大学や、政府機関の間に限った話ですが。

私たちが現在よく知るインターネットは、その 21 年後の 1991 年まで公開されませんでした。しかし、それはコンピューターのユーザーが、まったく通信しなかったという意味ではありません。

インターネット以前、一般的なコンピューター間の通信方法は、直接的なポイントツーポイントのダイヤルアップ接続でした。

たとえば、ファイルを送信したい場合は、モデムからモデムを呼び出して、ファイルを転送します。これを一種のネットワークに作り上げるために、 UUCP が生まれました。

このシステムでは、認識しているホストと電話番号、そのホスト上のユーザー名とパスワードをリストしたファイルを各コンピューターが所有します。次に、現在のマシンから目的地への「パス」を作成します。各ホストは、次のホストへの接続方法を知っています。こんな感じです：

sw-hosts!digital-lobby!zack

このアドレスは、ファイルを送信したり、コンピューターに直接接続したりするだけでなく、メールアドレスにもなり得ます。「メールサーバー」のない時代は、私のコンピューターが電源オフのとき、あなたは私にメールを送信できなかったのです。

ARPANET の使用は一流大学に限定されていましたが、 UUCP は私たちのためにインターネットの模造品を作成しました。 Usenet と BBS の基盤となったからです。

DNS

最終的には、現在も利用されている DNS システムが 1983 年に提案されました。たとえば、dig ツールを使用して DNS クエリを実行すると、現在であれば次のように返ってきます。

;; ANSWER SECTION:google.com.   299 IN  A 172.217.4.206

これにより、Google.com に 172.217.4.206 のアドレスでアクセスできると分かります。

ご存知かもしれませんが、A はこれが「アドレス」のレコードであり、ドメインを IPv4 アドレスにマッピングしていることを示しています。 299 は「存続可能時間」であり、この値が再度照会されるまでに有効な秒数を示します。では、IN はどのような意味でしょうか？

IN は「インターネット」の略です。この時代はインターネット以外にもコンピューターネットワークがいくつも競合しており、相互運用することを考える必要があったのです。

IN 以外にあり得た値として、CHAOSNET の CH または Athena システムのネームサービスである Hesiod の HS がありました。 CHAOSNET は長い間使われていませんが、MIT の学生は進化した Athena のバージョンをいまだに使用しています。

DNS クラスのリストは IANA ウェブサイトで見つけることができますが、現在も一般的に使用されている値は1つだけです。

TLDs（トップレベルドメイン）

他の TLD が作成されることはありえない。 — John Postel, 1994

ドメインを階層的にすることが決まると、ルートを決定する必要性が生じました。

ルートは伝統的に、単一の「ドット（.）」で表されます。すべてのドメイン名をドットで終了することは意味的にも正しいですし、実際に google.com. とブラウザに入力しても機能します。

最初の TLD は .arpa でした。

これにより、ユーザーは arpa への移行中であっても、従来の ARPANET ホスト名に対処できました。たとえば、私のマシンが以前に hfnet として登録されていた場合、私の新しいアドレスは hfnet.arpa になります。

しかしそれは一時的なもので、サーバーの管理者は移行中に重要な選択を迫られました。「 .com 」「 .gov 」「 .org 」「 .edu」「 .mil 」の5つの TLD のうち、どれを想定しますか？ …というものです。

DNS が階層的であると言うとき、たとえば、 .com を .com ネームサーバーに変え、次に Google.com にアクセスするための、一連のルートDNSサーバーがある状態を表します。

インターネットのルート DN Sゾーンは、 13 の DNS サーバークラスターで構成されています。 1 つの UDP パケットに収まるのはそれだけなので、サーバークラスターは 13 個しかありません。

歴史的に、 DNS は UDP パケットを介して動作してきたため、リクエストへの応答は 512 バイトを超えることはできません。

当然ですが、トップレベルの TLD のネームサーバーは実際にはそれほど頻繁に変更されません。ルート DNS サーバーが受信するリクエストの 98％ はエラーなのです。ほとんどの場合、壊れたおもちゃのようなクライアントが結果を適切にキャッシュしないためです。

これは大きな問題に繋がります。

いくつかのルート DNS オペレーターは、ローカルの IP アドレスで逆引き DNS ルックアップを要求するすべてのユーザーに対して、「ゴーアウェイ」を返すためのサーバーを新たに起動する必要がありました。

TLD ネームサーバーは、世界中のさまざまな企業や政府によって管理されています（Verisignは .com を管理しています）。 .com ドメインを購入すると、約 0.18 ドルが ICANN に、 7.85 ドルが Verisign に支払われます。

Punycode

この世界では、私たち開発者が新しいプロジェクトにつけたバカみたいな名前が、最終的に公開された製品に使われることは稀です。会社のデータベースに「デラウェア」と名づけても（すべての会社が登録されている場所だからです）、それが本番稼働する頃には CompanyMetadataDatastore になっていることでしょう。

しかし、めったにないことですが、中にはひとつくらい抜け出してしまうものがあります。

訳者注） Punycode はPuny（小さな）と Code （コード）を組み合わせた造語で、Unicode の読み方をもじったものだそうです（出典 :『「Punycode」とは何ですか？』）

Punycode は、ドメイン名に Unicode をエンコードするためのシステムです。これが解決する問題は簡単です。

インターネットシステム全体が、もっとも外にある外字がチルダであるASCIIアルファベット使っていたとき、どうやって比薩 .com というドメインを設定するのでしょうか？

それは「 Unicode を使用するためにドメインを切り替えればよい」という、単純な問題ではありません。ドメインを管理するオリジナルの文書には、 ASCII を使ってエンコードされると明記されています。あなたがこの記事を読むために使われている Cisco や Juniper のルーターを含め、過去40 年間のインターネットハードウェアのすべてがそのように仮定されているのです。

ウェブ自体は、決して ASCI Iだけのものではないのです。

実際には ISO 8859–1 を使うために考案され、これは ASCII 文字すべてと、 ¼ や ä のような特殊なマークを持つ文字セットを追加しています。しかし、ラテン語以外の文字は一切含まれていません。

この HTML の制限は最終的に 2007 年に撤廃され、同年には Unicode がウェブ上でもっとも人気のある文字コードとなりました。しかし、ドメインは依然として ASCII に制限されていました。

さて、 Punycode はこの問題を解決する最初の提案ではありませんでした。 UTF-8 は Unicode をバイトにエンコードする一般的な方法です（ 8 はバイトの 8 ビットを表します）。

2000 年にインターネット技術タスクフォース（ IETF ）のメンバーが、UTF-5 のアイデアを思いつきました。そのアイデアとは、 Unicode を 5 つのビットチャンクにエンコードすることでした。

ドメイン名で許可された文字（ A-V と 0–9 ）に、各 5 ビットを後からマッピングできます。もし私が日本語学習のサイトを持っていれば、「日本語 .com 」は、暗号化された「M5E5M72COA9E.com」に変換されてしまいます。

また、この方法にはいくつか欠点があります。

ひとつは、 A-V と 0–9 が出力エンコーディングに使われているということです。

ドメインの各セグメントが 63 文字に制限されている場合、非常に長いドメインになります。ミャンマー語のドメインであれば、 15 文字以下に制限されてしまいます。この提案では、モールス信号や電報で Unicode を送信するために UTF-5 を使用するという、非常に興味深い提案がなされていました。

また、アドレスバーに「 M5E5M72COA9E.com 」ではなく、適切な Unicode 文字を表示させたとき、そのドメインがエンコードされていることを、クライアントにどのようにして知らせるかという問題もありました。

いくつかの提案がありましたが、そのうちの 1 つは DNS レスポンスに未使用のビットを使うことでした。これは「ヘッダー末尾の未使用ビット」であり、 DNS 担当者は「このビットを手放すことを躊躇していた」みたいです。

もう 1 つの提案は、このエンコーディング方法を使ってすべてのドメインを ra — で始めることでした。

当時（ 2000 年 4 月中旬）は、このような特定の文字で始まるドメインは存在しなかったのです。インターネットに詳しい私に言わせれば、この提案が発表された直後に、誰かが恨みを込めて ra — ドメインを登録したのだと思います。

最終的な結論として、 2003 年に Punycode というフォーマットを採用することが決まりました。これには、エンコードされたドメイン名を一気に短縮できるデルタ圧縮が含まれていました。

デルタ圧縮は、ドメイン内のすべての文字が Unicode 内の同じ一般領域に存在する確率が高いため、非常に良いアイデアです。例えば、ペルシャ語の 2 つの文字は、ペルシャ語とヒンディー語の別の 2 つの文字よりも近くに位置しています。これがどう機能するかの例として、ナンセンスなフレーズを考えてみます：

يذؽ

圧縮されていない形式では、これは 3 つの文字 [1610, 1584, 1597] （Unicode コードポイントにもとづく）として保存されます。

これを圧縮するには、まず数値的にソート（元の文字がどこにあったかを追跡する）： [1584, 1597, 1610] となります。

次に、もっとも低い値（ 1584 ） と、その値と次の文字との差（ 13 ）のデルタを格納し、次の文字との差（ 23 ）も同じように格納します。

Punycode はこれらの整数を、ドメイン名での使用が許可されている文字へと効率的にエンコードします。そして、これが「エンコードされたドメインである」ことをクライアントに知らせるために、先頭に xn — を挿入します。すべての Unicode 文字が、ドメインの最後尾に気づくでしょう。

彼らは単に値をエンコードしない、もしくは、ドメインの ASCII 部分に挿入されるべき場所をエンコードします。

例をあげると、「熱狗 sales.com 」は「 n — sales-r65lm0e.com 」になります。ブラウザのアドレスバーに Unicode ベースのドメイン名を入力すると、常にこのようにエンコードされます。

この変換は透過性を持っていますが、セキュリティ上の問題が発生します。あらゆる種類の Unicode 文字は、既存の ASCII 文字と同じように表示されてしまうのです。

たとえば、キリル文字の小文字 a （“а”）とラテン文字の小文字 a （“a”）の違いがわかりません。キリル文字の аmazon.com （ аmazon.com ）が、偽のサイトだと気づくのは難しいでしょう。したがって、🍕💩.ws にアクセスすると、「 xn — vi8hiv.ws 」の文字がアドレスバーにお粗末に表示されてしまいます。

プロトコル

URL の最初の部分は、アクセスに使用するプロトコルです。もっとも一般的なプロトコルは http で、これはティム・バーナーズ＝リーがウェブを動かすために考案したシンプルな文書転送プロトコルです。

しかし、選択肢はひとつだけではありませんでした。 Gopher を使えばいいという人もいました。 Gopher は汎用的ではなく、「ファイルツリーがどのように構造化されているか」を表す、構造化データの送信に特化して設計されています。

例えば、 /Cars エンドポイントをリクエストすると、このようなレスポンスがが返ってくるでしょう：

1Chevy Camaro             /Archives/cars/cc     gopher.cars.com     70iThe Camero is a classic  fake                  (NULL)              0iAmerican Muscle car      fake                  (NULL)              01Ferrari 451              /Factbook/ferrari/451  gopher.ferrari.net 70

これは2つの Car を識別するもので、それぞれの「メタデータ」と「詳細な情報を得るためにどこに接続できるか」を示しています。クライアントはこの情報を解析して、目的地のページとエントリーをリンクさせた使用可能なフォームに変換できました。

最初に普及したプロトコルは FTP で、1971年にリモートコンピュータ上のファイルをリストアップしてダウンロードする方法として開発されました。

Gopher はこれを論理的に拡張したもので、同様のリストを提供しますが、エントリのメタデータを読み取る機能が含まれていました。これは、ニュースフィードやシンプルなデータベース等に、より自由に使えることを意味しています。しかし、 HTTP や HTML を特徴づけるほど自由でシンプルではありませんでした。

HTTP は、 FTP や今日人気が高まっている HTTP/3 のような他のプロトコルと比較すると、とてもシンプルなプロトコルです。

まず第一に、 HTTP は完全にテキストベースであり、バイナリの呪文で構成されていません（その方がより効率的です）。ティム・バーナーズ＝リーは、テキストベースのフォーマットを使用すれば、以降何世代ものプログラマーが HTTP ベースのアプリケーションの開発やデバッグが容易になると直感していました。

HTTP はまた、送信する内容を仮定しません。 HTML 言語に付随して発明されたにもかかわらず、HTTP はどんなコンテンツでも指定できます (当時まだ新しかったMIME Content-Typeを使用します）。プロトコル自体はかなりシンプルです：

このようなリクエストは：

GET /index.html HTTP/1.1
Host: www.example.com

おそらくこのようなレスポンス返ってきます。

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close<html>
    <head>
        <title>An Example Page</title>
    </head>
    <body>
        Hello World, this is a very simple HTML document.
    </body>
</html>

このことから、インターネットが使用するネットワークシステムは、 IP （インターネットプロトコル）に始まっていると考えられます。

IP は、 1 台のコンピュータから別のコンピュータに、データの小さなパケット（約 1500 バイト）を送信する役割を担っています。その上に TCP があります。

TCP は、ドキュメントやファイル全体のように大きなデータブロックを取り、多くの IP パケットを介して信頼性の高い方法で送信します。その上で、 HTTP や FTP のようなプロトコルを実装し、 TCP （または UDP など）を介して送信するデータを理解しやすく意味づけをするために、どのフォーマットを使用すべきかを指定します。

つまり、 TCP/IP は別のコンピュータにバイトのかたまりを送信し、プロトコルはバイトが何であるべきか、何を意味するかを教えてくれるのです。

TCP メッセージの中のバイトを好きなように組み立てて、独自のプロトコルを作ることができます。唯一の条件は、相手が同じ言語を話すことだけです。そのため、プロトコルは標準化するのが一般的です。

もちろん、遊びのプロトコルもあります。例えば、 Quote of The Day プロトコル（ポート 17 ）や Random Characters プロトコル（ポート 19 ）があります。今見ると少し馬鹿げてますが、 HTTP のような汎用的な文書送信フォーマットがいかに重要であったかを示しています。

ポート

Gopher と HTTP のタイムラインは、デフォルトのポート番号で証明できます。 Gopher は 70 、 HTTP は 80 です。

HTTP のポート番号は、 1990 年から 1992 年の間にティム・バーナーズ＝リーの依頼で（おそらく IANA の Jon Postel の手によって）割り当てられました。

「ポート番号」を登録するというこの概念は、インターネット以前からありました。

ARPANET を動かしていた NCP プロトコルでは、リモートアドレスは 40 ビットで識別されていました。最初の 32 ビットはリモートホストを識別するもので、今日の IP アドレスの仕組みに似ています。最後の 8 つは、 AEN （「 Another Eight-bit Number 」の略）として知られており、リモートマシンでポート番号として使用され、異なるプロセス向けのメッセージを分離するために使われていましたた。

要するに、アドレスは「メッセージがどのマシンに送られるべきか」を指定し、 AEN （またはポート番号）は「どのアプリケーションがメッセージを受け取るべきかをリモートのマシンに伝える」ものだったのです。

彼らは、衝突のリスクを減らすために、ユーザーがこれらの「ソケット番号」を即座に登録することを要求しました。 TCP/IP でポート番号が 16 ビットに拡張されたときも、この登録プロセスは継続されました。

プロトコルにはデフォルトのポートがありますが、ローカルでの開発や同じマシン上での複数のサービスのホスティングを可能にするために、ポートを手動で指定できることは理にかなっています。その同じ論理は、ウェブサイトに www.prefixing を付けるための基礎となっていました。

当時は、「実験的な」ウェブサイトをホスティングするためだけに、自分のドメインのルートに誰でもアクセスできるようにするとは思われていませんでした。

しかし、特定のマシンのホスト名（ dx3.cern.ch ）をユーザに与えてしまうと、そのマシンを入れ替えるときに困ってしまいます。共通のサブドメイン（ www.cern.ch ）を使用することで、必要に応じて指定を変更できるのです。

中間ビット

ご存知のように、 URL 構文ではプロトコルと残りのURLの間にダブルスラッシュ（ // )を入れます：

http://cloudflare.com

このダブルスラッシュは、最初のネットワーク化されたワークステーションの 1 つであるアポロコンピュータシステムから継承されました。アポロチームはティム・バーナーズ＝リーと同じ問題を抱えていました。彼らの解決策は、特別なパスフォーマットを作成することでした。

//computername/file/path/as/usual

そしてティム・バーナーズ＝リーは、そのスキームを模倣したのです。ちなみに、彼はドメイン（この場合は example.com ）はパスの最初の部分であるべきだと願ったが、その決定を後悔しています。

URL が現在のようになるとは意図していませんでした：ユーザーがウェブ上のサイトを識別するための無意味な方法です。残念ながら、私たちは URN を標準化できませんでした。現在の URL システムで十分だと主張するのは、DOS コマンドラインを賞賛し、ただ「コマンドラインの構文を学べ」と言っているようなものです。ウィンドウシステムがあるのは、コンピュータをより使いやすく、より広く使われるようにするためです。同じ考えは、ウェブ上の特定のサイトを見つける優れた方法へと私たちを導いてくれるはずです。 — Dale Dougherty 1996

「インターネット」を理解する方法はいくつかあります。

ひとつは、「ネットワークを使って接続されたコンピュータシステム」としての理解です。

インターネットのこのバージョンは、 1969 年に ARPANET の開発によって誕生しました。メールやファイルやチャットはすべて、 HTTP や HTML 、そして「ウェブブラウザ」が誕生する前に、ネットワーク上を飛び交っていました。

1992 年、ティム・バーナーズ＝リーは、 HTTP プロトコルと HTML 、そして URL の３つを開発し、インターネットを誕生させました。

彼の目標は、「ハイパーテキスト」を実現することでした。ハイパーテキストとは、簡単に言えば、互いにリンクする文書を作成する機能のことです。

当時ハイパーテキストは SF 道具ではなく、ハイパーメディアや、前に「 Hyper 」をつけて他の言葉を補完するものだと思われていました。

ハイパーテキストの主な要件は、ある文書から別の文書へのリンク機能でした。

しかし、ティム・バーナーズ＝リーの時代には、これらの文書は多数のフォーマットでホストされ、 Gopher や FTP のようなプロトコルを使ってアクセスされていました。彼は、ファイルのプロトコル、インターネット上のホスト、そのホスト上に存在する場所をエンコードしたファイルを参照するための、共通の方法を必要としていました。

1992 年 3 月のオリジナルの World-Wide Web のプレゼンテーションで、彼ははこれを「 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 ）でスペースをエンコードする必要性についても説明されています：

> The use of white space characters has been avoided in UDIs: spaces
> are not legal characters.  This was done because of the frequent
> introduction of extraneous white space when lines are wrapped by
> systems such as mail, or sheer necessity of narrow column width, and
> because of the  inter-conversion of various forms of white space
> which occurs during character code conversion and the transfer of
> text between applications.（訳）
> UDI では、空白文字の使用は避けられています。:
> スペースは正規の文字ではありません。
> これは、メールのようなシステムで行が折り返されたときに余計なホワイトスペースが頻繁に導入されることや、列幅が狭いことから、文字コードの変換やアプリケーション間のテキスト転送の際に発生する様々な形式のホワイトスペースの相互変換のために行われました。

もっとも重要なことは、 URL は基本的に、スキーム・ドメイン・ポート・資格情報・パスの組み合わせを参照するための、シンプルな方法に過ぎなかったということです。

最初に URL が公式に定義されたのは、 1994 年に発行された RFC です。

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

このシステムにより、ハイパーテキスト内で異なるシステムを参照することが可能になりましたが、事実上すべてのコンテンツが HTTP でホストされる現在、その必要性は薄くなりました。

早いもので 1996 年にはすでに、ブラウザはユーザーに http:// と www. を自動で挿入していました（未だにそれらを含む広告は、本当にばかげています）。

パス

私は、人々が URL の意味を学べるかどうかが問題だとは思っていません。おばあちゃんやおじいちゃんに UNIX のファイルシステムの規約を理解させるのは、道徳的に忌み嫌われていると思うだけです。 — Israel del Rio 1996

URL のスラッシュで区切られたパスコンポーネントは、過去 50 年来のコンピュータのユーザなら誰でも知っています。階層型ファイルシステム自体は、 MULTICS によって導入されました。その開発者は、 1952 年にのAlbert Einstein との 2 時間に及ぶ会話の中でそのことを結論づけました。

MULTICS は、ファイルパスの構成要素を分離するために、 greater than シンボル（ > ） を使用していました。例えば：

>usr>bin>local>awk

これは論理的なやり方でしたが、UNIX使いはパス区切りを前方スラッシュ（ / ）に委ねて、リダイレクトを表すために > を使うことにしました。

最高裁をスナップチャット

間違っている。私たちは今、はっきりと意見が一致していない。あなたと私は
…
私は一人の人間として、異なる目的で異なる基準を用いる権利を持っています。私は、一般的なものに名前をつけられるようにしたい。そして、特定の翻訳と特定のバージョンには名前をつけられます。私は、あなたの提案よりも遥かに豊かな世界を望んでいます。私は、「文書」と「変数」という二段階のシステムに縛られたくありません。 — Tim Berners-Lee 1993

米国最高裁の意見で参照されている URL の半分は、いまや存在しません。 2011 年に 2001 年の学術論文を読んでも、 URL が有効でない可能性が高いのです。

1993 年には、 URL は URN に負けるだろうという熱烈な信念がありました。 URN はコンテンツへの永久的な参照であり、URL とちがい決して変更されたり、壊れたりしません。ティム・バーナーズ＝リーは、1991 年に「緊急の必要性」を最初に説明しました。

URN を作るもっとも簡単な方法は、ページの内容の暗号化ハッシュを使うことかもしれません。例えば、urn:791f0de3cfffc6ec7a0aacda2b147839 などがあります。この方法はウェブコミュニティの基準を満たしていません。また、同じコンテンツを表すファイル（例えば圧縮されたものと圧縮されていないもの）に、ありがちなフォーマットの変更も考慮していませんでした。

1996 年にキース・シェーファー氏をはじめとする数人が、 URL が壊れる問題の解決策を提案しました。この解決策へのリンクは、現在壊れています。ロイ・フィールディングは 1995 年 7 月に実装の提案を投稿しました。そのリンクも…現在壊れています。

私はこれらのページを Google 検索で見つけましたが、機能的にページタイトルに URN が使われていました。 URN の形式は 1997 年に最終決定され、それ以降は基本的に一度も使われていません。

URN の実装自体は興味深いものです。各 URN は2つのコンポーネントから構成されており、与えられたタイプの URN を解決できる権限と、この文書の特定の ID を示しています。例えば、「 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 Spec

もしウェブ好きな人ならば、クエリパラメータには精通しているでしょう。クエリパラメータは URL のパスに続き、オプションをエンコードします。

クエリがアンパサンド文字（ & ）を使用していることに違和感を感じるかもしれませんが、これは HTML で特殊文字をエンコードする際に使用するのと同じ文字です。実際に、あなたがHTMLを長い間使用する中で、URLでアンパサンドをエンコードする必要があったでしょう：

「 http://host/?x=1&y=2 」を「 http://host/?x=1&y=2 」または「 http://host?x=1&y=2（その特定の混乱は常に存在している）」に飛ばしています。

Cookie もこれに近いですが、異なるフォーマットである x=1;y=2 に従っています。この考えは W3C にも当てはまり、1995 年には早くもクエリパラメータの &と同様に ; のサポートを開発者に推奨しています。

もともと、URL のクエリパラメータ部分は「インデックス」を検索するために使われていました。

ウェブはもともと、高エネルギー物理学者の共同研究のために作られました（もちろん、資金提供はそのためでした）。

これは、ティム・バーナーズ＝リーが汎用的なコミュニケーションツールを作った自覚がなかった、という意味ではありません。彼は何年もテーブルのサポートを追加しませんでしたが、これはおそらく物理学者たちがそうさせたのでしょう。

いずれにしても、「物理学者」は、情報をエンコードしてリンクする方法と、その情報を検索する方法を必要としていました。それを提供するために、ティム・バーナーズ＝リーは <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>

ティム・バーナーズ＝リーは、強く型付けされたクエリを定義する方法が必要だと考えていました。

<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> を再利用することを前向きに検討されました。もちろん、代替フォームの提案もありました。その一つには、のちの 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>

この例では、入力は type で指定された型と照合され、 VAR の値は URL の文字列置換で使用できるようにページ上で利用できます。

http://cloudflare.com/apps/$appId

追加の提案では、クエリコンポーネントを分離するために、実際には = ではなく @ を使用しています。

name@value+name@(value&value)

Mosaic 社での実装をもとに、現在使われている方法を提案したのはマーク・アンドリーセンでした。

name=value&name=value&name=value

ちょうど 2 ヶ月後、 Mosaic は method=POST フォームのサポートを追加し、「モダンな」 HTML フォームが誕生しました。

もちろん、 Cookie フォーマットを（別のセパレータを使って）作成したのはマーク・アンドリーセンの Netscape 社でした。彼らの提案はとても近視眼的で、 Set-Cookie2 ヘッダの導入の試みにつながり、今日 Cloudflare で扱われている基本的な構造的な問題を導入しました。

フラグメント

URL の「 # 」に続く部分はフラグメントです。フラグメントは最初の仕様以来、 URL の一部であり、読み込まれるページの特定の場所にリンクするために使用されていました。例えば、サイトにアンカーがあるとします：

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

このようにリンクできます。

http://zack.is/#bio

この概念は徐々にアンカー以外の任意の要素にも拡張され、name 属性ではなく id 属性に移動しました。

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

ティム・バーナーズ＝リーは、（生粋の英国人であるはずですが）米国の住所との関連性に基づいて、この特性を利用しました。彼の言葉を借りれば：

アメリカの住所は、建物内の部屋番号に記号を使うのが一般的です。つまり、 12 Acacia Av #12 は「 12 Acacia Av にある建物の 12 号室」を意味します。これは自然に思えます。ところで、 http://www.example.com/foo#bar は、「リソース http://www.example.com/foo の中で、bar として知られているそれの特定のビュー」を意味します。

ダグラス・エングルバートが作成したオリジナルのハイパーテキストシステムでも、同じ目的で「 # 」という文字が使われていました。これは偶然かもしれませんし、「アイデアの借用」かもしれません。

さて、フラグメントは HTTP リクエストには明示的に含まれません。

このコンセプトは、クライアント側のナビゲーション実装時に価値があると証明されました ( pushState が導入される前のことです）。また、実際にサーバに送信せずに URL に状態を保存する方法として、フラグメントは非常に価値がありました。

これは何を意味するのでしょうか？考えてみましょう。

Molehills and Mountains

電子データ交換 [sic]、つまりフォームやフォーム送信を意味する SGML のような気味の悪い規格があります。私はよく知りませんが、これはフォートランを逆さにしてスペースをなくしたようなものです。 — Tim Berners-Lee 1993

インターネット標準化団体は、 2002 年に HTTP 1.1 と HTML 4.01 が最終決定されてから、 HTML5 が軌道に乗った頃まで、特に何もしていないというのが一般的な認識です。

この時期は、 XHTML の暗黒時代としても知られています（私だけが知っています）。しかし、標準化団体は非常に忙しかったのです。彼らは、最終的にはそれほど価値にはならなかったことばかりやっていましたが。

その努力の1つが、セマンティックウェブでした。

それは、コンテンツに関するメタデータを普遍的に表現できるようにする、リソース記述フレームワーク（編集部注：フレームワークを作ろうとするチームには近寄らないでくださいね）を作る夢でした。

例えば、私の Corvette Stingray （車）についての素敵なウェブページを作る代わりに、そのサイズや色、スピード違反の切符の数などを記述した RDF ドキュメントを作ります。

これは悪い考えではありません。しかし、このフォーマットは XML をベースにしたもので、世界全体を文書化することと、ブラウザがその文書を使って役に立つことの間には、鶏と卵のような大きな問題がありました。

しかし、哲学的な議論の場が提供されたのです。そのような最高の議論の 1 つは、少なくとも 10 年以上続いたもので、 httpRange-14 という見事なコードネームで知られています。

httpRange-14 は、「 URL とは何か」という根本的な疑問に答えようとしました。 URL は常にドキュメントを参照しているのか、それとも何でも参照できるのか？自分の車を指す URL を持つことは可能か？

彼らはこの質問に、満足のいく方法で答えようとはしませんでした。

代わりに、 303 リダイレクトを使ってドキュメントであるリンクへとユーザーを誘導する方法や、 URL フラグメント（「 # 」の後のビット）を使ってユーザーをリンクされたデータへ誘導する方法やタイミングに焦点を当てています。

今日では、「 URL とは何か」という問いは愚問かもしれません。私たちは URL は何にでも使えますし、人々はあなたのものを使ったり使わなかったりします。しかし、セマンティックウェブは、セマンティクス以外のことは気にしていません。

このトピックは、 2002 年 7 月 1 日、 7 月 15 日、 7 月 22 日、 7 月 29 日、 9 月 16 日、そして 2005 年までの間に 20 回以上は議論されました。

2005 年の大規模な「 httpRange-14 の解決」で解決され、 2007 年と 2011 年には苦情が寄せられ、 2012 年には新たな解決策を求める声が上がっています。この問題は衒学的なウェブグループによって激しく議論されました。

ただ、あらゆる種類の URL 上にセマンティックなデータが大量に置かれることだけは起こりませんでした。

認証

URL にはユーザー名とパスワードを含めることができます：

http://zack:shhhhhh@zack.is

ブラウザはこの認証データを Base64 にエンコードし、ヘッダとして送信します：

Authentication: Basic emFjazpzaGhoaGho

Base64 エンコーディングの唯一の目的は、ヘッダ内では無効な可能性のある文字を許可し、ユーザ名とパスワードの値をはっきりさせることです。

特に SSL 以前のインターネットでは、これはやっかいな問題でした。接続を盗み見できる人は、誰でも簡単にパスワードを閲覧できてしまったのです。今も昔も広く使われているセキュリティプロトコル「 Kerberos 」を含む、多くの代替案が提案されました。

しかし多くの例に漏れず、シンプルな Basic 認証の提案が、ブラウザメーカー（ Mosaic ）の実装を考えると簡単でした。これにより、開発者が独自の認証システムを構築するまでは、 Basic 認証が最初の、そして最終的には唯一のソリューションとなりました。

ウェブアプリケーション

ウェブアプリケーションの世界では、ウェブの基本がハイパーリンクであると考えるのは少し奇妙なことかもしれません。

ハイパーリンクは1つのドキュメントを別のドキュメントにリンクする方法であり、スタイリングやコードの実行にセッション、認証によって徐々に拡張されました。そして最終的には、 70 年代の多くの研究者が創造しようとした（そして失敗していた）、ソーシャルなコンピューティング共有の体験を提供することになりました。

結局のところ、結論は当時と同じように、今日のどのようなプロジェクトやスタートアップにも当てはまります。重要なのは採用されることです。

人々に使ってもらえさえすれば、たとえどんなに不完全なものであっても、彼らが仕上げを手伝ってくれます。その逆もまた然りで、誰も使っていなければ、どんなに技術的に優れていようが関係ありません。

何百万時間もかけて作られたツールの中には、今日では誰も使っていないものが無数にあるのです。

原著は、元々 Eager 社のブログに掲載されていた記事を参考にしており、2016年に Eager は買収され Cloudflare Apps のメンバーに加わりました。