ids/2/1.txt

[14] [DFN[[CODE(URI)@en[[[http:]]]]]] は、 [[HTTP]] によってアクセスできる[[資源]]を表す
[[URL scheme]] です。

;; [15] [[Semantic Web]] の世界では、実際には [[HTTP]] でアクセスしても存在していない[[資源]]や、
[[HTTP]] によって[[メタデータ]]が取得できるに過ぎない[[資源]]にも [CODE(URI)@en[[[http:]]]] [[URL]]
が濫用されています。

* 仕様書

- [18] [CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]] 
<http://tools.ietf.org/html/rfc2616#section-3.2.2>

* 意味

[19] [CODE(HTTP)@en[[[http:]]]] [[URL]] は、指定された [[host]]、[[port]] に [[HTTP]] over [[TCP]]
で接続し、 [[path]] と [[query]] を [CODE(ABNF)@en[[[Request-URI]]]] として指定したときに得られる[[資源]]を識別しています。
[SRC[>>18, [[RFC 2616]] 正誤表]]

** Semantic Web 界での解釈

[5]
[CITE[What do HTTP URIs Identify? - Design Issues]] <http://www.w3.org/DesignIssues/HTTP-URI>
([[名無しさん]])

[6]
[CITE[What do HTTP URIs Identify? - Design Issues]] <http://www.w3.org/DesignIssues/HTTP-URI2.html>
([[名無しさん]])

[7]
[CITE[TAG Issues List]] <http://www.w3.org/2001/tag/issues.html?type=1#httpRange-14>
([[名無しさん]])

[8]
[CITE@EN[URNs, Namespaces and Registries]] ([CODE[2006-09-01 17:51:46 +09:00]] 版) <http://www.w3.org/2001/tag/doc/URNsAndRegistries-50-2006-08-17.html>

** TLS

[118] [[RFC 2817]] は、 [CODE(HTTP)@en[[[Upgrade:]]]] による [[TLS/1.0]] への切り替えを使う場合にも
[CODE(URI)@en[[[http:]]]] [[URL]] を使うことを提案していました。

;; [119] 実際にはこれは利用されておらず、 [CODE(HTTP)@en[[[Upgrade:]]]] を使わない
[CODE(URI)@en[[[https:]]]] がもっぱら利用されています。

* Authority

[81] [[IPアドレス]]を使うことは可能な限り避ける[['''べきです''']] [SRC[>>18]]。

[87] 仕様上は、 [CODE(ABNF)@en[[[userinfo]]]] を使うことは認められていません。
これは >>97 から [[RFC 2616]] (>>86) までずっと変わっていません。

;; [98] 認められなかったというよりは、単に追加されなかっただけでしょうな。
初期の [[HTTP]] には[[認証]]が何も実装されていませんでしたから。

** 串における処理

[83] [[串]]は、[[ホスト名]]が [[FQDN]] でなければ、[[ホスト名]]を追加して[['''構いません''']]。
[[FQDN]] は書き換えては[['''なりません''']]。 [SRC[>>18]]

* Port

[20] [[既定のポート]]は [CODE[[[80]]]] です [SRC[>>18]]。

* Path

[82] [[path]] が省略されている場合、 [[HTTP]] [[要求]]の [CODE(ABNF)@en[[[Request-URI]]]]
としては「[CODE(URI)@en[[[/]]]]」を使わなければ[['''なりません''']] [SRC[>>18]]。

** ディレクトリー

[107] [CODE(URI)@en[[[http:]]]] [[URL]] の [[path]] の末尾が [CODE(URI)[[[/]]]] で終わる場合、
[[ファイル・システム]]の類似の概念になぞらえて「[[ディレクトリー]]」や「[[フォルダー]]」
と呼ぶことがあります。 [[URL]] 仕様上も [CODE(URI)@en[[[http:]]]]
[[URL]] 仕様上も「[[ディレクトリー]]」という概念は存在しませんが、そもそも
[[URL]] の「[CODE(URI)[[[/]]]]」は[[ディレクトリー]]に由来していますし、
現在でも [CODE(URI)@en[[[http:]]]] [[URL]] の [[path]] を[[ファイル・システム]]の [[path]]
に対応付けることがしばしばあるため、慣用的に用いられています。

[108] [CODE(URI)@en[http://example/a/]] という[[ディレクトリー]]と
[CODE(URI)@en[http://example/a]] は同じではありません。前者が存在しても、
後者は存在しないかもしれません。ですが、実際には [[HTTP]] 
を[[ファイル・システム]]に対応付けるよう[[鯖]]が設定されている場合には後者から前者へと[[リダイレクト]]されるのが普通です。

[109] [[ディレクトリー]]は [CODE(URI)[[[/]]]] で終わるのが正式である (ことが多い) のでそちらの [[URL]]
を使うべきだとの意見や、無駄な[[リダイレクト]]が発生するから [CODE(URI)[[[/]]]] 
で終わり[[リダイレクト]]されない [[URL]] を使うべきだとの意見もあります。

[120] [[ファイル]]から[[ディレクトリー]]に途中で変えたくなる場合、あるいはその逆の場合があり得ること、
あるいは並列な[[ファイル]]/[[ディレクトリー]]が混在する場合に一貫した [[path]]
にしたいといったような理由により、 [CODE(URI)[[[/]]]] を付けない方に統一するべきだという意見もかつてはありましたが、
最近は聞かなくなりました。

** 拡張子

[110] [CODE(URI)@en[[[http:]]]] [[URL]] の [[path]] の末尾が [CODE(file)[[[.]]]]
と数文字の[[英数字]]で終わる場合、[[ファイル・システム]]の類似の概念になぞらえて「[[拡張子]]」
と呼ぶことがあります。 [[URL]] の仕様上も [[HTTP]] でも「[[拡張子]]」
という概念は存在しませんが、 [CODE(URI)@en[[[http:]]]] [[URL]] の [[path]]
を[[ファイル・システム]]の [[path]] に対応付けることがしばしばあるため、
慣用的に用いられています。

[111] [[HTTP]] の仕様上は不透明な [[path]] の一部であり[[プロトコル]]上や[[クライアント]]の動作には影響しないはずですが、
便宜上、[[利用者エージェント]]の一部の動作に影響することがあります。例えば、
[CODE(URI)@en[[[http:]]]] [[URL]] の[[拡張子]]が[[画像]]を表すものかどうかによって挙動が変わることがあります。

;; [112] [[HTTP]] の仕様の想定としては実際にアクセスして [CODE(HTTP)@en[[[Content-Type]]]]
を見て挙動を変えるのが適切なのでしょうが、 [[URL]] だけを見て、
ネットワーク・アクセスを発生させずに挙動を決定するには[[拡張子]]が便利なので、
しばしば用いられるのです。

[113] [[拡張子]]は、 [[HTTP]] [[鯖]]において [[HTTP]]
[[実体頭欄]]を決定したり、[[内容折衝]]を行ったりする際の情報として利用されることがあります。
例えば [[Apache]] の [[mod_mime]] は、 [CODE@en[[[AddType]]]] や
[CODE@en[[[AddCharset]]]] などの[[指令]]によって決まる[[拡張子]]と[[MIME型]]などの対応情報に基づき、
[CODE(HTTP)@en[[[Content-Type]]]] [[頭欄]]などを決定したり、[[内容折衝]]を行ったりします。

[114] [[内容折衝]]などを活用することにより [[HTTP]] や [CODE(HTTP)@en[[[http:]]]] [[URL]]
を ([[表現]]より一段抽象化された) [[資源]]として捉えることを好む人達は、
[[URL]] に[[拡張子]]が含まれることは好ましくないと考えています。
[[拡張子]]を含めなければ、 [[GIF]] と [[PNG]] の2種類が[[鯖]]に用意されているときに、
[[クライアント]]が送ってきた [CODE(HTTP)@en[[[Accept:]]]] 
[[頭欄]]を見てどちらか適切な方を返すことができるからです。

[115] 実際に [[Apache]] では[[ファイル・システム]]上の[[拡張子]]付きのファイルに対して[[拡張子]]を除去した [[URL]] を使ってアクセスして[[内容折衝]]を行わせることができます。

** 予約されている path

[99] 次に述べる [[path]] は、公式または非公式に予約されていて、特定の目的に使われます。

- [100] [CODE(URI)@en[/[[robots.txt]]]]
- [101] [CODE(URI)@en[/[[favicon.ico]]]]
- [12] [CODE(URI)@en[[[/.well-known/]]]]

** ホーム・ディレクトリー

[102] [CODE(URI)@en[http://[VAR[host]]/~[VAR[username]]/[VAR[path]]]] のような [[URL]]
は、[[利用者]] [VAR[username]] に割り当てられた領域を意味するものとして使う慣習があります。
[VAR[host]] は通常は [[ISP]] や[[大学]]などの所有する[[ドメイン名]]であり、
[[会員]]や[[教員]]・[[学生]]に [[Web]] 公開用の領域として割り当てています。

[103] [CODE(URI)[[[~]]]] は、 [[Unix]] で[[ホーム・ディレクトリー]]を表す記号として用いられていて、
それをそのまま [[URL]] として使っているものと推測されます。

[104] [[Apache]] などの普及している
[[HTTP]] [[鯖]]の既定の設定においては、 [CODE(URI)@en[/~[VAR@en[username]]/]] 
は[[ファイル・システム]]上の [CODE(file)@en[~[VAR@en[username]]/[[public_html]]/]]
に対応します。

[105] 近年では組織が構成員に [[Web]] 用の領域を割り当て、
そこを使って [[Webサイト]]を公開することが少なくなってきたので、
この形式の [[URL]] を見ることも減ってきました。 [TIME[2011-02-27T14:13:06.00Z]]

[106] なお、 [CODE(URI)[[[~]]]] は古い [[RFC]] では使用が認められておらず、
[CODE(URI)@en[[[%7E]]]] と[[百分率符号化]]しなければならなかったにも関わらず、
この慣習は広く行われており、 [CODE(URI)[[[~]]]] をそのまま使った [[URL]]
も昔からよく見かけました。結局 [CODE(URI)[[[~]]]] は仕様上も追認されることになるのですが、
それまでは [CODE(URI)@en[[[%7E]]]] と書くべきだとか、そもそも [CODE(URI)[[[~]]]]
を使うのは好ましくないだとかいった議論がしばしばなされました。

* 長さ

[94] [[URLの長さ]]を参照してください。

* 正準形

[92] [[HTTPにおけるURLの比較]]を参照してください。

* 処理モデル

** 比較

[84] いつ使うのかは不明確ではありますが、 [[HTTPにおけるURLの比較]]の方法が定義されています。

** フォーム提出

[11] [CITE@en-GB-x-Hixie[Web Forms 2.0]] ([TIME[2009-01-05 20:07:15 +09:00]] 版) <http://www.whatwg.org/specs/web-forms/current-work/#for-http>

* 不思議解釈

[4]

> RFC 2616 には HTTPプロトコルに関することが書かれており,3.2.2 http URL に書かれている http URL も,HTTPプロトコルの中での話になります.一般に,HTML のリンクに使用されるものは,純粋に HTTPプロトコルの中で使用される http URL ではなく, scheme が http であるURI References です.

出典: [CITE[Perlメモ]] <http://www.din.or.jp/%7Eohzaki/perl.htm#httpURL>
(2005年3月現在)

このような解釈は正しく'''ありません'''。 [[IANA]]
の [[URI scheme]] 登録簿に拠れば [CODE(URI)[[[http]]:]]
URI scheme の出典は [[RFC 2616]] であり、 [[IETF]]
的に有効な [CODE(URI)[[[http]]:]] [[URI]] の規定は
([[HTTP]] であれ [[HTML]] であれ、その他の文脈であれ)
[[RFC 2616]] だけです。

更に

> たとえば http://user:passwd@www.din.or.jp/~ohzaki/perl.htm#URI は URI References ですが,user:passwd@ の部分,すなわち,userinfo や,#URI の部分,すなわち, Fragment Identifier は HTTPプロトコルの中で使用される http URL としては不正なものとなります.しかし,HTML のリンクとしては問題ありません.なぜなら,クライアント(ブラウザ)が HTTPプロトコルで通信する際にはそれらを削除しているからです.

と説明がありますが、このような議論は実装がそうであるというだけで、
仕様がそうであるとの根拠はありません。
([[RFC 2396]] の時代に [[URI参照]]の一部分ではあっても [[URI]]
の一部分ではなかった[[素片識別子]]は別として、)
単に仕様と実世界が整合していないというだけであって、
[[HTTP]] で使うか [[HTML]] で使うかは関係ありません。

個々の [[URI scheme]] の規定は [[RFC 2396]] (や新しい [[RFC 3986]])
の一般の規定に優先するので、 [[RFC 2396]] で許されるように見えても
[[RFC 2616]] で許されないものは、すべて認められません。

([CODE(URI)[[[ftp]]:]] [[URI]] に関する部分にも同様の指摘ができます。
ただし [CODE(URI)[[[ftp]]:]] [[URI scheme]] の仕様は未だにいにしえの
[[RFC 1738]] のままで、実装とまったく整合していません。)

* 歴史

** 太古の定義

[97] [CITE[HTTPAddressing -- /Addressing]] ([TIME[1992-04-13 17:08:21 +09:00]] 版) <http://www.w3.org/History/19921103-hypertext/hypertext/WWW/Addressing/HTTPAddressing.html>

** RFC 1630 の定義

[96] [CITE@en[RFC 1630 - 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]] 
<http://tools.ietf.org/html/rfc1630#page-13>

** RFC 1738 の定義

[95] [CITE@en[RFC 1738 - Uniform Resource Locators (URL)]] 
<http://tools.ietf.org/html/rfc1738#section-3.3>

** RFC 1808 の定義

[116] [CITE@en[RFC 1808 - Relative Uniform Resource Locators]] ([TIME[2011-02-27 10:22:45 +09:00]] 版) <http://tools.ietf.org/html/rfc1808#section-2.3>

[117] [[RFC 1808]] は、「Note」の中で、 [[RFC 1738]] は [CODE(URI)@en[[[http:]]]] [[URL]]
の中で普通に [CODE(URI)@en[[[;]]]] を認めていたけどその[[意味]]は明記しておらず、
[[RFC 1808]] ではそれをちゃんと定義してる、と述べています。その意味というのがどういうことなのか実は不明確ですがw、
[[URI]] の一般的な構文における [CODE(ABNF)@en[[[params]]]] のための区切子として扱われているので、
その意味で扱うべきという見解だったのでしょう。

** RFC 1945、RFC 2068 の定義

[2] [CODE(HTTP)@en[[[http:]]]] [[URL]] は [[HTTP/1.0]]、[[HTTP/1.1]] の仕様の一部として
[[RFC 1945]] 3.2 [SRC[>>90]]、[[RFC 2068]] 3.2 で規定されました。

[88] この仕様は当時の [[URL]] の正式な規定であるところの [[RFC 1738]] や [[RFC 1808]]
に[[意図的違反]]していました。具体的には、本来 [[URL]] では使えないはずの [CODE(ABNF)@en[[[national]]]]
の[[オクテット]] (つまり任意の[[オクテット]]) が認められていたりしました。
その理由としては、[[鯖]]は[[文字]]の制約に縛られていないこと、
[[串]]はどのみち受け入れるしかないことが挙げられていました。

;; [91] [[誤り処理]]であるとも取れますが、曖昧ですな。

[89] 
なんかこの [[ABNF]] 構文破綻してる気がしますが。。。
例えば [CODE(ABNF)[segment = 2068.segment - "/"]]
と定義しておかないと[[欲張り]]過ぎるんじゃ?

*** 仕様書

- [90] [CITE@en[RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0]] 
<http://tools.ietf.org/html/rfc1945#section-3.2.2>
- [93] [CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]] 
<http://tools.ietf.org/html/rfc2068#section-3.2.2>

** RFC 2616 の定義

[85] [[RFC 2068]] の改訂である [[RFC 2616]] では、 [CODE(ABNF)@en[[[national]]]]
を認めていた独自の定義は削除され、 [[RFC 2396]] に定義を委ねる形になっています。

[86] 
>
[PRE(ABNF code)[
   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
]PRE]

* テスト・ケース

[1] ''Another HTML-lint : Explanation'' <http://openlab.ring.gr.jp/k16/htmllint/explain.html#illegal-format-url>
正しくない [[URI]] の例が幾つかあります。

* 関連

[16] [CODE(URI)@en[[[http:]]]] に非常によく似た [[URL scheme]] として、
[[HTTP/TLS]] を表す [CODE(HTTP)@en[[[https:]]]]、 [[SHTTP]] を表す 
[CODE(HTTP)@en[[[shttp:]]]] があります。

[17] [[Web]] の[[掲示板]]などでは、 [CODE(HTTP)@en[[[http:]]]] [[URL]] を検知して自動的に[[ハイパーリンク]]として解釈する機能が適用されることを防ぐため、
[CODE(HTTP)@en[[[ttp:]]]]、[CODE(HTTP)@en[[[tp:]]]]、[CODE(HTTP)@en[[[p:]]]]
といった [[URL scheme]] を用いたり、 [[URL scheme]] を省略して [CODE(URI)[[[:]]]]
から始めたり、 「[CODE(HTTP)@en[[[http]]]]」の一部又は全部を[[全角]]で表記したりすることがあります。

[13] [[HTTPにおけるURL]]の項もご覧ください。
1	wakaba	1.6	[14] [DFN[[CODE(URI)@en[[[http:]]]]]] は、 [[HTTP]] によってアクセスできる[[資源]]を表す
2			[[URL scheme]] です。
3	wakaba	1.2
4	wakaba	1.7	;; [15] [[Semantic Web]] の世界では、実際には [[HTTP]] でアクセスしても存在していない[[資源]]や、
5	wakaba	1.6	[[HTTP]] によって[[メタデータ]]が取得できるに過ぎない[[資源]]にも [CODE(URI)@en[[[http:]]]] [[URL]]
6			が濫用されています。
7	wakaba	1.2
8	wakaba	1.9	* 仕様書
9
10			- [18] [CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]]
11			<http://tools.ietf.org/html/rfc2616#section-3.2.2>
12
13	wakaba	1.7	* 意味
14	wakaba	1.2
15	wakaba	1.9	[19] [CODE(HTTP)@en[[[http:]]]] [[URL]] は、指定された [[host]]、[[port]] に [[HTTP]] over [[TCP]]
16			で接続し、 [[path]] と [[query]] を [CODE(ABNF)@en[[[Request-URI]]]] として指定したときに得られる[[資源]]を識別しています。
17			[SRC[>>18, [[RFC 2616]] 正誤表]]
18
19	wakaba	1.7	** Semantic Web 界での解釈
20
21			[5]
22			[CITE[What do HTTP URIs Identify? - Design Issues]] <http://www.w3.org/DesignIssues/HTTP-URI>
23			([[名無しさん]])
24
25			[6]
26			[CITE[What do HTTP URIs Identify? - Design Issues]] <http://www.w3.org/DesignIssues/HTTP-URI2.html>
27			([[名無しさん]])
28	wakaba	1.2
29	wakaba	1.7	[7]
30			[CITE[TAG Issues List]] <http://www.w3.org/2001/tag/issues.html?type=1#httpRange-14>
31			([[名無しさん]])
32	wakaba	1.2
33	wakaba	1.7	[8]
34			[CITE@EN[URNs, Namespaces and Registries]] ([CODE[2006-09-01 17:51:46 +09:00]] 版) <http://www.w3.org/2001/tag/doc/URNsAndRegistries-50-2006-08-17.html>
35	wakaba	1.2
36	wakaba	1.26	** TLS
37
38			[118] [[RFC 2817]] は、 [CODE(HTTP)@en[[[Upgrade:]]]] による [[TLS/1.0]] への切り替えを使う場合にも
39			[CODE(URI)@en[[[http:]]]] [[URL]] を使うことを提案していました。
40
41			;; [119] 実際にはこれは利用されておらず、 [CODE(HTTP)@en[[[Upgrade:]]]] を使わない
42			[CODE(URI)@en[[[https:]]]] がもっぱら利用されています。
43
44	wakaba	1.10	* Authority
45
46			[81] [[IPアドレス]]を使うことは可能な限り避ける[['''べきです''']] [SRC[>>18]]。
47
48	wakaba	1.17	[87] 仕様上は、 [CODE(ABNF)@en[[[userinfo]]]] を使うことは認められていません。
49	wakaba	1.18	これは >>97 から [[RFC 2616]] (>>86) までずっと変わっていません。
50
51			;; [98] 認められなかったというよりは、単に追加されなかっただけでしょうな。
52			初期の [[HTTP]] には[[認証]]が何も実装されていませんでしたから。
53	wakaba	1.12
54	wakaba	1.10	** 串における処理
55
56			[83] [[串]]は、[[ホスト名]]が [[FQDN]] でなければ、[[ホスト名]]を追加して[['''構いません''']]。
57			[[FQDN]] は書き換えては[['''なりません''']]。 [SRC[>>18]]
58
59			* Port
60
61			[20] [[既定のポート]]は [CODE[[[80]]]] です [SRC[>>18]]。
62
63			* Path
64
65			[82] [[path]] が省略されている場合、 [[HTTP]] [[要求]]の [CODE(ABNF)@en[[[Request-URI]]]]
66			としては「[CODE(URI)@en[[[/]]]]」を使わなければ[['''なりません''']] [SRC[>>18]]。
67	wakaba	1.2
68	wakaba	1.22	** ディレクトリー
69
70	wakaba	1.23	[107] [CODE(URI)@en[[[http:]]]] [[URL]] の [[path]] の末尾が [CODE(URI)[[[/]]]] で終わる場合、
71	wakaba	1.22	[[ファイル・システム]]の類似の概念になぞらえて「[[ディレクトリー]]」や「[[フォルダー]]」
72			と呼ぶことがあります。 [[URL]] 仕様上も [CODE(URI)@en[[[http:]]]]
73			[[URL]] 仕様上も「[[ディレクトリー]]」という概念は存在しませんが、そもそも
74			[[URL]] の「[CODE(URI)[[[/]]]]」は[[ディレクトリー]]に由来していますし、
75			現在でも [CODE(URI)@en[[[http:]]]] [[URL]] の [[path]] を[[ファイル・システム]]の [[path]]
76			に対応付けることがしばしばあるため、慣用的に用いられています。
77
78			[108] [CODE(URI)@en[http://example/a/]] という[[ディレクトリー]]と
79			[CODE(URI)@en[http://example/a]] は同じではありません。前者が存在しても、
80			後者は存在しないかもしれません。ですが、実際には [[HTTP]]
81			を[[ファイル・システム]]に対応付けるよう[[鯖]]が設定されている場合には後者から前者へと[[リダイレクト]]されるのが普通です。
82
83			[109] [[ディレクトリー]]は [CODE(URI)[[[/]]]] で終わるのが正式である (ことが多い) のでそちらの [[URL]]
84			を使うべきだとの意見や、無駄な[[リダイレクト]]が発生するから [CODE(URI)[[[/]]]]
85			で終わり[[リダイレクト]]されない [[URL]] を使うべきだとの意見もあります。
86
87	wakaba	1.27	[120] [[ファイル]]から[[ディレクトリー]]に途中で変えたくなる場合、あるいはその逆の場合があり得ること、
88			あるいは並列な[[ファイル]]/[[ディレクトリー]]が混在する場合に一貫した [[path]]
89			にしたいといったような理由により、 [CODE(URI)[[[/]]]] を付けない方に統一するべきだという意見もかつてはありましたが、
90			最近は聞かなくなりました。
91
92	wakaba	1.23	** 拡張子
93
94			[110] [CODE(URI)@en[[[http:]]]] [[URL]] の [[path]] の末尾が [CODE(file)[[[.]]]]
95			と数文字の[[英数字]]で終わる場合、[[ファイル・システム]]の類似の概念になぞらえて「[[拡張子]]」
96			と呼ぶことがあります。 [[URL]] の仕様上も [[HTTP]] でも「[[拡張子]]」
97			という概念は存在しませんが、 [CODE(URI)@en[[[http:]]]] [[URL]] の [[path]]
98			を[[ファイル・システム]]の [[path]] に対応付けることがしばしばあるため、
99			慣用的に用いられています。
100
101			[111] [[HTTP]] の仕様上は不透明な [[path]] の一部であり[[プロトコル]]上や[[クライアント]]の動作には影響しないはずですが、
102			便宜上、[[利用者エージェント]]の一部の動作に影響することがあります。例えば、
103			[CODE(URI)@en[[[http:]]]] [[URL]] の[[拡張子]]が[[画像]]を表すものかどうかによって挙動が変わることがあります。
104
105			;; [112] [[HTTP]] の仕様の想定としては実際にアクセスして [CODE(HTTP)@en[[[Content-Type]]]]
106			を見て挙動を変えるのが適切なのでしょうが、 [[URL]] だけを見て、
107			ネットワーク・アクセスを発生させずに挙動を決定するには[[拡張子]]が便利なので、
108			しばしば用いられるのです。
109
110			[113] [[拡張子]]は、 [[HTTP]] [[鯖]]において [[HTTP]]
111			[[実体頭欄]]を決定したり、[[内容折衝]]を行ったりする際の情報として利用されることがあります。
112			例えば [[Apache]] の [[mod_mime]] は、 [CODE@en[[[AddType]]]] や
113			[CODE@en[[[AddCharset]]]] などの[[指令]]によって決まる[[拡張子]]と[[MIME型]]などの対応情報に基づき、
114			[CODE(HTTP)@en[[[Content-Type]]]] [[頭欄]]などを決定したり、[[内容折衝]]を行ったりします。
115
116	wakaba	1.24	[114] [[内容折衝]]などを活用することにより [[HTTP]] や [CODE(HTTP)@en[[[http:]]]] [[URL]]
117			を ([[表現]]より一段抽象化された) [[資源]]として捉えることを好む人達は、
118			[[URL]] に[[拡張子]]が含まれることは好ましくないと考えています。
119			[[拡張子]]を含めなければ、 [[GIF]] と [[PNG]] の2種類が[[鯖]]に用意されているときに、
120			[[クライアント]]が送ってきた [CODE(HTTP)@en[[[Accept:]]]]
121			[[頭欄]]を見てどちらか適切な方を返すことができるからです。
122
123			[115] 実際に [[Apache]] では[[ファイル・システム]]上の[[拡張子]]付きのファイルに対して[[拡張子]]を除去した [[URL]] を使ってアクセスして[[内容折衝]]を行わせることができます。
124
125	wakaba	1.19	** 予約されている path
126
127			[99] 次に述べる [[path]] は、公式または非公式に予約されていて、特定の目的に使われます。
128
129			- [100] [CODE(URI)@en[/[[robots.txt]]]]
130			- [101] [CODE(URI)@en[/[[favicon.ico]]]]
131			- [12] [CODE(URI)@en[[[/.well-known/]]]]
132	wakaba	1.2
133	wakaba	1.20	** ホーム・ディレクトリー
134
135			[102] [CODE(URI)@en[http://[VAR[host]]/~[VAR[username]]/[VAR[path]]]] のような [[URL]]
136	wakaba	1.21	は、[[利用者]] [VAR[username]] に割り当てられた領域を意味するものとして使う慣習があります。
137	wakaba	1.20	[VAR[host]] は通常は [[ISP]] や[[大学]]などの所有する[[ドメイン名]]であり、
138			[[会員]]や[[教員]]・[[学生]]に [[Web]] 公開用の領域として割り当てています。
139
140			[103] [CODE(URI)[[[~]]]] は、 [[Unix]] で[[ホーム・ディレクトリー]]を表す記号として用いられていて、
141			それをそのまま [[URL]] として使っているものと推測されます。
142
143	wakaba	1.21	[104] [[Apache]] などの普及している
144	wakaba	1.20	[[HTTP]] [[鯖]]の既定の設定においては、 [CODE(URI)@en[/~[VAR@en[username]]/]]
145			は[[ファイル・システム]]上の [CODE(file)@en[~[VAR@en[username]]/[[public_html]]/]]
146			に対応します。
147
148	wakaba	1.21	[105] 近年では組織が構成員に [[Web]] 用の領域を割り当て、
149			そこを使って [[Webサイト]]を公開することが少なくなってきたので、
150			この形式の [[URL]] を見ることも減ってきました。 [TIME[2011-02-27T14:13:06.00Z]]
151
152	wakaba	1.22	[106] なお、 [CODE(URI)[[[~]]]] は古い [[RFC]] では使用が認められておらず、
153			[CODE(URI)@en[[[%7E]]]] と[[百分率符号化]]しなければならなかったにも関わらず、
154			この慣習は広く行われており、 [CODE(URI)[[[~]]]] をそのまま使った [[URL]]
155			も昔からよく見かけました。結局 [CODE(URI)[[[~]]]] は仕様上も追認されることになるのですが、
156			それまでは [CODE(URI)@en[[[%7E]]]] と書くべきだとか、そもそも [CODE(URI)[[[~]]]]
157			を使うのは好ましくないだとかいった議論がしばしばなされました。
158
159	wakaba	1.16	* 長さ
160
161			[94] [[URLの長さ]]を参照してください。
162
163	wakaba	1.14	* 正準形
164
165			[92] [[HTTPにおけるURLの比較]]を参照してください。
166
167	wakaba	1.7	* 処理モデル
168	wakaba	1.2
169	wakaba	1.11	** 比較
170
171			[84] いつ使うのかは不明確ではありますが、 [[HTTPにおけるURLの比較]]の方法が定義されています。
172
173	wakaba	1.7	** フォーム提出
174	wakaba	1.2
175	wakaba	1.7	[11] [CITE@en-GB-x-Hixie[Web Forms 2.0]] ([TIME[2009-01-05 20:07:15 +09:00]] 版) <http://www.whatwg.org/specs/web-forms/current-work/#for-http>
176	wakaba	1.2
177	wakaba	1.7	* 不思議解釈
178	wakaba	1.2
179			[4]
180
181			> RFC 2616 には HTTPプロトコルに関することが書かれており,3.2.2 http URL に書かれている http URL も,HTTPプロトコルの中での話になります.一般に,HTML のリンクに使用されるものは,純粋に HTTPプロトコルの中で使用される http URL ではなく, scheme が http であるURI References です.
182
183			出典: [CITE[Perlメモ]] <http://www.din.or.jp/%7Eohzaki/perl.htm#httpURL>
184			(2005年3月現在)
185
186			このような解釈は正しく'''ありません'''。 [[IANA]]
187			の [[URI scheme]] 登録簿に拠れば [CODE(URI)[[[http]]:]]
188			URI scheme の出典は [[RFC 2616]] であり、 [[IETF]]
189			的に有効な [CODE(URI)[[[http]]:]] [[URI]] の規定は
190			([[HTTP]] であれ [[HTML]] であれ、その他の文脈であれ)
191			[[RFC 2616]] だけです。
192
193			更に
194
195			> たとえば http://user:passwd@www.din.or.jp/~ohzaki/perl.htm#URI は URI References ですが,user:passwd@ の部分,すなわち,userinfo や,#URI の部分,すなわち, Fragment Identifier は HTTPプロトコルの中で使用される http URL としては不正なものとなります.しかし,HTML のリンクとしては問題ありません.なぜなら,クライアント(ブラウザ)が HTTPプロトコルで通信する際にはそれらを削除しているからです.
196
197			と説明がありますが、このような議論は実装がそうであるというだけで、
198			仕様がそうであるとの根拠はありません。
199			([[RFC 2396]] の時代に [[URI参照]]の一部分ではあっても [[URI]]
200			の一部分ではなかった[[素片識別子]]は別として、)
201			単に仕様と実世界が整合していないというだけであって、
202			[[HTTP]] で使うか [[HTML]] で使うかは関係ありません。
203
204			個々の [[URI scheme]] の規定は [[RFC 2396]] (や新しい [[RFC 3986]])
205			の一般の規定に優先するので、 [[RFC 2396]] で許されるように見えても
206			[[RFC 2616]] で許されないものは、すべて認められません。
207
208			([CODE(URI)[[[ftp]]:]] [[URI]] に関する部分にも同様の指摘ができます。
209			ただし [CODE(URI)[[[ftp]]:]] [[URI scheme]] の仕様は未だにいにしえの
210			[[RFC 1738]] のままで、実装とまったく整合していません。)
211
212	wakaba	1.7	* 歴史
213	wakaba	1.2
214	wakaba	1.18	** 太古の定義
215
216			[97] [CITE[HTTPAddressing -- /Addressing]] ([TIME[1992-04-13 17:08:21 +09:00]] 版) <http://www.w3.org/History/19921103-hypertext/hypertext/WWW/Addressing/HTTPAddressing.html>
217
218	wakaba	1.17	** RFC 1630 の定義
219
220			[96] [CITE@en[RFC 1630 - 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]]
221			<http://tools.ietf.org/html/rfc1630#page-13>
222
223			** RFC 1738 の定義
224
225			[95] [CITE@en[RFC 1738 - Uniform Resource Locators (URL)]]
226			<http://tools.ietf.org/html/rfc1738#section-3.3>
227
228	wakaba	1.25	** RFC 1808 の定義
229
230			[116] [CITE@en[RFC 1808 - Relative Uniform Resource Locators]] ([TIME[2011-02-27 10:22:45 +09:00]] 版) <http://tools.ietf.org/html/rfc1808#section-2.3>
231
232			[117] [[RFC 1808]] は、「Note」の中で、 [[RFC 1738]] は [CODE(URI)@en[[[http:]]]] [[URL]]
233			の中で普通に [CODE(URI)@en[[[;]]]] を認めていたけどその[[意味]]は明記しておらず、
234			[[RFC 1808]] ではそれをちゃんと定義してる、と述べています。その意味というのがどういうことなのか実は不明確ですがw、
235			[[URI]] の一般的な構文における [CODE(ABNF)@en[[[params]]]] のための区切子として扱われているので、
236			その意味で扱うべきという見解だったのでしょう。
237
238	wakaba	1.13	** RFC 1945、RFC 2068 の定義
239	wakaba	1.2
240	wakaba	1.13	[2] [CODE(HTTP)@en[[[http:]]]] [[URL]] は [[HTTP/1.0]]、[[HTTP/1.1]] の仕様の一部として
241			[[RFC 1945]] 3.2 [SRC[>>90]]、[[RFC 2068]] 3.2 で規定されました。
242	wakaba	1.3
243	wakaba	1.13	[88] この仕様は当時の [[URL]] の正式な規定であるところの [[RFC 1738]] や [[RFC 1808]]
244			に[[意図的違反]]していました。具体的には、本来 [[URL]] では使えないはずの [CODE(ABNF)@en[[[national]]]]
245			の[[オクテット]] (つまり任意の[[オクテット]]) が認められていたりしました。
246			その理由としては、[[鯖]]は[[文字]]の制約に縛られていないこと、
247			[[串]]はどのみち受け入れるしかないことが挙げられていました。
248
249			;; [91] [[誤り処理]]であるとも取れますが、曖昧ですな。
250
251			[89]
252			なんかこの [[ABNF]] 構文破綻してる気がしますが。。。
253	wakaba	1.7	例えば [CODE(ABNF)[segment = 2068.segment - "/"]]
254			と定義しておかないと[[欲張り]]過ぎるんじゃ?
255	wakaba	1.4
256	wakaba	1.14	*** 仕様書
257	wakaba	1.13
258			- [90] [CITE@en[RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0]]
259			<http://tools.ietf.org/html/rfc1945#section-3.2.2>
260	wakaba	1.15	- [93] [CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]]
261			<http://tools.ietf.org/html/rfc2068#section-3.2.2>
262	wakaba	1.13
263	wakaba	1.12	** RFC 2616 の定義
264
265	wakaba	1.13	[85] [[RFC 2068]] の改訂である [[RFC 2616]] では、 [CODE(ABNF)@en[[[national]]]]
266			を認めていた独自の定義は削除され、 [[RFC 2396]] に定義を委ねる形になっています。
267	wakaba	1.12
268			[86]
269			>
270			[PRE(ABNF code)[
271			http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
272			]PRE]
273
274	wakaba	1.6	* テスト・ケース
275
276			[1] ''Another HTML-lint : Explanation'' <http://openlab.ring.gr.jp/k16/htmllint/explain.html#illegal-format-url>
277			正しくない [[URI]] の例が幾つかあります。
278
279	wakaba	1.4	* 関連
280
281	wakaba	1.7	[16] [CODE(URI)@en[[[http:]]]] に非常によく似た [[URL scheme]] として、
282			[[HTTP/TLS]] を表す [CODE(HTTP)@en[[[https:]]]]、 [[SHTTP]] を表す
283			[CODE(HTTP)@en[[[shttp:]]]] があります。
284
285	wakaba	1.8	[17] [[Web]] の[[掲示板]]などでは、 [CODE(HTTP)@en[[[http:]]]] [[URL]] を検知して自動的に[[ハイパーリンク]]として解釈する機能が適用されることを防ぐため、
286			[CODE(HTTP)@en[[[ttp:]]]]、[CODE(HTTP)@en[[[tp:]]]]、[CODE(HTTP)@en[[[p:]]]]
287			といった [[URL scheme]] を用いたり、 [[URL scheme]] を省略して [CODE(URI)[[[:]]]]
288			から始めたり、「[CODE(HTTP)@en[[[http]]]]」の一部又は全部を[[全角]]で表記したりすることがあります。
289
290	wakaba	1.4	[13] [[HTTPにおけるURL]]の項もご覧ください。