[14] http: は、 HTTP over TCP
によってアクセスできる資源を表す URL scheme です。
[121] https: は、 HTTP over TLS/SSL
(HTTPS) によってアクセスできる資源を表す URL scheme です。
[66] 両者の総称を HTTP(S) scheme といいます >>67。
[19] http: URL は、指定された host、port に HTTP over TCP
で接続し、 path と query を Request-URI として指定したときに得られる資源を識別しています。
>>18, RFC 2616 正誤表, >>125
[133] https: URL は、指定された host、port に HTTP
over TLS over TCP
で接続し、 path と query を Request-URI として指定したときに得られる資源を識別しています。
>>125
[444] 両者は異なる名前空間、起源鯖を表すものですから、 たとえホストとポートが同じであっても、 path や query によって識別される資源が共通であるとは限りません >>125。
[52] HTTP/0.9、HTTP/1.0、HTTP/1.1 >>125、HTTP/2 >>51
のいずれも http:/https: URL scheme
を使います。 URL のみによってプロトコルの版を特定・指定することはできません。
[15] Semantic Web の世界では、実際には HTTP でアクセスしても存在していない資源や、
HTTP によってメタデータが取得できるに過ぎない資源にも http: URL
が濫用されています。
[127] RFC 7230 は、 RFC 3986 に基づき http: URI scheme
の構文を次のように定義しています >>125。
http-URI = "http:" "//" authority path-abempty [ "?" query ] [ "#" fragment ]
[135] RFC 7230 は、 RFC 3986 に基づき https: URI scheme
の構文を次のように定義しています >>125。
https-URI = "https:" "//" authority path-abempty [ "?" query ] [ "#" fragment ]
[130] host が登録名であれば、これは DNS などの名前解決サービスによって起源鯖のアドレスを探すための間接識別子です。 >>125
[129] host がIPアドレスであれば、起源鯖がそのIPアドレスで TCP を listen しているかもしれないことを表しています。 >>125
[128] 送信者は空の host を生成してはなりません。 受信者は非妥当であるとして拒絶しなければなりません。 >>125
[20] http: URL では、
ポートがないか空であるときの既定のポートは 80 です >>18, >>125。
[131] 構文上 userinfo も利用できます。実装によっては userinfo を認証情報として使います >>125。
[132] しかし送信者は要求対象やヘッダーの値として含まれる
http:/https: URL において
userinfo を生成してはなりません >>125。
[83] 串は、ホスト名が FQDN でなければ、ホスト名を追加して構いません。 FQDN は書き換えてはなりません。 >>18
[23] パスは鯖によって解釈されます。パスは
/ とパスセグメントを繰り返したものと定義されてはいますが、
前後の区切り文字やパーセント符号化を除けば事実上任意の文字列を使うことができます。
[82] path が省略されている (空文字列である) 場合、 HTTP 要求の Request-URI
としては「/」を使わなければなりません >>18。
[24] パスにはほとんど任意の文字列が認められるとはいえ、多くの場合は以降で述べる通り、 最後以外のパスセグメントをディレクトリーなどの階層、 最後のパスセグメントをファイルなど階層内のオブジェクトを表すものとして扱っています。 鯖がファイルシステムに URL を対応付けていない場合であっても、 同様の仮想的な階層構造でパスを設計するのが一般的です。
[25] 次のものは、そのような一般的な階層構造を想定して作られていたり、 一般的な階層構造の場合に最も使いやすくなっていたりします。
Path<applet codebase>[78] ディレクトリーURLも参照。
[74] サービスワーカーの適用範囲の指定では、
パーセント符号化された / や \ にあたる %2F
や %5C が含まれている時、エラーとして扱います。
サーバーの不具合を突いた攻撃を防ぐためなのでしょう。
[76] CGI を実装するサーバーによっては、 PATH_INFO
にパーセント符号化された / にあたる %2F
が含まれている時、エラーとして扱うことがあります。
PATH_INFO 参照。[107] http: URL の path の末尾が / で終わる場合、
ファイル・システムの類似の概念になぞらえて「ディレクトリー」や「フォルダー」
と呼ぶことがあります。
[110] http: URL の path の末尾が .
と数文字の英数字で終わる場合、ファイル・システムの類似の概念になぞらえて「拡張子」
と呼ぶことがあります。 URL の仕様上も HTTP でも「拡張子」
という概念は存在しませんが、 http: URL の path
をファイル・システムの path に対応付けることがしばしばあるため、
慣用的に用いられています。
[111] HTTP の仕様上は不透明な path の一部でありプロトコル上やクライアントの動作には影響しないはずですが、
便宜上、利用者エージェントの一部の動作に影響することがあります。例えば、
http: URL の拡張子が画像を表すものかどうかによって挙動が変わることがあります。
Content-Type
を見て挙動を変えるのが適切なのでしょうが、 URL だけを見て、
ネットワーク・アクセスを発生させずに挙動を決定するには拡張子が便利なので、
しばしば用いられるのです。[113] 拡張子は、 HTTP 鯖において HTTP
実体頭欄を決定したり、内容折衝を行ったりする際の情報として利用されることがあります。
例えば Apache の mod_mime は、 AddType や
AddCharset などの指令によって決まる拡張子とMIME型などの対応情報に基づき、
Content-Type 頭欄などを決定したり、内容折衝を行ったりします。
[114] 内容折衝などを活用することにより HTTP や http: URL
を (表現より一段抽象化された) 資源として捉えることを好む人達は、
URL に拡張子が含まれることは好ましくないと考えています。
拡張子を含めなければ、 GIF と PNG の2種類が鯖に用意されているときに、
クライアントが送ってきた Accept:
頭欄を見てどちらか適切な方を返すことができるからです。
[115] 実際に Apache ではファイル・システム上の拡張子付きのファイルに対して拡張子を除去した URL を使ってアクセスして内容折衝を行わせることができます。
[10] MIME型の他、言語などを表す拡張子を組み合わせて Apache
の AddType や AddLanguage などに対応づけることがあります。
[21] 例えば URL path /document.ja.html.utf-8 によって
Content-Language: ja,
Content-Type: text/html; charset=utf-8
を生成するように設定されていることがあります。
[57] .cgi や .asp や .exe のように、
応答の種類をまったく表さず、専らサーバー側で実行するべき処理の手段を表すもの
(Apache では AddHandler で使うもの) もよく用いられています。
[99] 次に述べる path は、 http: および https:
で公式または非公式に予約されていて、特定の目的に使われます。
[102] http://host/~username/path のような URL
は、利用者 username に割り当てられた領域を意味するものとして使う慣習があります。
host は通常は ISP や大学などの所有するドメイン名であり、
会員や教員・学生に Web 公開用の領域として割り当てています。
[103] ~ は、 Unix でホームディレクトリーを表す記号として用いられていて、
それをそのまま URL として使っているものと推測されます。
[104] Apache などの普及している
HTTP 鯖の既定の設定においては、 /~username/
はファイルシステム上の ~username/public_html/
に対応します。
[105] 近年では組織が構成員に Web 用の領域を割り当て、 そこを使って Webサイトを公開することが少なくなってきたので、 この形式の URL を見ることも減ってきました。
[106] なお、 ~ は古い RFC では使用が認められておらず、
%7E と百分率符号化しなければならなかったにも関わらず、
この慣習は広く行われており、 ~ をそのまま使った URL
も昔からよく見かけました。結局 ~ は仕様上も追認されることになるのですが、
それまでは %7E と書くべきだとか、そもそも ~
を使うのは好ましくないだとかいった議論がしばしばなされました。
params[54] 過去の URL 仕様では、 path と params (; から始まる引数列)
が区別されていたこともありました。しかし http:/https:
URL で実際に区別して扱われることは無いようです。
[55] W3C の Webサーバー http://www.w3.org/ では comma tools
と称して、通常の URL の path の末尾に ,tools のような指定を加えて
http://www.w3.org/,tools のようにすることで、
元の URL に対して便利ツールを呼び出すことができるように設定されていました。
[56] これは当該サーバーのみの独自のサーバー側の処理で、クライアント側で特別な扱いもされていませんでしたし、 何らかの標準化を試みたものでもなかったようです。 W3C 以外で同様の仕組みを実装した例はほとんどありません。
[35] WebDAV に適合する資源は、次の「HTTP URL 名前空間モデル」 に対応しなければなりません >>34。
[36] HTTP URL 名前空間は、 / を階層区切り文字とする階層化された名前空間です >>34。
[37] HTTP URL 名前空間は、 HTTP 階層中のすべてのURL について、 その URL を内部メンバーURLとして含むコレクションが存在するなら、 一貫しているといいます。 ただし、対象となる名前空間の根 (最上位コレクション) を除きます。 >>34
[39] HTTP URL 名前空間の全体が一貫していることは要求されていません。 従って WebDAV に適合する資源であっても親となるコレクションが存在しないこともあります。 しかし、いくつかの WebDAV のメソッドは、 名前空間が一貫しなくなるような操作を禁止しています。 >>34
[62] Webサイトの所有者の確認を参照。
[58] query の構文と意味は HTTP 仕様としては規定されておらず、 解釈はサーバーに委ねられています。
[59] HTML では、フォームの提出などで使う application/x-www-form-urlencoded
形式の query が規定されています。しかしこれはあくまでフォームなどの
HTML の機能を使って HTTP 要求を生成する場合に限った規定であり、
リンクの URL などそれ以外の文脈では、サーバーが好きな構文と意味を採用できます。
[60] 素片識別子の利用に関する制約は特にありません。応答として返される MIME型の規定に従い任意の素片識別子を利用できます。
[92] HTTPにおけるURLの比較を参照してください。
[26] http: URL を (Webページにアクセスするためのアドレスではなく)
何らかの概念を指す識別子として使うことを好む人がいます。
[28] URL を識別子として使うことを好む人の中には
URN や XRI などを好む人もいますが、 http:
を好む人は、それらは名前空間文書へのアクセス手段に乏しいため好ましくないと主張しているようです。
[30] 識別子として使われる HTTP URL は、 (>>28 のような主張の期待に背いて)
HTTP でアクセスしても適切な文書が存在しないことがよくあります。
定義された瞬間は存在しても、その後メンテナンスがなされなくなり
404 になる、というのは良い方で、
最初から存在しなかったり、そもそもHTTP鯖が存在しなかったりすることも珍しくはありません。
[32] アクセスが可能でも、リダイレクトされて他の URL で何らかの文書やスキーマが提供されていることもよくあります。 これは名前空間URLをコピペするときに誤った値にしてしまう要因の一つとなっています。
[33] HTML名前空間 http://www.w3.org/1999/xhtml
にアクセスすると http://www.w3.org/1999/xhtml/
にリダイレクトされるので、後者の URL を使う人もいますが、
正しくありません。
[47] HTTP や HTTPS の http: や https:
のような本来の URL scheme の他に、 HTTP 上で動作するプロトコルや HTTP
を利用するアプリケーションは、そのプロトコルやアプリケーションに適用範囲が限定される以外は
http: や https: と変わらない URL scheme
を使っていることがあります。
[48] 例えば次のようなものがあります。
[49] 掲示板等では URL の自動リンクを回避するため、敢えて
URL scheme の一部を省略したり、書き換えたりすることがあります。
[50] HTTP と関連が深いプロトコルである WebSocket は、次の URL scheme
を使います。構文も非常によく似ています。
[61] HTTPにおけるURLを参照。
RFC 2616 には HTTPプロトコルに関することが書かれており,3.2.2 http URL に書かれている http URL も,HTTPプロトコルの中での話になります.一般に,HTML のリンクに使用されるものは,純粋に HTTPプロトコルの中で使用される http URL ではなく, scheme が http であるURI References です.
出典: Perlメモ http://www.din.or.jp/%7Eohzaki/perl.htm#httpURL (2005年3月現在)
このような解釈は正しくありません。 IANA
の URI scheme 登録簿に拠れば http:
URI scheme の出典は RFC 2616 であり、 IETF
的に有効な 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 で許されないものは、すべて認められません。
(ftp: URI に関する部分にも同様の指摘ができます。
ただし ftp: URI scheme の仕様は未だにいにしえの
RFC 1738 のままで、実装とまったく整合していません。)
[126] http: は、最古の URL scheme の一つで、 WWW
と共に誕生しました。
[97] HTTPAddressing -- /Addressing ( 版) http://www.w3.org/History/19921103-hypertext/hypertext/WWW/Addressing/HTTPAddressing.html
[96] 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
[95] RFC 1738 - Uniform Resource Locators (URL) http://tools.ietf.org/html/rfc1738#section-3.3
[116] RFC 1808 - Relative Uniform Resource Locators ( 版) http://tools.ietf.org/html/rfc1808#section-2.3
[117] RFC 1808 は、「Note」の中で、 RFC 1738 は http: URL
の中で普通に ; を認めていたけどその意味は明記しておらず、
RFC 1808 ではそれをちゃんと定義してる、と述べています。その意味というのがどういうことなのか実は不明確ですがw、
URI の一般的な構文における params のための区切子として扱われているので、
その意味で扱うべきという見解だったのでしょう。
[2] http: URL は HTTP/1.0、HTTP/1.1 の仕様の一部として
RFC 1945 3.2 >>90、RFC 2068 3.2 で規定されました。
[88] この仕様は当時の URL の正式な規定であるところの RFC 1738 や RFC 1808
に意図的違反していました。具体的には、本来 URL では使えないはずの national
のオクテット (つまり任意のオクテット) が認められていたりしました。
その理由としては、鯖は文字の制約に縛られていないこと、
串はどのみち受け入れるしかないことが挙げられていました。
[89]
なんかこの ABNF 構文破綻してる気がしますが。。。
例えば segment = 2068.segment - "/"
と定義しておかないと欲張り過ぎるんじゃ?
[85] RFC 2068 の改訂である RFC 2616 では、 national
を認めていた独自の定義は削除され、 RFC 2396 に定義を委ねる形になっています。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
[118] RFC 2817 は、 Upgrade: による TLS/1.0
への切り替えを使う場合にも http: URL
(https: でなく。) を使うことを提案していました。
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'.
[44] RFC 2818 (HTTPS) では、 http: のかわりに
https: を URL scheme として使う >>123 と規定がありました。
[5] What do HTTP URIs Identify? - Design Issues http://www.w3.org/DesignIssues/HTTP-URI (名無しさん)
[6] What do HTTP URIs Identify? - Design Issues http://www.w3.org/DesignIssues/HTTP-URI2.html (名無しさん)
[7] TAG Issues List http://www.w3.org/2001/tag/issues.html?type=1#httpRange-14 (名無しさん)
[8]
URNs, Namespaces and Registries (2006-09-01 17:51:46 +09:00 版) http://www.w3.org/2001/tag/doc/URNsAndRegistries-50-2006-08-17.html
[42] RFC 5785 は /.well-known/ を定義しており、そのために
http: の RFC 2616 と https:
の RFC 2818 を更新しています。
[446] HTTP の改訂版である RFC 7230 は、従来 RFC 2616 で定義されていた
http: に加えて、 HTTPS の RFC である RFC 2818 に含まれていた
https: をも定義しています。
[447] IANA登録簿の登録も、更新されています >>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] http:/https: に非常によく似た URL scheme として、
SHTTP を表す shttp: があります。
[17] Web の掲示板などでは、 http: URL を検知して自動的にハイパーリンクとして解釈する機能が適用されることを防ぐため、
ttp:、tp:、p:
といった URL scheme を用いたり、 URL scheme を省略して :
から始めたり、 「http」の一部又は全部を全角で表記したりすることがあります。
[13] HTTPにおけるURLの項もご覧ください。
[124] IRC logs: freenode / #whatwg / 20110808 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20110808#l-1235
[22] Docker は次のような URL を使っているようです:
http:///var/run/docker.sock/v1.15/images/create?fromImage=hoge%3Alatest
or as a UNIX-domain socket path specified after the word “unix” and enclosed in colons:
proxy_pass http://unix:/tmp/backend.socket:/uri/;
HTTP-URL: URL with a fixed scheme of "http" or "https"
[64] Fix #244: improve HSTS language · whatwg/fetch@6568ab8 ( 版) https://github.com/whatwg/fetch/commit/6568ab88c1fbfb581f63f8e5f020c367ef38e78d
[65] Define HTTP(S) scheme for HTML ( (annevk著, )) https://github.com/whatwg/url/commit/08f9d3924f64cecf04746c926ac05c2429c5fe87
[68] Use URL's HTTP(S) scheme concept and define rel=icon better ( (annevk著, )) https://github.com/whatwg/html/commit/a932f7dfd5e50101db47a373cee27b04ed108934
[69] HTTPS and the Semantic Web/Linked Data | W3C Blog ( ()) https://www.w3.org/blog/2016/05/https-and-the-semantic-weblinked-data/
[70] Editorial: use network and HTTP(S) scheme concepts ( (annevk著, )) https://github.com/whatwg/fetch/commit/a7e7af28629938544d1b705225d04776261a2ff4
[71] Non-HTTP(S) schemes are a network error during redirects ( (annevk著, )) https://github.com/whatwg/fetch/commit/9b75908a1e6f6f520a77b8b420015a61fb5d8512
[63] Editorial: move some terminology from the URL Standard here (annevk著, ) https://github.com/whatwg/fetch/commit/1d76b020ef8e90d1a021c70202060f8b27c29cd9
[72] Editorial: some terminology moved from the URL to Fetch Standard (annevk著, ) https://github.com/whatwg/html/commit/1308ec083b999df9ead67a2066e7e260fefae0e8
[73] Editorial: move some terminology to the Fetch Standard (annevk著, ) https://github.com/whatwg/url/commit/8fb8684a19b449db4c8920aee6cd3efb41bcdcfd
sftp|ftp|ftps|ftpes|http|https|scp :// [ <username> [ : <password> ] [ ; <fingerprint> ] @ ] <host> [ : <port> ] /
[84] well-known-locations · Microformats Wiki () http://microformats.org/wiki/well-known-locations
[109] Module ngx_http_core_module () http://nginx.org/en/docs/http/ngx_http_core_module.html#merge_slashes
The fetcher supports a parameter "downloadfilename" that allows the name of the downloaded file to be specified. Specifying the name of the downloaded file is useful for avoiding collisions in DL_DIR when dealing with multiple files that have the same name.
Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure”.
[140] RFC 8292 - Voluntary Application Server Identification (VAPID) for Web Push () https://tools.ietf.org/html/rfc8292#section-2.1
[141] RFC 8292 - Voluntary Application Server Identification (VAPID) for Web Push () https://tools.ietf.org/html/rfc8292#section-2.1
[142] 長谷みこと@ジェムカンさんはTwitterを使っています 「少し遅くなりましたが! #ミューコミプラス 出演させていただきありがとうございました! GEMSCOMPANYからよっぴーさんプロデュースユニット、Http: がもっと沢山の人に愛されるよう!ころん❤︎ #えいちてぃーてぃーぴーころん #ネットのかみさま #GEMSCOMPANY https://t.co/pEZAgwWXvb」 / Twitter () https://twitter.com/hasemikoto/status/1239451171154055173
[143] Skypeで特定の文字列を送受信するとクラッシュするバグが見つかり、修正版が公開される | スラド IT, https://it.srad.jp/story/15/06/05/226230/