ผมจะไม่เติม query string ลงใน URL ของคุณ

 (susam.net)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังจากอ่าน No query strings ของ Chris Morgan แล้ว Susam Pal ได้ลบพารามิเตอร์ query via= ที่เคยเพิ่มไว้ใน Wander Console
  • Wander Console คือเว็บคอนโซลแบบกระจายศูนย์ โฮสต์เองได้ สำหรับให้ผู้เยี่ยมชมเว็บไซต์ส่วนตัวสุ่มสำรวจหน้าที่ชุมชนแนะนำ ปัจจุบันมีเว็บไซต์โฮสต์แล้วมากกว่า 50 แห่ง และแนะนำเว็บเพจมากกว่า 1500 หน้า
  • ฟีเจอร์ via= ทำให้ผู้ดูแลเว็บไซต์ที่ถูกแนะนำเห็นแหล่งที่มาของผู้เข้าชมจาก access log ได้ แต่ใช้วิธีแก้ URL ปลายทางโดยตรง เช่น https://midnight.pub/?via=https://susam.net/wander/
  • เมื่อเติม query string เข้าไป จะกลายเป็น URL ใหม่ ซึ่งอาจชี้ไปยัง resource อื่นหรือทำให้เกิด 404 ได้ และเคยทำให้เว็บไซต์จริงพังมาแล้ว เช่นหน้าฟอนต์ของ int10h.org ที่ใช้ query string เป็นตัวระบุของตัวเอง
  • เบราว์เซอร์มี Referer และ Referrer-Policy อยู่แล้วเพื่อควบคุมการส่งข้อมูลแหล่งที่มา ดังนั้นตั้งแต่ Wander Console 0.6.0 เป็นต้นไป จะไม่เพิ่ม query string สำหรับที่มาคำแนะนำลงใน URL ของคนอื่นอีก

บทวิจารณ์ query string ของ Chris Morgan เป็นจุดเริ่มต้น

  • Susam Pal อ่านบทความ No query strings ของ Chris Morgan แล้วตัดสินใจลบพารามิเตอร์ query via= ที่เคยเพิ่มไว้ในโปรเจกต์ Wander Console ของตน
  • Chris Morgan ไม่ต้องการให้คนอื่นเติมข้อมูลติดตามลงใน URL ของเขา เช่น https://chrismorgan.info/no-query-strings?ref=example.com
  • ถ้าต้องการข้อมูลแหล่งที่มา ก็สามารถดู HTTP header Referer ได้ และหากไม่มี header นี้ ก็มักจะมีเหตุผลสมควรอยู่แล้ว
  • Susam Pal เคยได้รับบทเรียนเรื่องการคงเส้นใต้ลิงก์และคงสีม่วงของลิงก์ที่เคยเปิดอ่าน จาก feedback แบบละเอียด ที่ Chris Morgan เคยฝากไว้บน Hacker News เกี่ยวกับกฎ CSS boilerplate ของเขา
  • นับจากนั้นมาก็ได้ติดตามอ่านบทความและความเห็นด้านเว็บของ Chris Morgan มาโดยตลอด และยกคอมเมนต์ล่าสุดบน Lobsters ใน Adding author context to RSS เป็นอีกตัวอย่างที่มีประโยชน์

โครงสร้างและเป้าหมายของ Wander Console

  • Wander Console คือเว็บคอนโซลขนาดเล็ก แบบกระจายศูนย์ และโฮสต์เองได้ ที่ช่วยให้ผู้เยี่ยมชมเว็บไซต์ส่วนตัวสำรวจเว็บไซต์และหน้าที่น่าสนใจซึ่งชุมชนของผู้ดูแลเว็บไซต์ส่วนตัวอิสระแนะนำไว้
  • คอนโซลของ Susam Pal อยู่ที่ susam.net/wander/ และเมื่อกดปุ่ม Wander จะโหลดเว็บเพจส่วนตัวแบบสุ่มที่ชุมชน Wander แนะนำไว้
  • เครื่องมือนี้ประกอบด้วยไฟล์ HTML หนึ่งไฟล์ที่ทำหน้าที่เป็นคอนโซล และไฟล์ JavaScript หนึ่งไฟล์ที่ผู้ดูแลเว็บใช้กำหนดรายชื่อคอนโซลเพื่อนบ้านและรายชื่อเว็บเพจที่แนะนำ
  • เพียงคัดลอกสองไฟล์นี้ไปไว้บนเว็บเซิร์ฟเวอร์ ก็ใช้งานได้ด้วยเว็บเซิร์ฟเวอร์ทั่วไป โดยไม่ต้องมี logic ฝั่งเซิร์ฟเวอร์หรือซอฟต์แวร์ฝั่งเซิร์ฟเวอร์เพิ่มเติม
  • จึงสามารถโฮสต์ได้แม้ในสภาพแวดล้อมที่มีข้อจำกัด เช่น Codeberg Pages หรือ GitHub Pages
  • เมื่อกดปุ่ม Wander คอนโซลจะเชื่อมต่อไปยังคอนโซลระยะไกลอื่น ๆ ดึงคำแนะนำเว็บเพจมา แล้วสุ่มเลือกหนึ่งหน้าเพื่อโหลดในเบราว์เซอร์
  • มันคล้าย StumbleUpon ที่เลิกให้บริการไปแล้วอยู่บ้าง แต่ต่างกันตรงที่เป็นระบบกระจายศูนย์เต็มรูปแบบ
  • ยังคล้าย webring อยู่เล็กน้อย แต่เครือข่ายชุมชนไม่ได้ถูกจำกัดให้เป็นโครงสร้างแบบวงแหวน และสามารถเป็นกราฟรูปแบบใดก็ได้
  • ตอนนี้มีเว็บไซต์มากกว่า 50 แห่งที่โฮสต์เครื่องมือนี้ และเมื่อรวมกันแล้วมีการแนะนำเว็บเพจมากกว่า 1500 หน้า
  • ดู snapshot ล่าสุดของคอนโซลที่รู้จักและหน้าที่ถูกแนะนำได้ที่ susam.codeberg.page/wcn/
  • หากต้องการดูรายละเอียดเพิ่มเติมของเครื่องมือหรือวิธีตั้งค่าบนเว็บไซต์ของตัวเอง ให้ดูที่ codeberg.org/susam/wander

พารามิเตอร์ query via= ที่เป็นฟีเจอร์ผิดพลาด

  • ใน Wander Console 0.4.0 มีการเพิ่มฟีเจอร์ที่แนบพารามิเตอร์ query via= เวลาจะโหลดเว็บเพจ
  • ตัวอย่างเช่น ถ้าเจอ midnight.pub จากคอนโซล susam.net/wander/ เดิมจะโหลดหน้าด้วย URL ต่อไปนี้
https://midnight.pub/?via=https://susam.net/wander/
  • วิธีนี้ทำให้ผู้ดูแลเว็บไซต์ที่ถูกแนะนำตรวจสอบจาก access log ได้ว่าการเข้าชมนั้นมาจาก Wander Console
  • ฟีเจอร์นี้ถูกเพิ่มเข้ามาหลังเห็น feature request บน Codeberg แต่ในตอนแรกก็ลังเลอยู่
  • ตอนนั้นใกล้กำหนดส่งงานวิจัยด้าน algebraic graph theory และส่วนใหญ่ของ Wander Console เองก็ถูกสร้างขึ้นในช่วงพักสั้น ๆ ระหว่างทำวิจัย
  • เวอร์ชันแรกของคอนโซลถูกสร้างขึ้นในเช้าตรู่วันหนึ่งภายในเวลาประมาณ 1 ชั่วโมง 30 นาที และฟีเจอร์ via= ก็ถูกทำขึ้นในช่วงพักสั้น ๆ คล้ายกัน
  • Susam Pal ชอบแนวทางดูแลโปรเจกต์งานอดิเรกเล็ก ๆ ด้วยการจำกัดขอบเขต และเมื่อทำครบตามความต้องการหลักแล้วก็ถือว่าฟีเจอร์เสร็จสมบูรณ์ แทนที่จะเติมฟีเจอร์ต่อไปเรื่อย ๆ
  • ถึงอย่างนั้น เขาก็มองว่าความเหนื่อยล้าและภาระงานวิจัยที่หนัก ทำให้ตนเองไม่อาจมองข้ามคำขอฟีเจอร์นี้ได้
  • ฟีเจอร์ via= มีตัวเลือกให้ปิดได้ แต่ภายหลังก็ตัดสินว่านี่ก็เป็นความผิดพลาดเช่นกัน
  • ฟีเจอร์ที่น่าสงสัย ต่อให้จะทำ ก็ควรเป็นแบบ เปิดใช้โดยชัดเจน ไม่ใช่เปิดเป็นค่าเริ่มต้นแล้วค่อยปิดได้
  • คำพูดจาก Jurassic Park ที่ว่า “มัวแต่สนใจว่าทำได้หรือเปล่า จนไม่ได้คิดว่าควรทำหรือไม่” ดูจะเข้ากับสถานการณ์นี้พอดี

query string ทำให้ URL จริงพังได้

  • หลังจากทำฟีเจอร์ via= แล้ว ก็พบว่าหน้าหนึ่งบนเว็บไซต์ที่ชอบไม่สามารถโหลดผ่านคอนโซลได้
  • URL ที่เกี่ยวข้อง ซึ่งคล้ายกันแต่ต่างกันเล็กน้อย มีดังนี้
  • URL แรกและ URL ที่สองโหลดได้ตามปกติ แต่ URL ที่สามจะคืนหน้า error HTTP 404
  • เว็บไซต์นี้ใช้ query string เพื่อตัดสินใจว่าจะแสดงคอลเลกชันฟอนต์ชุดใดจากหลายชุด
  • ถ้าเติม query string ตามอำเภอใจเข้าไป เว็บไซต์จะพยายามตีความมันเป็นตัวระบุคอลเลกชันฟอนต์ จึงทำให้โหลดหน้าไม่สำเร็จ
  • เมื่อตอนที่ Wander Console เติมพารามิเตอร์ query via= ให้กับ URL แรก หน้าเว็บก็พังด้วยเหตุผลเดียวกัน
  • เมื่อเปลี่ยน URL ต่อให้เป็นเพียงการเพิ่ม query string ที่ดูเล็กน้อย มันก็กลายเป็น URL ใหม่
  • URL ใหม่นี้อาจชี้ไปยัง resource ที่ต่างออกไปโดยสิ้นเชิง หรืออาจไม่ชี้ไปยัง resource ใดเลยก็ได้
  • Susam Pal จึงมองว่าการเติม query string via= ทำให้ตนเองไปทำลาย URL ปกติของเว็บไซต์ที่ตน ชื่นชอบ

ปัญหาของการเลี่ยงผ่าน Referer และ Referrer-Policy

  • ในเว็บเบราว์เซอร์มี HTTP header Referer สำหรับข้อมูลแหล่งที่มาอยู่แล้ว
  • header นี้ถูกควบคุมโดย Referrer-Policy
  • Referrer-Policy สามารถตั้งค่าได้ในระดับเซิร์ฟเวอร์ ระดับเอกสาร และระดับลิงก์รายตัว
  • มาตรฐานเว็บมีวิธีควบคุมโดยเจตนาอยู่แล้วสำหรับกำหนดว่าจะส่งข้อมูลแหล่งที่มาในขอบเขตใด
  • วิธีแนบ query string สำหรับที่มาคำแนะนำลงใน URL เป็นการเลี่ยงผ่านกลไกควบคุมเหล่านี้
  • มันเท่ากับดึงประเด็นเรื่องความเป็นส่วนตัวและการระบุแหล่งที่มาออกมาจากกลไก referrer แล้วฝังลงไปตรง ๆ ใน URL ปลายทาง
  • จึงเห็นว่าเครื่องมือ HTML ไม่ควรเปลี่ยน URL ด้วยวิธีแบบนี้
  • และการแก้ URL แทนผู้ใช้เพื่อใส่ query string บอกที่มาคำแนะนำลงไป ก็ไม่ใช่สิ่งที่ถูกต้องเช่นกัน

การลบฟีเจอร์และหลักการหลังจากนี้

  • ฟีเจอร์ query string สำหรับที่มาคำแนะนำถูกลบออกจาก Wander Console แล้ว
  • เดิมอาจเก็บไว้เป็นตัวเลือกแบบเปิดใช้โดยชัดเจนได้ แต่เมื่อมองว่าเป็นฟีเจอร์ที่ผิดพลาด ก็ไม่อยากให้มันคงอยู่ในซอฟต์แวร์ไม่ว่าในรูปแบบใด
  • เขามองว่านี่เป็นจังหวะที่ดีในการลบ เพราะโปรเจกต์ยังใหม่และยังอยู่ในช่วง release 0.x
  • เมื่อ No query strings ของ Chris Morgan ปรากฏขึ้นใน feed reader เขาจึงแบ่งเวลาจากงานวิจัยมาลบฟีเจอร์นี้
  • รายละเอียดการลบดูได้จาก commit b26d77c
  • ใน release ล่าสุด 0.6.0 ไม่มีฟีเจอร์นี้อีกต่อไป
  • ต่อไปหากสร้างโปรเจกต์งานอดิเรกใหม่ที่ต้องโหลด URL เขาได้ตั้งหลักการไว้ว่าจะโหลดตามที่เจ้าของเว็บไซต์ตั้งใจไว้ทุกประการ
  • และได้ข้อสรุปว่าจะไม่เพิ่ม query string ลงใน URL ของคนอื่นอีก

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

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

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Lobste.rs

  • ขอบคุณที่บอกว่าบทความของฉันช่วยอย่างไร เหตุผลที่ฉันเขียนรีวิวละเอียดมีหลายอย่าง ทั้งเพื่อความพึงพอใจของตัวเอง เพื่อช่วยโปรเจ็กต์ต้นฉบับ และบางครั้งก็เพราะนักพัฒนาสนใจ บางครั้งก็ไม่ แต่ก็อาจเป็นเพราะ มีใครบางคนบนอินเทอร์เน็ต คิดผิด อยู่
    แต่เหตุผลที่ใหญ่ที่สุดคือฉัน ชอบการสอน และรู้ว่าคนอื่นอ่านรีวิวพวกนี้อยู่ จริง ๆ แล้วรีวิวของฉันมักเป็นคอมเมนต์ที่ได้คะแนนโหวตสูงที่สุดอยู่เสมอ
    บางครั้งฉันให้คุณค่ากับคอมเมนต์ขอบคุณจากคนแปลกหน้ามากจริง ๆ และคำขอบคุณละเอียดแบบนี้ก็ทำให้รู้สึกอบอุ่นยิ่งขึ้น
    ที่น่าสนใจคือฉันเพิ่งเจอเว็บไซต์ของคุณเมื่อเดือนมกราคม และชอบบทความ “more purple links, please” มากเป็นพิเศษ แต่พอมาวันนี้ถึงได้รู้ว่าโดยไม่รู้ตัวฉันคงมีอิทธิพลต่อจุดยืนของคุณไปแล้ว
    เมื่อวานฉันเพิ่งเปิดตัวเว็บไซต์ใหม่ และจากนี้ไปตั้งใจจะลงรีวิวในสื่อต่าง ๆ ให้มากขึ้นอีกมาก เดือนที่แล้วฉันเขียนแผนนี้ไว้เล็กน้อย: https://lobste.rs/s/vpdpkq/llm_reviews_cargo_crev#c_8uk441
    อีกอย่างหนึ่งที่ค่อนข้างน่าแปลกใจก็คือ มีอีกตัวอย่างหนึ่งของหน้าที่แสดงอาการแพ้ต่อ query string ที่ถูกเพิ่มเข้ามา อยู่แล้ว เว็บไซต์นั้นใช้ query string สำหรับ route ไปยังหน้าลูกเฉพาะหน้านั้นในรูปแบบ ?1, ?2, ?3, ?4 ส่วนหน้าอื่น ๆ กลับรับ query string ได้ การแบ่งหน้าตามลำดับนั้นชัดเจนว่าเป็นโครงสร้างแบบลำดับชั้น จึงขัดกับจิตวิญญาณของ URL แต่รูปแบบอย่าง ?page=1 ก็พบได้ทั่วไป
    ตอนตัดสินใจว่าจะคืน status code อะไร ฉันกังวลว่า 404 อาจก่อผลข้างเคียงจากสมมติฐานที่ผิดพลาด แต่บางทีฉันอาจกังวลเกินไป ฉันลืมไปว่าเว็บจำนวนมากไม่ได้ใช้ path อย่างมีความหมาย

    • ไม่ได้พิจารณาจะคืน "418 I'm not a teapot" สำหรับ query string ที่ไม่ได้รับอนุญาตบ้างหรือ?

  • ดีมาก Wander console กำลังเติบโตได้อย่างยอดเยี่ยม และความใส่ใจในรายละเอียดที่ Susam แสดงให้เห็นที่นี่ก็ดูเป็นเหตุผลสำคัญว่าทำไมมันถึงเวิร์ก
    ฉันเองก็เคยเห็น URL ของฉันถูกเติม query string ที่ไม่ต้องการอยู่หลายแบบ Newsletter ของ Programmer Weekly ใส่ query มาให้ แต่ก็มี referrer header อยู่แล้ว เลยซ้ำซ้อน
    อีกกรณีหนึ่งดูเหมือนจะใส่ unique ID ให้สมาชิกแต่ละคน ซึ่งฉันไม่ต้องการเลย ที่ลำบากคือไม่มี referrer ทำให้ไม่รู้ด้วยซ้ำว่าไซต์ไหนเป็นคนทำ
    /blog/modeling-on-demand-pricing/?ck_subscriber_id=<unique-id>

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

    • หมายความว่าอย่างไร?

  • “ทำไมถึงเพิ่มเข้าไปน่ะหรือ? ก็ยอมตามความต้องการของมหาชน” งั้นหรือ มันถึงขั้นนั้นจริงหรือ? มันเป็นแค่ คอมเมนต์สั้น ๆ ที่ได้โหวต 5 คะแนนใน issue ที่ไม่เกี่ยวข้องเองนะ ดูเหมือนการต่อสู้ก่อนยอมจำนนจะไม่ได้ดุเดือดเท่าไร ;-)

    • ฉันไม่ค่อยแน่ใจว่าคำว่า ‘คอมเมนต์สั้น ๆ’ ที่นี่หมายถึงอะไร คอมเมนต์นั้นมาจากคนที่ได้ลองใช้ซอฟต์แวร์ของฉันโดยตรง ติดตั้งมันบนเว็บไซต์ของตัวเอง และทำให้เว็บไซต์นั้นกลายเป็นส่วนหนึ่งของเครือข่ายชุมชน ฉันไม่คิดว่าจะลดค่ามันว่าเป็นเรื่อง ‘เล็กน้อย’ ได้
      ตอนที่โปรเจ็กต์นี้มีผู้ใช้ราวสิบคน ถ้าข้อเสนอฟีเจอร์ใหม่ได้โหวต 5 คะแนน สำหรับฉันมันก็รู้สึกเหมือนเป็น ความต้องการของมหาชน
      ปกติโปรเจ็กต์ของฉันเป็นเครื่องมือเล็ก ๆ ที่ทำเป็นงานอดิเรก ยกเว้นไม่กี่ตัว จำนวนผู้ใช้ไม่ได้มากนัก เพราะอย่างนั้นเมื่อได้รับคำขอฟีเจอร์หรือรายงานบั๊ก ไม่ว่าจะอยู่ใน issue ที่เกี่ยวข้องหรือไม่เกี่ยวข้อง มันก็สำคัญสำหรับฉัน ถึงจะยังลงมือทำทันทีไม่ได้เสมอไป แต่ฉันจะจดไว้ในใจว่าคำขอไหนมีความต้องการมากกว่า