[14] [DFN[[CODE(URI)@en[[[http:]]]]]] は、 [[HTTP]] over [[TCP]] によってアクセスできる[[資源]]を表す [[URL scheme]] です。 [121] [DFN[[CODE(URI)@en[[[https:]]]]]] は、 [[HTTP]] over [[TLS]]/[[SSL]] ([[HTTPS]]) によってアクセスできる[[資源]]を表す [[URL scheme]] です。 [66] 両者の総称を [DFN[HTTP(S) scheme]] といいます [SRC[>>67]]。 * 仕様書 [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]] 版) ''' - [445] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) - [34] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) - [51] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) - [67] [CITE@en[URL Standard]] ([TIME[2016-05-25 22:00:23 +09:00]]) ]REFS] * 意味 [19] [CODE(HTTP)@en[[[http:]]]] [[URL]] は、指定された [[host]]、[[port]] に [[HTTP]] over [[TCP]] で接続し、 [[path]] と [[query]] を [CODE(ABNF)@en[[[Request-URI]]]] として指定したときに得られる[[資源]]を識別しています。 [SRC[>>18, [[RFC 2616]] 正誤表, >>125]] ;; しかし [[Opportunistic Security for HTTP/2]] のように [[HTTPS]] を使う場合も (理論上は) あります。 [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]] のみによって[[プロトコルの版]]を特定・指定することはできません。 -*-*- [15] [[Semantic Web]] の世界では、実際には [[HTTP]] でアクセスしても存在していない[[資源]]や、 [[HTTP]] によって[[メタデータ]]が取得できるに過ぎない[[資源]]にも [CODE(URI)@en[[[http:]]]] [[URL]] が濫用されています。 ;; [139] [[Semantic Web]] の世界は [[RDF]] で表される世界内部の「意味」 は重視しますが、 [[HTTP]] や [[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]] では、 [[ポート]]がないか[[空]]であるときの[[既定のポート]]は [N[80]] です [SRC[>>18, >>125]]。 [136] [CODE(URI)@en[[[https:]]]] [[URL]] では、 [[ポート]]がないか[[空]]であるときの[[既定のポート]]は [N[443]] です [SRC[>>125]]。 [75] 利用される[[ポート番号]]については、[[HTTP接続]]の [[TCP]] の項を参照。 ** 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] [82] [[path]] が省略されている ([[空文字列]]である) 場合、 [[HTTP]] [[要求]]の [CODE(ABNF)@en[[[Request-URI]]]] としては「[CODE(URI)@en[[[/]]]]」を使わなければ[['''なりません''']] [SRC[>>18]]。 ;; [[URLの構文解析]]や[[要求対象]]も参照。 ** パスの階層化 [24] パスにはほとんど任意の文字列が認められるとはいえ、多くの場合は以降で述べる通り、 最後以外の[[パスセグメント]]を[[ディレクトリー]]などの階層、 最後の[[パスセグメント]]を[[ファイル]]など階層内のオブジェクトを表すものとして扱っています。 [[鯖]]が[[ファイルシステム]]に [[URL]] を対応付けていない場合であっても、 同様の仮想的な階層構造で[[パス]]を設計するのが一般的です。 [25] 次のものは、そのような一般的な階層構造を想定して作られていたり、 一般的な階層構造の場合に最も使いやすくなっていたりします。 [FIG(list middle)[ - [[相対URL]] - [[基本認証]]の[[保護空間]]の判別 ([[credentials]] 参照) - [[クッキー]]の [CODE(HTTP)@en[[[Path]]]] - [[隣接異体]] - [[WebDAV]] における名前空間モデル - [[サービスワーカー]]の[[適用範囲][適用範囲URL]]の指定 ([[ディレクトリーURL]]) 参照 - [[AppCache]] の適用範囲の制限 - [[HTML4]] [CODE(HTML)@en[]] ]FIG] [78] [[ディレクトリーURL]]も参照。 ** 階層区切り文字 [74] [[サービスワーカー]]の適用範囲の指定では、 [[パーセント符号化]]された [CODE[/]] や [CODE[\]] にあたる [CODE[%2F]] や [CODE[%5C]] が含まれている時、エラーとして扱います。 [[サーバー]]の不具合を突いた攻撃を防ぐためなのでしょう。 ;; [[登録開始]]参照。 [76] [[CGI]] を実装する[[サーバー]]によっては、 [CODE(CGI)@en[PATH_INFO]] に[[パーセント符号化]]された [CODE[/]] にあたる [CODE[%2F]] が含まれている時、エラーとして扱うことがあります。 ;; [CODE[PATH_INFO]] 参照。 -*-*- [156] [CITE[https://web.archive.org/web/20000925113303fw_/http://kahn.xj.cninfo.net/halmurat/uighurqae/index-uighurqae%20sol.html]], [TIME[2025-06-14T13:38:55.000Z]] > [PRE[ [SNIP[]][SNIP[]] ]PRE] ** ディレクトリーを表す path [107] [CODE(URI)@en[[[http:]]]] [[URL]] の [[path]] の末尾が [CODE(URI)[[[/]]]] で終わる場合、 [[ファイル・システム]]の類似の概念になぞらえて「[[ディレクトリー]]」や「[[フォルダー]]」 と呼ぶことがあります。 ;; 詳しくは[[ディレクトリーURL]]を参照。 ** 拡張子 [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] [57] [CODE[[[.cgi]]]] や [CODE[[[.asp]]]] や [CODE[[[.exe]]]] のように、 [[応答]]の種類をまったく表さず、専ら[[サーバー]]側で実行するべき処理の手段を表すもの ([[Apache]] では [CODE[[[AddHandler]]]] で使うもの) もよく用いられています。 ** 予約されている path [99] 次に述べる [[path]] は、 [CODE(URI)@en[[[http:]]]] および [CODE(URI)@en[[[https:]]]] で公式または非公式に予約されていて、特定の目的に使われます。 [FIG(middle list)[ [79] [DFN[特別な意味][特別なHTTP(S) URL]]を持つ [[HTTP(S) URL]] [[パス][URL path]] - [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[VAR[*]].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]]]] - [CODE(URI)@en[[[/ping]]]] - [CODE(URI)@en[[[/humans.txt]]]] - [CODE(URI)@en[[[/apis.[VAR[*]]]]]] - [CODE(URI)@en[/wpad.dat]] - [CODE(URI)@en[/BingSiteAuth.xml]] - [CODE(URI)@en[/apple-app-site-association]] - [CODE(URI)@en[/ads.txt]] - [CODE[/sellers.json]] - [CODE[/uri-res/]] - [CODE[/indexnow]] - [CODE[/search.cgi]] - [CODE[/llms.txt]] - [CODE[/[VAR[*]]/llms.txt]] - [CODE[/llms-full.txt]] - [CODE[/[VAR[*]]/llms-full.txt]] ]FIG] [144] 関連: [[特別なファイル名]] ** ホームディレクトリー [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)[~]] を使うのは好ましくないだとかいった議論がしばしばなされました。 -*-*- [145] [[平成時代]]中頃以後の [[Webサービス]]ではこれに変わって何も付けないスタイル、 つまり [CODE[http://service.example/[VAR[username]]/]] のような [[URL]] が流行しました。 [146] しかしこの方式は [VAR[username]] に任意の[[英数字]]が許されるとすると、 [[Webサービス]]の構成要素の頁の [[URL]]、 例えば [CODE[/accounts/]] や [CODE[/groups/]] や [CODE[/guide/]] のような [[URL path]] と衝突してしまうことになります。 [147] 事前にこの種の名前を予約したり、 新ページの追加時に既存の名前と衝突しないことを確認したりといった作業が必要になります。 [148] また、あたかも公式機能の一部分であるかのような偽装による[[フィッシング]]等に悪用されない機能設計が必須となります。 -*-*- [149] [[平成時代]]後期頃には >>146 の問題の対策として、 サービス側の機能は [CODE[https://service.example/-/[VAR[foo]]]] のように [DFN[[CODE[/-/]]]] から始めるスタイルが使われるケースがありました。 [150] 英語圏でも日本語圏でもいくつかのサービス等でこのような [[URL]] が使われることがありました。よく普及したというほどではありませんが、 それなりに広まり、現在でも稀に見られます。 [151] [CODE[/-/]] が意味不明である、サービスの機能の [[URL]] がわかりにくくなる、 などといった不評もあります。 -*-*- [152] [[令和時代]]に入って[[ハンドル (YouTube)]] のようにかつての [CODE[~]] の部分に [CODE[@]] を使う事例がでてきました。 [153] [CODE[@]] の利用は、 [CITE[Twitter]] の普及によって[[利用者アカウント]]の名前の先頭に [CODE[@]] を付けるスタイルに由来します。 [[ハンドル (YouTube)]] は単に [[URL]] に使われるだけでなく、サービス内での参照用の識別子にもなっているようです。 [154] [CITE[YouTube]] 以外のサービスも同様の [[URL]] を使う例が出て来ています。 一気に普及するというような勢いはありませんが、 今後もじわじわと広まるのかどうか注目されます。 ** [CODE(ABNF)@en[params]] [54] 過去の [[URL]] 仕様では、 [[path]] と [[params]] ([CODE[;]] から始まる[[引数]]列) が区別されていたこともありました。しかし [CODE(URI)@en[[[http:]]]]/[CODE(URI)@en[[[https:]]]] [[URL]] で実際に区別して扱われることは無いようです。 ** comma tools [55] [[W3C]] の [[Webサーバー]] では [[comma tools]] と称して、通常の [[URL]] の [[path]] の末尾に [CODE[,tools]] のような指定を加えて のようにすることで、 元の [[URL]] に対して便利ツールを呼び出すことができるように設定されていました。 [56] これは当該サーバーのみの独自のサーバー側の処理で、[[クライアント]]側で特別な扱いもされていませんでしたし、 何らかの標準化を試みたものでもなかったようです。 [[W3C]] 以外で同様の仕組みを実装した例はほとんどありません。 ** CGI と派生仕様におけるパス [120] [[スクリプトURL]]、[CODE[SCRIPT_NAME]], [CODE[PATH_INFO]], [CODE[PATH_TRANSLATED]] を参照。 ** 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]] [FIG(quote)[ [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]] 名前空間は、 [CODE(URI)[/]] 文字で区切られた階層のある階層名前空間です。 >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 で識別されることができます。 ]FIG] [40] [[コレクション]]に関する制約は、[[コレクション]]の項を参照。 ** 階層以外の利用例 [REFS[ - [41] [CITE@en[RFC 8040 - RESTCONF Protocol]] ([TIME[2017-03-27 23:03:09 +09:00]]) ]REFS] ** 非ASCII文字 [157] [CITE[Enciklopedinis kompiuterijos žodynas]], [TIME[2020-12-04T16:40:43.000Z]], [TIME[2025-10-25T08:36:58.011Z]] > [PRE[ ]PRE] [158] [CITE@lt[null]], [TIME[2020-11-04T11:32:03.000Z]], [TIME[2025-10-25T08:38:33.142Z]] [159] >>157 のリンク先が >>158。 ** 存在確認 [62] [[Webサイトの所有者の確認]]を参照。 ** 設計 [108] [[URL設計]]参照。 * query [58] [[query]] の構文と意味は [[HTTP]] 仕様としては規定されておらず、 解釈は[[サーバー]]に委ねられています。 [59] [[HTML]] では、[[フォームの提出]]などで使う [CODE(MIME)@en[[[application/x-www-form-urlencoded]]]] 形式の [[query]] が規定されています。しかしこれはあくまで[[フォーム]]などの [[HTML]] の機能を使って [[HTTP]] [[要求]]を生成する場合に限った規定であり、 [[リンク]]の [[URL]] などそれ以外の文脈では、[[サーバー]]が好きな構文と意味を採用できます。 ;; 詳細や実際の利用状況については [[query]] も参照。 * 素片識別子 [60] [[素片識別子]]の利用に関する制約は特にありません。[[応答]]として返される [[MIME型]]の規定に従い任意の[[素片識別子]]を利用できます。 ;; [[素片識別子]]も参照。 * 長さ [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:]]]] - [CODE(URI)@en[hxxp:]] ]FIG] [50] [[HTTP]] と関連が深いプロトコルである [[WebSocket]] は、次の [[URL scheme]] を使います。構文も非常によく似ています。 [FIG(short list)[ - [CODE(URI)@en[[[ws:]]]] - [CODE(URI)@en[[[wss:]]]] ]FIG] * 処理 ** フォーム提出 [11] [[フォームの提出]]を参照。 * 文脈 [61] [[HTTPにおけるURL]]を参照。 * 不思議解釈 [4] > RFC 2616 には HTTPプロトコルに関することが書かれており,3.2.2 http URL に書かれている http URL も,HTTPプロトコルの中での話になります.一般に,HTML のリンクに使用されるものは,純粋に HTTPプロトコルの中で使用される http URL ではなく, scheme が http であるURI References です. 出典: [CITE[Perlメモ]] (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]] 版) ** 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]] ** RFC 1738 の定義 [95] [CITE@en[RFC 1738 - Uniform Resource Locators (URL)]] ** RFC 1808 の定義 [116] [CITE@en[RFC 1808 - Relative Uniform Resource Locators]] ([TIME[2011-02-27 10:22:45 +09:00]] 版) [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]] - [93] [CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]] ** 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]] ]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]] 版) ]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]] 版)) ]REFS] ** Semantic Web 界での解釈 [5] [CITE[What do HTTP URIs Identify? - Design Issues]] ([[名無しさん]]) [6] [CITE[What do HTTP URIs Identify? - Design Issues]] ([[名無しさん]]) [7] [CITE[TAG Issues List]] ([[名無しさん]]) [8] [CITE@EN[URNs, Namespaces and Registries]] ([CODE[2006-09-01 17:51:46 +09:00]] 版) ** 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'' 正しくない [[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]] 版)) [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]] 版) ]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] [FIG(quote)[ [FIGCAPTION[ [53] ([TIME[2015-05-12 21:52:50 +09:00]] 版) ]FIGCAPTION] > HTTP-URL: URL with a fixed scheme of "http" or "https" ]FIG] [64] [CITE@en[Fix #244: improve HSTS language · whatwg/fetch@6568ab8]] ([TIME[2016-03-27 22:44:39 +09:00]] 版) [65] [CITE@en[Define HTTP(S) scheme for HTML]] ( ([[annevk]]著, [TIME[2016-05-25 22:00:17 +09:00]])) [68] [CITE@en[Use URL's HTTP(S) scheme concept and define rel=icon better]] ( ([[annevk]]著, [TIME[2016-05-26 21:59:00 +09:00]])) [69] [CITE@en-US[HTTPS and the Semantic Web/Linked Data | W3C Blog]] ( ([TIME[2016-05-27 23:40:07 +09:00]])) [70] [CITE@en[Editorial: use network and HTTP(S) scheme concepts]] ( ([[annevk]]著, [TIME[2016-05-30 21:46:40 +09:00]])) [71] [CITE@en[Non-HTTP(S) schemes are a network error during redirects]] ( ([[annevk]]著, [TIME[2016-05-30 22:19:04 +09:00]])) [63] [CITE@en[Editorial: move some terminology from the URL Standard here]] ([[annevk]]著, [TIME[2017-03-21 16:13:28 +09:00]]) [72] [CITE@en[Editorial: some terminology moved from the URL to Fetch Standard]] ([[annevk]]著, [TIME[2017-03-21 00:44:39 +09:00]]) [73] [CITE@en[Editorial: move some terminology to the Fetch Standard]] ([[annevk]]著, [TIME[2017-03-21 16:15:06 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [77] [CITE@en[Session URL :: WinSCP]] ( ([TIME[2017-03-26 04:30:05 +09:00]])) ]FIGCAPTION] > sftp|ftp|ftps|ftpes|http|https|scp :// '''[''' '''[''' : ''']''' '''[''' ; ''']''' @ ''']''' '''[''' : ''']''' / ]FIG] [84] [CITE@en[well-known-locations · Microformats Wiki]] ([TIME[2017-04-13 03:57:29 +09:00]]) [109] [CITE[Module ngx_http_core_module]] ([TIME[2017-05-26 20:36:59 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [137] [CITE[BitBake User Manual]] ([TIME[2017-11-20 17:21:42 +09:00]]) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [138] [CITE@en[Chromium Blog: A secure web is here to stay]] ([TIME[2018-02-09 05:10:27 +09:00]]) ]FIGCAPTION] > Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure”. ]FIG] [140] [CITE@en[RFC 8292 - Voluntary Application Server Identification (VAPID) for Web Push]] ([TIME[2018-12-23 23:07:53 +09:00]]) [141] [CITE@en[RFC 8292 - Voluntary Application Server Identification (VAPID) for Web Push]] ([TIME[2018-12-23 23:07:53 +09:00]]) [142] [CITE@ja[長谷みこと@ジェムカンさんはTwitterを使っています 「少し遅くなりましたが! #ミューコミプラス 出演させていただきありがとうございました! GEMSCOMPANYからよっぴーさんプロデュースユニット、Http: がもっと沢山の人に愛されるよう!ころん❤︎ #えいちてぃーてぃーぴーころん #ネットのかみさま #GEMSCOMPANY https://t.co/pEZAgwWXvb」 / Twitter]] ([TIME[2020-08-16 13:18:50 +09:00]]) [143] [CITE@ja[Skypeで特定の文字列を送受信するとクラッシュするバグが見つかり、修正版が公開される | スラド IT]], [TIME[2024-01-22T13:55:33.000Z]]