ถ้าคุณอยากนิยาม Well-Known URI

 (mnot.net)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อไคลเอนต์รู้จักเว็บไซต์นั้นอยู่แล้ว และต้องค้นหาข้อมูลระดับทั้งเว็บไซต์อย่างมีประสิทธิภาพ Well-Known URI เหมาะที่สุด
  • การวางนโยบายไว้ที่ตำแหน่งศูนย์กลางแบบ robots.txt ช่วยลดการตรวจซ้ำได้ แต่ก็ใช้เพื่อเปิดการโต้ตอบระดับทั้งเว็บไซต์อย่าง change-password ได้เช่นกัน
  • หากโปรโตคอลสามารถส่ง URL จริงได้ การใช้ Well-Known URI จะทำให้ บริการกับเว็บไซต์ถูกผูกแบบ 1:1 จนการปรับใช้และการทำ routing แข็งตัวเกินไป
  • เมื่อนำไปใช้กับกลไกการค้นพบหรือ metadata ของเนื้อหา ควรพิจารณา โครงสร้างการปฏิบัติการ อย่างชื่อโฮสต์เริ่มต้น ตำแหน่งค้นหา การรีไดเร็กต์ และเว็บไซต์ที่มีผู้เผยแพร่หลายรายก่อน
  • หากต้องย้ายจากพาธคงที่ที่รูทเดิม จำเป็นต้องมีแผนการเปลี่ยนผ่าน และควรระบุสคีมที่เกี่ยวข้องนอกเหนือจาก http·https ให้ชัดเจนเพื่อเพิ่มโอกาสในการลงทะเบียนสำเร็จ

สถานการณ์ที่ Well-Known URI เหมาะสม

  • Mark Nottingham หนึ่งในผู้เขียน Well-Known URI specification และเป็น Designated Expert ของ registry ได้แชร์เกณฑ์เชิงปฏิบัติว่าเมื่อใดควรใช้ Well-Known URI
  • เกณฑ์เหล่านี้ไม่ใช่ข้อกำหนดการลงทะเบียนทั้งหมด แต่ใกล้เคียงกับ แนวปฏิบัติที่ดี มากกว่า
  • ตำแหน่ง Well-Known เหมาะเมื่อไคลเอนต์รู้จักเว็บไซต์นั้นอยู่แล้ว และต้องค้นพบบางอย่างหรือโต้ตอบกับบางอย่างในระดับทั้งเว็บไซต์
    • ในที่นี้ เว็บไซต์ในเชิงเทคนิคหมายถึง origin ซึ่งเป็นทูเพิล (scheme, host, port)
  • แม้ robots.txt จะมีอยู่ก่อน RFC แต่ก็เป็นหนึ่งในเหตุผลหลักที่ทำให้มีการสงวนพื้นที่ Well-Known
    • crawler จำเป็นต้องรู้ว่านโยบายการเข้าถึงของเว็บไซต์เป็นอย่างไร
    • การวางนโยบายไว้ในตำแหน่งศูนย์กลางทำให้ไม่ต้องตรวจ header และเนื้อหาของทุกการตอบกลับ
  • ตำแหน่ง Well-Known ไม่จำเป็นต้องเก็บเฉพาะนโยบายเท่านั้น
    • หากเป็นกลไกที่ไคลเอนต์รู้จักเว็บไซต์นั้นอยู่แล้ว และต้องเรียนรู้หรือโต้ตอบกับบางอย่างในระดับทั้งเว็บไซต์ ก็อาจเป็นผู้สมัครที่เหมาะสม
    • ตำแหน่ง Well-Known ของ change-password ช่วยให้ไคลเอนต์เปลี่ยนรหัสผ่านของเว็บไซต์นั้นได้

กรณีที่มันกลายเป็นเครื่องมือที่ไม่เหมาะ

  • บางการออกแบบกำหนดตำแหน่ง Well-Known ไม่ใช่เพราะปัญหาจริง แต่เพราะ มันดูเหมือนควรทำแบบนั้น
  • การมีรายการในพื้นที่ลงทะเบียนไม่ได้หมายความว่าจะตามมาด้วยความชอบธรรมหรืออัตราการยอมรับใช้งาน
    • ตำแหน่ง Well-Known แก้ปัญหาเฉพาะแบบ “ไคลเอนต์รู้จักเว็บไซต์อยู่แล้ว และมีบางอย่างที่ต้องใช้ในระดับทั้งเว็บไซต์”
    • หากโปรโตคอลไม่ได้มีปัญหาแบบนั้น การลงทะเบียนอาจสร้างปัญหาใหม่ และไม่ได้นำไปสู่การยอมรับใช้งานตามที่คาด
  • ข้อเสนอบางอย่างใช้ตำแหน่ง Well-Known เสมือนเป็น ตัวย่อ URL
    • ในโปรโตคอลจะส่งเฉพาะเว็บไซต์ที่เกี่ยวข้อง ไม่ได้ส่ง URL แบบเต็ม
    • แล้วตำแหน่ง Well-Known จะเติมส่วนพาธที่เหลือให้
  • แพตเทิร์นนี้ทำให้บริการกับเว็บไซต์ถูกตรึงไว้ใน ความสัมพันธ์แบบ 1:1
    • หากการปรับใช้ต้องใช้หลายบริการ ก็ต้องสร้างเว็บไซต์อื่นเพิ่ม
    • และยังต้องมีวิธีแยกต่างหากเพื่อส่งผู้ใช้ไปยังเว็บไซต์ที่เหมาะสม
  • หากโปรโตคอลส่งได้จริงแค่ชื่อโฮสต์ การใช้ตำแหน่ง Well-Known ก็อาจสมเหตุสมผล
  • แต่ถ้าใช้ URL จริงได้ ก็มักจะดีกว่าที่จะไม่ใช้ตำแหน่ง Well-Known และหากเลือกใช้เพราะความสะดวกหรือเพราะให้ความรู้สึกเป็นทางการ การปรับใช้อาจแข็งตัวโดยไม่จำเป็น

กับดักที่เกิดในกลไกการค้นพบ

  • โปรโตคอลจำนวนมากพยายามใช้ตำแหน่ง Well-Known เป็น กลไกการค้นพบ โดยตั้งอยู่บนสมมติฐานว่า “ผู้ใช้รู้จักเว็บไซต์นั้นอยู่แล้ว”
  • แต่ในความเป็นจริง ขอบเขตการโต้ตอบปัจจุบันของผู้ใช้กับตำแหน่งที่เกิดการค้นพบอาจไม่ตรงกัน
    • หากไคลเอนต์เริ่มที่ login.example.com ก็จะเกิดคำถามว่าควรค้นหาตำแหน่ง Well-Known ที่เว็บไซต์นั้น หรือที่ example.com
    • ต้องกำหนดด้วยว่าควรตามการรีไดเร็กต์จากฝั่งหนึ่งไปอีกฝั่งหนึ่งหรือไม่
    • และอาจไม่ชัดเจนว่าผู้เผยแพร่ควรให้ตำแหน่ง Well-Known ไว้ที่เว็บไซต์ใดเพื่อให้ทำงานร่วมกันได้
  • ปัญหานี้ยิ่งสำคัญเมื่อโปรโตคอลไม่ได้จัดการกับตัวเว็บไซต์จริง ๆ แต่ใช้ HTTP เพื่อจุดประสงค์อื่น
  • อาจอยากกำหนดให้วางตำแหน่ง Well-Known ของชื่อโดเมนที่จดทะเบียนได้ไว้ที่ apex แต่ในบางสภาพแวดล้อมอาจทำได้ยากในเชิงปฏิบัติการ
  • โปรโตคอลในกลุ่มนี้ต้องพิจารณาทั้งสิ่งที่กำลังค้นพบ และตำแหน่งที่ผู้ใช้เริ่มต้นไปพร้อมกัน
    • ต้องกำหนดวิธีค้นหาชื่อโฮสต์ที่ถูกต้องได้อย่างเสถียร โดยไม่ตั้งสมมติฐานเกี่ยวกับสถาปัตยกรรมเว็บมากเกินไป

ข้อแลกเปลี่ยนเมื่อใช้กับ metadata ของเนื้อหา

  • บางโปรโตคอลพยายามใช้ตำแหน่ง Well-Known เพื่อเรียนรู้เกี่ยวกับเนื้อหาของเว็บไซต์
  • /robots.txt ทำงานในลักษณะนี้ แต่แพตเทิร์นนี้ไม่ได้เข้ากับ metadata ของเนื้อหาทุกแบบได้ง่ายเสมอไป
  • เว็บไซต์จำนวนมากเป็นตัวแทนของผู้เผยแพร่หลายราย
    • ตัวอย่างคือธรรมเนียม /~username/ ในอดีต
  • การวาง metadata ของเนื้อหาไว้ในตำแหน่งศูนย์กลางทำให้เกิดปัญหาสองอย่าง
    • กลไกนั้นอาจแทบใช้งานไม่ได้จริงสำหรับผู้ใช้แต่ละราย
    • ผู้ดูแลระบบอาจต้องสร้างโครงสร้างพื้นฐานที่ซับซ้อนเพื่อรองรับการควบคุมของผู้ใช้และการกำกับดูแล
  • การปรับใช้แบบนี้แสดงให้เห็นถึงข้อแลกเปลี่ยนระหว่าง ความสะดวกกับความละเอียด
    • อาจจำเป็นต้องสร้างกลไก metadata แบบขนานใน HTTP response header หรือตัวเนื้อหาเอง
    • และยังต้องจัดระเบียบวิธีแนบ metadata ที่แตกต่างกันด้วย
  • ไม่ใช่ว่าจะใช้ตำแหน่ง Well-Known กับ metadata ของทรัพยากรไม่ได้ แต่การทำเช่นนั้นอาจต้องใช้แรงมากกว่าที่คาดมาก
  • โปรโตคอลที่ใช้ตำแหน่ง Well-Known กับ metadata ของทรัพยากรต้องคำนึงถึงโครงสร้างเว็บไซต์ที่หลากหลายบนเว็บ

สิ่งที่ควรพิจารณาเมื่อลงทะเบียนและเปลี่ยนผ่าน

  • มีข้อเสนอบางอย่างที่นิยามตำแหน่งคงที่ไว้ที่รูทอยู่ก่อนแล้ว
    • กรณีแบบนี้เช่น /robots.txt ที่มารู้จักตำแหน่ง Well-Known ภายหลัง
  • ในกรณีเช่นนี้ จำเป็นต้องมี แผนการเปลี่ยนผ่าน สำหรับการปรับใช้เดิม
    • ผู้เสนอมีแนวโน้มจะโฟกัสกับฐานการปรับใช้ปัจจุบันมากเกินไป
    • หากมีแผนการเปลี่ยนผ่านที่ดีในช่วงเวลาที่สมเหตุสมผล ก็สามารถจัดการการย้ายไปยังตำแหน่ง Well-Known ได้
  • ข้อเสนอจำนวนมากตั้งสมมติฐานโดยนัยว่าเป็น URL แบบ http และ https
  • ตำแหน่ง Well-Known ใช้ได้กับ URL scheme อื่นด้วย จึงควร ระบุสคีมที่เกี่ยวข้องให้ชัดเจน
  • ตำแหน่ง Well-Known จำเป็นต้องลงทะเบียน
    • ลิงก์ดังกล่าวมีแนวทางว่าเมื่อใดควรลงทะเบียน และควรเลือกชื่ออย่างไร
    • แนวทางการลงทะเบียนนี้ต่างจากคำแนะนำก่อนหน้า เพราะมีผลต่อโอกาสสำเร็จในการลงทะเบียนจริง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความเห็นใน Hacker News

  • อยากให้ใช้แนวทางแบบนี้แทนการสร้างมาตรฐานใหม่ใน root namespace อยู่เรื่อย ๆ นึกถึง llms.txt เป็นตัวอย่าง
    เลิกทำให้โดเมนรูทเลอะเทอะได้แล้วก็น่าจะดี
    https://llmstxt.org/

    • LLMs.txt ดูไม่มีความหมายมากนักในตัวมันเอง เพราะบริษัท AI รายใหญ่ก็ไม่ได้ยอมรับใช้งาน

  • ไม่เห็นด้วย บทความนี้ไม่ได้ช่วยอะไรเท่าไรอยู่ดี เนื้อหาแทบไม่มีและเหมือนพูดแต่เรื่องที่รู้อยู่แล้ว
    ถ้าไม่มีตัวอย่างที่นำไปสู่คำแนะนำเชิงปฏิบัติจริง ความเชี่ยวชาญที่ผู้เขียนยกมาก็แทบไม่มีประโยชน์

    • ผู้เขียนเคยพยายามถอดการรองรับ HTTP 418 "I'm a teapot" ออกจาก NodeJS มาก่อน และผลคือเกิดแรงต้านจน Python กลับเพิ่มการรองรับเข้าไปแทน
      https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
    • แรงไปหน่อย ผู้เขียนน่าจะเคยได้รับคำถามจากคนที่อยากลงทะเบียน well-known path จริง ๆ และบางคนก็อาจไม่ได้คำนึงถึงโครงสร้างไซต์แบบ ~user
      บทความนี้อาจช่วยให้คนพวกนั้นใช้วิธีที่ดีกว่าได้ ถึงอย่างนั้นถ้ายังมั่นใจว่าต้องใช้ well-known URL ก็ยังมีลิงก์ไปขั้นตอนการลงทะเบียนให้ด้วย
    • ใจความของบทความคือ ถ้าจำเป็นต้องเพิ่มอะไรแบบ robots.txt ก็ไม่ควรวางไว้แบบสุ่ม ๆ แต่ต้อง บอกให้รู้ว่ามันอยู่ที่ไหน

  • ไม่เข้าใจว่าทำไมต้องเจาะจงขนาดนั้น ทำ link tree ที่ใช้งานทั่วไปได้แทน password-reset ไม่ได้หรือ?
    แม้แต่การยืนยันโดเมนของ Discord ก็น่าจะทำเป็นรายการแบบไดนามิกใต้ domain-verifications ได้ ดูเหมือนเสียเวลาเปล่า สำหรับการใช้งานของผมคงนิยามสเปกของตัวเองไว้นอก well-known มากกว่า

    • ถ้าทำสเปกเอง คนอื่นก็ไม่ใช้
      well-known endpoint ของ password-reset ใช้เพื่อให้ตัวจัดการรหัสผ่านแสดงปุ่ม "Change password..." ใน UI แล้วพาไปยังหน้าสำหรับเปลี่ยนรหัสผ่านที่ระบุไว้ในไฟล์ well-known นั้นได้โดยตรง
    • discord domain verification นั้น TXT record เองก็เป็นรายการของรายการแบบไดนามิกอยู่แล้ว จึงง่ายกว่าโครงสร้างแยกต่างหาก
      หมายความว่าไล่ดูรายการแล้วเทียบช่วงต้นของแต่ละค่ากับสตริงที่ค้นหาเพื่อหา discord domain verification จะง่ายกว่ามาก
      ตัวอย่างเช่น TXT record ของ ycombinator.com มีค่ารวมกันอย่าง openai-domain-verification=..., anthropic-domain-verification-..., google-site-verification=..., apple-domain-verification=..., dropbox-domain-verification=..., rippling-domain-verification=...
    • discord domain verification เป็นปัญหาฝั่ง Discord ไม่ได้อยู่ใน IANA registry: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
      ส่วนเรื่องทำ password-reset ให้เป็น link tree ที่ใช้งานทั่วไปได้มากขึ้นนั้น มีคำตอบไว้ละเอียดกว่าในเธรดข้างเคียง: https://news.ycombinator.com/item?id=48596286

  • ไม่ว่าจะใช้ .well-known, DNS record หรือ DNS over HTTP ก็ตาม ผมคิดว่าสิ่งสำคัญคือการทำให้ค้นพบได้เองโดยอาศัย ความเชื่อถือที่ผูกกับโดเมน
    Cloudflare ดูเหมือนจะเพิ่มความสามารถในการสังเกตการณ์ในพื้นที่นี้เข้าไปในผลิตภัณฑ์พอสมควรแล้ว และผมก็กำลังสำรวจอยู่เช่นกัน: https://instagrate-me.sudoscience.dev/
    ยิ่งการใช้งานแบบเอเจนต์เพิ่มขึ้น จำนวนบริการที่ต้องการสิ่งนี้และปริมาณที่แต่ละองค์กรต้องใช้ก็น่าจะเพิ่มขึ้นด้วย auth.md ก็ดูเป็นอีกตัวอย่างล่าสุดที่ใช้ .well-known

  • “เว็บไซต์นี้ต้องใช้เบราว์เซอร์ที่ทันสมัยกว่านี้เพื่อทำงานอย่างปลอดภัย กรุณาอัปเกรดเบราว์เซอร์ของคุณ”
    อีกทางเลือกหนึ่งคือ ทำได้แม้ไม่มี SNI
    https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

    • SNI ไม่ใช่เรื่องดีหรือ? อยากรู้ว่ามันเป็นปัญหาในกรณีไหน
    • ถ้าคุณอยู่ในฝั่งที่ต้องการ เฝ้าระวังหรือเซ็นเซอร์ ผู้ใช้เว็บ SNI ก็ไม่ดี
      เพราะงั้นมันดีมาก

  • registry ของ change-password มีการใช้งานจริงไหม? ไม่แน่ใจด้วยซ้ำว่าบอตใช้หรือเปล่า
    ในไซต์ของผมไม่เคยเห็นบอตเช็ก URL .well-known/change-password เลย มันอาจเหมาะเป็นที่วางการตั้งค่าแบบสาธารณะ แต่ไม่เหมือนเป็น กลไกสำหรับการค้นพบ

    • ตัวจัดการรหัสผ่านบางตัวอย่าง Chrome จะแสดงปุ่ม "change password" ใน UI เมื่อรหัสผ่านรั่วไหล
      ฟีเจอร์นี้อิงจาก .well-known/change-password

  • .well-known เริ่มต้นมาอย่างเรียบร้อยดี แต่เงียบ ๆ กลายเป็น ลิ้นชักรวมของจุกจิก ของเว็บรูทไปแล้ว security.txt, ACME, app-site-association และอย่างอื่นก็เพิ่มขึ้นเรื่อย ๆ

    • ไม่เข้าใจว่าหมายถึงอะไร ก็ออกแบบมาให้เป็นลิ้นชักรวมของจุกจิกตั้งแต่แรกแล้ว
    • มี ลิ้นชักรวมของจุกจิก ยังดีกว่าปล่อยจุกจิกกระจัดกระจาย
    • นั่นไม่ใช่จุดประสงค์ของมันหรือ? แทนที่จะวางของจุกจิกเกลื่อนบนเคาน์เตอร์ครัว ก็เอาใส่ลิ้นชักที่ติดป้ายว่าของจุกจิก

  • ดูเหมือนคนจะมองข้ามกันบ่อยว่า หนึ่งโดเมนมี well-known ได้หลายรายการ

  • ชื่อเรื่องเขียนว่า URI แต่ในบทความพูดถึงแค่ URL ซึ่งเป็น URI ชนิดหนึ่งเท่านั้น

  • แล้ว URI เหล่านั้นมัน well-known แค่ไหนกันจริง ๆ? :-\

    • ผมลองคุ้ยทั้งบทความ, RFC, Wikipedia และ Google อยู่ 10 นาทีเพื่อหาตัวอย่าง .well-known แต่ไม่เจอสักอัน
      เคยอ่านเจออันหนึ่งมาก่อนตอนทำงานกับ GitHub OIDC และตอนนั้นมันมีประโยชน์ทีเดียว
      ไม่เข้าใจว่าทำไมเอกสารเทคนิคชอบใช้อธิบายแนวคิดแบบยืดยาว แต่ไม่ยกตัวอย่างสักอย่าง นี่ไม่ใช่ครั้งแรกที่เจอแบบนี้
    • รวมอยู่ใน registry นี้: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    • ใน Wikipedia มีรายการที่น่าสนใจอยู่: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
    • เห็นด้วย ผมคาดหวังว่าจะมีตัวอย่างดี ๆ สักสองสามอย่างแต่ไม่เห็นเลย ตัวอย่างเดียวที่ผมรู้จักคือ OIDC discovery endpoint
    • ดูเหมือนจะเป็นสิ่งที่คนรู้จักน้อยกว่า XDG directory ในหมู่นักพัฒนาซอฟต์แวร์ฝั่ง Linux เสียอีก
      พูดจริง ๆ ชื่อนี้มันย้อนแย้ง /index.html นั่นแหละคือ URL ที่ well-known ตามความหมายตรงตัว และนักพัฒนาเว็บส่วนใหญ่ก็รู้จัก แต่การสร้าง URL จำนวนมากที่มีความหมายกำหนดไว้ล่วงหน้าแล้วติดป้ายว่า “well-known” ไม่ได้ทำให้มันกลายเป็นที่รู้จักขึ้นมาจริง ๆ