Well-Known URI tanımlamak istiyorsanız

 (mnot.net)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • İstemci siteyi zaten biliyorsa ve site genelindeki bilgileri verimli biçimde bulması gerekiyorsa Well-Known URI en uygun seçenek olur
  • robots.txt gibi politikaları merkezi bir konuma koymak tekrar eden kontrolleri azaltabilir, ancak change-password gibi site genelinde etkileşim başlatmak için de kullanılabilir
  • Gerçek URL'leri iletebilen bir protokol Well-Known URI kullanırsa hizmet ile site 1:1 bağlanır ve dağıtım ile yönlendirme katılaşır
  • Keşif mekanizmalarına veya içerik metaverisine uygularken başlangıç ana makine adı, arama konumu, yönlendirmeler, çok yayıncılı siteler gibi işletim yapıları önce değerlendirilmelidir
  • Mevcut köke sabitlenmiş yoldan taşınacaksa bir geçiş planı gerekir ve http·https dışındaki şemaları da açıkça belirtmek kayıt başarısı olasılığını artırır

Well-Known URI'nin uygun olduğu durumlar

  • Well-Known URI specification yazarlarından biri ve registry için Designated Expert olan Mark Nottingham, Well-Known URI'nin ne zaman kullanılmasının iyi olduğuna dair pratik ölçütler paylaşıyor
  • Bu ölçütlerin hiçbiri kayıt şartı değildir; daha çok iyi uygulama niteliğindedir
  • Well-Known konumu, istemci sitenin ne olduğunu zaten biliyorsa ve o sitenin geneli hakkında bir şey keşfetmesi ya da onunla etkileşime geçmesi gerekiyorsa uygundur
    • Buradaki site, teknik olarak (scheme, host, port) üçlüsünden oluşan origin anlamına gelir
  • robots.txt RFC'den önce vardı, ancak Well-Known alanının ayrılmasının başlıca nedenlerinden biriydi
    • Tarayıcı botlarının sitenin erişim politikasını bilmesi gerekir
    • Politikayı merkezi bir konuma koymak, her yanıtta başlıkları ve içeriği kontrol etme ihtiyacını ortadan kaldırır
  • Well-Known konumunun mutlaka yalnızca politika içermesi gerekmez
    • İstemci siteyi zaten biliyorsa ve site geneli hakkında bir şey öğrenmesini veya onunla etkileşime geçmesini sağlayan bir mekanizmaysa aday olabilir
    • change-password Well-Known konumu, istemcinin sitenin parolasını değiştirmesine olanak tanır

Yanlış araç haline geldiği durumlar

  • Bazı tasarımlar gerçek bir problem yüzünden değil, öyle yapılması gerekiyormuş gibi göründüğü için Well-Known konumu tanımlar
  • Kayıt alanına bir öğe eklenmesi, tek başına meşruiyet ya da benimsenme getirmez
    • Well-Known konumu, “istemci siteyi biliyor ve site genelinde ihtiyaç duyduğu bir şey var” şeklindeki belirli bir problemi çözer
    • Protokolde böyle bir problem yoksa kayıt yeni sorunlar yaratabilir ve beklenen benimsenmeyi sağlamayabilir
  • Bazı öneriler Well-Known konumunu fiilen bir URL kısaltıcısı gibi kullanır
    • Protokol tam URL'yi iletmek yerine yalnızca ilgili siteyi iletir
    • Well-Known konumu yolun geri kalanını tamamlar
  • Bu desen, hizmet ile siteyi 1:1 ilişkiye sabitler
    • Dağıtım birden fazla hizmet gerektiriyorsa başka siteler oluşturmak gerekir
    • Kullanıcıyı uygun siteye göndermek için ayrı bir yönteme de ihtiyaç doğar
  • Protokol gerçekten yalnızca ana makine adını iletebiliyorsa Well-Known konumu kullanmak makul olabilir
  • Gerçek URL kullanılabiliyorsa, sadece kolaylık ya da resmiyet hissi için Well-Known konumu tercih etmemek daha iyidir; aksi halde dağıtım gereksiz yere katılaşır

Keşif mekanizmalarında ortaya çıkan tuzaklar

  • Pek çok protokol, “kullanıcı siteyi zaten biliyor” varsayımıyla Well-Known konumunu bir keşif mekanizması olarak kullanmak ister
  • Pratikte ise kullanıcının o anda etkileşimde bulunduğu kapsam ile keşfin gerçekleştiği yer birbiriyle uyuşmayabilir
    • İstemci login.example.com üzerinden başladıysa Well-Known konumunun bu sitede mi yoksa example.com üzerinde mi aranacağı sorunu doğar
    • Bir taraftan diğerine yönlendirmelerin izlenip izlenmeyeceği de belirlenmelidir
    • Yayıncının birlikte çalışabilirliği garanti etmek için hangi sitede Well-Known konumu sunması gerektiği de belirsiz olabilir
  • Bu sorun, protokol doğrudan web sitesinin kendisini ele almadığında ve HTTP'yi başka amaçlarla kullandığında özellikle önemlidir
  • Kayıt edilebilir alan adının Well-Known konumunun apex'te olmasını şart koşmak istenebilir, ancak bazı ortamlarda bu operasyonel olarak zor olabilir
  • Bu kategorideki protokoller, neyin keşfedildiğini ve kullanıcının nereden başladığını birlikte değerlendirmelidir
    • Web mimarisi hakkında aşırı varsayımlarda bulunmadan doğru ana makine adını güvenilir biçimde bulmanın yolu belirlenmelidir

İçerik metaverisinde kullanmanın ödünleşimleri

  • Bazı protokoller, site içeriği hakkında bilgi edinmek için Well-Known konumu kullanmak ister
  • /robots.txt bu şekilde çalışır, ancak bu desen her içerik metaverisi türüne kolayca uymaz
  • Pek çok site birden fazla yayıncıyı temsil eder
    • Geçmişteki /~username/ geleneği buna örnektir
  • İçerik metaverisini merkezi bir konuma koymak iki sorun yaratır
    • Bu mekanizma tekil kullanıcılar için fiilen kullanılamaz hale gelebilir
    • Yöneticilerin kullanıcı denetimini desteklemek ve gözetmek için karmaşık bir altyapı kurması gerekebilir
  • Bu tür dağıtımlar, kolaylık ile ayrıntı düzeyi arasındaki ödünleşimi gösterir
    • HTTP yanıt başlıklarında veya içeriğin kendisinde paralel bir metaveri mekanizması oluşturma ihtiyacı doğabilir
    • Farklı metaveri ekleme yöntemlerini de uyumlu hale getirmek gerekir
  • Well-Known konumu içerik metaverisinde hiç kullanılamaz değildir, ancak beklenenden çok daha fazla çalışma gerektirebilir
  • Kaynak metaverisi için Well-Known konumu kullanan protokoller, web üzerindeki farklı site yapılarını hesaba katmalıdır

Kayıt ve geçiş sırasında dikkat edilmesi gerekenler

  • Bazı öneriler zaten kökte sabit bir konum tanımlamış durumdadır
    • /robots.txt örneğinde olduğu gibi, Well-Known konumundan sonradan haberdar olunan durumlar buna dahildir
  • Bu gibi durumlarda mevcut dağıtımlar için bir geçiş planı gerekir
    • Öneri sahipleri mevcut dağıtım tabanına aşırı odaklanma eğilimindedir
    • Makul bir süre boyunca iyi bir geçiş planı hazırlanırsa Well-Known konumuna geçiş yönetilebilir
  • Pek çok öneri http ve https URL'lerini örtük olarak varsayar
  • Well-Known konumu başka URL şemalarına da uygulanabildiği için ilgili şemalar açıkça listelenmelidir
  • Well-Known konumu kayıt ettirilmelidir
    • Bu bağlantıda ne zaman kayıt yapılması gerektiği ve isim seçiminin nasıl yapılacağına dair kılavuz yer alır
    • Bu kayıt kılavuzu, önceki tavsiyelerden farklı olarak, kayıt başarısı olasılığını gerçekten etkiler

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Kök ad alanında durmadan yeni standartlar üretmek yerine keşke böyle bir yaklaşım izlenseydi. Örneğin aklıma llms.txt geliyor
    Alan adının kökünü kirletmeye artık bir son versek iyi olur
    https://llmstxt.org/

    • LLMs.txt büyük yapay zeka şirketleri tarafından benimsenmedi, bu yüzden kendi başına da pek anlamlı görünmüyor

  • Katılmıyorum. Bu yazı zaten pek yardımcı olmuyor. Neredeyse hiç içerik yok ve sadece bariz şeyleri söylüyor gibi
    Somut tavsiyeye dönüşen örnekler yoksa, yazarın öne sürdüğü uzmanlığın da fazla bir değeri kalmıyor

    • Yazar daha önce NodeJS'ten HTTP 418 "I'm a teapot" desteğini kaldırmaya çalışmıştı; bunun üzerine tepki doğmuş ve Python tersine bu desteği eklemişti
      https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
    • Fazla sert. Yazarın gerçekten well-known yolu kaydetmek isteyen kişilerden soru almış olması muhtemel ve bunların bazıları ~user yolu gibi site yapıları düşünmemiş olabilir
      Bu yazı böyle kişilerin daha iyi bir çözüm kullanmasını sağlayabilir. Yine de well-known URL gerektiğine eminseniz, kayıt sürecine giden bağlantıyı da veriyor
    • Yazının asıl noktası, robots.txt gibi bir şey eklemeniz gerekiyorsa bunu rastgele koymamanız, nerede olduğunu bildirmeniz gerektiği

  • Neden bu kadar özel tanımlanmış, anlamıyorum. password-reset yerine daha genel bir bağlantı ağacı olsa olmaz mı?
    Discord alan adı doğrulaması da domain-verifications altında dinamik bir listeyle yapılabilirdi; zaman kaybı gibi görünüyor. Kendi kullanımım için olsaydı, well-known dışında kendi spesifikasyonumu tanımlardım

    • Kendi spesifikasyonunu yaparsan başkaları kullanmaz
      password-reset well-known endpoint'i, parola yöneticilerinin arayüzde "Change password..." düğmesini göstermesi ve doğrudan well-known dosyasında belirtilen parola değiştirme sayfasına gitmesi için kullanılıyor
    • discord domain verification için TXT kaydının kendisi zaten dinamik öğe listesidir; bu, ayrı bir yapıdan daha basit
      Listeyi dolaşıp her değerin başını arama dizesiyle karşılaştırarak discord domain verification değerini bulmak çok daha kolay demek
      Örneğin ycombinator.com alan adının TXT kayıtlarında openai-domain-verification=..., anthropic-domain-verification-..., google-site-verification=..., apple-domain-verification=..., dropbox-domain-verification=..., rippling-domain-verification=... gibi değerler birlikte bulunuyor
    • discord domain verification Discord tarafının sorunu. IANA kayıtlarında yok: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
      password-reset için daha genel bir bağlantı ağacı önerisine de kardeş başlıkta daha ayrıntılı yanıt verilmiş: https://news.ycombinator.com/item?id=48596286

  • .well-known, DNS kaydı ya da DNS over HTTP; hangisi olursa olsun, alana sabitlenmiş güvene dayanarak otonom keşif yapılabilmesini önemli buluyorum
    Cloudflare bu alanın gözlemlenebilirliğini ürünlerine epey eklemiş gibi görünüyor, ben de araştırıyorum: https://instagrate-me.sudoscience.dev/
    Ajan tipi kullanım arttıkça, buna ihtiyaç duyan servislerin sayısı da kuruluş başına gereken miktar da artacak gibi. auth.md de .well-known kullanan yeni örneklerden biri gibi görünüyor

  • “Bu web sitesinin güvenli şekilde çalışması için daha modern bir tarayıcı gerekiyor. Lütfen tarayıcınızı yükseltin.”
    Alternatif olarak SNI olmadan da mümkün
    https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

    • SNI iyi bir şey değil mi? Hangi durumda sorun olduğunu merak ediyorum
    • Web kullanıcılarını izlemek veya sansürlemek istiyorsanız SNI iyi değildir
      O yüzden gayet iyi

  • change-password kaydı gerçekten kullanılıyor mu? Botların bile kullandığından emin değilim
    Kendi sitelerimde botların .well-known/change-password URL'sini kontrol ettiğini hiç görmedim. Ortak ayarları koymak için iyi bir yer olabilir ama keşif mekanizması olarak değil gibi

    • Chrome gibi bazı parola yöneticileri, bir parola sızdırıldığında arayüzde "change password" düğmesi gösteriyor
      Bu özellik .well-known/change-password temeline dayanıyor

  • .well-known başlangıçta temizdi ama sessizce web kökünün ıvır zıvır çekmecesine dönüştü. security.txt, ACME, app-site-association derken liste uzayıp gidiyor

    • Ne demek istediğini anlamıyorum. Zaten baştan ıvır zıvır çekmecesi olmak için tasarlanmıştı
    • Etrafa saçılmış ıvır zıvırdan iyidir, ıvır zıvır çekmecesi olması daha iyi
    • Amaç bu değil mi zaten? Mutfak tezgâhının üstüne saçmak yerine, üstünde ıvır zıvır yazan bir çekmeceye koyuyorsun

  • Tek bir alan adında birden fazla well-known öğe olabileceği sık sık gözden kaçıyor gibi

  • Başlıkta URI yazıyor ama yazı aslında URI'nin bir türü olan URL ile ilgileniyor

  • Peki bu URI'ler gerçekten ne kadar well-known? :-\

    • Yazıyı, RFC'yi, Wikipedia'yı, Google'ı 10 dakika kurcalayıp .well-known örneği bulmaya çalıştım ama bir tane bile bulamadım
      GitHub OIDC işi yaparken daha önce bir tane okumuştum ve o zaman oldukça faydalıydı
      Teknik belgelerin neden bu kadar çok lafla kavramı derinlemesine anlattığını ama tek bir örnek bile vermediğini anlamıyorum. Böyle bir şeyle ilk kez de karşılaşmıyorum
    • Hepsi şu kayıtta toplanmış: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    • Wikipedia'da ilginç bir liste var: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
    • Katılıyorum. Birkaç iyi örnek görmeyi bekliyordum ama yoktu. Benim bildiğim tek örnek OIDC discovery endpoint
    • Linux hedefleyen yazılım geliştiricileri arasındaki XDG dizinleri kadar bile bilinmiyor gibi
      Ciddi konuşmak gerekirse adı çelişkili. /index.html kelimenin tam anlamıyla iyi bilinen bir URL'dir ve çoğu web geliştiricisi bunu bilir. Ama önceden tanımlı anlamı olan bir sürü URL oluşturup üstüne “well-known” etiketi yapıştırmak, onların gerçekten yaygın olarak bilindiği anlamına gelmez