[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

しかし Opportunistic Security for HTTP/2 のように HTTPS を使う場合も (理論上は) あります。

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

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

[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 が濫用されています。

[139] Semantic Web の世界は RDF で表される世界内部の「意味」 は重視しますが、 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 ]

authority

登録名

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

IP アドレス

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

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

空文字列

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

port

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

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

[75] 利用されるポート番号については、HTTP接続の TCP の項を参照。

userinfo

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

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

[87] 旧仕様上は、 userinfo を使うことは認められていませんでした。 これは >>97 から RFC 2616 (>>86) までずっと変わっていませんでした。[98] 認められなかったというよりは、単に追加されなかっただけでしょうな。 初期の HTTP には認証が何も実装されていませんでしたから。

串における処理

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

パス

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

  1. *
    1. /
    2. パスセグメント

[82] path が省略されている (空文字列である) 場合、 HTTP 要求の Request-URI としては「/」を使わなければなりません >>18。

URLの構文解析や要求対象も参照。

パスの階層化

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

[25] 次のものは、そのような一般的な階層構造を想定して作られていたり、 一般的な階層構造の場合に最も使いやすくなっていたりします。

  • 相対URL
  • 基本認証の保護空間の判別 (credentials 参照)
  • クッキーの Path
  • 隣接異体
  • WebDAV における名前空間モデル
  • サービスワーカーの適用範囲適用範囲URLの指定 (ディレクトリーURL) 参照
  • AppCache の適用範囲の制限
  • HTML4 <applet codebase>

[78] ディレクトリーURLも参照。

階層区切り文字

[74] サービスワーカーの適用範囲の指定では、 パーセント符号化された / や \ にあたる %2F や %5C が含まれている時、エラーとして扱います。 サーバーの不具合を突いた攻撃を防ぐためなのでしょう。

登録開始参照。

[76] CGI を実装するサーバーによっては、 PATH_INFO にパーセント符号化された / にあたる %2F が含まれている時、エラーとして扱うことがあります。

PATH_INFO 参照。

[156] https://web.archive.org/web/20000925113303fw_/http://kahn.xj.cninfo.net/halmurat/uighurqae/index-uighurqae%20sol.html, https://web.archive.org/web/20000925113303fw_/http://kahn.xj.cninfo.net/halmurat/uighurqae/index-uighurqae%20sol.html

<img id="_x0000_i1087" src="/web/20000925113303im_/http://kahn.xj.cninfo.net/halmurat/uighurqae/vaerip001\001.gif" border="0" width="8" height="16">

ディレクトリーを表す path

[107] http: URL の path の末尾が / で終わる場合、 ファイル・システムの類似の概念になぞらえて「ディレクトリー」や「フォルダー」 と呼ぶことがあります。

詳しくはディレクトリーURLを参照。

拡張子

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

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

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

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

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

[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 で使うもの) もよく用いられています。

予約されている path

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

[79] 特別な意味特別なHTTP(S) URLを持つ HTTP(S) URL パスURL path
  • [100] /robots.txt
  • [101] /favicon.ico
  • [12] /.well-known/
  • /crossdomain.xml
  • /apple-touch-icon*.png
  • /rsd.xml
  • /search.cgi
  • /w3c/p3p.xml
  • /cgi-bin/
  • /clientaccesspolicy.xml
  • /ping
  • /humans.txt
  • /apis.*
  • /wpad.dat
  • /BingSiteAuth.xml
  • /apple-app-site-association
  • /ads.txt
  • /sellers.json
  • /uri-res/
  • /indexnow
  • /search.cgi
  • /llms.txt
  • /*/llms.txt
  • /llms-full.txt
  • /*/llms-full.txt

[144] 関連: 特別なファイル名

ホームディレクトリー

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

[145] 平成時代中頃以後の Webサービスではこれに変わって何も付けないスタイル、 つまり http://service.example/username/ のような URL が流行しました。

[146] しかしこの方式は username に任意の英数字が許されるとすると、 Webサービスの構成要素の頁の URL、 例えば /accounts/ や /groups/ や /guide/ のような URL path と衝突してしまうことになります。

[147] 事前にこの種の名前を予約したり、 新ページの追加時に既存の名前と衝突しないことを確認したりといった作業が必要になります。

[148] また、あたかも公式機能の一部分であるかのような偽装によるフィッシング等に悪用されない機能設計が必須となります。

[149] 平成時代後期頃には >>146 の問題の対策として、 サービス側の機能は https://service.example/-/foo のように /-/ から始めるスタイルが使われるケースがありました。

[150] 英語圏でも日本語圏でもいくつかのサービス等でこのような URL が使われることがありました。よく普及したというほどではありませんが、 それなりに広まり、現在でも稀に見られます。

[151] /-/ が意味不明である、サービスの機能の URL がわかりにくくなる、 などといった不評もあります。

[152] 令和時代に入ってハンドル (YouTube) のようにかつての ~ の部分に @ を使う事例がでてきました。

[153] @ の利用は、 Twitter の普及によって利用者アカウントの名前の先頭に @ を付けるスタイルに由来します。 ハンドル (YouTube) は単に URL に使われるだけでなく、サービス内での参照用の識別子にもなっているようです。

[154] YouTube 以外のサービスも同様の URL を使う例が出て来ています。 一気に普及するというような勢いはありませんが、 今後もじわじわと広まるのかどうか注目されます。

params

[54] 過去の URL 仕様では、 path と params (; から始まる引数列) が区別されていたこともありました。しかし http:/https: URL で実際に区別して扱われることは無いようです。

comma tools

[55] W3C の Webサーバー http://www.w3.org/ では comma tools と称して、通常の URL の path の末尾に ,tools のような指定を加えて http://www.w3.org/,tools のようにすることで、 元の URL に対して便利ツールを呼び出すことができるように設定されていました。

[56] これは当該サーバーのみの独自のサーバー側の処理で、クライアント側で特別な扱いもされていませんでしたし、 何らかの標準化を試みたものでもなかったようです。 W3C 以外で同様の仕組みを実装した例はほとんどありません。

CGI と派生仕様におけるパス

[120] スクリプトURL、SCRIPT_NAME, PATH_INFO, PATH_TRANSLATED を参照。

WebDAV における制約

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

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

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

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

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

[155] RFC 2518 (WebDAV) 5.1 HTTP URL Namespace Model

The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.

HTTP URL 名前空間は、 / 文字で区切られた階層のある階層名前空間です。

An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member. The root, or top-level collection of the namespace under consideration is exempt from the previous rule.

ある HTTP URL が次の条件を満たす時、一貫しているといいます: その HTTP 階層中の各 URL について、その URI を内部 member として含んでいる collection があること。 件の名前空間の根 (最上位) collection は先の規則からは除外します。

Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL namespace be consistent. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies.

HTTP/1.1 も WebDAV も、全 HTTP URL 名前空間が一貫していることは要求していません。 しかし、名前空間非一貫をもたらすことを禁じている WebDAV method があります。

Although implicit in [RFC2068] and [RFC2396], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.

RFC2068 及び RFC2396 が暗示していますが、 collection 資源を含めて、 すべての資源は複数の URL で識別されてもかまいません。 たとえば、ある資源は複数の HTTP URL で識別されることができます。

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

階層以外の利用例

  • [41] RFC 8040 - RESTCONF Protocol () https://tools.ietf.org/html/rfc8040#section-3.5.3

非ASCII文字

[157] Enciklopedinis kompiuterijos žodynas, , http://www.ims.mii.lt/EK%C5%BD/enciklo.html

<frame src="a/abėcėlė.html" name='fc' scrolling="auto" noresize onload='istorija();'>

[158] null, , http://www.ims.mii.lt/EK%C5%BD/a/ab%C4%97c%C4%97l%C4%97.html

[159] >>157 のリンク先が >>158。

存在確認

[62] Webサイトの所有者の確認を参照。

設計

[108] URL設計参照。

query

[58] query の構文と意味は HTTP 仕様としては規定されておらず、 解釈はサーバーに委ねられています。

[59] HTML では、フォームの提出などで使う application/x-www-form-urlencoded 形式の query が規定されています。しかしこれはあくまでフォームなどの HTML の機能を使って HTTP 要求を生成する場合に限った規定であり、 リンクの URL などそれ以外の文脈では、サーバーが好きな構文と意味を採用できます。

詳細や実際の利用状況については query も参照。

素片識別子

[60] 素片識別子の利用に関する制約は特にありません。応答として返される MIME型の規定に従い任意の素片識別子を利用できます。

素片識別子も参照。

長さ

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

比較と正規化

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

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

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

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

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

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

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

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

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

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

URL scheme のバリエーション

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

[48] 例えば次のようなものがあります。

[49] 掲示板等では URL の自動リンクを回避するため、敢えて URL scheme の一部を省略したり、書き換えたりすることがあります。

[50] HTTP と関連が深いプロトコルである WebSocket は、次の URL scheme を使います。構文も非常によく似ています。

処理

フォーム提出

[11] フォームの提出を参照。

文脈

[61] HTTPにおけるURLを参照。

不思議解釈

[4]

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

RFC 1630 の定義

[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

RFC 1738 の定義

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

RFC 1808 の定義

[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 のための区切子として扱われているので、 その意味で扱うべきという見解だったのでしょう。

RFC 1945、RFC 2068 の定義

[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 のオクテット (つまり任意のオクテット) が認められていたりしました。 その理由としては、鯖は文字の制約に縛られていないこと、 串はどのみち受け入れるしかないことが挙げられていました。

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

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

仕様書

  • [90] RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 http://tools.ietf.org/html/rfc1945#section-3.2.2
  • [93] 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 では、 national を認めていた独自の定義は削除され、 RFC 2396 に定義を委ねる形になっています。

[86] 

   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
  • [18] RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 http://tools.ietf.org/html/rfc2616#section-3.2.2

RFC 2817

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

[119] 実際にはこれは利用されておらず、 Upgrade: を使わない https: がもっぱら利用されています。
  • [122] RFC 2817 - Upgrading to TLS Within HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2817#section-8.1
8.1 Implications for the https: URI Scheme

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'.

RFC 2818

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

[45] https: URL scheme は SSL/2.0 以来使われていましたが、仕様書として明文化されたのはこの時が初めてと思われます。
  • [123] RFC 2818 - HTTP Over TLS ( ( 版)) http://tools.ietf.org/html/rfc2818

Semantic Web 界での解釈

[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

RFC 5785

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

RFC 7230

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

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

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

[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

[46] 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/;

[53] ( 版) http://www.etsi.org/deliver/etsi_ts/103200_103299/103285/01.01.01_60/ts_103285v010101p.pdf

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

[77] Session URL :: WinSCP ( ()) https://winscp.net/eng/docs/session_url

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

[137] BitBake User Manual () http://www.yoctoproject.org/docs/2.4/bitbake-user-manual/bitbake-user-manual.html#http-ftp-fetcher

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.

[138] Chromium Blog: A secure web is here to stay () https://blog.chromium.org/2018/02/a-secure-web-is-here-to-stay.html

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/