1.txt

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

[121] [DFN[[CODE(URI)@en[[[https:]]]]]] は、 [[HTTP]] over [[TLS]]/[[SSL]]
([[HTTPS]]) によってアクセスできる[[資源]]を表す [[URL scheme]] です。

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

* 仕様書

[REFS[
- [125] '''[CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#page-17>'''
- [445] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-8.2>
- [34] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) <http://tools.ietf.org/html/rfc4918#section-5>
- [51] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-3>
]REFS]

* 意味

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

[133] [CODE(HTTP)@en[[[https:]]]] [[URL]] は、指定された [[host]]、[[port]] に [[HTTP]] 
over [[TLS]] over [[TCP]]
で接続し、 [[path]] と [[query]] を [CODE(ABNF)@en[[[Request-URI]]]] として指定したときに得られる[[資源]]を識別しています。
[SRC[>>125]]

;; [134] [[RFC 7230]] の定義上 [[TLS]] に限定されており、 [[SSL]] は含まれていません。

[444] 両者は異なる[[名前空間]]、[[起源鯖]]を表すものですから、
たとえ[[ホスト]]と[[ポート]]が同じであっても、 [[path]] や [[query]]
によって識別される[[資源]]が共通であるとは限りません [SRC[>>125]]。

[52] [[HTTP/0.9]]、[[HTTP/1.0]]、[[HTTP/1.1]] [SRC[>>125]]、[[HTTP/2]] [SRC[>>51]]
のいずれも [CODE(URI)@en[[[http:]]]]/[CODE(URI)@en[[[https:]]]] [[URL scheme]]
を使います。 [[URL]] のみで[[プロトコルの版]]を特定・指定することはできません。

* 構文

[127] [[RFC 7230]] は、 [[RFC 3986]] に基づき [CODE(URI)@en[[[http:]]]] [[URI scheme]]
の構文を次のように定義しています [SRC[>>125]]。

[PRE(ABNF code)[
     http-URI = "http:" "//" [[authority]] [[path-abempty]] [ "?" [[query]] ]
                [ "#" [[fragment]] ]
]PRE]

[135] [[RFC 7230]] は、 [[RFC 3986]] に基づき [CODE(URI)@en[[[https:]]]] [[URI scheme]]
の構文を次のように定義しています [SRC[>>125]]。

[PRE(ABNF code)[
     https-URI = "https:" "//" [[authority]] [[path-abempty]] [ "?" [[query]] ]
                 [ "#" [[fragment]] ]
]PRE]

* authority

** 登録名

[130] [[host]] が[[登録名]]であれば、これは [[DNS]] などの[[名前解決]]サービスによって[[起源鯖]]の[[アドレス]]を探すための間接識別子です。
[SRC[>>125]]

** IP アドレス

[129] [[host]] が[[IPアドレス]]であれば、[[起源鯖]]がその[[IPアドレス]]で [[TCP]]
を [[listen]] しているかもしれないことを表しています。 [SRC[>>125]]

;;
[81] [[RFC 2616]] は、[[IPアドレス]]を使うことは可能な限り避ける[['''べき''']] [SRC[>>18]]
としていました。

** 空文字列

[128] [[送信者]]は空の [[host]] を[[生成]]しては[['''なりません''']]。
[[受信者]]は[[非妥当]]であるとして拒絶しなければ[['''なりません''']]。 [SRC[>>125]]

** port

[20] [CODE(URI)@en[[[http:]]]] [[URL]] では、
[[ポート]]がないか[[空]]であるときの[[既定のポート]]は [CODE[[[80]]]] です [SRC[>>18, >>125]]。

[136] [CODE(URI)@en[[[https:]]]] [[URL]] では、
[[ポート]]がないか[[空]]であるときの[[既定のポート]]は [CODE[[[443]]]] です [SRC[>>125]]。

** userinfo

[131] 構文上 [[userinfo]] も利用できます。実装によっては [[userinfo]]
を[[認証]]情報として使います [SRC[>>125]]。

[132] しかし[[送信者]]は[[要求対象]]や[[ヘッダー]]の値として含まれる
[CODE(URI)@en[[[http:]]]]/[CODE(URI)@en[[[https:]]]] [[URL]] において 
[[userinfo]] を[[生成]]しては[['''なりません''']] [SRC[>>125]]。

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

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

** 串における処理

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

* パス

[23] [[パス]]は[[鯖]]によって解釈されます。[[パス]]は
[CODE(URI)[[[/]]]] と[[パスセグメント]]を繰り返したものと定義されてはいますが、
前後の区切り文字や[[パーセント符号化]]を除けば事実上任意の文字列を使うことができます。

[FIG(railroad)[
= *
== [CODE(URI)[[[/]]]]
== [[パスセグメント]]
]FIG]

[24] 任意の文字列が認められるとはいえ、多くの場合は以降で述べる通り、
最後以外の[[パスセグメント]]を[[ディレクトリー]]などの階層、
最後の[[パスセグメント]]を[[ファイル]]など階層内のオブジェクトを表すものとして扱っています。
[[鯖]]が[[ファイルシステム]]に [[URL]] を対応付けていない場合であっても、
同様の仮想的な階層構造で[[パス]]を設計するのが一般的です。

[25] 次のものは、そのような一般的な階層構造を想定して作られていたり、
一般的な階層構造の場合に最も使いやすくなっていたりします。
[FIG(list short)[
- [[相対URL]]
- [[クッキー]]の [CODE(HTTP)@en[[[Path]]]]
- [[隣接異体]]
- [[WebDAV]] における名前空間モデル
- [[AppCache]] の適用範囲の制限
]FIG]

[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)[[[/]]]] を付けない方に統一するべきだという意見もかつてはありましたが、
最近は聞かなくなりました。

[41] [[ディレクトリー]]が[[ファイルシステム]]に[[写像]]される場合、
特定の名前の[[ファイル]]があれば、[[ディレクトリー]]へのアクセス時にその[[ファイル]]が返されるように実装・設定されていることがよくあります。
そのような[[ファイル]]の名前としてよく使われるものには、次のものがあります。
どれが使われるかは実装や設定に依存します。
[FIG(list short)[
- [CODE(file)[[[index.html]]]]
- [CODE(file)[[[index.htm]]]]
- [CODE(file)[[[default.htm]]]]
- [CODE(file)[[[Overview.html]]]]
]FIG]

** 拡張子

[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]] だけを見て、
ネットワーク・アクセスを発生させずに挙動を決定するには[[拡張子]]が便利なので、
しばしば用いられるのです。

[EG[
[3] [[掲示板]]の類で[[利用者]]が入力した [[URL]] を[[リンク]]または[[画像]]に変換するシステムでは、
[[拡張子]]によって[[リンク]]か[[画像]]かを決定することがあります。 
]EG]

[EG[
[9] [[キャッシュ串]]の中には、[[拡張子]]を[[キャッシュ]]するかどうかの判断条件に使うものがあります。
]EG]

[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]] を使ってアクセスして[[内容折衝]]を行わせることができます。

[10] [[MIME型]]の他、[[言語]]などを表す[[拡張子]]を組み合わせて [[Apache]]
の [CODE@en[[[AddType]]]] や [CODE@en[[[AddLanguage]]]] などに対応づけることがあります。

[EG[
[21] 例えば [[URL]] [[path]] [CODE(URL)[/document.ja.html.utf-8]] によって
[CODE(MIME)@en[[[Content-Language:]] [[ja]]]], 
[CODE(MIME)@en[[[Content-Type:]] [[text/html]]; [[charset]]=[[utf-8]]]]
を[[生成]]するように設定されていることがあります。
]EG]

** 予約されている path

[99] 次に述べる [[path]] は、 [CODE(URI)@en[[[http:]]]] および [CODE(URI)@en[[[https:]]]]
で公式または非公式に予約されていて、特定の目的に使われます。

[FIG(short list)[
- [100] [CODE(URI)@en[/[[robots.txt]]]]
- [101] [CODE(URI)@en[/[[favicon.ico]]]]
- [12] [CODE(URI)@en[[[/.well-known/]]]]
- [CODE(URI)@en[[[/crossdomain.xml]]]]
- [CODE(URI)@en[[[/apple-touch-icon*.png]]]]
- [CODE(URI)@en[[[/rsd.xml]]]]
- [CODE(URI)@en[[[/search.cgi]]]]
- [CODE(URI)@en[[[/w3c/p3p.xml]]]]
- [CODE(URI)@en[[[/cgi-bin/]]]]
- [CODE(URI)@en[[[/clientaccesspolicy.xml]]]]
]FIG]

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

[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)[[[~]]]]
を使うのは好ましくないだとかいった議論がしばしばなされました。

** WebDAV における制約

[35] [[WebDAV]] に適合する[[資源]]は、次の「HTTP URL 名前空間モデル」
に対応しなければ[['''なりません''']] [SRC[>>34]]。

[36] HTTP URL 名前空間は、 [CODE(URI)[[[/]]]] を階層区切り文字とする階層化された[[名前空間]]です [SRC[>>34]]。

[37] HTTP URL 名前空間は、 [[HTTP]] 階層中のすべての[[URL]] について、
その [[URL]] を[[内部メンバーURL]]として含む[[コレクション]]が存在するなら、
[RUBYB[一貫している]@en[consistent]]といいます。
ただし、対象となる[[名前空間]]の[[根]] (最上位[[コレクション]])
を除きます。 [SRC[>>34]]

;; [38] ここでいう「[[根]]」は必ずしも[[パス]] [CODE[/]]
でなくても構いません。 [CODE[/servlets/webdav/]] のようなものでも構いません。 [SRC[>>34]]

[39] HTTP URL 名前空間の全体が一貫していることは要求されていません。
従って [[WebDAV]] に適合する[[資源]]であっても[[親]]となる[[コレクション]]が存在しないこともあります。
しかし、いくつかの [[WebDAV]] の[[メソッド]]は、
名前空間が一貫しなくなるような操作を禁止しています。 [SRC[>>34]]

[40] [[コレクション]]に関する制約は、[[コレクション]]の項を参照。

* 長さ

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

* 比較と正規化

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

* 名前空間や識別子としての HTTP URL

[26] [CODE(URI)@en[[[http:]]]] [[URL]] を ([[Webページ]]にアクセスするための[[アドレス]]ではなく)
何らかの概念を指す[[識別子]]として使うことを好む人がいます。

;; [27] [[Semantic Web]] 界隈などに多くいるようです。 

[28] [[URL]] を識別子として使うことを好む人の中には
[[URN]] や [[XRI]] などを好む人もいますが、 [CODE(URI)@en[[[http:]]]]
を好む人は、それらは[[名前空間文書]]へのアクセス手段に乏しいため好ましくないと主張しているようです。

[30] 識別子として使われる [[HTTP URL]] は、 (>>28 のような主張の期待に背いて)
[[HTTP]] でアクセスしても適切な[[文書]]が存在しないことがよくあります。
定義された瞬間は存在しても、その後メンテナンスがなされなくなり
[CODE(HTTP)[[[404]]]] になる、というのは良い方で、
最初から存在しなかったり、そもそも[[HTTP鯖]]が存在しなかったりすることも珍しくはありません。

;; [31] メンテナンスがされなくなった後[[ドメイン]]の所有者が変わっていることもあり、
そのような問題を避けるために [[PURL]] を使ったものの、その[[リダイレクト]]先がなくなっている事例もあったりします。

[32] アクセスが可能でも、[[リダイレクト]]されて他の [[URL]] で何らかの[[文書]]や[[スキーマ]]が提供されていることもよくあります。
これは[[名前空間URL]]を[[コピペ]]するときに誤った値にしてしまう要因の一つとなっています。

[EG[
[33] [[HTML名前空間]] [CODE(URI)@en[[[http://www.w3.org/1999/xhtml]]]]
にアクセスすると [CODE(URI)@en[[[http://www.w3.org/1999/xhtml/]]]]
に[[リダイレクト]]されるので、後者の [[URL]] を使う人もいますが、
正しくありません。
]EG]

;; [29] [[名前空間URL]]や[[XML名前空間]]を参照。

* URL scheme のバリエーション

[47] [[HTTP]] や [[HTTPS]] の [CODE(URI)@en[[[http:]]]] や [CODE(URI)@en[[[https:]]]]
のような本来の [[URL scheme]] の他に、 [[HTTP]] 上で動作する[[プロトコル]]や [[HTTP]]
を利用する[[アプリケーション]]は、その[[プロトコル]]や[[アプリケーション]]に適用範囲が限定される以外は
[CODE(URI)@en[[[http:]]]] や [CODE(URI)@en[[[https:]]]] と変わらない [[URL scheme]]
を使っていることがあります。

[48] 例えば次のようなものがあります。
[FIG(short list)[
- [CODE(URI)@en[[[ipp:]]]], [CODE(URI)@en[[[ipps:]]]]
- [CODE(URI)@en[[[coffee:]]]]
- [CODE(URI)@en[[[feed:]]]]
- [CODE(URI)@en[[[googlechrome:]]]], [CODE(URI)@en[[[googlechromes:]]]]
]FIG]

[49] [[掲示板]]等では [[URL]] の[[自動リンク]]を回避するため、敢えて
[[URL scheme]] の一部を省略したり、書き換えたりすることがあります。
[FIG(short list)[
- [CODE(URI)@en[[[ttp:]]]]
- [CODE(URI)@en[[[ttps:]]]]
- [CODE(URI)@en[[[tp:]]]]
- [CODE(URI)@en[[[p:]]]]
- [CODE(URI)@en[[[:]]]]
- [CODE(URI)@en[[[ht+tp:]]]]
]FIG]

[50] [[HTTP]] と関連が吹かうプロトコルである [[WebSocket]] は、次の [[URL scheme]]
を使います。構文も非常によく似ています。
[FIG(short list)[
- [CODE(URI)@en[[[ws:]]]]
- [CODE(URI)@en[[[wss:]]]]
]FIG]

* 処理

** フォーム提出

[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]] のままで、実装とまったく整合していません。)

* 歴史

[126] [CODE(URI)@en[[[http:]]]] は、最古の [[URL scheme]] の一つで、 [[WWW]]
と共に誕生しました。

** 太古の定義

[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]

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

** RFC 2817

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

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

[REFS[
- [122] [CITE@en[RFC 2817 - Upgrading to TLS Within HTTP/1.1]] ([TIME[2012-01-09 20:05:09 +09:00]] 版) <http://tools.ietf.org/html/rfc2817#section-8.1>
]REFS]

[FIG(quote)[
[FIGCAPTION[
8.1 Implications for the https: URI Scheme
]FIGCAPTION]

>   While nothing in this memo affects the definition of the 'https' URI
scheme, widespread adoption of this mechanism for HyperText content
could use 'http' to identify both secure and non-secure resources.
>   The choice of what security characteristics are required on the
connection is left to the client and server.  This allows either
party to use any information available in making this determination.
For example, user agents may rely on user preference settings or
information about the security of the network such as 'TLS required
on all POST operations not on my local net', or servers may apply
resource access rules such as 'the FORM on this page must be served
and submitted using TLS'.
]FIG]

** RFC 2818

[44] [[RFC 2818]] ([[HTTPS]]) では、 [CODE(URI)@en[[[http:]]]] のかわりに
[CODE(URI)@en[[[https:]]]] を [[URL scheme]] として使う [SRC[>>123]] と規定がありました。

;; [45] [CODE(URI)@en[[[https:]]]] [[URL scheme]] は [[SSL/2.0]]
以来使われていましたが、[[仕様書]]として明文化されたのはこの時が初めてと思われます。

[REFS[
- [123] [CITE@en[RFC 2818 - HTTP Over TLS]]
( ([TIME[2013-07-28 23:15:29 +09:00]] 版))
<http://tools.ietf.org/html/rfc2818>
]REFS]

** 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>

** RFC 5785

[42] [[RFC 5785]] は [CODE(URI)@en[[[/.well-known/]]]] を定義しており、そのために
[CODE(URI)@en[[[http:]]]] の [[RFC 2616]] と [CODE(URI)@en[[[https:]]]]
の [[RFC 2818]] を[[更新]]しています。

** RFC 7230

[446] [[HTTP]] の改訂版である [[RFC 7230]] は、従来 [[RFC 2616]] で定義されていた
[CODE(URI)@en[[[http:]]]] に加えて、 [[HTTPS]] の [[RFC]] である [[RFC 2818]] に含まれていた
[CODE(URI)@en[[[https:]]]] をも定義しています。

[448] [[RFC 3986]] に基づく定義となっています。

;; [449] [[RFC 3987]] や [[URL Standard]] は参照していません。

[447] [[IANA登録簿]]の登録も、更新されています [SRC[>>445]]。

[43] なお [[RFC 2616]] と [[RFC 2818]] を[[更新]]している [[RFC 5785]]
を[[更新]]するか、少なくても参照はしないと筋が通らなそうですが、
[[RFC 7230]] は何も言及していません。

* テスト・ケース

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

* 関連

[16] [CODE(URI)@en[[[http:]]]]/[CODE(URI)@en[[[https:]]]] に非常によく似た [[URL scheme]] として、
[[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]]の項もご覧ください。

* メモ

[124] [CITE[IRC logs: freenode / #whatwg / 20110808]]
( ([TIME[2011-08-23 23:29:07 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20110808#l-1235>

[22] [[Docker]] は次のような [[URL]] を使っているようです:
[CODE(URI)@en[http:///var/run/docker.sock/v1.15/images/create?fromImage=hoge%3Alatest]]
[TIME[2014-10-31T07:14:24.200Z]]

[FIG(quote)[
[FIGCAPTION[
[46] [CITE[Module ngx_http_proxy_module]]
([TIME[2015-02-26 15:57:24 +09:00]] 版)
<http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass>
]FIGCAPTION]

> or as a UNIX-domain socket path specified after the word “unix” and enclosed in colons:
> proxy_pass http://unix:/tmp/backend.socket:/uri/;

]FIG]