URLのセキュリティー

Edit New

URL (Web)

[60] URL は、 Web においてアドレスや識別子として用いられている文字列です。

仕様書

[63] URL は、 URL Standard により定義されています。

URL の構成要素

[155] 文字列表現を URL文字列 (URL string) >>156、 データ構造を URL記録 (URLレコード) (URL record) >>154といい、 曖昧でなければどちらも共に URL と呼びます。

[157] 仕様書の定義上、 URL文字列は、 URL としての構文に適合する文字列をいいます。 その他に、 URL構文解析器を通すと URL記録が得られるが URL文字列ではない文字列や、 URL構文解析器が失敗する文字列もあります。
[158] すべての URL記録は、 URL直列化器により URL文字列に変換できます。 すべての URL文字列]は、適切な基底URLを選べばURL記録に変換できます。 (基底URLによっては失敗となることがあります。)

[70] URL はいろいろな要素によって構成されています。

[26] URL記録は、次の状態を持ちます。

cannot-be-a-base-URL flag
boolean。初期状態は偽。
cannot have a username/password/port
起源
credentialsを含む
blog URL entry
オブジェクト
blob: URL が関連付けられた Blob (あれば) です。初期状態は null。

[159] URL記録はオブジェクトを持つことができますが、 URL文字列はこれに相当するものを持ちません。 オブジェクトは URL構文解析器によってその時点の blob URL store の状態に基づき設定されます。

URL scheme

[137] URI の構造は、大きく scheme (識別方式), authority (命名権者), path (経路), query (照会), fragment (素片識別子) の5つに分けられます。

このうち、 scheme は authority, path, query の詳細な構文と意味を決定します。

URI では様々な scheme が定義・利用されています。 それぞれの URI scheme はその構文と、 誰が識別子を作ることができるのか、 その識別子がどんな意味を持つのか、 色々なプロトコルや書式でどんな風に使うことができるのかなどを規定しています。

[138] このように URI scheme はそれぞれ独立した識別子の空間を作っています。 この独立性により、新しい資源の識別方法を URI に取り込むことが可能になっています。

[139] 詳しくは URI scheme の項をご覧下さい。

素片識別子

[140] URI の5大部品の一つが素片識別子 (fragment) です。素片識別子以外の URI が識別した資源の一部分・一表現を、 素片識別子は更に細かく識別します。

素片識別子は URI の一部ではないなどと呼ばれていた時代もありましたが、 現在では URI の一部分と考えられています。

[141] 詳しくは素片識別子の項をご覧下さい。

URL の分類

[61] URL には、単独で解釈できる絶対URLと、他の絶対URLを文脈として解釈される相対URLがあります。 細かな構文要素が認められるか否かにより、更に細かく次のような分類が存在しています。

[62] 絶対URLには URL scheme が含まれており、その値によって http: URL、 mailto: URL、ftp: URL などに分類されます。

URL scheme も参照。

[32] 妥当なURL (valid URL) とは、 URL のうち、 URL Standard の著者への要件に適合するものをいいます >>31。

URL と URI、URN、IRI

[199] 1990年代中頃、それまでのアドレスとしての URL に加えて、 名前である URN が提案され、両者の総称が URI とされました。 URN は scheme が urn の URI で、 URL はそれ以外の URI と決められました。

[200] 2000年前後の頃、 URI には URL としての性質が強い場合と URN としての性質が強い場合があり、一概にどちらであるとは言えないと考えられるようになりました。 例えば http: URI は HTTP でアドレス (URL) としても使えるし、 XML名前空間で名前 (URN) としても使えると解釈されました。 このため技術用語の URL は徐々に URI へと置き換えられていきました。

[202] 2000年代前半、 ASCII文字の URI に対して、 Unicode に拡張された IRI が開発されました。 IRI は URI を拡張した事実上の新バージョンでしたが、 形式的には別の名前で別の仕様書で定義される別の技術とされました。 それまでの URI は IRI に置き換えられていきましたが、 URI を使い続けるものや、 URI という呼称で実態が IRI のものもありました。

[203] 2000年代半ば頃、 HTML5 は一部の専門家コミュニティー内でしか通用しない URI や IRI といった語を排除し、一般の開発者や市民に浸透した URL という呼称を復活させました。 2010年代に入ると、呼称だけでなく技術的にも実態に合っていない URI や IRI の仕様書にかわり、 URL Standard が開発されました。

[204] こうした経緯から、 URL と URN の区別の議論や URI と IRI (やその他のバリエーション) の違いの説明は、 今となっては意味をなさないものです。 (事情が複雑で「公式」見解がころころ変わるので、1990年代から2000年代にかけて書かれた解説記事などは当時としても不正確なことが多いです。)

[201] 詳しくは、歴史の章を参照。

URL に関する演算

[71] URL には色々な概念や演算が関係しています。

相対 URL と URL の解決

[142] URI (絶対URI参照) は URI scheme の名前から始まり、一つの資源を識別するべく説明を加えていきます。 例えば http://www.example.com/foo/bar/baz は特定の baz という資源を識別するために、 http: URI scheme を使うこと、 命名権者が www.example.com であること、 その中の foo の中の bar の中の baz が識別したい資源であることを順次説明しています。

しかし、このような説明は冗長なことがあります。 http://www.example.com/foo/bar/hoge が自分と同じ階層に存在する baz を指すためにわざわざ http: からはじめるのは面倒ですし、 不便なことも色々あります。

そこで、 URI の相対参照 (relative references) という表現が規定されています。 例えば baz が相対参照です。 ただし、 baz だけでは URI (絶対 URI 参照) ではありません。 http://www.example.com/foo/bar/hoge という文脈の情報 (基底URI (base URI) と言います。) があって始めて http://www.example.com/foo/bar/baz という URI (絶対 URI 参照) に解決 (resolve) されます。

参考: もし同じ相対参照 baz でも基底 URI が http://example.net/foo なら、 http://example.net/baz に解決されます。
[143] 詳しくは相対参照の項をご覧下さい。

URL の一部分の直列化

[160] 次の通り、 URL記録の一部を取り出して直列化する操作が必要になることがあります。

URL の一部分の書き換え

[170] 次の通り、 URL記録の一部を書き換える操作が必要になることがあります。

URL の一部分の取り出し

[181] URL記録の一部から情報を取り出す、次のような操作が使われることがあります。

URL の組み立て

[182] URL を組み立てるための次のような操作が使われることがあります。

API

[24] DOM には次の API があります。

[25] URL で指定された資源を取得する API は、 fetch を参照。

応用

[18] URL は様々な場面で使われています。

[186] URLの省略も参照。

[222] URL の性質

RSS における URL の利用

[5] RSS 2.0 は url 要素、 link 要素、url 属性、 docs 要素、comments 要素、 guid 要素で URL を値として使っています。ただし、「URL」の定義は明記されておらず、 どの仕様も引用されていません。

RSS Best Practices Profile は IRI を禁じるにあたって RFC 3987 を引用しているので、それを類推すれば RFC 3986 に従うのかもしれませんが、 RFC 3986 なら URL ではなく URI のはずです。

[6] このうち、なぜか url 要素と link 要素については URL scheme に関する制限があります。

仕様書:

妥当性

[10] url 要素と link 要素の内容は妥当な URL でなければなりません RSS Best Practices Profile。

IRI は使えません RSS Best Practices Profile。

[7] RSS 2.0 仕様書や RSS Best Practices Profile は、「最初の非空白文字には制限があります」といっています。 つまり、明記されていませんが、 URL の前に空白を挿入してもかまわないようです。

[8] url 要素と link 要素の URL の URL scheme は、 IANA 登録簿に登録されているものでなければなりません RSS 2.0, RSS Best Practices Profile。

[9] url 要素と link 要素の URL は相対URL であってはなりません RSS Best Practices Profile。

識別子としての利用

[16] 次の場面では URL がアドレスとしてではなく、 識別子として使われています。

[17] 次の場面では URL がアドレスとしての側面と識別子としての側面の両方を持っています。

[216] 元来プロトコルと結びつかない URL (例えば urn: URL scheme の URN) がこうした場面で使われることもありますが、 そうでない URL (例えば http: URL) もよく使われています。 後者が用いられる場合は、 URL の本来の意味 (例えば http: の場合 HTTP でアクセスできる資源という意味) が失われている場合が多いです。

[215] RDF では http: URL であっても任意のもの、 例えば現実の人なども表せるということになっています。

[20] Semantic Web 界では http: URL を識別子として使っているため、 HTTP から HTTPS への移行が難しいという人もいます >>19。 マイクロデータ界では実際に HTTPS 化時に識別子である URL を https: URL に書き換えようとした例 >>21 もあり、 URL を識別子として用いることの問題が浮き彫りになっています。 元来プロトコルのアドレスだったものを、 不透明な識別子に目的外利用してしまったがために、 認知と理論に齟齬が生じてしまっているのです。

[220] 長くて面倒なので、URLの省略の仕組みが導入されていることがあります。

[221] URL を識別子として使うという行為のバッドノウハウ感が否めないですが、 他によい代案がないこともあります。

[214] これらの場面のほとんどでは、URLの単純文字列比較が用いられています。

[27] Webmention () https://webmention.net/draft/#h-uris-for-form-encoded-properties

If your implementation wants to treat the source and target parameters as URIs, you can prefix the terms with http://www.w3.org/ns/webmention#.

[28] >>27 の source と target は application/x-www-form-urlencoded のキーなんだけど、このURLは何の役に立つんですかね・・・?

URL とプログラミング言語

[118] プログラム言語EではURIが言語の構文に組み込まれている。

URI Expressions http://www.erights.org/elang/io/uri-exprs.html

[119] 他にURIを積極的に言語そのものに取り入れたプログラム言語といえばWMLScriptがある。

URL の前後の区切り文字

URLの表示, URLの印刷, URLの省略, URL自動リンク

URL に含められる文字を区切り文字として使う文脈

[13] HTTPヘッダーである OPES-System: や OPES-Via: では、区切り文字として , や ; を使っています。 OPES-Bypass: では区切り文字として , を使っています。 いずれも構文解析方法は決められていません。

[14] HTML の srcset 属性では , が区切り文字として使われています。構文解析方法も明確に規定されています。

[240] RFC 4508: Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method, , https://www.rfc-editor.org/rfc/rfc4508.html#section-3

[241] >>240 SIP Refer-To では URI に引数が含まれる時 < ... > で括らなければならず、 そうでない場合はヘッダーの方の引数とみなすと定められています。

scheme のない URL

URLの省略

URL を組み込んだ構文

壊れたURL

URLの省略, URLの表示

URL に使えない文字

[238] LBRY

URL 設計

[191] URL は、 URL scheme によって残りの部分の構文と意味が決まります。 残りの部分を誰がどのように決めるかも、 URL scheme に依存します。 ただし、相対URLを使う URL scheme は、ある程度の共通制約があります。

具体的には相対URL、絶対URL、各 URL scheme の項を参照。

[193] x-callback-url のような複数の URL scheme の共通仕様もあります。

[192] URL の素片識別子は、原則として URL scheme や URL のその他の部分と独立しており、 URL を使った取得操作の結果得られるデータの形式に依存して構文と意味が決まります。 (一部の URL scheme では、 URL scheme が素片識別子にも干渉しています。)

素片識別子参照。

[102] URL 一般の設計論については、URLの決め方を参照。

[164] 特定目的で URL に別名を与えようとする試みとして、 URN、 PURL、 短縮URL といったものがありました。いずれも一時的に一定の賛同を得たものの、 それぞれの課題があって成功とはいえない状況です。

URL の表示

[185] URLのレンダリング、アドレスバーを参照。

URL の印刷

URLの印刷

URL の利用者親和性

[162]
Martin mid:6.0.0.20.2.20051107184759.06dd4750@localhost

URI は元々人間が見るものじゃなかったんすよ。

RoyF mid:2f1b97034b715561e35a2b370ec13d19@gbiv.com

んな阿呆な。

Martin mid:6.0.0.20.2.20051108185959.06a21ec0@localhost

いやね、 TimBL の旦那がそう言っとりましたよ。 1990年とかそこらの話だと思いやすけど。

[163] 確かにそんなこと Tim が言ってたのを www-talk かどこかで見た記憶がある。

自由文内の URL の抽出

[29] URLの自動リンク参照。

セキュリティー

[209] URL が表示されることがセキュリティー上重要とされる場合があります。

アドレスバー参照。

[210] ある程度の専門的知識を有する人は、 URL からその内容を推測し安全かどうかの判断基準として使うことがあります。 確実ではありませんが、ないよりは有用程度のヒントにはなります。

[211] 例えばハイパーリンクのリンク先の URL のドメインが既知のWebサイトかどうかで、そのリンクが安全かどうかを推測したりできます。 そのような判断をする人にとっては、Webブラウザーにリンク先の URL の表示機能が備わっていることは重要です。

[237] URL安全

URL 内の秘密情報

[146] URL には、漏洩するべきでない情報が含まれることがあります。 そのようなURLの決め方は好ましくありませんが、 現に存在しますし、避けられないこともあります。

[147] クッキーに対応していない古いWebブラウザーのために、 セッションIDを URL に付けていた時代もありました。 そのような URL の漏洩は深刻なセキュリティー問題でした。

[149] ブログの記事の題名から自動的に URL が決められる場合、 そのブログが非公開で閲覧に認証が必要であっても、 URL が漏れると題名が流出してしまうことになりますから、 取り扱いに注意が必要です。

[150] 特定の利用者にのみ発行される URL があり、 その文書に他の Webサイトへのリンクが含まれる場合で、 URL がリファラーとしてその Webサイトに送信されてしまう場合、 誰がアクセスしてきたかを他の Webサイトの側が特定できてしまうかもしれません。 場合によってはプライバシー保護の観点から問題となるかもしれません。

[112] 認証鍵付きURLや capability URL などと称して、 bearer を URL に付加することがよくあります。 簡易的な認証機能としたり、利用者の確認のために電子メールで URL を送信する際に用いたりします。

[148] 無作為に決められた十分長い秘密の URL によって認証を行ったり、 特定利用者向けの情報を公開したりすることがあります。

[151] URL の userinfo 部分は、元々利用者名と合言葉を記述する欄として用意されました。 現在では好ましくないと考えられています。しかし利便性が高いため、 しばしば用いられます。

[113] プロキシを指定する環境変数では、プロキシの URL を指定しますが、 userinfo にプロキシ認証のための情報を含めることがあります。

[114] Webアプリケーションから Webアプリケーションへの Web Hooks の設定画面では、 URL を指定する欄が1つだけ用意されていて、 そこに記述する https: URL の userinfo に基本認証の利用者名と合言葉も含められることがあります。

構成する文字に関わる問題

[217] 文字のセキュリティーも参照。

知的財産権

著作権

[103] あまり意識されることはありませんが、 URI である文字列に対して著作権が主張される可能性があります。 単に資源の位置を表すに過ぎない URL 的な URI の類が著作物足る要件を満たすとは考えにくいですが、 ほとんどあらゆる種類のものが URI として表現し得ます。 特に、

... のようなものは、著作物が URI の一部として入り込む可能性が高いといえます。 任意のデータが data: URI にした途端著作権が消滅するのはおかしいですから、 著作物たる data: URI が存在することは間違いありません。 また、 Bookmarklet などは創作性が高いと考えられますから、 簡単なものを除いて著作物だとの主張が認められる可能性が高いと思われます。

[104] もちろん、百分率符号化などの仔細な表現上の違いは著作権が存在するかどうかの議論とは無関係です。

[105] URI が著作物足り得るかどうかの議論は、 ハイパーテキストにおけるリンクの自由性にも関わってきます。

[106] URI に著作権は及ばないという主張の例:

[107] URI に著作権が及ぶという主張の例:

[110] 葉っぱ日記 - ぼくはまちちゃん!(Hatena) - urlのポエム化 (2007-01-17 09:25:44 +09:00 版) http://d.hatena.ne.jp/hasegawayosuke/20070117/p1 (名無しさん 2007-01-17 00:28:09 +00:00)

商標権

[111] URI として使用する文字列の一部が商標としてみなされることがあります。 特に URI に一部としてよく使われるドメイン名は頻繁に商標に関する係争が発生しています。 ドメイン名に限らず、商標を根拠に商標権者が URI の使用者に使用しないように主張する可能性があります。

テストデータ

[120] UriTesting - ESW Wiki http://esw.w3.org/topic/UriTesting

[2004] UriTesting - W3C Wiki ( ( 版)) http://www.w3.org/wiki/UriTesting

[121] Index of /uri (2007-01-05 15:38:16 +09:00 版) http://skew.org/uri/ (名無しさん 2007-01-05 06:39:54 +00:00)

歴史

[64] URL ははじめ TimBL によって World Wide Web を構成する技術の一つとして提案されました。 この当時の仕様書は W3O の Webサイトや www-talk メーリングリストなどで配布されていました。

[228] Document identifiers, , https://lists.w3.org/Archives/Public/www-talk/1991NovDec/0012.html

[227] Draft: Universal Document Identifiers, , https://lists.w3.org/Archives/Public/www-talk/1992JanFeb/0024.html

[226] URLs - new document; URL mail server, , https://lists.w3.org/Archives/Public/www-talk/1992SepOct/0055.html

[229] MIME, SGML, UDIs, HTML and W3, , https://lists.w3.org/Archives/Public/www-talk/1992MayJun/0038.html

[230] IETF BOF on Universal Document Identifiers, , https://lists.w3.org/Archives/Public/www-talk/1992MayJun/0065.html

[65] その後は IETF によって標準化が行われました。

[66] URL 本体仕様として、次のものが発行されています。

[212] しかしこれら「正式」な仕様書ではカバーしきれていない現実の問題が多く存在しており、 W3C は IRI の様々なバリエーションを規定しましたし、 Webブラウザーはそのいずれとも違うものを実装していました。

[67] この期間の歴史は本項の他に URN、IRI の項も参照してください。

[68] 00年代に WHATWG で改めて URL を定義する動きがあり、紆余曲折を経て2012年、 Anne van Kesteren により URL Standard が作られました。

[69] この期間の歴史は、 URL Standard の歴史の項も参照してください。

呼称

[15] URL の一部または全部を指して、歴史的に様々な呼称が用いられてきました。

[88] IETF は RFC を改版する度に用語やその定義を少しずつ変えていました。 更に、実際に普及した用語や DOM 等の API で使われている用語とも一致していませんでした。 そのため、色々な仕様書や実装で似たような異なるような概念が交錯し、 大混乱していました。

[89] 加えて W3C は、 XML 関連仕様を新たに出版する度に、 新しい「URI のようなもの」を定義していました。その定義も少しずつ異なるものでした。

詳細は IRI も参照。

[42] URI 関係の古い定義:

[82] fragment identifiers from Roy T. Fielding on 2002-07-23 (www-tag@w3.org from July 2002) http://lists.w3.org/Archives/Public/www-tag/2002Jul/0253.html

[83] URI の標準化はかなりいい加減で混乱気味の上に W3C/Martin Durest は IRI を進めていて、それも SP を認めるとか # もどうとか無茶苦茶なこと言ってたし、混乱は当分収まりそうにない。

[84] RFC 2396 は、絶対 URI だけを URI としており、相対 URI や素片識別子がついた URI も含めた名称を URI 参照としています。 (旧版の RFC 1808 も含めて) 旧来の仕様や慣習では絶対 URI と相対 URI の両方を URI と言っていましたし、素片識別子も仕様書には URI の一部ではないと書いてあるけど実際には曖昧に使われていた (古い URI 仕様書まで遡るとこちらも曖昧だった) という歴史的経緯がありまして、単に URI とだけ言われると厳密には何を指しているのだかわかったものではありません。たまに論争の火種になります(w

[85] XML 関連仕様書は URI という名前で IRI を指していたり、「URI と解釈されるもの」というわけのわからんのがでてきたりしますから混迷極まり (XML//URI 参照)。

[86] あと目立たないけど注意しておきたいのは、空文字列。 RFC 2396 的には URI 参照の一種ですが URI じゃないですし、相対 URI でもないかもしれません。 RFC 1808 から意味が変更されたものですから解釈は実装依存になってしまう。その上使えるかどうかは採用する規格に依存。 (URI 参照を使うと書かれている規格でも、よく見ると字数制限1文字以上で使えなかったりする。)

[87] 2396bis ではまた変わるみたいです。。。

拡張

[205] 歴史的にいくつも URL の拡張が提案されていますが、広く採用されたものはありません。

[206] URL の拡張の提案

URI

[36] URI (Uniform Resource Identifiers, 統一資源識別子) は、資源を識別するための統一的な仕組みとして提案されていました。 簡単に言えば、色々なものに名前を付けるための仕組みでした。 あるいは、その仕組みによる識別子をも URI と呼んでいました。 また、文脈で意味が曖昧でない場合には、識別子によって参照される資源のことすらも URI と呼ぶことがありました。

[37] 従来の情報システム・計算機システムは、 それぞれで資源を識別する仕組みや番地付けの仕組みを持っていました。 しかし、それらはあくまでそれぞれのシステムの範囲内でのみ有効な識別子システムでした。

ところが、1990年頃 TimBL が発明した WWW では、番地付けのために URI を採用しました。 URI は URI scheme によって命名システムを識別し、 URI scheme ごとにその中で更に具体的な資源を識別するという構造を持っています。 そのため、従来の情報システムの識別子を URI scheme として再定義することによってあらゆる資源を統一的に扱うことに成功したのです。

参考: そのような設計が採用された背景には、 当時様々な情報システムが提案されて割拠していたことがあります。 WWW は HTTP だけではなく、それら他のシステムも URI によって取り込むことで魅力的な情報システムになったのです。

[38] URI で識別される資源は、何も計算機で表現できるものに限りません。 urn:isbn: URI を使えば ISBN によって書籍を識別することができます。 物理的に存在するもの以外でも、 言葉や抽象概念などありとあらゆる資源を識別することが可能です。

[39] URI が元々 HTTP と HTML で番地付けのために使われてきたことから、 単にネットワーク資源の位置を表す住所のようなものと考えられることがよくあります。 しかし、 >>38 のように URI はネットワークで取出すことができないものであっても識別できます。 Webブラウザで画面に表示することはできないかもしれませんが、 それだけが URI の役割ではないのです。

[223] Univeral Resource Identifiers -- Axioms of Web architecture, , https://www.w3.org/DesignIssues/Axioms.html

URI の定義

[2000] 「URI」という言葉の定義は、URI を定義する仕様自体でも歴史的に変化していますし、 URI を参照する様々な仕様でも様々な意味に用いられています。 仕様内でもそうなのですから、それ以外の世界ではその意味は全く安定していないといっても過言ではありません。

[2001] 最も大きな定義上の混乱の1つは、 URI と URI参照の違いです。 最新の URI の定義である RFC 3986 によると、相対参照は URI参照ですが、 URI ではありません。その前の RFC 2396 の定義によると、素片識別子を含んだものは URI参照ですが、URI ではありませんでした。 仕様書以外の場面 (や多くの関連仕様!) では、「URI」というと URI参照を指すことが多くあります。 これらについては URI参照や素片識別子の項をごらんください。

[2002] もう1つの最大の混乱は、利用可能な文字の種類に関するものです。 URI で本来認められない ASCII文字や、IRI では認められる非ASCII文字の扱いをめぐって、 多くの仕様がいろいろなものを「URI」と呼んでいます。 詳しくは IRI の項をご覧ください。

[2003] 前述の2つに比べれば細かい話ですが、 URI の構文や相対参照の解決の方法は新しい仕様書が発行される度に変化しています。 特に最新の RFC 3986 とその1つ前の RFC 2732 あるいは RFC 2396 との関係は、 どちらがどちらの部分集合でも超集合でもありません。 URI を用いる色々な仕様がそれぞれ異なる版の URI を参照しており、 通常そのような仕様が多数組み合わせて用いられるので、 厳密に解釈すると URI の扱いは非常にややこしいことになります。

IETF における URI の標準化

[81] URI.NET http://uri.net/

ちょっと古いしちゃんと管理されていないみたい。 (名無しさん 2005-03-11 03:40:22 +00:00)

既存の識別子との関係

[125] URI は URI を意識せずに作られた識別子体系でもそのまま取り込んでしまうことができます (もちろん相性のようなものはありますが)。 既に色々な識別子を URI として使う方法が定義されています。

[126] 色々な識別子の体系を URI 1つにまとめると、 何かしたいときに各識別子体系それぞれに対してその方法を考える必要がなくなります。 例えば引用文献を記述する時に、引用する文献が Web頁 (URI) でも紙の書籍 (ISBN) でも両方 URI として扱えると便利になることがあります。 あるいは連絡先がインターネットの電子メイル (電子メイル・アドレス) でも従来の電話 (電話番号) でも統一して扱えたりもします。

[131] 既存の識別子と URI の対応

既存の識別子体系URI備考
出版物
ISBNurn:isbn:
ISSNurn:issn:
公開識別子urn:publicid:
RFCurn:ietf:rfc:
ネットワーク番地
電話番号tel:
FTPftp:
インターネットの電子メイルmailto:
ニュース組news:
チャットのチャンネルirc:
言語・文化
言語札urn:x-suika-fam-cx:lang:
その他
UUIDurn:uuid:

RFC 1630 (第1世代)

[46]

  • RFC1630 『Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web (WWW における普遍資源識別子 : World Wide Web で使われているネットワーク上の物体の 名前と番地の表現の統一構文)』,
    • T. Berners-Lee, 1994 年6月, Informational RFC。
    • この文書は、 WWW でインターネット上の物体の名前と番地を符号化するのに使われている構文を定義します。 Web は、既存のプロトコル, web 自体のために新しく開発されたプロトコル, 将来発明されるプロトコルを含めた拡張可能な数のプロトコルを使って接続可能な物体を含むと考えられます。 特定のプロトコルによる個々の物体への接続指示は、 番地文字列の形式に符号化されます。 他のプロトコルは種々の形式の物体名の使用を認めています。 一般物体の抽象的考えのために、 web は物体の普遍的集合の概念及び物体の名前及び番地の普遍的概念を必要としているのです。

[33]

  • 『A Framework for Identifying, Locating, and Describing Networked Information Resources (ネットワーク情報資源の識別, 位置付け, 記述の枠組み)』
    • http://www.apache.org/~fielding/uri/rfc/lynch93.txt
    • Clifford Lynch, 1993年3月。
    • インターネット上のネットワーク情報資源の増加につれ、 この資源の体系的で標準的な識別・位置付け・記述手段が益々必要となっています。 そのような方式の開発の動機は様々ですが、 開発を進めるに当たって少なくても3つの大きな応用があります。 1つには、図書館界では伝統的な型録記述をネットワーク資源に拡張する必要があります。 本質的には、 (in the sense that libraries are shifting from collections to access, and increasingly view their catalogs and other databases as bibliographies of materials to which they are prepared to provide, and perhaps subsidize, access) 書誌記述及び統一的に図書館蔵書と協調させるためのネットワーク情報資源の管理を可能とし、 これらへの接続を向上させる必要があります。 As networked information resources become critical to scholarship and research, and come to represent significant investments by institutions, it also becomes essential to apply the practices of information management to this new class of resources.

RFC 1738 (第2世代)

[34]

  • RFC1736
    • 『Functional Recommendations for Internet Resource Locators (インターネット資源位置子の機能的要件)』
    • J. Kunze, 1995年2月。 Informational RFC。
    • この文書は、位置と資源の接続情報を伝達するインターネット資源位置子の要件の最小集合を規定します。 資源の典型的な例には、ネットワークで接続可能な文書, WAIS データベース, FTP サーバー, Telnet 終点を含みます。

[35]

  • RFC1737
    • 『Functional Requirements for Uniform Resource Names (統一資源名の機能的要件)』
    • K. Sollins, L. Masinter, 1994年12月。 Informational RFC。
    • この文書は、統一資源名 (URN) として知られるある種のインターネット資源識別子の要件の最小集合を規定します。 URN は、統一資源特性 (URC), 統一資源位置子 (URL) を加えて構成される上位のインターネット情報体系内に fit します。 URN は識別に使用され、 URC はめた情報を含めるのに使用され、 URL は資源の位置付けや探索に用いられます。 この文書は URN の規格を評価する基礎として提供します。 議論はメイリング・リスト MAIL:uri@bunyip.com 及び IETF の URI 作業部会の部で行われます。

[40]

  • RFC1738
    • 『Uniform Resource Locators (URL) (統一資源位置子 URL)』
    • T. Berners-Lee, L. Masinter, M. McCahill, 1994年12月。 提案標準。
    • RFC 1808, RFC 2368, RFC 2396 が更新。
    • この文書は、位置及びインターネットを介した資源への接続の形式化された情報の構文及び意味である統一資源位置子 (URL) を規定します。

[92] RFC 1630 (URI) と RFC 1738 は、内容的に大体同じですが、文章としては全然違います。

RFC 1808 (第2世代の相対URL)

[41]

  • RFC1808
    • 『Relative Uniform Resource Locators (相対統一資源位置子)』
    • R. Fielding, 1995年6月。提案標準。
    • RFC 1738 を更新。
    • RFC 2368, RFC 2396 が更新。
    • 統一資源位置子 (URL) は、インターネットを介して入手可能な資源の位置及び接続方法の短小な表現です。 URL を基底分書中に埋め込む時には、 絶対形式だと基底文書の取り出しの文脈で、 方式, ネットワーク位置, url-path の一部のように非常に多くの既知の情報を含んでいます。 基底 URL が良く定義されていて解析器 (人間又は機械) がそれを知っている時には、その文脈を実現値毎に際して慰するのではなく、継承した URL 参照を埋め込むことが出来ると便利です。 この文書ではこのような相対統一資源位置子の構文と意味を定義します。

RFC 2396 (第3世代)

[43]

  • RFC2396
    • 『Uniform Resource Identifiers (URI): Generic Syntax (統一資源識別子 (URI): 一般的構文)』
    • T. Berners-Lee, R. Fielding, L. Masinter, 1998年8月。原案標準。
    • RFC 1808, RFC 1738 を更新。
    • 統一資源識別子 (URI) は、抽象資源又は物理資源を識別する短小な文字の列です。 この文書は、絶対形及び相対形の双方を含む、 URI の一般的構文とこれらの使用の指針を定義します。 この文書は RFC 1738 及び RFC 1808 の一般的定義を改訂・置換します。
    • この文書は全ての妥当な URI の超集合である文法を定義します。従って、実装は方式規定の可能な識別型毎の要件を知ること無しに URI 参照の共通の部品を解析することが出来ます。 この文書は URI の生成文法は定義しません。 その作業は各 URI 方式の個々の仕様書が行うことでしょう。

[91] RFC 1738 (URL) と RFC 2396 (URI) は、ほとんど別の文章です。扱う対象はほぼ同じであるにもかかわらず、 2396 は概念的にもかなり整理されていて、 diff が役に立つ立たない以前の問題です。それ程違います。

[90] RFC 1808 (相対 URI) と RFC 2396 は、多くの部分が共通しています。節単位で diff を取ったら違いは URL→URI ばっかり、みたいな。それでも、 2396 の包括的な定義に比較すると 1738 的古臭さ(謎)を感じる部分があって、その辺は 2396 にそのまま入ってはいません。

[93] >>92、>>91、>>90 というわけで、 URI の仕様書は毎回全然違う内容で出てくるのであって、同じ WWW でも HTTP の仕様書 (RFC1945, RFC2068, RFC2616) が追記的に成長していっているのに比べると、中々興味深いところであります。

[94] >>93 比較的早くまとまった (それでも随分かかってるけど。) HTTP の仕様に比べて、 URI は色々ありましたからねぇ。概念的に成熟するまでが長かったし、未だに不安定な部分も多々あるし・・・。

[95] >>94 HTTP みたいな転送プロトコルは前例が一杯あるからかも。 URI のような規模の番地付けってインターネットでは初めての試みだったと思うし。

[96] WWW のもう一つの要素, HTML は、リッチテキスト的構成要素は爆発的に進歩したよね。仕様の安定性って話とはちょっと違うけど、今までの文書処理の経験がやっぱり効いてると思う。一方で単純参照リンク以上のリンクとか、メタ情報とか、そっちの方向は全然進まなくて、今になってようやく SemanticWeb とか大々的に表に出てきた。っていう二面性があって又興味深い。リンクもメタ情報も、やっぱり十分な経験がなかったから。

[97] >>95-96 そういう意味では、 HTTP でも、リンクやメタ情報って蔑ろにされがち。リンクなんてほとんどなかったことにされてるし。。。

[44]

  • RFC2717 = BCP35
    • 『Registration Procedures for URL Scheme Names (URL 方式名の登録手続き)』
    • R. Petke, I. King, 1999年11月。現状の最善の運用。
    • この文書は、新しい URL 方式を登録する過程を定義します。

[45]

  • RFC2718
    • 『Guidelines for new URL Schemes (新しい URL 方式の指針)』
    • L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, 1999年11月。情報提供 RFC。
    • 統一資源位置子 (URL) はインターネットを介して入手可能な資源の位置の短小な文字列表現です。 この文書は新しい URL 方式の定義の指針を提供します。

[47]

RFC 2373 (IPv6 拡張)

[48]

  • RFC2732
    • 『Preferred Format for Literal IPv6 Addresses in URL's (URL 中の生 IPv6 番地の好ましい書式)』
    • R. Hinden, B. Carpenter, L. Masinter, 1999年12月。
    • この文書は、 World Wide Web ブラウザの実装での URL 中に生 IPv6 番地の書式を定義します。 この書式は Microsoft Internet Explorer, Mozilla, Lynz を含む幾つかの広く用いられているブラウザの IPv6 版で実装されています。 この書式はサービス位置プロトコルの IPv6 版でも使用される見込みです。
    • この文書は RFC 2396 で定義された統一資源識別子の一般的構文の更新を含みます。 この文書は IPv6 番地の構文を定義し、 この予約目的のために陽に URI 中に [ 及び ] の使用を認めます。

RFC 1738 の廃止

[98] RFC 4248 (telnet: URI scheme) が発行されて、遂に RFC 1738 が廃止されました。

ftp:, news:, nntp:, gopher: は改訂版が出てないけどいいのかね? gopher: は RFC編集者の待ち行列にいるからいいとして・・・。 (名無しさん 2005-11-10 10:47:05 +00:00)

[99] あ、 file: も結局放置されたままじゃん?

[100] しかし RFC 4248 は全くやる気がないな。 telnet: を標準化過程に残すためにとか書いてあったけど、 もう要らないんじゃないのか? それよりも ftp:, news:, file: が一時的にせよ標準化過程から離れることの方がむしろ問題かと。 (名無しさん 2005-11-10 10:52:16 +00:00)

RFC 4395

[101] RFC 2717, RFC 2718は廃止されてBCP 115 RFC 4395になりました。 (名無しさん 2006-02-14 14:11:09 +00:00)

90年代-00年代の応用仕様における URL

[75]

  • RFC1727
    • 『A Vision of an Integrated Internet Information Service (統合インターネット情報サービスの展望)』
    • C. Weider, P. Deutsch, 1994年12月。
    • この論文は、今後数年間でインターネット情報サービスがいかに統合されるかの展望を示し、 統合を実現するためにどのような手順が必要かの詳細を幾らか議論します。
  • RFC1728
    • 『Resource Transponders (資源配送路)』
    • C. Weider, 1994年12月16日。
    • ここ数年で資源の位置とインターネット上の誘導を提供する数多のシステムが作られてきましたが、 これらのシステムに含まれる情報は手動で管理・更新しなければなりません。 この論文では、資源位置情報を維持するために、 自動化機構と資源配送路を記述します。
  • RFC2016
    • 『Uniform Resource Agents (URAs) (統一資源エージェント URA)』
    • L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan, 1996年10月。実験的 RFC。

[49] RFC 1866 (HTML 2.0) における定義
URI
A Uniform Resource Identifier is a formatted string that serves as an identifier for a resource, typically on the Internet. URIs are used in HTML to identify the anchors of hyperlinks. URIs in common practice include Uniform Resource Locators (URLs)[URL] and Relative URLs [RELURL].

[50] >>49 について、この定義ではURNはURIに含まれていないのではないかと指摘する人がいますが、単にURLがURIに含まれていることを述べているに過ぎず、URN (やURCやその他の何か) については何も言及していないと解釈するのが適当だと思います。

[2] JIS X 4081:2002
s) URL (Uniform Resource Locator)
インターネット上のアドレス。

[3] >>2 なにこの定義、ふざけてるの?

[76]

  • 2168 Resolution of Uniform Resource Identifiers using the Domain Name System. R. Daniel, M. Mealling. June 1997. (Format: TXT=46528 bytes) (Updated by RFC2915) (Status: EXPERIMENTAL)
  • 2169 A Trivial Convention for using HTTP in URN Resolution. R. Daniel. June 1997. (Format: TXT=17763 bytes) (Status: EXPERIMENTAL)
  • 2276 Architectural Principles of Uniform Resource Name Resolution. K. Sollins. January 1998. (Format: TXT=64811 bytes) (Status: INFORMATIONAL)
  • RFC2483
    • 『URI Resolution Services Necessary for URN Resolution (URN 解決に必要な URI 解決サービス)』
    • M. Mealling, R. Daniel, 1999年1月。実験的 RFC。
    • 統一資源識別子 (URI) によって識別される資源の取り出しは、 URI について施せる処理の1つに過ぎません。 元の URI から、例えばその別名である他の識別子の一覧やその URI が示す資源の書誌的記述を尋ねたり入手したりもするかもしれません。 これは統一資源名 (URN) に対しても統一資源位置子 (URL) に対しても適用されます。 統一資源特性 (URC) はこの文書中で議論しますが、 識別子というよりは資源の記述に過ぎません。
  • 2972 Context and Goals for Common Name Resolution. N. Popp, M. Mealling, L. Masinter, K. Sollins. October 2000. (Format: TXT=26252 bytes) (Status: INFORMATIONAL)

[77]

  • RFC2017
    • 『Definition of the URL MIME External-Body Access-Type (URL MIME 外部本体接続型の定義)』
    • N. Freed, K. Moore, A. Cargille, 1996年10月。提案標準。
  • 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields. G. Neufeld, J. Baer. July 1998. (Format: TXT=30853 bytes) (Status: PROPOSED STANDARD)
  • 3087 Control of Service Context using SIP Request-URI. B. Campbell, R. Sparks. April 2001. (Format: TXT=83612 bytes) (Status: INFORMATIONAL)

URI もどき

[133] URI が使われる文脈で使われる、 URI でない (又はなさそうな, あってほしくない) ものたち, および URL っぽいが URL だとは明言されていないものたち

[136] ResourceUtils (Spring Framework) http://www.springframework.org/docs/api/org/springframework/util/ResourceUtils.html

Javaのパッケージを表すclasspath: pseudo URLがある。

JavaのクラスのためのURI schemeはjava:など他にも複数ある。
2008年12月現在、 404。

[198] Oracle の DBURIType は URI を名乗っていますが、 実際には XPath です。

HTML5 と URL Standard

[145] HTML5 で Web における URL が規定されました。紆余曲折を経て、 単独の仕様書 URL Standard となりました。

[144] URL Standard 参照。

[239] Karasuma::URL

メモ

[50] Document Structure – SVG 1.1 (Second Edition) ( ( 版)) http://www.w3.org/TR/2011/REC-SVG11-20110816/struct.html#__svg__SVGDocument__URL

[51] How many ways can you slice a URL and name the pieces? - Tantek ( ( 版)) http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces

[52] The use of Metadata in URIs ( ( 版)) http://www.w3.org/2001/tag/doc/metaDataInURI-31.html

[53] URL formats · Microformats Wiki ( 版) http://microformats.org/wiki/url-formats

[54] cweb/iri-tests ( ( 版)) https://github.com/cweb/iri-tests

[55] JSON-LD API 1.0 ( ( 版)) http://json-ld.org/spec/FCGS/json-ld-api/20120626/#idl-def-URL

[56] WWW-Talk Apr-Jun 1993: URL plain text version's URL ( ( 版)) http://1997.webhistory.org/www.lists/www-talk.1993q2/0140.html

[57] IRC logs: freenode / #whatwg / 20131220 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20131220

[58] Bug 23968 – Reference the URL spec ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=23968

[59] draft-ietf-appsawg-uri-get-off-my-lawn-01 - Standardising Structure in URIs ( ( 版)) https://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-01

[73] Clarify URL use in APIs · eece8eb · whatwg/url ( ( 版)) https://github.com/whatwg/url/commit/eece8ebf1391c538cdbaab6e4b957ea769d06b56

[74] July 2014 snapshot of the URL Standard for the purposes of patent lawyers and government officials ( ( 版)) http://www.whatwg.org/specs/url/2014-07-30/

[4] How URL started as UDI — a brief conversation with @timberners_lee @W3C #TPAC - Tantek ( 版) http://tantek.com/2014/304/b1/url-started-as-udi-conversation-w3c-tpac

[22] [whatwg] Relative URL plan (Anne van Kesteren 著, 版) https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jun/0028.html

[23] Remove incorrect note (URLs with scheme data also have query/fragment… · whatwg/url@d5470b8 ( 版) https://github.com/whatwg/url/commit/d5470b8d02a14b7c1ca0467ddae61e0fc671cee4

[28] 1151899 – Integrate the rust-url parser into necko ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=1151899

[122] mohta 氏が script と language の違いを説いてるのがなんか可笑しい。 (1997年の ietf-url にて。)

[2005] draft-nottingham-uri-get-off-my-lawn-00 - Standardising Structure in URIs ( ( 版)) http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-00

[2007] URI Specification Community Group ( ( 版)) http://www.w3.org/community/urispec/

[2008] public-urispec@w3.org Mail Archives ( ( 版)) http://lists.w3.org/Archives/Public/public-urispec/

[2009] Home · urispec/urispec Wiki ( ( 版)) https://github.com/urispec/urispec/wiki

[2010] RFC 7320 - URI Design and Ownership ( ( 版)) https://tools.ietf.org/html/rfc7320

[2011] draft-ietf-urnbis-semantics-clarif-00 - URN Semantics Clarification ( ( 版)) http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-00

[123] WWW-Talk Oct-Dec 1993: First URI meeting notes ( 版) http://1997.webhistory.org/www.lists/www-talk.1993q4/0376.html

[124] WWW-Talk Oct-Dec 1993: What URIs are and are not. ( 版) http://1997.webhistory.org/www.lists/www-talk.1993q4/0377.html

[152] 未踏召喚://ブラッドサイン (電撃文庫) | 鎌池 和馬, 依河 和希 | ライトノベル | Amazon.co.jp ( 版) http://www.amazon.co.jp/exec/obidos/ASIN/4048668617/wakaba1-22/

[179] 26402 – "Parsed URL" isn't defined in URL ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=26402

[30] Introduce the terms URL record and URL string for disambiguation. Fix… · whatwg/url@656b803 ( 版) https://github.com/whatwg/url/commit/656b803201027c022e3603c5b2b4d4fa498bc911

[72] URLs are parsed and produce records · whatwg/html@30bc255 ( 版) https://github.com/whatwg/html/commit/30bc2557105ad62881ec9670f253febbc9761b44

[178] GTFS リファレンス  |  乗換案内  |  Google Developers (最終更新日: 11月 25, 2015 ()) https://developers.google.com/transit/gtfs/reference

完全な URL 値を作成する方法については、http://www.w3.org/Addressing/URL/4_URI_Recommentations.html を参照してください。

[115] 国会図書館検索でスマホ現在地漏えいの恐れ : 科学 : 読売新聞(YOMIURI ONLINE) () http://www.yomiuri.co.jp/science/goshinjyutsu/20161005-OYT8T50089.html

「位置情報がURLに含まれていることは把握している。URLに含まれるのは位置情報のみであり、個人を特定するものではないので、URLだけが第三者に知られたとしても個人が特定できるわけではない。現時点では改修の予定はない。ただしURLに位置情報を含めない方策についても今後検討していきたい」(国会図書館総務課広報)とのことだった。

[116] Editorial: give URL syntax components their own terms (annevk著, ) https://github.com/whatwg/url/commit/451696e4297c4c676fae21dbc926aeafb2477e6c

[194] cpython: 110ec861e5ea Lib/urlparse.py () https://hg.python.org/cpython/file/2.7/Lib/urlparse.py

[195] Clarify valid URL (tstarling著, ) https://github.com/whatwg/html/commit/ba265b7f4966e1ed2cf725f0088785c536a28574

[196] Define which URLs are valid in the parser examples (annevk著, ) https://github.com/whatwg/url/commit/97563cb4e6430883ca3538def339282d77989ece

[197] Editorial: use valid URL string from the URL Standard (annevk著, ) https://github.com/whatwg/html/commit/cbbc2f2b43994e954556c032342e2028ceaf4d6e

[207] Yahoo広告配信用 s.yimg.jp ドメインでのXSSの解説 · GitHub ( ()) https://gist.github.com/mala/1d30e42e9e99520b7a501e9d2458eb49

[208] RFC 1736 - Functional Recommendations for Internet Resource Locators () https://tools.ietf.org/html/rfc1736

[213] Concise Binary Object Representation (CBOR) () https://cbor-wg.github.io/CBORbis/#encodedtext

Tag 32 is for URIs, as defined in [RFC3986];

[117] URL's object can no longer be a MediaStream (annevk著, ) https://github.com/whatwg/url/commit/21711b0c85bc489612a5e39473d525d903ead824

[12] Editorial: url ➡️ URL (annevk著, ) https://github.com/whatwg/fetch/commit/5088fce32b79bd0b22047d30869581f8b7e79be8

[187] Editorial: spell URL concepts uppercase · Issue #697 · whatwg/fetch () https://github.com/whatwg/fetch/issues/697

[188] Editorial: url ➡️ URL by annevk · Pull Request #795 · whatwg/fetch () https://github.com/whatwg/fetch/pull/795

[189] 上原 哲太郎/Tetsu. Ueharaさんのツイート: "URLの//はどこから来たのか、というのはいま生き残っている分散OSではWindowsで使われてるUNCの\\が古いのでこれかな(起源はMS-Net)と思ってたんだけど、どうやらApolloがAEGISで//を1981年ごろには使ってたという指摘が。これが最古かな?https://t.co/tytnLkU1vA Tim先生はどちらを見て決めた?" () https://twitter.com/tetsutalow/status/1042530141950234625

[190] Editorial: url ➡️ URL (annevk著, ) https://github.com/whatwg/fetch/commit/5088fce32b79bd0b22047d30869581f8b7e79be8

[218] Editorial: spell URL concepts uppercase · Issue #697 · whatwg/fetch () https://github.com/whatwg/fetch/issues/697

[219] Editorial: url ➡️ URL by annevk · Pull Request #795 · whatwg/fetch () https://github.com/whatwg/fetch/pull/795

Updated: