Nếu muốn định nghĩa Well-Known URI

 (mnot.net)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi client đã biết sẵn một site và cần tìm thông tin cho toàn bộ site một cách hiệu quả, Well-Known URI là lựa chọn phù hợp nhất
  • Đặt chính sách ở một vị trí trung tâm như robots.txt có thể giảm việc phải kiểm tra lặp lại, nhưng cũng có thể dùng để mở ra tương tác trên toàn site như change-password
  • Nếu một giao thức có thể truyền URL thực tế mà vẫn dùng Well-Known URI, dịch vụ và site sẽ bị ràng buộc 1:1, khiến việc triển khai và định tuyến trở nên cứng nhắc
  • Khi áp dụng cho cơ chế khám phá hoặc metadata nội dung, cần xem xét trước cấu trúc vận hành như hostname khởi đầu, vị trí tra cứu, chuyển hướng và site có nhiều publisher
  • Nếu muốn chuyển từ đường dẫn cố định ở root hiện có, cần một kế hoạch chuyển đổi; đồng thời nên chỉ rõ cả các scheme ngoài http và https để tăng khả năng đăng ký thành công

Những trường hợp Well-Known URI thực sự phù hợp

  • Mark Nottingham, một trong các tác giả của Well-Known URI specification và là Designated Expert của registry, đã chia sẻ các tiêu chí thực tế về thời điểm nên dùng Well-Known URI
  • Các tiêu chí này không phải tất cả đều là yêu cầu để đăng ký, mà gần với thực hành tốt hơn
  • Vị trí Well-Known phù hợp khi client đã biết site đó và cần khám phá hoặc tương tác với điều gì đó trên toàn bộ site
    • Ở đây, site theo nghĩa kỹ thuật là origin, tức bộ ba (scheme, host, port)
  • robots.txt đã tồn tại trước RFC, nhưng là một trong những lý do chính khiến không gian Well-Known được dành riêng
    • Crawler cần biết chính sách truy cập của site
    • Đặt chính sách ở một vị trí trung tâm giúp không phải kiểm tra header và nội dung của mọi response
  • Vị trí Well-Known không nhất thiết chỉ dùng để chứa chính sách
    • Nếu đó là một cơ chế mà client đã biết site và cần tìm hiểu hoặc tương tác trên phạm vi toàn site, nó có thể là ứng viên phù hợp
    • Vị trí Well-Known change-password cho phép client thay đổi mật khẩu của site

Khi nó trở thành công cụ không phù hợp

  • Một số thiết kế chỉ định vị trí Well-Known không phải vì vấn đề thực tế, mà vì trông như nên làm vậy
  • Việc có một mục trong không gian đăng ký không đồng nghĩa với tính chính đáng hay mức độ chấp nhận sẽ tự động đi kèm
    • Vị trí Well-Known giải quyết một bài toán cụ thể: “client biết site và có nhu cầu ở phạm vi toàn site”
    • Nếu giao thức không có bài toán đó, việc đăng ký có thể tạo ra vấn đề mới và không dẫn đến mức độ chấp nhận như kỳ vọng
  • Một số đề xuất thực chất dùng vị trí Well-Known như trình rút gọn URL
    • Giao thức không truyền toàn bộ URL mà chỉ truyền site liên quan
    • Vị trí Well-Known sẽ điền phần đường dẫn còn lại
  • Mẫu này cố định dịch vụ và site vào quan hệ 1:1
    • Nếu triển khai cần nhiều dịch vụ, sẽ phải tạo thêm các site khác
    • Đồng thời cũng cần một cách riêng để đưa người dùng tới đúng site phù hợp
  • Nếu giao thức thực sự chỉ có thể truyền hostname, việc dùng vị trí Well-Known có thể là hợp lý
  • Nếu có thể dùng URL thực tế, tốt hơn là không nên dùng vị trí Well-Known; chọn nó chỉ vì tiện lợi hoặc trông chính thức sẽ khiến việc triển khai cứng nhắc một cách không cần thiết

Những cạm bẫy trong cơ chế khám phá

  • Nhiều giao thức muốn dùng vị trí Well-Known làm cơ chế khám phá với giả định rằng “người dùng đã biết site”
  • Nhưng trên thực tế, phạm vi tương tác hiện tại của người dùng và nơi việc khám phá diễn ra có thể không trùng khớp
    • Nếu client bắt đầu từ login.example.com, sẽ nảy sinh câu hỏi là nên tìm vị trí Well-Known ở site đó hay ở example.com
    • Cũng cần quyết định có nên đi theo chuyển hướng từ bên này sang bên kia hay không
    • Có thể cũng không rõ publisher phải cung cấp vị trí Well-Known ở site nào để đảm bảo khả năng tương tác
  • Vấn đề này đặc biệt quan trọng khi giao thức không thực sự xử lý chính website, mà dùng HTTP cho mục đích khác
  • Có thể muốn chỉ định rằng vị trí Well-Known của tên miền có thể đăng ký phải nằm ở apex, nhưng trong một số môi trường điều đó có thể gây khó khăn về vận hành
  • Với nhóm giao thức này, cần cân nhắc cùng lúc việc đang khám phá cái gì và người dùng bắt đầu từ đâu
    • Cần xác định cách tìm đúng hostname một cách ổn định mà không đặt ra quá nhiều giả định về kiến trúc web

Những đánh đổi khi dùng cho metadata nội dung

  • Một số giao thức muốn dùng vị trí Well-Known để tìm hiểu nội dung của site
  • /robots.txt hoạt động theo cách này, nhưng mẫu đó không dễ áp dụng cho mọi loại metadata nội dung
  • Nhiều site đại diện cho nhiều publisher
    • Ví dụ là quy ước /~username/ trước đây
  • Khi đặt metadata nội dung ở vị trí trung tâm, sẽ phát sinh hai vấn đề
    • Cơ chế đó có thể gần như không dùng được trên thực tế đối với từng người dùng riêng lẻ
    • Quản trị viên có thể phải xây dựng hạ tầng phức tạp để hỗ trợ và giám sát quyền kiểm soát của người dùng
  • Những kiểu triển khai như vậy cho thấy sự đánh đổi giữa tính tiện lợi và độ chi tiết
    • Có thể sẽ cần cơ chế metadata song song trong HTTP response header hoặc ngay trong chính nội dung
    • Cũng cần làm rõ cách các phương thức gắn metadata khác nhau tương tác với nhau
  • Không phải là không thể dùng vị trí Well-Known cho metadata nội dung, nhưng có thể sẽ cần nhiều công sức hơn rất nhiều so với dự kiến
  • Các giao thức dùng vị trí Well-Known cho metadata tài nguyên cần tính tới sự đa dạng trong cấu trúc site trên web

Những điểm cần cân nhắc khi đăng ký và chuyển đổi

  • Đã có những đề xuất định nghĩa sẵn một vị trí cố định ở root
    • Trường hợp này giống như /robots.txt, tức là chỉ biết đến vị trí Well-Known sau đó
  • Trong những trường hợp như vậy, cần có kế hoạch chuyển đổi cho các triển khai hiện có
    • Người đề xuất thường có xu hướng tập trung quá mức vào nền tảng triển khai hiện tại
    • Nếu có một kế hoạch chuyển đổi hợp lý trong thời gian phù hợp, có thể quản lý được việc chuyển sang vị trí Well-Known
  • Nhiều đề xuất ngầm giả định URL http và https
  • Vị trí Well-Known cũng áp dụng cho các URL scheme khác, vì vậy nên liệt kê rõ ràng các scheme liên quan
  • Vị trí Well-Known cần được đăng ký
    • Liên kết đó có hướng dẫn về thời điểm nên đăng ký và cách chọn tên
    • Khác với phần lời khuyên ở trên, hướng dẫn đăng ký này thực sự ảnh hưởng đến khả năng đăng ký thành công

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Bình luận trên Hacker News

  • Ước gì người ta làm theo cách này thay vì cứ tiếp tục tạo các tiêu chuẩn mới trong root namespace. Ví dụ làm tôi nghĩ đến llms.txt
    Mong là thôi đừng làm bẩn root của domain nữa
    https://llmstxt.org/

    • LLMs.txt không được các công ty AI lớn chấp nhận, nên tự bản thân nó có vẻ cũng không có nhiều ý nghĩa

  • Tôi không đồng ý. Bài này rốt cuộc cũng chẳng giúp ích mấy. Nội dung gần như không có gì, chỉ nói những điều quá hiển nhiên
    Nếu không có ví dụ nào dẫn đến khuyến nghị thực tế, thì chuyên môn mà tác giả nêu ra cũng không có nhiều giá trị

    • Trước đây tác giả từng định gỡ hỗ trợ HTTP 418 "I'm a teapot" khỏi NodeJS, và kết quả là bị phản ứng ngược đến mức Python còn bổ sung hỗ trợ luôn
      https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
    • Hơi harsh quá. Rất có thể tác giả đã nhận câu hỏi từ những người thực sự muốn đăng ký well-known path, và trong số đó có người chưa từng cân nhắc cấu trúc website như đường dẫn ~user
      Bài này có thể khiến những người đó dùng giải pháp tốt hơn. Dù vậy, nếu họ vẫn chắc chắn cần một well-known URL, bài cũng có cung cấp link đến quy trình đăng ký
    • Ý chính của bài là nếu bạn cần thêm thứ gì đó như robots.txt, thì đừng chỉ đặt bừa ở đó, mà phải cho biết nó nằm ở đâu

  • Không hiểu sao lại cụ thể đến vậy. Sao không đặt một cây liên kết tổng quát hơn thay vì password-reset?
    Việc xác minh domain của Discord cũng có thể dùng danh sách động dưới domain-verifications, trông như một sự lãng phí thời gian. Nếu là nhu cầu của tôi thì chắc tôi sẽ tự định nghĩa đặc tả riêng bên ngoài well-known

    • Nếu tự làm đặc tả riêng thì người khác sẽ không dùng
      Endpoint well-known password-reset được dùng để trình quản lý mật khẩu hiển thị nút "Change password..." trong UI và dẫn thẳng đến trang đổi mật khẩu được ghi trong tệp well-known đó
    • discord domain verification thì bản thân TXT record đã là danh sách các mục động sẵn rồi, nên đơn giản hơn một cấu trúc riêng
      Ý là chỉ cần duyệt danh sách và so phần đầu của từng giá trị với chuỗi cần tìm để tìm discord domain verification thì dễ hơn nhiều
      Ví dụ, TXT record của ycombinator.com có đồng thời các giá trị như openai-domain-verification=..., anthropic-domain-verification-..., google-site-verification=..., apple-domain-verification=..., dropbox-domain-verification=..., rippling-domain-verification=...
    • discord domain verification là chuyện của Discord. Nó không có trong registry của IANA: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
      Về ý biến password-reset thành một cây liên kết tổng quát hơn, tôi đã trả lời chi tiết hơn ở thread cùng cấp này: https://news.ycombinator.com/item?id=48596286

  • Dù là .well-known, DNS record hay DNS over HTTP, tôi nghĩ điều quan trọng là làm cho việc khám phá tự động trở nên khả thi dựa trên độ tin cậy gắn với domain
    Cloudflare có vẻ đã thêm khá nhiều khả năng quan sát cho mảng này vào sản phẩm của họ, và tôi cũng đang tìm hiểu: https://instagrate-me.sudoscience.dev/
    Càng nhiều ứng dụng kiểu agent thì số dịch vụ cần những thứ này và lượng cần cho mỗi tổ chức có lẽ đều sẽ tăng. auth.md cũng có vẻ là một ví dụ gần đây dùng .well-known

  • “Trang web này cần một trình duyệt hiện đại hơn để hoạt động an toàn. Hãy nâng cấp trình duyệt của bạn.”
    Một phương án khác là có thể làm được mà không cần SNI
    https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

    • SNI chẳng phải là thứ tốt sao? Tôi muốn biết trong trường hợp nào nó lại thành vấn đề
    • Nếu bạn đứng ở phía giám sát hoặc kiểm duyệt người dùng web thì SNI không tốt
      Nên nó rất tốt

  • Registry change-password có thực sự được dùng không? Tôi còn không biết bot có dùng hay không
    Trên các site của tôi, tôi chưa từng thấy bot nào kiểm tra URL .well-known/change-password. Làm nơi để đặt cấu hình công khai thì ổn, nhưng có vẻ không phải là cơ chế khám phá

    • Một số trình quản lý mật khẩu như Chrome sẽ hiển thị nút "change password" trong UI khi mật khẩu bị lộ
      Tính năng này dựa trên .well-known/change-password

  • .well-known ban đầu khởi đầu khá gọn gàng, nhưng âm thầm biến thành ngăn kéo lặt vặt của web root. security.txt, ACME, app-site-association và nhiều thứ khác vẫn đang tiếp tục tăng lên

    • Tôi không hiểu ý đó. Ngay từ đầu nó đã được thiết kế như một ngăn kéo lặt vặt rồi mà
    • Có ngăn kéo lặt vặt còn hơn là đồ lặt vặt bị vứt rải rác khắp nơi
    • Chẳng phải đó chính là mục đích sao? Thay vì rải đồ lặt vặt trên mặt bếp, bạn bỏ chúng vào một ngăn kéo có dán nhãn là đồ lặt vặt

  • Có vẻ mọi người thường bỏ qua việc một domain có thể có nhiều mục well-known

  • Tiêu đề nói về URI, nhưng bài lại chỉ bàn đến URL, vốn chỉ là một loại của URI

  • Nhưng rốt cuộc những URI đó thực sự well-known đến mức nào? :-\

    • Tôi đã mò bài viết, RFC, Wikipedia và Google suốt 10 phút để tìm ví dụ về .well-known mà không thấy nổi một cái nào
      Trước đây tôi từng đọc một cái khi làm việc với GitHub OIDC, và lúc đó nó khá hữu ích
      Không hiểu sao tài liệu kỹ thuật lại có thể giải thích khái niệm rất sâu bằng cả đống chữ mà lại không đưa nổi một ví dụ nào. Đây cũng không phải lần đầu tôi gặp kiểu này
    • Chúng được tập hợp ở registry này: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    • Wikipedia có một danh sách khá thú vị: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
    • Đồng ý. Tôi cũng mong có vài ví dụ hay nhưng chẳng thấy đâu. Ví dụ duy nhất tôi biết là OIDC discovery endpoint
    • Có vẻ nó còn kém nổi tiếng hơn cả thư mục XDG trong giới phát triển phần mềm cho Linux
      Nói nghiêm túc thì cái tên này tự mâu thuẫn. /index.html đúng nghĩa là một URL quen thuộc và hầu hết lập trình viên web đều biết. Nhưng việc tạo ra cả đống URL có ý nghĩa được định nghĩa sẵn rồi dán nhãn “well-known” cho chúng không khiến chúng tự nhiên trở nên nổi tiếng thật