L(O*62).ONG ที่ทำให้ URL ยาวขึ้น

 (loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.ong)
4 คะแนน โดย GN⁺ 2024-06-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เครื่องมือที่ทำให้ URL ยาวขึ้น

  • ฟังก์ชัน: เป็นเครื่องมือที่ทำให้ URL ยาวมาก
  • ผู้สร้าง: สร้างร่วมกันโดย ccbikai และ ChatGPT
  • แรงบันดาลใจ: ได้แรงบันดาลใจจาก llIlI.lI

ความเห็นของ GN⁺

  • ประโยชน์ใช้สอย: เครื่องมือนี้อาจมีประโยชน์ในบางสถานการณ์ที่จำเป็นต้องทำให้ URL ยาว เช่น ใช้ทดสอบระบบที่มีพฤติกรรมแตกต่างกันตามความยาวของ URL
  • จุดที่น่าสนใจ: อาจกระตุ้นความสงสัยว่าทำไมจึงจำเป็นต้องทำให้ URL ยาว
  • ข้อพิจารณาทางเทคนิค: URL ที่ยาวเกินไปอาจทำให้เกิดปัญหาเมื่อประมวลผลในเบราว์เซอร์หรือเซิร์ฟเวอร์ ดังนั้นจึงควรใช้งานด้วยความระมัดระวัง
  • ทางเลือก: เป็นแนวคิดตรงกันข้ามกับบริการย่อ URL และยังมีเครื่องมือหลากหลายแบบสำหรับปรับความยาวของ URL

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

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

 
GN⁺ 2024-06-03
ความคิดเห็นจาก Hacker News

  • ผู้เขียนเอง เดิมตั้งใจจะเผยแพร่เองแต่ไม่รู้ว่ามีคนเอาไปลงแล้ว
    ระหว่างปล่อยใช้งานเจอปัญหาค่อนข้างเยอะ โดยหลัก ๆ เกี่ยวกับ ใบรับรอง HTTPS ความยาวสูงสุดของแต่ละเซกเมนต์ในชื่อโดเมนคือ 63 ตัวอักษร และความยาวสูงสุดของ commonName ในใบรับรอง HTTPS คือ 64 ตัวอักษร ดังนั้น Cloudflare, Vercel และ Netlify จึงเซ็นกับ Let's Encrypt ไม่ได้เพราะใช้ชื่อโดเมนเป็น commonName แต่ Zeabur ทำได้
    สุดท้ายเลยเปลี่ยนใบรับรองของ Cloudflare ไปเป็น Google Trust Services LLC แล้วเซ็นสำเร็จ สามารถดูใบรับรองที่เกี่ยวข้องได้ที่ https://crt.sh/?q=looooooooooooooooooooooooooooooooooooooooo...

    • Let's Encrypt รองรับ ใบรับรองที่ไม่มี CN มาตั้งแต่ปี 2023 จึงรองรับโดเมนยาว ๆ ได้เต็มรูปแบบแล้ว: https://community.letsencrypt.org/t/simplifying-issuance-for...
      วิธีอ้อมแบบเดิมคือใส่โดเมนที่สองซึ่งสั้นกว่าไว้ในใบรับรองด้วย แต่ก็ไม่ได้ง่ายหรือทำได้เสมอไป
    • เสริมว่า commonName ไม่ใช่สิ่งจำเป็นในใบรับรองเลย และจริง ๆ ก็แทบจะเป็นของล้าสมัย/แบบ legacy แล้ว
      Letsencrypt ไม่ได้บังคับให้ตั้ง commonName ขอแค่มี Subject Alternative Name (SAN) ก็พอ และ SAN ยาวได้ถึง 255 ตัวอักษร แต่ผู้ให้บริการบางรายก็ยังบังคับใช้ commonName โดยไม่มีเหตุผลชัดเจน
    • โดเมน .ong ไม่ใช่ว่าต้องเป็น องค์กรพัฒนาเอกชนนอกภาครัฐ ที่อยู่นอกจีนถึงจะมีสิทธิ์จดทะเบียนเหรอ?
      อ้างอิงตาม [1] https://www.godaddy.com/help/about-ong-domains-41384
    • ชอบอันนี้มาก
      ความประทับใจแรกคือ “นี่มัน QA แบบไหนกันนะ? อะไรจะพังได้บ้าง?” เข้าใจได้ที่เอาชื่อโดเมนไปใช้เป็น commonName แต่ก็ดูเป็นวิธีแบบเก่าไม่ใช่เหรอ ตอนนี้ส่วนขยาย SAN ของ x.509 น่าจะครอบคลุมเรื่องนี้แล้ว เลยแปลกใจนิดหน่อยที่หน่วยงานออกใบรับรองยังยึดติดกับวิธีเก่าอยู่
    • สุดยอดเลย จะมีบริการอีเมลด้วยไหม? ^^

  • ทำออกมาดีจนแอบหงุดหงิดเลย
    อยู่นี่: https://looooooooooooooooooooooooooooooooooooooooooooooooooo...

    • เป็นเว็บไซต์สำหรับ Hacker News แล้วทำไมถึงมี คำเตือนเนื้อหา ขึ้นล่ะ?
      1. การจัดตัวพิมพ์ใหญ่พิมพ์เล็กพอมองหรี่ตาแล้วสร้าง ลวดลายทางสายตา ที่น่าสนใจทีเดียว
      2. นี่มันอะไรกันเนี่ย 555

  • น่าจะต้องมีป้ายกำกับว่าคนต้องใส่ protocol ก่อน พอเข้าไปฉันพิมพ์ google.com ทันทีแล้วไม่มีอะไรเกิดขึ้น เลยคิดไปแป๊บหนึ่งว่ามันพังหรือโดนทราฟฟิกจาก HN ถล่มอยู่

    • ฉันก็ทำเหมือนกันเลย แล้วทำไมมันต้องจำเป็นด้วยล่ะ?
    • ไม่เข้าใจเลย ต้องใส่อะไรแน่? ฉันลองใส่ Google.com เหมือนกัน แต่ไม่รู้ว่าต้องทำอะไรต่อ
    • เห็นด้วย ตอนแรกกะจะถามว่าทำไมบนมือถือไม่ทำงาน ที่แท้ก็เพราะแบบนี้นี่เอง

  • เคยทำอะไรคล้าย ๆ กันที่ทำให้ลิงก์ “ดูน่าสงสัย”
    ฟังก์ชันสร้างลิงก์อัตโนมัติอาจพังได้ แต่ถ้าคัดลอกไปวางหรือทำลิงก์อย่างถูกต้องก็น่าจะใช้ได้
    https://sketchylinkasdf.com/ssl_webmaster.zip/qwerty/

    • ลองเพิ่ม subdomain ดีไหม? ทำทั้งโดเมนให้เป็นอะไรแบบ mail.com.sketchylinkasdf.com
    • ฉันทำงานเป็นผู้ทดสอบเจาะระบบฝั่ง purple team แล้วไม่รู้ว่า URL นั้นทำให้ PTSD กำเริบหรือทำให้ขำมากกว่ากัน
    • เว็บเจ๋งดี ฉันลองเข้าไปที่หน้า /feedback แต่ดูเหมือนไม่มีทาง ส่งฟีดแบ็ก จริง ๆ เลย ฉันพลาดอะไรไปรึเปล่า?
    • มีตัวสร้าง “URL น่าสงสัย” แบบนี้อีกหลายตัว ลองค้นดูก็เจอ

  • บริษัทชื่อ Halibut Stuff เคยขายเสื้อยืดที่แถมบริการส่งต่ออีเมลฟรี
    ที่อยู่อีเมลของฉันคือ myself@iwenttodefcon7.andalligotwas.thislousyemailaddress.com และมันทำให้ฟอร์มสมัครจำนวนมากพัง ตอนนั้นฉันทำงานทดสอบซอฟต์แวร์อยู่ เลยเคยเสนอให้ทำบริการอีเมลที่ “มีโอกาสทำให้ระบบพังสูง” ไปขายให้นักทดสอบคนอื่น ๆ แต่สุดท้ายก็เลิกคิดเพราะมองว่าคนที่ต้องใช้คงอธิบายให้คนมีอำนาจอนุมัติงบเข้าใจได้ยาก

    • แม้จะเป็นเกณฑ์แบบตั้งเอง แต่ปกติฉันจะกำหนดฟิลด์อีเมลในฐานข้อมูลเป็น n?varchar อย่างน้อย 100 ตัวอักษร

  • ชอบวิธีที่เอา URL ไปเข้ารหัสเป็น เลขฐานสอง แล้วเปลี่ยน 0 กับ 1 เป็น O และ o มาก ฉลาดสุด ๆ

    • รู้ได้ยังไง? ไปอ่านจากไหนมา? หรือฉันพลาดอะไรไป?

  • โดยพื้นฐานแล้วควรมี https:// กรอกไว้ล่วงหน้าในฟอร์ม

    • นอกจากนี้ดูเหมือนว่าจะตรวจแค่ http: + อักขระหนึ่งตัว เลยค่อนข้างชวนสับสน เช่น https:/a ก็กลายเป็นโดเมนที่ “ใช้ได้” เหมือนกัน

  • หรือฉันเป็นโรคหลอดเลือดสมองไปแล้ว? ฉันมั่นใจ 100% ว่าเมื่อวานเห็นหัวข้อนี้เป๊ะ ๆ พร้อมคอมเมนต์ชุดเดียวกันเป๊ะ ๆ แต่ตอนนี้ทั้งหมดกลับแสดงว่าโพสต์เมื่อ 5 ชั่วโมงก่อน

    • เรื่องแบบนี้จะเกิดขึ้นเมื่อโพสต์ถูกชุบชีวิตกลับมาจาก second-chance pool เท่าที่ฉันเข้าใจ วิธีเดียวที่มีอยู่ตอนนี้ในการปลุกเธรดเดิมกลับมาคือการเปลี่ยน timestamp ดังนั้นสำหรับคนที่เคยเห็นเธรดเดิมมาก่อน มันจึงทำให้งงมาก
      ลิงก์ค้นหาใน Algolia ที่มีคำอธิบายของ dang สำหรับคำถามแบบเดียวกันนี้และคำอธิบายเก่า ๆ อยู่ที่นี่: https://news.ycombinator.com/item?id=36472976
    • นี่มันวิศวกรรม Mandela effect ชัด ๆ

  • ต้องระวังเวลาทำเว็บแบบนี้ นานมาแล้วฉันเคยทำอะไรคล้ายกัน (urllengthener.sadale.net) แล้วเว็บก็ถูกแจ้งว่าเป็น “แคมเปญสแปม” ปรากฏว่าสแปมเมอร์เอาเว็บฉันไปใช้สร้าง ลิงก์สแปม และฉันก็ปิดเว็บลงทันที เลยไม่ได้โดนบทลงโทษอะไรเพิ่มเติม
    วิธีการเป็นแบบนี้ สแปมเมอร์ใช้ตัวทำ URL ยาวของฉันเป็นบริการ redirect เพื่อพาไปยังเว็บที่ภายนอกดูเหมือนโปรเจกต์ที่ยังทำไม่เสร็จ แต่จริง ๆ เป็นแค่ฉากบังหน้า เว็บนั้นมีโค้ด JavaScript ที่ตรวจจับ URL fragment identifier หรือก็คือส่วน hash ท้าย URL และถ้า fragment ตรงกับโฆษณาของตัวเองก็จะ redirect ไปยังโฆษณาสแปมจริง
    สมมติว่าสแปมเมอร์มี example.org เขาจะตั้งให้ https://urllengthener.sadale.net/foobarbaz redirect ไปที่ https://example.org แล้วส่งลิงก์สแปม https://urllengthener.sadale.net/foobarbaz#identifierXYZ ไปหาผู้เสียหาย ถ้าผู้เสียหายคลิก ก็จะไปที่ https://example.org/#identifierXYZ แล้วเห็นโฆษณา ตัว https://example.org/ เองจะดูปกติ และ URL fragment ก็เป็นองค์ประกอบฝั่งไคลเอนต์ จึงไม่ถูกบันทึกใน HTTP server log ด้วย ถ้าไม่ได้มีการแจ้งการใช้งานสแปมนี้ ฉันก็คงไม่มีวันรู้ เลยออกจะรู้สึกขอบคุณอยู่เหมือนกัน
    ทั้งนี้ example.org ไม่ใช่เว็บสแปมจริง แต่เป็นโดเมนตัวอย่าง ไว้ถ้ามีเวลาสักวันฉันควรเขียนเรื่องนี้เป็นบทความ และพอลองทดสอบบริการนี้ดูก็เหมือนว่าจะถูกนำไปใช้ในแบบเดียวกับเว็บฉันได้เป๊ะ อย่างน้อยก็ขอแนะนำอย่างยิ่งให้ปิดการ redirect ของ URL fragment identifier ตัวอย่างการนำไปใช้ในทางที่ผิดคือ https://looooooooooooooooooooooooooooooooooooooooooooooooooo...

    • ที่บอกว่า “ปิดเว็บลงแล้วเลยไม่ได้โดนบทลงโทษอะไรเพิ่มเติม” นี่คิดว่าอาจโดน บทลงโทษ อะไร จากใครเหรอ?
    • อันนี้ต่างจาก GET parameter ของ URL ยังไง? สงสัยว่ามันเกี่ยวเฉพาะกับ URL fragment อย่างเดียวหรือเปล่า JavaScript ก็ parse พารามิเตอร์ใน URL ได้ และถ้าเป็นเว็บสแปมก็อาจเอาส่วน path ไป rewrite เพื่อใช้ในทางที่ผิดได้เหมือนกัน
    • ใช่เลย ฟังดูหดหู่ แต่ดูเหมือนแค่รอ 3... 2... 1... ก็จะมีผู้ไม่หวังดีเอาบริการนี้ไปใช้ในทางไม่ดีแล้ว

  • ใช้ subdomain เพื่อทำให้ยาวขึ้นอีกไม่ได้เหรอ?
    เท่าที่ฉันเข้าใจ โดเมนยาวได้ถึง 255 ตัวอักษร
    https://a.lot.looooooooo(...)nger.than.looooooooo(...).ng

    • ความยาวรวมของ URL มีขีดจำกัดตามการใช้งานจริงอยู่ [0] และขีดจำกัดนั้นยาวเกิน 255 ตัวอักษรไปมาก ส่วน path ของ URL ก็ยาวได้ตามใจภายในขีดจำกัดนั้น ดังนั้นการใช้แค่ subdomain จึงจำกัดเกินความจำเป็น และแม้จะเอามาผสมเพิ่มก็แทบไม่มีข้อดีอะไร
      [0] https://stackoverflow.com/questions/417142/what-is-the-maxim...