Jika Ingin Mendefinisikan Well-Known URI

 (mnot.net)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Saat klien sudah mengenal sebuah situs dan perlu menemukan informasi untuk seluruh situs secara efisien, Well-Known URI adalah pilihan yang paling tepat
  • Seperti robots.txt, menempatkan kebijakan di lokasi terpusat dapat mengurangi pemeriksaan berulang, tetapi juga bisa dipakai untuk membuka interaksi tingkat situs secara menyeluruh seperti change-password
  • Jika protokol yang sebenarnya bisa menyampaikan URL memilih memakai Well-Known URI, layanan dan situs akan terikat 1:1 sehingga deployment dan routing menjadi kaku
  • Saat menerapkannya pada mekanisme discovery atau metadata konten, pertimbangkan lebih dulu struktur operasional seperti nama host awal, lokasi pencarian, redirect, dan situs dengan banyak penerbit
  • Jika ingin berpindah dari jalur tetap yang sudah ada di root, diperlukan rencana transisi, dan peluang registrasi berhasil lebih tinggi bila skema selain http dan https juga disebutkan secara eksplisit

Situasi ketika Well-Known URI cocok digunakan

  • Mark Nottingham, salah satu penulis Well-Known URI specification dan Designated Expert untuk registry, membagikan pedoman praktis tentang kapan Well-Known URI layak digunakan
  • Kriteria ini bukan seluruhnya persyaratan registrasi, melainkan lebih dekat ke praktik yang baik
  • Lokasi Well-Known cocok ketika klien sudah mengenal situs tersebut dan perlu menemukan sesuatu atau berinteraksi pada tingkat seluruh situs
    • Yang dimaksud situs di sini secara teknis adalah origin, yaitu tuple (scheme, host, port)
  • robots.txt sudah ada sebelum RFC ini, tetapi menjadi salah satu alasan utama ruang Well-Known akhirnya dicadangkan
    • Crawler perlu mengetahui kebijakan akses sebuah situs
    • Dengan menaruh kebijakan di lokasi terpusat, tidak perlu memeriksa header dan konten di setiap respons
  • Lokasi Well-Known tidak harus hanya berisi kebijakan
    • Jika mekanismenya membuat klien yang sudah mengenal situs dapat mempelajari atau berinteraksi dengan seluruh situs, itu bisa menjadi kandidat
    • Lokasi Well-Known change-password memungkinkan klien mengubah kata sandi untuk situs tersebut

Ketika menjadi alat yang salah

  • Beberapa desain menetapkan lokasi Well-Known bukan karena ada masalah nyata, tetapi karena terlihat seperti memang seharusnya begitu
  • Adanya entri dalam ruang registrasi tidak otomatis membawa legitimasi atau tingkat adopsi
    • Lokasi Well-Known menyelesaikan masalah spesifik: “klien sudah mengenal situs, dan ada sesuatu yang dibutuhkan untuk seluruh situs”
    • Jika protokol tidak punya masalah seperti itu, registrasi justru bisa menciptakan masalah baru dan tidak menghasilkan adopsi yang diharapkan
  • Beberapa usulan pada praktiknya memakai lokasi Well-Known seperti pemendek URL
    • Protokol tidak mengirimkan URL lengkap, hanya situs terkait
    • Lokasi Well-Known melengkapi sisa jalurnya
  • Pola ini mengunci layanan dan situs dalam hubungan 1:1
    • Jika deployment memerlukan beberapa layanan, maka harus membuat situs lain
    • Juga dibutuhkan cara terpisah untuk mengarahkan pengguna ke situs yang tepat
  • Jika protokol benar-benar hanya bisa menyampaikan nama host, penggunaan lokasi Well-Known bisa dibenarkan
  • Jika URL sebenarnya bisa digunakan, lebih baik tidak memaksakan lokasi Well-Known; memilihnya demi kenyamanan atau kesan formal justru membuat deployment menjadi kaku tanpa perlu

Jebakan yang muncul dalam mekanisme discovery

  • Banyak protokol ingin menggunakan lokasi Well-Known sebagai mekanisme discovery dengan asumsi bahwa “pengguna sudah mengenal situs”
  • Dalam praktiknya, cakupan interaksi pengguna saat ini dan lokasi discovery terjadi bisa tidak selaras
    • Jika klien memulai dari login.example.com, perlu diputuskan apakah lokasi Well-Known harus dicari di situs itu atau di example.com
    • Perlu juga ditentukan apakah redirect dari salah satunya ke yang lain harus diikuti
    • Bisa juga tidak jelas di situs mana penerbit harus menyediakan lokasi Well-Known agar interoperabilitas terjamin
  • Masalah ini sangat penting terutama ketika protokol tidak benar-benar menangani website itu sendiri, melainkan menggunakan HTTP untuk tujuan lain
  • Mungkin muncul keinginan untuk menetapkan agar lokasi Well-Known untuk nama domain yang dapat diregistrasi diletakkan di apex, tetapi dalam sebagian lingkungan hal itu bisa sulit secara operasional
  • Untuk kategori protokol seperti ini, apa yang ditemukan dan dari mana pengguna memulai harus dipertimbangkan bersama
    • Perlu ditentukan cara menemukan nama host yang benar secara andal tanpa membuat asumsi berlebihan tentang arsitektur web

Kompromi saat dipakai untuk metadata konten

  • Beberapa protokol ingin menggunakan lokasi Well-Known untuk mempelajari konten sebuah situs
  • /robots.txt memang bekerja dengan cara ini, tetapi pola tersebut tidak selalu mudah diterapkan pada semua metadata konten
  • Banyak situs mewakili beberapa penerbit
    • Contohnya adalah konvensi lama /~username/
  • Menaruh metadata konten di lokasi terpusat menimbulkan dua masalah
    • Mekanisme itu bisa menjadi nyaris tidak dapat dipakai oleh pengguna individu
    • Administrator mungkin harus membangun infrastruktur yang rumit untuk mendukung kontrol pengguna dan melakukan pengawasan
  • Deployment seperti ini menunjukkan kompromi antara kenyamanan dan granularitas
    • Bisa muncul kebutuhan untuk membuat mekanisme metadata paralel di header respons HTTP atau di dalam konten itu sendiri
    • Cara-cara berbeda untuk menempelkan metadata juga perlu dirapikan
  • Bukan berarti lokasi Well-Known tidak bisa dipakai untuk metadata konten, tetapi pekerjaan yang diperlukan bisa jauh lebih besar dari perkiraan
  • Protokol yang memakai lokasi Well-Known untuk metadata sumber daya perlu mempertimbangkan beragam struktur situs di web

Hal yang perlu dipertimbangkan saat registrasi dan transisi

  • Ada juga usulan yang sudah lebih dulu mendefinisikan lokasi tetap di root
    • Kasus seperti /robots.txt, yang baru mengetahui konsep lokasi Well-Known belakangan, termasuk di sini
  • Dalam kasus seperti ini, dibutuhkan rencana transisi untuk deployment yang sudah ada
    • Pengusul cenderung terlalu berfokus pada basis deployment saat ini
    • Dengan rencana transisi yang baik dalam jangka waktu yang wajar, perpindahan ke lokasi Well-Known dapat dikelola
  • Banyak usulan mengasumsikan URL http dan https secara implisit
  • Karena lokasi Well-Known juga berlaku untuk skema URL lain, skema yang relevan perlu dicantumkan secara eksplisit
  • Lokasi Well-Known harus didaftarkan
    • Tautan itu berisi panduan tentang kapan harus mendaftar dan bagaimana memilih nama
    • Berbeda dari saran sebelumnya, panduan registrasi ini memang memengaruhi peluang keberhasilan registrasi

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Seharusnya pendekatan seperti ini dipakai, alih-alih terus membuat standar baru di namespace root. Misalnya teringat llms.txt
    Semoga kita berhenti mengotori root domain
    https://llmstxt.org/

    • LLMs.txt sendiri tampaknya juga tidak terlalu berarti karena belum diadopsi oleh perusahaan AI besar

  • Tidak setuju. Tulisan ini toh tidak terlalu membantu. Isinya hampir tidak ada dan terasa hanya menyampaikan hal-hal yang sudah jelas
    Kalau tidak ada contoh yang mengarah ke rekomendasi nyata, keahlian yang dibanggakan penulis juga tidak banyak gunanya

    • Penulisnya dulu pernah mencoba menghapus dukungan HTTP 418 "I'm a teapot" dari NodeJS, dan akibat penolakan yang muncul, Python malah akhirnya menambahkan dukungan itu
      https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
    • Terlalu keras. Sangat mungkin penulis memang mendapat pertanyaan dari orang-orang yang ingin mendaftarkan well-known path, dan sebagian dari mereka mungkin tidak mempertimbangkan struktur situs seperti path ~user
      Tulisan ini bisa membuat orang-orang seperti itu memakai solusi yang lebih baik. Meski begitu, kalau mereka tetap yakin butuh well-known URL, dia juga menyediakan tautan ke proses pendaftarannya
    • Inti tulisannya adalah bahwa kalau Anda perlu menambahkan sesuatu seperti robots.txt, jangan asal menaruhnya begitu saja, tapi harus memberi tahu di mana letaknya

  • Kenapa harus sespesifik ini? Kenapa bukan pohon tautan yang lebih umum saja, alih-alih password-reset?
    Verifikasi domain Discord juga bisa dibuat sebagai daftar dinamis di bawah domain-verifications; ini tampak seperti buang-buang waktu. Untuk kebutuhan saya, saya mungkin akan mendefinisikan spesifikasi sendiri di luar well-known

    • Kalau membuat spesifikasi sendiri, orang lain tidak akan memakainya
      Endpoint well-known password-reset dipakai agar password manager bisa menampilkan tombol UI "Change password..." dan langsung membuka halaman ganti kata sandi yang tercantum di file well-known itu
    • discord domain verification sendiri lebih sederhana karena TXT record sudah merupakan daftar item dinamis
      Maksudnya, jauh lebih mudah menelusuri daftar itu dan membandingkan awal tiap nilai dengan string pencarian untuk menemukan discord domain verification
      Misalnya, TXT record untuk ycombinator.com berisi nilai seperti openai-domain-verification=..., anthropic-domain-verification-..., google-site-verification=..., apple-domain-verification=..., dropbox-domain-verification=..., rippling-domain-verification=... secara bersamaan
    • discord domain verification itu urusan Discord. Tidak ada di registry IANA: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
      Soal menjadikan password-reset sebagai pohon tautan yang lebih umum dijawab lebih rinci di thread saudara ini: https://news.ycombinator.com/item?id=48596286

  • Menurut saya penting agar sesuatu bisa ditemukan secara otonom berdasarkan kepercayaan yang melekat pada domain, entah itu lewat .well-known, DNS record, atau DNS over HTTP
    Cloudflare tampaknya sudah cukup banyak menambahkan observabilitas produk di area ini, dan saya juga sedang menyelidikinya: https://instagrate-me.sudoscience.dev/
    Semakin banyak penggunaan berbasis agen, tampaknya jumlah layanan yang membutuhkan hal seperti ini dan jumlah yang dibutuhkan per organisasi juga akan meningkat. auth.md tampaknya contoh terbaru lain yang memakai .well-known

  • “Situs web ini memerlukan browser yang lebih modern agar dapat berfungsi dengan aman. Silakan upgrade browser Anda.”
    Sebagai alternatif, tanpa SNI pun bisa
    https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

    • Bukankah SNI itu bagus? Saya penasaran dalam situasi seperti apa itu jadi masalah
    • Kalau posisinya adalah mengawasi atau menyensor pengguna web, SNI memang tidak bagus
      Jadi itu sangat bagus

  • Apakah registry change-password benar-benar dipakai? Saya bahkan tidak tahu apakah bot pun memakainya
    Di situs-situs saya, saya belum pernah melihat bot memeriksa URL .well-known/change-password. Cocok sebagai tempat untuk menaruh pengaturan publik, tapi sepertinya bukan mekanisme penemuan

    • Beberapa password manager seperti Chrome menampilkan tombol UI "change password" ketika kata sandi bocor
      Fitur ini berbasis .well-known/change-password

  • .well-known awalnya dimulai dengan rapi, tetapi diam-diam berubah menjadi laci serba-serbi di root web. security.txt, ACME, app-site-association, dan lain-lain terus bertambah

    • Saya tidak paham maksudnya. Dari awal memang dirancang sebagai laci serba-serbi
    • Laci serba-serbi lebih baik daripada serba-serbi yang berserakan
    • Bukankah itu memang tujuannya? Daripada membiarkan serba-serbi berserakan di meja dapur, masukkan saja ke laci yang berlabel serba-serbi

  • Tampaknya orang sering mengabaikan fakta bahwa satu domain bisa punya lebih dari satu entri well-known

  • Judulnya menyebut URI, tetapi tulisannya hanya membahas URL, yang merupakan salah satu jenis URI

  • Tapi sebenarnya seberapa well-known URI-URI itu? :-\

    • Saya mencoba mencari contoh .well-known selama 10 menit lewat artikel, RFC, Wikipedia, dan Google, tetapi tidak menemukan satu pun
      Dulu saya pernah membaca satu saat mengerjakan GitHub OIDC, dan waktu itu cukup berguna
      Saya tidak paham kenapa dokumentasi teknis bisa menjelaskan konsep panjang lebar dengan begitu banyak kata tetapi tidak memberi satu pun contoh. Ini juga bukan pertama kalinya saya melihat kasus seperti ini
    • Terkumpul di registry ini: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    • Ada daftar menarik di Wikipedia: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
    • Setuju. Saya berharap ada beberapa contoh bagus, tapi tidak terlihat. Satu-satunya contoh yang saya tahu adalah OIDC discovery endpoint
    • Rasanya ini bahkan kurang dikenal dibanding direktori XDG di kalangan pengembang perangkat lunak untuk Linux
      Serius, namanya kontradiktif. /index.html secara harfiah adalah URL yang sudah dikenal dan diketahui oleh sebagian besar pengembang web. Tetapi membuat banyak URL dengan makna yang sudah ditentukan lalu menempelkan label “well-known” tidak otomatis membuatnya benar-benar terkenal