अगर आप Well-Known URI को परिभाषित करना चाहते हैं

• जब क्लाइंट पहले से किसी साइट को जानता हो और उसे पूरी साइट की जानकारी कुशलता से ढूंढनी हो, तब Well-Known URI सबसे उपयुक्त होता है
• robots.txt की तरह नीतियों को एक केंद्रीय स्थान पर रखने से बार-बार जांच की जरूरत कम हो सकती है, लेकिन इसे change-password की तरह पूरी साइट-स्तरीय इंटरैक्शन खोलने के लिए भी इस्तेमाल किया जा सकता है
• अगर कोई प्रोटोकॉल वास्तविक URL दे सकता है, फिर भी Well-Known URI का उपयोग करता है, तो service और site के बीच 1:1 बंधन बन जाता है, जिससे deployment और routing कठोर हो जाते हैं
• discovery mechanism या content metadata पर इसे लागू करते समय start hostname, lookup location, redirect, multi-publisher site जैसी operational structure को पहले समझना चाहिए
• मौजूदा root-fixed path से इसे स्थानांतरित करना हो तो transition plan चाहिए, और http·https के अलावा अन्य schemes को भी स्पष्ट रूप से बताने पर registration सफल होने की संभावना बढ़ती है

---

वे स्थितियाँ जहाँ Well-Known URI सही बैठता है

• Well-Known URI specification के लेखकों में से एक और registry के Designated Expert Mark Nottingham ने यह साझा किया कि व्यावहारिक रूप से Well-Known URI का उपयोग कब करना अच्छा रहता है
• ये सभी बिंदु औपचारिक registration requirements नहीं हैं, बल्कि good practice के अधिक करीब हैं
• Well-Known location तब उपयुक्त होती है जब क्लाइंट पहले से साइट को जानता हो और उसे उस पूरी साइट के बारे में कुछ discover करना हो या उससे इंटरैक्ट करना हो
  • यहाँ site का तकनीकी अर्थ (scheme, host, port) tuple यानी origin है
• robots.txt RFC से पहले मौजूद था, लेकिन Well-Known space reserve करने का यह एक मुख्य कारण बना
  • crawler को साइट की access policy जाननी होती है
  • policy को एक केंद्रीय location पर रखने से हर response में header और content जांचने की जरूरत नहीं रहती
• यह जरूरी नहीं कि Well-Known location केवल policy ही रखे
  • अगर कोई mechanism ऐसा है जिसमें क्लाइंट पहले से साइट को जानता है और उसे पूरी साइट के बारे में सीखना या उससे इंटरैक्ट करना है, तो वह उम्मीदवार हो सकता है
  • change-password Well-Known location क्लाइंट को साइट का password बदलने देती है

जब यह गलत tool बन जाता है

• कुछ design वास्तविक समस्या के कारण नहीं, बल्कि ऐसा करना चाहिए जैसा लगता है इस वजह से Well-Known location तय कर देते हैं
• registry space में entry होने भर से उसकी वैधता या adoption अपने-आप नहीं आती
  • Well-Known location एक खास समस्या हल करती है: “क्लाइंट साइट को जानता है, और उसे पूरी साइट के लिए कुछ चाहिए”
  • अगर प्रोटोकॉल में ऐसी समस्या ही नहीं है, तो registration नया मसला खड़ा कर सकता है और अपेक्षित adoption भी नहीं ला सकता
• कुछ प्रस्ताव Well-Known location को लगभग URL shortener की तरह इस्तेमाल करते हैं
  • प्रोटोकॉल में पूरा URL देने के बजाय केवल संबंधित site दी जाती है
  • बाकी path Well-Known location भर देती है
• यह pattern service और site को 1:1 relationship में बांध देता है
  • अगर deployment को कई services चाहिए, तो अलग sites बनानी पड़ेंगी
  • और users को सही site तक भेजने का अलग तरीका भी चाहिए होगा
• अगर प्रोटोकॉल सचमुच केवल hostname ही दे सकता है, तो Well-Known location का उपयोग उचित हो सकता है
• लेकिन अगर वास्तविक URL इस्तेमाल किया जा सकता है, तो बिना जरूरत Well-Known location से बचना बेहतर है; केवल convenience या अधिक औपचारिक दिखने के लिए इसे चुनने पर deployment अनावश्यक रूप से कठोर हो जाता है

discovery mechanism में आने वाले pitfalls

• कई protocols यह मानकर Well-Known location को discovery mechanism में इस्तेमाल करना चाहते हैं कि “user पहले से साइट को जानता है”
• लेकिन व्यवहार में user की मौजूदा interaction scope और discovery के होने की location अलग हो सकती है
  • अगर क्लाइंट login.example.com से शुरू हुआ, तो सवाल उठता है कि Well-Known location वहीं खोजी जाए या example.com पर
  • यह भी तय करना होगा कि एक तरफ से दूसरी तरफ redirect follow करना है या नहीं
  • interoperability सुनिश्चित करने के लिए publisher को किस site पर Well-Known location देनी चाहिए, यह भी अस्पष्ट हो सकता है
• यह समस्या खास तौर पर तब महत्वपूर्ण हो जाती है जब प्रोटोकॉल वास्तव में website को नहीं, बल्कि HTTP को किसी अन्य उद्देश्य के लिए इस्तेमाल कर रहा हो
• आप यह तय करना चाह सकते हैं कि registrable domain name की Well-Known location apex पर हो, लेकिन कुछ environments में यह operational रूप से कठिन हो सकता है
• इस तरह के protocols में क्या discover किया जा रहा है और user कहाँ से शुरू करता है, इन दोनों को साथ लेकर चलना होगा
  • web architecture के बारे में अत्यधिक assumptions किए बिना सही hostname को विश्वसनीय तरीके से कैसे ढूंढना है, यह तय करना होगा

content metadata में उपयोग के समय trade-off

• कुछ protocols साइट के content के बारे में जानने के लिए Well-Known location का उपयोग करना चाहते हैं
• /robots.txt इस तरह काम करता है, लेकिन यह pattern हर प्रकार के content metadata पर आसानी से लागू नहीं होता
• कई sites कई publishers का प्रतिनिधित्व करती हैं
  • उदाहरण के लिए, पहले का /~username/ convention
• content metadata को केंद्रीय location में रखने पर दो समस्याएँ पैदा होती हैं
  • यह mechanism व्यक्तिगत users के लिए व्यावहारिक रूप से अनुपयोगी हो सकता है
  • या administrators को users के control और supervision के समर्थन के लिए जटिल infrastructure बनाना पड़ सकता है
• ऐसे deployments convenience और granularity के बीच trade-off दिखाते हैं
  • HTTP response headers या content में ही parallel metadata mechanism बनाने की जरूरत पड़ सकती है
  • metadata जोड़ने के अलग-अलग तरीकों को भी व्यवस्थित करना होगा
• इसका मतलब यह नहीं कि content metadata के लिए Well-Known location का उपयोग नहीं किया जा सकता, लेकिन इसमें उम्मीद से कहीं अधिक काम लग सकता है
• resource metadata के लिए Well-Known location इस्तेमाल करने वाले protocols को web की विविध site structures को ध्यान में रखना चाहिए

registration और transition के समय ध्यान देने योग्य बातें

• कुछ प्रस्ताव पहले से root में fixed location परिभाषित कर चुके हैं
  • /robots.txt की तरह, जहाँ Well-Known location की अवधारणा बाद में सामने आई
• ऐसे मामलों में मौजूदा deployments के लिए transition plan जरूरी है
  • प्रस्तावक अक्सर मौजूदा deployment base पर जरूरत से ज्यादा ध्यान केंद्रित करते हैं
  • लेकिन उचित समयावधि के साथ अच्छा transition plan हो, तो Well-Known location की ओर बदलाव संभाला जा सकता है
• कई प्रस्ताव http और https URL को implicit रूप से मान लेते हैं
• Well-Known location अन्य URL schemes पर भी लागू होती है, इसलिए संबंधित schemes को स्पष्ट रूप से सूचीबद्ध करना चाहिए
• Well-Known location को register करना होता है
  • उस लिंक में यह बताया गया है कि registration कब करना चाहिए और नाम कैसे चुनना चाहिए
  • पहले की सलाहों के विपरीत, यह registration guidance वास्तव में registration की सफलता की संभावना को प्रभावित करती है

[GN⁺]

Hacker News टिप्पणियाँ

• काश लोग root namespace में नए standard बनाते रहने के बजाय यह तरीका अपनाएँ। उदाहरण के लिए llms.txt याद आता है
  domain root को गंदा करना अब बंद होना चाहिए
  https://llmstxt.org/

  • LLMs.txt को बड़े AI vendors ने अपनाया नहीं है, इसलिए अपने आप में भी इसका ज़्यादा मतलब नहीं लगता

• मैं सहमत नहीं हूँ। यह लेख वैसे भी ज़्यादा मददगार नहीं है। इसमें लगभग कोई सामग्री नहीं है और बस साफ़-साफ़ बातें ही कही गई हैं
  अगर इसे किसी वास्तविक recommendation तक ले जाने वाले examples नहीं हैं, तो लेखक की बताई जा रही expertise भी बहुत काम की नहीं है

  • लेखक ने पहले NodeJS से HTTP 418 "I'm a teapot" support हटाने की कोशिश की थी, और उसके खिलाफ़ backlash होने पर Python ने उल्टे support जोड़ दिया था
    https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
  • यह कुछ ज़्यादा ही harsh है। संभव है कि लेखक से ऐसे लोगों ने सवाल किए हों जो सच में well-known path register करना चाहते हों, और उनमें से कुछ ने ~user path जैसी site structure पर विचार न किया हो
    यह लेख ऐसे लोगों को बेहतर समाधान अपनाने में मदद कर सकता है। फिर भी अगर वे well-known URL की ज़रूरत को लेकर आश्वस्त हैं, तो registration process का link भी दिया गया है
  • लेख का मूल बिंदु यह है कि अगर आपको robots.txt जैसी कोई चीज़ जोड़नी है, तो उसे मनमाने ढंग से मत रखिए, बल्कि यह बताइए कि वह कहाँ है

• यह इतना specific क्यों है, समझ नहीं आता। password-reset की जगह एक ज़्यादा generic link tree क्यों नहीं रखा जा सकता?
  Discord domain verification भी domain-verifications के नीचे dynamic list रखने के तरीके से हो सकता था, यह समय की बर्बादी लगता है। मेरे use case में तो मैं well-known के बाहर अपनी spec define करता

  • अगर आप अपनी spec बनाएँगे, तो उसे कोई और इस्तेमाल नहीं करेगा
    password-reset well-known endpoint का उपयोग password managers UI में "Change password..." बटन दिखाने और well-known file में दिए गए password change page पर सीधे ले जाने के लिए करते हैं
  • discord domain verification में TXT record खुद ही dynamic entries की list है, इसलिए अलग structure से यह ज़्यादा simple है
    मतलब list को iterate करके हर value की शुरुआत को search string से compare करते हुए discord domain verification ढूँढना कहीं आसान है
    उदाहरण के लिए ycombinator.com के TXT records में openai-domain-verification=..., anthropic-domain-verification-..., google-site-verification=..., apple-domain-verification=..., dropbox-domain-verification=..., rippling-domain-verification=... जैसी values साथ में मौजूद हैं
  • discord domain verification Discord की तरफ़ की चीज़ है। यह IANA registry में नहीं है: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    password-reset को ज़्यादा generic link tree बनाने वाली बात का जवाब sibling thread में और विस्तार से दिया गया है: https://news.ycombinator.com/item?id=48596286

• .well-known, DNS records, DNS over HTTP — इनमें से कोई भी तरीका हो, domain से बँधे trust के आधार पर autonomous discovery संभव बनाना महत्वपूर्ण लगता है
  Cloudflare ने इस क्षेत्र की observability अपने product में काफ़ी जोड़ दी है, और मैं भी इसे देख रहा हूँ: https://instagrate-me.sudoscience.dev/
  जैसे-जैसे agentic use बढ़ेगा, वैसे-वैसे ऐसी चीज़ों की ज़रूरत वाली services की संख्या और हर organization के लिए ज़रूरी मात्रा दोनों बढ़ेंगी। auth.md भी .well-known का एक हालिया उदाहरण लगता है

• “इस website को सुरक्षित रूप से चलने के लिए एक अधिक आधुनिक browser चाहिए। कृपया अपना browser upgrade करें।”
  विकल्प के तौर पर SNI के बिना भी यह संभव है
  https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

  • क्या SNI अच्छी चीज़ नहीं है? जानना चाहता हूँ कि किन परिस्थितियों में यह समस्या बनती है
  • अगर आपका काम web users की निगरानी या सेंसरशिप करना है, तो SNI अच्छी चीज़ नहीं है
    इसलिए यह बहुत अच्छी है

• क्या change-password registry सच में इस्तेमाल होती है? पता नहीं bots भी इसका उपयोग करते हैं या नहीं
  मैंने अपनी sites पर bots को .well-known/change-password URL जाँचते नहीं देखा है। public settings रखने की जगह के तौर पर तो ठीक है, लेकिन discovery mechanism के रूप में नहीं लगता

  • Chrome जैसे कुछ password managers password leak होने पर UI में "change password" बटन दिखाते हैं
    यह feature .well-known/change-password पर आधारित है

• .well-known ने शुरुआत साफ़-सुथरे तरीके से की थी, लेकिन चुपचाप web root की junk drawer बन गया है। security.txt, ACME, app-site-association वगैरह लगातार बढ़ते जा रहे हैं

  • इसका मतलब समझ नहीं आया। इसे शुरू से ही junk drawer बनने के लिए design किया गया था
  • बिखरे हुए कबाड़ से junk drawer बेहतर है
  • क्या यही इसका मकसद नहीं है? यानी कबाड़ को kitchen counter पर फैलाकर रखने के बजाय, उसे कबाड़-लेबल वाले drawer में रख दिया जाए

• ऐसा लगता है कि लोग अक्सर इस बात को नज़रअंदाज़ कर देते हैं कि एक domain में कई well-known entries हो सकती हैं

• शीर्षक में URI लिखा है, लेकिन लेख URI के सिर्फ़ एक प्रकार यानी URL की ही बात करता है

• लेकिन ये URI वास्तव में कितने well-known हैं? :-\

  • मैंने article, RFC, Wikipedia और Google में 10 मिनट तक .well-known examples ढूँढने की कोशिश की, लेकिन एक भी नहीं मिला
    GitHub OIDC पर काम करते समय मैंने पहले एक देखा था, और तब वह काफ़ी उपयोगी था
    समझ नहीं आता technical docs इतने शब्दों में concepts को गहराई से क्यों समझाते हैं, लेकिन एक भी example नहीं देते। ऐसा पहली बार नहीं हुआ
  • वे यहाँ registry में इकट्ठा हैं: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
  • Wikipedia में एक दिलचस्प list है: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
  • सहमत। मुझे कुछ अच्छे examples की उम्मीद थी, लेकिन दिखे नहीं। मेरे जानने में एकमात्र उदाहरण OIDC discovery endpoint है
  • लगता है यह Linux के लिए software बनाने वालों के बीच XDG directories से भी कम जाना-पहचाना है
    गंभीरता से कहूँ तो इसका नाम ही विरोधाभासी है। /index.html सचमुच एक well-known URL है और ज़्यादातर web developers इसे जानते हैं। लेकिन पहले से तय meaning वाले ढेर सारे URLs बना देने और उन पर “well-known” का टैग लगा देने से वे वास्तव में मशहूर नहीं हो जाते