Loading article…
既知の URIは、 で始まるURLパス プレフィックスのUniform Resource Identifierです。これらは Web サーバーに実装されており、既知のサービスまたは情報を求めるサーバーへのリクエストが、サーバー間で一貫した既知の場所の URL で利用できるようになります。
/.well-known/
説明
既知の URI は、IETFによってRFC 8615で定義されているUniform Resource Identifiersです。 [1]これらは、で始まるURLパス プレフィックスです。この実装は、Web ベースのプロトコルでは、特定のサービスまたは情報が、特定のホストで URL パスがどのように構成されているかに関係なく、サーバー間で一貫した URL で利用できることを要求するという一般的な期待に応えています。URI は、Web サーバーで実装されているため、既知のサービスまたは情報に対するサーバーへの要求は、サーバー間でよく知られている場所の一貫した URL で利用できます。
/.well-known/
IETFは、Web サーバーが任意のユーザー エージェント( Web ブラウザーなど) が要求できるメタデータを保持するための簡単な方法を定義しました。メタデータは、Web ユーザーに Web サイトではなくモバイル アプリを使用するように指示したり、サイトを保護するさまざまな方法を示したりなど、さまざまなタスクに役立ちます。既知の場所は、Web サーバーがユーザー エージェントとメタデータを共有するために使用します。これらはファイルである場合もあれば、Web サーバー ソフトウェア自体からの情報の要求である場合もあります。提供できるさまざまなメタデータ要求を宣言する方法は、他の開発者がこの情報を見つけて使用する方法を知ることができるように、IETF によって標準化されています。
使用
パスの既知の URI は、文字 で始まり/.well-known/、そのスキームは「HTTP」、「HTTPS」、または既知の URI を使用するように明示的に指定された別のスキームです。たとえば、アプリケーションがサービス「example」をホストしている場合、対応する の既知の URI はhttps://www.example.com/で始まりますhttps://www.example.com/.well-known/example。[1]
よく知られたサービスとして Web サイトによって共有される情報は、特定の標準を満たすことが期待されます。このようなサイト全体のメタデータのリソースを定義する必要がある仕様は、衝突を回避し、サイトの URI スペースへの影響を最小限に抑えるために、その使用をInternet Assigned Numbers Authority (IANA) に登録できます。
よく知られている URI のリスト
以下のリストは、Web サーバーが実装できる .well-known サービスの既知の標準を示しています。
参考文献
- 「Well-Known URI」。IANA。2018年2月8日時点のオリジナルよりアーカイブ。2018年2月6日閲覧。
脚注
- ^ ab Nottingham, Mark (2019年5月6日). よく知られているUniform Resource Identifiers (URI). IETF . doi : 10.17487/RFC8615 . RFC 8615.
- ^ Barnes, Richard; Hoffman-Andrews, Jacob; McCarney, Daniel; Kasten, James (2019 年 3 月 6 日). Automatic Certificate Management Environment (ACME). IETF . doi : 10.17487/RFC8555 . RFC 8555.
- ^ 「Getting Started - OpenAI API」。platform.openai.com 。 2023年3月25日時点のオリジナルよりアーカイブ。2023年3月25日閲覧。
- ^ 「App Search プログラミング ガイド: ユニバーサル リンクのサポート」。developer.apple.com。2016年 3 月 31 日時点のオリジナルよりアーカイブ。2016 年 8 月 13 日閲覧。
- ^ 「Apple Developer Documentation」。developer.apple.com。2016年9月20日時点のオリジナルよりアーカイブ。2016年8月13日閲覧。
- ^ 「標準 135-2012 の提案された補遺、BACnet - ビル自動化および制御ネットワーク用データ通信プロトコル」(PDF)。2018 年 5 月 8 日のオリジナル(PDF)からアーカイブ。2018 年 2 月 7 日に取得。
- ^ 「Getting Started | Google Digital Asset Links」。Google Developers。2016年 11 月 5 日時点のオリジナルよりアーカイブ。2016 年 8 月 13 日閲覧。
- ^ “Handle | AT Protocol”. atproto.com . 2024年2月16日時点のオリジナルよりアーカイブ。2024年2月16日閲覧。
- ^ “Thunderbird:自動設定 - MozillaWiki”. 2021年7月30日時点のオリジナルよりアーカイブ。2021年7月30日閲覧。
- ^ ab Daboo, Cyrus (2013 年 2 月 6 日). WebDAV のカレンダー拡張機能 (CalDAV) および WebDAV の vCard 拡張機能 (CardDAV) のサービスの検索. IETF . doi : 10.17487/RFC6764 . RFC 6764.
- ^ 「パスワードを変更するためのよく知られた URL」w3c.github.io。 2022 年 4 月 21 日時点のオリジナルよりアーカイブ。2022 年2 月 6 日閲覧。
- ^ Bormann, Carsten; Lemay, Simon; Tschofenig , Hannes; Hartke, Klaus; Silverajan, Bill; Raymor, Brian (2018 年 2 月 6 日)。TCP、TLS、および WebSocket 上の CoAP (制約付きアプリケーション プロトコル) 。IETF。doi : 10.17487 / RFC8323。RFC 8323 。
- ^ 「ユーザーが個人用デバイスを登録する方法」。support.apple.com。2024年8月15日時点のオリジナルよりアーカイブ。2022年4月23日閲覧。
- ^ 「認証サーバーの検出」。developer.apple.com 。 2024年8月15日時点のオリジナルよりアーカイブ。2022年4月23日閲覧。
- ^ Shelby, Zach (2012 年 8 月 6 日). 制約付き RESTful 環境 (CoRE) リンク形式. IETF . doi : 10.17487/RFC6690 . RFC 6690.
- ^ 「Web上の表形式データとメタデータのモデル」www.w3.org。2015年12月17日。2024年8月15日時点のオリジナルよりアーカイブ。2021年10月6日閲覧。
- ^ 「dat:// でドメイン名を使用する」。beakerbrowser.com。2020年1月14日時点のオリジナルよりアーカイブ。2020年8月24日閲覧。
- ^ "DEP-0005: DNS - Dat プロトコル". www.datprotocol.com。
- ^ “advaith (@advaith@mastodon.social)”. Mastodon . 2023-07-17. 2024-08-15時点のオリジナルよりアーカイブ。 2023-08-29閲覧。
- ^ 「Tracking Preference Expression (DNT)」www.w3.org。 2024年8月15日時点のオリジナルよりアーカイブ。2021年10月6日閲覧。
- ^ 「プライバシーに配慮したDo Not Track（DNT）ポリシー」。電子フロンティア財団。2014年4月24日。2021年5月11日時点のオリジナルよりアーカイブ。 2018年2月7日閲覧。
- ^ Pritikin , Max; Yee, Peter E.; Harkins, Dan (2013 年 10 月 6 日) 。Enrollment over Secure Transport。IETF。doi : 10.17487 / RFC7030。RFC 7030 。
- ^ 「RDF 1.1 概念と抽象構文」www.w3.org。2024年8月15日時点のオリジナルよりアーカイブ。2021年10月6日閲覧。
- ^ 「グローバルプライバシーコントロール（GPC）」。グローバルプライバシーコントロール（GPC） - 2024年3月22日の提案。2024年6月13日時点のオリジナルよりアーカイブ。2024年6月13日閲覧。
- ^ Farrell, Stephen; Hoffman, Paul E.; Thomas, Michael (2015 年 3 月 6 日)。「HOBA プロセスのその他の部分」。HTTP Origin-Bound Authentication (HOBA) 。IETF。sec . 6。doi : 10.17487 / RFC7486。RFC 7486 。
- ^ ab Cook, Blaine; Hammer-Lahav, Eran (2011 年 10 月 6 日). Hammer-Lahav, E (ed.). Web ホスト メタデータ. IETF . doi : 10.17487/RFC6415 . RFC 6415.
- ^ Nottingham, Mark ; Thomson, Martin (2017 年 5 月 6 日)。「「http-opportunistic」Well-Known URI」。HTTP/2 の Opportunistic Security。IETF。sec . 2.3。doi : 10.17487/ RFC8164。RFC 8164 。
- ^ 「「keybase.txt」Well-Known Resource Identifier」。keybase.io。2024年8月15日時点のオリジナルよりアーカイブ。2018年2月7日閲覧。
- ^ 「クライアントサーバーAPI」。2024年8月15日時点のオリジナルよりアーカイブ。2020年6月17日閲覧。
- ^ “Mercure.rocks: Mercure: The Specifications”. mercure.rocks . 2020年9月24日時点のオリジナルよりアーカイブ。2019年11月21日閲覧。
- ^ Margolis, Daniel; Risher, Mark; Ramakrishnan, Binu; Brotman, Alex; Jones, Janet (2018 年 9 月 6 日)。「MTA-STS ポリシー」。SMTP MTA Strict Transport Security (MTA-STS)。IETF。sec . 3.2。doi : 10.17487 / RFC8461。RFC 8461 。
- ^ ファレル、スティーブン;カッチャー、ディルク。ダネウィッツ、クリスチャン。オールマン、ベルイェ。ケレーネン、アリ。フィリップ・ハラム・ベイカー（2013年4月6日）。ハッシュを使用して物事に名前を付ける。IETF。土井: 10.17487/RFC6920。RFC 6920。
- ^ “NodeInfo”. 2021年7月19日. 2019年5月18日時点のオリジナルよりアーカイブ。 2019年2月7日閲覧– GitHub経由。
- ^ 「NIP-05: Nostr キーを DNS ベースのインターネット識別子にマッピングする」. github.com .
- ^ Jones, Michael B.; Sakimura, Nat; Bradley, John (2018 年 6 月 28 日). OAuth 2.0 認可サーバーメタデータ. IETF . doi : 10.17487/RFC8414 . RFC 8414.
- ^ 「最終版: エラッタ セット 1 を組み込んだ OpenID Connect Discovery 1.0」。openid.net。2021年 10 月 28 日時点のオリジナルよりアーカイブ。2021 年 10 月 6 日閲覧。
- ^ 「組織プロフィール文書」. opd.data.ac.uk .
- ^ Koch, Werner. OpenPGP Web キー ディレクトリ。IETF . ID draft-koch-openpgp-webkey-service-07。
- ^ 「公的に信頼される証明書の発行と管理に関する基本要件証明書ポリシー」(PDF) 。2018年 9 月 10 日のオリジナルからアーカイブ(PDF) 。2018年 2 月 7 日に取得。
- ^ Miller, Matthew A.; Saint-Andre, Peter (2015 年 11 月 6 日). PKIX over Secure HTTP (POSH). IETF . doi : 10.17487/RFC7711 . RFC 7711.
- ^ 「プライバシー サンドボックスに登録する」。Google for Developers 。2024年 10 月 17 日閲覧。
- ^ 「ウェブ」。[リンク切れ ]
- ^ Jennings, Cullen; Lowekamp, Bruce; Rescorla, Eric; Baset, Salman; Schulzrinne, Henning (2014 年 1 月 6 日). Lowekamp, B (編). REsource LOcation And Discovery (RELOAD) 基本プロトコル. IETF . doi : 10.17487/RFC6940 . RFC 6940.
- ^ Borenstein , Nathaniel S. ; Kucherawy, Murray (2013 年 11 月6日)。評判クエリ プロトコル。IETF。doi : 10.17487 / RFC7072。RFC 7072 。
- ^ 「ANSI/NISO Z39.99-2017」.
- ^ 「security.txt」。security.txt。
- ^ 「「statements.txt」の既知のリソース識別子」。stated.ai。
- ^ Reddy.K, Tirumaleswar; Patil, Prashanth; R , Ram; Uberti, Justin (2015 年 8 月 6 日)。サードパーティ認証のための NAT (STUN) 拡張用セッション トラバーサル ユーティリティ。IETF。doi : 10.17487 / RFC7635。RFC 7635 。
- ^ 「TDM 予約プロトコル (TDMRep) ; 最終コミュニティグループレポート」。テキストおよびデータマイニング予約プロトコルコミュニティグループ。2022年。 2023年6月1日閲覧。
- ^ “20151129 Time over HTTPS 仕様 — PHKs Bikeshed”. phk.freebsd.dk . 2019-05-31 時点のオリジナルよりアーカイブ。2018-02-07に取得。
- ^ ダグラス、マイケル;ダブー、サイラス（2016年3月6日）。タイムゾーンデータ配信サービス。IETF。土井: 10.17487/RFC7808。RFC 7808。
- ^ Maler, E.; Machulak, M.; Richer, J. (2018 年 1 月 7 日)。「OAuth 2.0 認証のためのユーザー管理アクセス (UMA) 2.0 許可」。docs.kantarainitiative.org。
- ^ 「ツールバー フラグ リファレンス」。vercel.com。2024年9 月 9 日時点のオリジナルよりアーカイブ。2024 年 9 月 9 日閲覧。
- ^ 「VoIDボキャブラリによるリンクデータセットの記述」www.w3.org。2021年10月22日時点のオリジナルよりアーカイブ。2021年10月6日閲覧。
- ^ ジョーンズ、ポール;サルゲイロ、ゴンサロ。ジョーンズ、マイケル。スマー、ジョセフ (2013 年 9 月 6 日)ウェブフィンガー。IETF。土井: 10.17487/RFC7033。RFC 7033。
- ^ "xrp-ledger.toml ファイル | XRPL.org". xrpl.org .