authority

authority (URL)

[412] authority は、URL のうち、 scheme: の直後の // とその後最初の /, ?, # または末尾の間にある部分です。

[413] 多くの場合 authorityドメイン名ホスト名IPアドレス (host) と、 省略可能な利用者名合言葉 (userinfo) やポート番号 (port) を指定することになっています。

  1. ?
    1. ユーザー名
    2. ?
      1. :
      2. パスワード
    3. @
  2. ホストとポート

authority の内容

そもそも使わない

[416] mailto:, about:, tel: などではそもそも authority 部分が存在しません。

空文字列

[43] 空文字列以外の用法が示されていないもの:

ホストとポート

[415] http: など多くの URL では、 ホスト名を指定します。 直後にポート番号、直前に userinfo を指定することも可能なことが多いです。

[20] userinfo を認めないもの、利用者名は認めても合言葉は認めないものもあります。

[23] 詳しくはホストとポートも参照。

ホスト名以外のネットワーク上のオブジェクトの識別子

[47] ホスト名以外でも、プロトコル独自のネットワーク上のオブジェクト (計算機、ネットワーク、資源など) を指す識別子や番地が authority 部分に指定されることがあります。

resource-less JID

[9] httpx: では resource-less JID を指定します。

作業グループ名

[418] smb: ではホスト名SMB 鯖名SMB 作業グループ名を指定できます。

[46] userinfo には利用者名だけでなく、ドメイン (Windows 用語) も指定できます。

IRC ネットワーク名

[417] irc: ではホスト名の他に IRCネットワーク名も指定できます。

URL のようなもの

[14] pack: URI scheme では、 authority 部にパッケージURI を適当に変換したものを使います。

ファイル名

[408] res: URL では Windowsファイル名authority として使います。

パッケージ名など内部構造の名前

[403] chrome: (Gecko)、 chrome-extension:safari-extension: では拡張機能のパッケージ名を authority 部分に使っています。

[401] hcp:ms-help: では内部的な識別子を指定するために使います。

[414] widget: URL では UUID とされています。

[409] wysisyg:

[450] android-app:android.resource: はパッケージ名 (逆ドメイン名) を使っています。

[451] 逆ドメイン名らしきもの

[10] gs: では bucket 名とされています。

[11] widget: では UUID推奨されています。

LDAP

[419] ldap:Microsoft の実装では dn など LDAP における名前と値の組の並びを指定できるようです。

[420] IETF の定義では path の部分に含めることになっているものです。

利用者識別子

[453] 何らかの利用者を識別するもの (ユーザー名アカウントのIDなど) を使うものもあります。

x-callback-url

[452] x-callback-url 参照。

[12] ホストによる指定と x-callback-url の両方に対応している URL scheme もあります。

無制限

path と変わらない使い方をされるもの

[423] URL の構造的意味を理解せずに設計された URL scheme では、しばしば authority は単に scheme の後に :// を続けたためだけに形式的に存在するのみで、 実質的には path のような使われ方をされています。階層型構造の位置を表していたり、 アプリケーション内の識別子であったり、アプリケーションの動作の指令であったりします。

常に空文字列

その他独自のもの

[15] その他独自の authority を用いる URL scheme

userinfo

[454] userinfo の項を参照してください。

authority 以外のドメイン名

[16] authority 以外でもドメイン名URL に含まれることはよくあります。 Internet Archivehttp: URL のようにが自身の裁量で命名規則の一部として用いる場合もしばしばありますが、それを除けば、 URL schemeプロトコルの定義により次に示す箇所で使われます。

[411] 次の URL scheme は、 path 部分に URL やそれに類する構造を埋め込むことができ、 authority に相当する構造がそれに含まれることがあります。

[410] 次の URL scheme は、メールアドレスに由来する構造を採用しており、 ドメイン名やそれに由来する構文を pathquery の一部に含むことがあります。

[455] 次の URL scheme はその他何らかの形でドメイン名pathquery に含むことがあります。

[17] 次の XPointer scheme を使う場合は素片識別子URL が入れ子に含まれることがあります。

[]

[459] 元々 URL では [] は使えない (パーセント符号化しなければならない) ことになっていましたが、 RFC 2732IPv6アドレスを表すために authority でのみ使えるように変更されました。

[460] RFC 3986 では同じく authorityIPvFuture 構文が導入されました。

[461] 現実には、それ以外の部分でもしばしばこれらの文字が使われています。

[462] 一部の URL scheme では構文の定義上、また http: URL などでは側の判断により、 pathquery などの一部または全部として他の URLauthority に相当する部分が埋め込まれることがあります。 その場合元の URLauthority にこれらの文字が含まれていると、 pathquery にもこれらの文字が (パーセント符号化なしで) 埋め込まれることがあります。

[463] http: URL などでは側の処理言語やライブラリー等により、 あるいはスクリプトなどクライアント側の処理のライブラリー等により、 これらの文字が (パーセント符号化なしで) 特定の意味を持つ使われ方をしていることがあります。 例えば PHP では query 内の名前と値の組の名前の部分で、 配列を表すために使われます。また JSONPquerycallback 引数で、数値または文字列によるオブジェクトのメンバーへのアクセスを表すためにこれらの文字が使われることがあります。

[464] 素片識別子でも、これらの文字を含む ID を表すため、あるいはスクリプトなどクライアント側の処理で用いるため、 これらの文字が パーセント符号化なしで) 使われることがあります。

歴史

[457] RFC 1738 (URL) 3.1. Common Internet Scheme Syntax

While the syntax for the rest of the URL may vary depending on the particular scheme selected, URL schemes that involve the direct use of an IP-based protocol to a specified host on the Internet use a common syntax for the scheme-specific data:

Some or all of the parts "<user>:<password>@", ":<password>", ":<port>", and "/<url-path>" may be excluded. The scheme specific data start with a double slash "//" to indicate that it complies with the common Internet scheme syntax. The different components obey the following rules:

user
An optional user name. Some schemes (e.g., ftp) allow the specification of a user name.
password
An optional password. If present, it follows the user name separated from it by a colon.

The user name (and password), if present, are followed by a commercial at-sign "@". Within the user and password field, any ":", "@", or "/" must be encoded.

Note that an empty user name or password is different than no user name or password; there is no way to specify a password without specifying a user name. E.g., <URL:ftp://@host.com/> has an empty user name and no password, <URL:ftp://host.com/> has no user name, while <URL:ftp://foo:@host.com/> has a user name of "foo" and an empty password.

host The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [5]
a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumerical character and possibly also containing "-" characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses.
port
The port number to connect to. Most schemes designate protocols that have a default port number. Another port number may optionally be supplied, in decimal, separated from the host by a colon. If the port is omitted, the colon is as well.
url-path
The rest of the locator consists of data specific to the scheme, and is known as the "url-path". It supplies the details of how the specified resource can be accessed. Note that the "/" between the host (or port) and the url-path is NOT part of the url-path.

The url-path syntax depends on the scheme being used, as does the manner in which it is interpreted.

[458] RFC 1808 (相対 URL) 2.4.3. Parsing the Network Location/Login

If the parse string begins with a double-slash "//", then the substring of characters after the double-slash and up to, but not including, the next slash "/" character is the network location/login (<net_loc>) of the URL. If no trailing slash "/" is present, the entire remaining parse string is assigned to <net_loc>. The double-slash and <net_loc> are removed from the parse string before continuing.

解析文字列が二重斜線 // から始まる場合、その二重斜線から次の斜線 / 文字の手前までの部分文字列が URL のネットワーク位置・ログイン (net_loc) です。 お尻の斜線 / がない場合には、解析文字列の残りの部分全体が net_loc に割り当てられます。 二重斜線及び net_loc は、続行する前に解析文字列から削除します。

[465] RFC 2396 (URI) 3.2. Authority Component

Many URI schemes include a top hierarchical element for a naming authority, such that the namespace defined by the remainder of the URI is governed by that authority. This authority component is typically defined by an Internet-based server or a scheme-specific registry of naming authorities.

多くの URI scheme は、最上位階層要素として命名権者を含めており、 URI の残りの部分で定義される名前空間はその命名権者の領めるところとなります。 この命名権者部品は、典型的にはインターネットを基にしたサーバー又は scheme 定義の命名権者登録簿により定義されます。

The authority component is preceded by a double slash "//" and is terminated by the next slash "/", question-mark "?", or by the end of the URI. Within the authority component, the characters ";", ":", "@", "?", and "/" are reserved.

命名権者部品は前に二重斜線 // がつき、 次の斜線 /, 疑問符 ? 又は URI の末端により終端されます。 命名権者部品中では、文字 ;, :, @, ?, /予約されています。

An authority component is not required for a URI scheme to make use of relative references. A base URI without an authority component implies that any relative reference will also be without an authority component.

命名権者部品は、 URI scheme が相対参照を使うために必須ではありません。 命名権者部品なしの基底URI は、 全ての相対参照が命名権者部品のやはり欠けたものであることを暗に示します。

3.2.1. Registry-based Naming Authority

The structure of a registry-based naming authority is specific to the URI scheme, but constrained to the allowed characters for an authority component.

登録簿を基にした命名権者は URI scheme に特有のものですが、 命名権者部品で許される文字に制約されます。

  • reg_name = 1*( unreserved | escaped | "$" | "," | ";" | ":" | "@" | "&" | "=" | "+" )

3.2.2. Server-based Naming Authority

URL schemes that involve the direct use of an IP-based protocol to a specified server on the Internet use a common syntax for the server component of the URI's scheme-specific data:

インターネットの特定のサーバーに対する IP を基にしたプロトコルの直接使用を含んだ URL scheme は、 URI の scheme 特定データのサーバー部品に共通の構文を使います。

where <userinfo> may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the server. The parts "<userinfo>@" and ":<port>" may be omitted.

ここで、 userinfo は利用者の名前を入れることができて、任意選択によって、サーバーに接続するための認証の方法についての scheme 特有の情報をも入れることができます。 <userinfo>@ の部分と :<port> の部分アh省略可能です。

The user information, if present, is followed by a commercial at-sign "@".

利用者情報を示す場合は、その後に単価記号 @ が続きます。

Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used.

URL scheme によっては、 userinfo 欄に user:password の書式を使います。 この慣習は、認証情報を平文 (URI とか。) で渡すことはその使用されるほとんど全ての場合に置いて安全上の危険を負うこととなるので、推奨しません

The host is a domain name of a network host, or its IPv4 address as a set of four decimal digit groups separated by ".". Literal IPv6 addresses are not supported.

host は、ネットワーク・ホストのドメイン名か、その IPv4アドレス. で分離した4つの10進数集団の集合としたものです。 生 IPv6アドレスには対応していません。

Hostnames take the form described in Section 3 of [RFC1034] and Section 2.1 of [RFC1123]: a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumeric character and possibly also containing "-" characters. The rightmost domain label of a fully qualified domain name will never start with a digit, thus syntactically distinguishing domain names from IPv4 addresses, and may be followed by a single "." if it is necessary to distinguish between the complete domain name and any local domain. To actually be "Uniform" as a resource locator, a URL hostname should be a fully qualified domain name. In practice, however, the host component may be a local domain literal.

ホスト名は、 RFC 1034 の3章と RFC 1123 の2.1章で説明されている形を取りました。 . で分離されたドメイン札の連続体で、それぞれのドメイン札は英数字で始まり英数字で終わり、 - を含めることもできます。完全修飾ドメイン名の再右ドメイン札は数字で始まることはないので、 IPv4 アドレスとドメイン名を構文的に区別できますし、完全などメイン名と局所ドメインを区別する必要がある時には単一の . を続けることができます。 真に「統一」された資源位置子であるためには、 URL ホスト名は完全修飾名であるべきです。しかし、実際にはホスト部品は局所ドメイン札かもしれません。

Note: A suitable representation for including a literal IPv6 address as the host part of a URL is desired, but has not yet been determined or implemented in practice.

注意 : URL のホスト部分として生 IPv6 アドレスを含める適当な表現が望まれますが、まだ決定していませんし実際に実装されてもいません。

The port is the network port number for the server. Most schemes designate protocols that have a default port number. Another port number may optionally be supplied, in decimal, separated from the host by a colon. If the port is omitted, the default port number is assumed.

port は、サーバーのネットワーク・ポート番号です。ほとんどの scheme は既定ポート番号のあるプロトコルを指示しています。 他のポート番号は省略可能ですが10進数で host とコロンで区切って指定して構いません。 port が省略されている時には、 既定ポート番号が仮定されます。

RFC 2732 (IPv6 アドレス in URI)

RFC 2732

メモ

[2] dcp.tcp.pft: URI schemeRFC 2396 的には構文的に適当でしたが、 RFC 3986 で駄目になっちゃいました。

[#XERCESJ-1060] anyURI validation is too strict - ASF JIRA <http://issues.apache.org/jira/browse/XERCESJ-1060>

Reg-name conflict between 2396 and 3986 <mid:4256B135.3070900@metalab.unc.edu>

(名無しさん)

[3] Computer Security Research - McAfee Avert Labs Blog (2007-01-23 20:48:55 +09:00 版) <http://www.avertlabs.com/research/blog/?p=178> (名無しさん 2007-01-23 11:55:04 +00:00)

[4] ITmedia エンタープライズ:8進数や16進数で検出回避する新手のスパム (2007-01-23 20:46:26 +09:00 版) <http://www.itmedia.co.jp/enterprise/articles/0701/23/news016.html> (名無しさん 2007-01-23 11:55:38 +00:00)

[5] IEBlog : URLs in Internet Explorer 7 (2007-02-22 09:21:45 +09:00 版) <http://blogs.msdn.com/ie/archive/2005/08/15/452006.aspx> (名無しさん 2007-02-22 00:24:26 +00:00)

[6] IP Version 6 Support (2007-02-22 09:23:49 +09:00 版) <http://msdn2.microsoft.com/en-us/library/aa385325.aspx> (名無しさん 2007-02-22 00:24:58 +00:00)

[7] IEBlog : IPv6 URIs in IE7 (2007-02-22 09:21:53 +09:00 版) <http://blogs.msdn.com/ie/archive/2007/02/20/ipv6-uris-in-ie7.aspx> (名無しさん 2007-02-22 00:30:32 +00:00)

[8] Internet Explorer では Web サイト アドレス (HTTP URL および HTTPS URL) に含まれるユーザー名およびパスワードがサポートされない ( 版) <http://support.microsoft.com/kb/834489/ja>

[402] IRC logs: freenode / #whatwg / 20100423 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20100423#l-689>

[404] ドット付き 10 進数 URL の不明瞭化 | Symantec Connect Community ( ( 版)) <http://www.symantec.com/connect/blogs/10-url>

[405] IPアドレスによるURL偽装手法まとめ | Rubusig ( ( 版)) <http://m1n0x.hp2.jp/blog/archives/737>

[406] 変なIPに書き換えても繋がるかテスト ( ( 版)) <http://abc.s65.xrea.com/1/>

[421] Bug 10326 – make "user:password" in URLs a SYNTAX_ERR ( ( 版)) <http://www.w3.org/Bugs/Public/show_bug.cgi?id=10326>

[422] draft-carpenter-6man-uri-zoneid-00 - Representing IPv6 Zone Identifiers in Uniform Resource Identifiers ( ( 版)) <http://tools.ietf.org/html/draft-carpenter-6man-uri-zoneid-00>

[426] [whatwg] URL: IPv6 parsing and model/serializing ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037924.html>

[456] Forbid domains containing [ and ] to reduce IPv6 parsing weirdness · 3cd5c10 · whatwg/url ( ( 版)) <https://github.com/whatwg/url/commit/3cd5c107425d7feff015ab4c393636cb14eb488d>

[18] Connection String URI Format — MongoDB Manual 2.6.7 ( 版) <http://docs.mongodb.org/manual/reference/connection-string/>

The following connects to a replica set with three members running on localhost on ports 27017, 27018, and 27019:

mongodb://localhost,localhost:27018,localhost:27019

[19] Module ngx_http_proxy_module ( 版) <http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass>

or as a UNIX-domain socket path specified after the word “unix” and enclosed in colons:

proxy_pass http://unix:/tmp/backend.socket:/uri/;

[26] 700999 – Firefox does not appear to support IPv6 link-local addresses ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=700999>

[27] Bug 27234 – Support IPv6 link-local addresses? ( 版) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234>

[28] Anne van Kesteren on Twitter: "@sleevi_ @mnot pointers? The bug against Gecko was filed by users. I filed it against URL when the networking team asked me about it." ( 版) <https://twitter.com/annevk/status/584039291501862913>

[29] Link-local IPv6 addresses in URIs ( 版) <http://www.ietf.org/mail-archive/web/ipv6/current/msg14975.html>

[30] Issue 70762 - chromium - Can't specify ScopeID when using link-local IPv6 address. - An open-source project to help move the web forward. - Google Project Hosting ( 版) <https://code.google.com/p/chromium/issues/detail?id=70762>

[37] draft-fielding-url-syntax-04 - Uniform Resource Locators (URL): Generic Syntax and Semantics ( 版) <https://tools.ietf.org/html/draft-fielding-url-syntax-04>

1. We need to define a mechanism for using IPv6 addresses in the

URL hostname which will not break existing systems too badly.

Proposal: *hex *["." *hex] ".ipv6"

I.e., treat the top level domain of "ipv6" as special.

[38] <data> | Android Developers ( 版) <http://developer.android.com/guide/topics/manifest/data-element.html>

Note: host name matching in the Android framework is case-sensitive, unlike the formal RFC. As a result, you should always specify host names using lowercase letters.

[39] Bug 27254 – Semantics of 'host' component incompatible with some deployed schemes ( 版) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27254>

[40] RFC 2718 - Guidelines for new URL Schemes ( 版) <https://tools.ietf.org/html/rfc2718#section-2.1.2>

RL

schemes which do not contain a conformant hierarchical structure in

their <scheme-specific-part> should not use double slashes following

the "<scheme>:" string.

[41] RFC 4395 - Guidelines and Registration Procedures for New URI Schemes ( 版) <https://tools.ietf.org/html/rfc4395>

Avoid improper use of "//". The use of double slashes in the first

part of a URI is not an artistic indicator that what follows is a

URI: Double slashes are used ONLY when the syntax of the URI's

<scheme-specific-part> contains a hierarchical structure as described

in RFC 3986. In URIs from such schemes, the use of double slashes

indicates that what follows is the top hierarchical element for a

naming authority. (See Section 3.2 of RFC 3986 for more details.)

URI schemes that do not contain a conformant hierarchical structure

in their <scheme-specific-part> SHOULD NOT use double slashes

following the "<scheme>:" string.

[42] RFC 7595 - Guidelines and Registration Procedures for URI Schemes ( 版) <https://tools.ietf.org/html/rfc7595>

Schemes SHOULD avoid improper use of "//". The use of double slashes

in the first part of a URI is not a stylistic indicator that what

follows is a URI: double slashes are intended for use ONLY when the

syntax of the <scheme-specific-part> contains a hierarchical

structure. In URIs from such schemes, the use of double slashes

indicates that what follows is the top hierarchical element for a

naming authority (Section 3.2 of RFC 3986 has more details). Schemes

that do not contain a conformant hierarchical structure in their

<scheme-specific-part> SHOULD NOT use double slashes following the

"<scheme>:" string.

[44] kennethreitz/dj-database-url ( 版) <https://github.com/kennethreitz/dj-database-url>

With PostgreSQL, you can also use unix domain socket paths with percent encoding: postgres://%2Fvar%2Flib%2Fpostgresql/dbname.

[45] XRI Resolution 2.0 ( 版) <http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html>

xri://@!a!b*(mailto:jd@example.com)*e/f

[35] Define "server-based naming authority" in terms of URL · whatwg/html@da7b5ba ( 版) <https://github.com/whatwg/html/commit/da7b5baf5815754cc40387452ae41e989848032f>

[52] Editorial: define "network scheme" · whatwg/url@e322a8a ( 版) <https://github.com/whatwg/url/commit/e322a8a79246b3f7c026bc9e705f22f069d1bde6>

[54] モデル使用に関するガイドライン|モーディア () <http://www.modea.co.jp/guideline>

◎許諾されたURLと一致しないWebサイトで使用された場合、契約外使用として違約金が科せられます。使用するURLの第一階層をすべてお知らせください。また、同一のスポンサー名・商品名を冠した同一レイアウトのWebサイトであっても、URLが違う場合は他者の使用と判断されます。特に、ショッピングモール等通販サイトやグローバルサイトのURLについてはご注意ください。

【 一階層 = http://に続く次のスラッシュまでのURL/】

[55] Arrival – Mozilla Open Design ( ()) <https://blog.mozilla.org/opendesign/arrival/>

[56] Mozilla の新しいロゴが発表されました | Mozilla Japan ブログ ( ()) <https://www.mozilla.jp/blog/entry/10569/>

[57] :// () <https://curl.haxx.se/favicon.ico>

[58] Add opaque hosts (annevk著, ) <https://github.com/whatwg/url/commit/30362553e9ce9fc706d3492bd61886e399fc94e2>

[60] 942074 - javascript method XMLHttpRequest.setRequestHeader(...) is no longer perform URL encoding () <https://bugzilla.mozilla.org/show_bug.cgi?id=942074>