Blog

รหัสสถานะ 506 คืออะไร: Variant Also Negotiates? วนลูปไม่รู้จบของรูปแบบ

INEZA Felin-Michel

INEZA Felin-Michel

29 October 2025

รหัสสถานะ 506 คืออะไร: Variant Also Negotiates? วนลูปไม่รู้จบของรูปแบบ

ลองจินตนาการว่าคุณเดินเข้าไปในร้านอาหารแห่งหนึ่ง ซึ่งเมนูอาหารนั้นซับซ้อนจนพนักงานเสิร์ฟต้องปรึกษาเมนูอื่นเพื่อทำความเข้าใจเมนูแรก และเมนูที่สองนั้นก็ต้องการการตรวจสอบจากเมนูที่สาม ทำให้เกิดการวนลูปของการตรวจสอบเมนูอย่างไม่รู้จบ ในที่สุดพนักงานเสิร์ฟก็ยอมแพ้และบอกคุณว่า "ผมติดขัดไปหมดแล้ว! ผมไม่รู้แม้กระทั่งจะบอกคุณได้อย่างไรว่าเราเสิร์ฟอะไรบ้าง"

นี่คือสิ่งที่เกิดขึ้นกับหนึ่งในรหัสสถานะ HTTP ที่คลุมเครือและเป็นเชิงทฤษฎีมากที่สุด: 506 Variant Also Negotiates

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

หากคุณหลงใหลในส่วนที่ลึกที่สุดและคลุมเครือที่สุดของโปรโตคอลเว็บ หรือหากคุณเป็นผู้ดูแลระบบที่ทำงานกับการกำหนดค่าเว็บเซิร์ฟเวอร์ขั้นสูง เรื่องราวของ 506 คือการเจาะลึกทางเทคนิคที่น่าสนใจ

💡
หากคุณกำลังสร้าง API และบริการเว็บที่ใช้งานได้จริง (ซึ่งเป็นสิ่งสำคัญในแต่ละวัน) คุณจำเป็นต้องมีเครื่องมือที่จัดการรหัสสถานะที่คุณจะพบเจอจริง ๆ ดาวน์โหลด Apidog ฟรี; เป็นแพลตฟอร์ม API แบบครบวงจรที่ช่วยให้คุณทดสอบและดีบักรหัสสถานะทั่วไปที่ส่งผลกระทบต่อแอปพลิเคชันของคุณจริง ๆ
button

ตอนนี้ เรามาไขปริศนาของรหัสสถานะ HTTP 506 กัน

ปูพื้นฐาน: การเจรจาเนื้อหา (Content Negotiation) และการเข้ารหัสเนื้อหาแบบโปร่งใส (Transparent Content Encoding)

เพื่อให้เข้าใจ 506 เราต้องทำความเข้าใจคุณสมบัติ HTTP ขั้นสูงสองประการก่อน: การเจรจาเนื้อหา (content negotiation) และ การเข้ารหัสเนื้อหาแบบโปร่งใส (transparent content encoding)

การเจรจาเนื้อหา (Content Negotiation): การสื่อสารด้วยภาษาของไคลเอนต์

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

จากนั้นเซิร์ฟเวอร์จะเลือกรูปแบบ (variant) ที่ดีที่สุดและส่งให้ ตัวอย่างเช่น หากคุณมีทรัพยากรที่พร้อมใช้งานทั้งภาษาอังกฤษและฝรั่งเศส เซิร์ฟเวอร์จะใช้การเจรจาเนื้อหาเพื่อตัดสินใจว่าจะส่งอันไหน

การเข้ารหัสเนื้อหาแบบโปร่งใส (Transparent Content Encoding)

นี่คือจุดที่น่าสนใจ RFC 2295 ได้แนะนำแนวคิดของ "การเจรจาเนื้อหาแบบโปร่งใส" ซึ่งอนุญาตให้มีกลไกการเจรจาที่ซับซ้อนมากขึ้น โดยได้แนะนำแนวคิดของ "รูปแบบ (variants)" ซึ่งเป็นการนำเสนอทรัพยากรเดียวกันในรูปแบบที่แตกต่างกัน

เซิร์ฟเวอร์สามารถส่งคืนรายการรูปแบบที่มีอยู่ และไคลเอนต์ที่ชาญฉลาดสามารถเลือกรูปแบบที่ดีที่สุดได้ ข้อผิดพลาด 506 ถูกกำหนดไว้โดยเฉพาะในบริบทของ RFC 2295 นี้

HTTP 506 Variant Also Negotiates หมายความว่าอย่างไร?

รหัสสถานะ 506 Variant Also Negotiates ระบุว่าเซิร์ฟเวอร์พบข้อผิดพลาดในการกำหนดค่าภายใน: ทรัพยากรรูปแบบที่เลือกเองก็ถูกกำหนดค่าให้ทำการเจรจาเนื้อหาแบบโปร่งใส ซึ่งทำให้เกิดการวนลูปไม่รู้จบ

พูดง่ายๆ คือ: เซิร์ฟเวอร์พยายามค้นหาไฟล์เวอร์ชันที่ถูกต้องเพื่อส่งให้คุณ แต่ไฟล์นั้นเองก็มีหลายเวอร์ชัน ทำให้เกิดการวนลูปการเจรจาที่ไม่สามารถแก้ไขได้

คำจำกัดความอย่างเป็นทางการของ RFC 2295 ระบุว่า:

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

การตอบสนอง 506 เชิงทฤษฎีอาจมีลักษณะดังนี้:

HTTP/1.1 506 Variant Also NegotiatesContent-Type: text/html
<html><head><title>506 Variant Also Negotiates</title></head><body><center><h1>506 Variant Also Negotiates</h1></center><hr><p>The server encountered an internal configuration error while trying to negotiate the best representation of the requested resource.</p></body></html>

กระบวนการนี้เรียกว่า การเจรจาเนื้อหา (content negotiation) ซึ่งช่วยให้เซิร์ฟเวอร์เลือกรูปแบบที่ดีที่สุดโดยอิงจากส่วนหัว (headers) เช่น Accept-Language, Accept-Encoding และ Accept-Type

อย่างไรก็ตาม หาก รูปแบบ (variant) นั้นเอง (ทรัพยากรที่เลือก) ถูกกำหนดค่าผิดพลาดให้ทำการเจรจาอีกครั้ง เซิร์ฟเวอร์ก็จะเข้าสู่การวนลูปที่ขัดแย้งกัน โดยสรุปคือ:

เซิร์ฟเวอร์กล่าวว่า "มาเจรจากันเถอะ!" และรูปแบบก็ตอบกลับว่า "ได้เลย ฉันก็เจรจาได้เหมือนกัน!" …แล้วพวกเขาก็ติดขัด

นั่นคือเมื่อข้อผิดพลาด HTTP 506 Variant Also Negotiates ปรากฏขึ้น มันเหมือนกับนักการทูตสองคนเจรจากันไม่รู้จบแทนที่จะลงนามในข้อตกลง

ทำไมสิ่งนี้ถึงสำคัญในการพัฒนา API สมัยใหม่

คุณอาจคิดว่า "โอเค แต่ฉันกำลังสร้าง API ไม่ใช่หน้าเว็บหลายภาษา ทำไมต้องสนใจ 506 ด้วย?"

นี่คือเหตุผล:

สรุปคือ การทำความเข้าใจ 506 ช่วยให้คุณออกแบบระบบที่แข็งแกร่งขึ้น และทำให้คุณเป็นผู้แก้ปัญหาที่ดีขึ้น

สถานการณ์วนลูปไม่รู้จบ: ข้อผิดพลาด 506 เกิดขึ้นได้อย่างไร

มาดูตัวอย่างที่เป็นรูปธรรม แต่เป็นเชิงทฤษฎีสูง ว่าข้อผิดพลาดนี้อาจเกิดขึ้นได้อย่างไร

การตั้งค่าเซิร์ฟเวอร์ที่กำหนดค่าผิดพลาด

ลองจินตนาการถึงเว็บไซต์ที่มีระบบการเจรจาเนื้อหาที่ซับซ้อน มีทรัพยากร /document ที่พร้อมใช้งานในหลายรูปแบบ:

  1. /document.html (เวอร์ชัน HTML)
  2. /document.pdf (เวอร์ชัน PDF)
  3. /document.json (การตอบสนอง API แบบ JSON)

เซิร์ฟเวอร์ถูกกำหนดค่าด้วย "รายการรูปแบบ (variant list)" ที่แมป /document ไปยังตัวเลือกทั้งสามนี้

การกำหนดค่าที่มีปัญหา

ตอนนี้ ลองจินตนาการว่าผู้ดูแลระบบเซิร์ฟเวอร์ทำผิดพลาดครั้งสำคัญ พวกเขากำหนดค่า รูปแบบ JSON (/document.json) ให้มีชุดรูปแบบของตัวเองด้วย:

การวนลูปไม่รู้จบ

  1. ไคลเอนต์ร้องขอ /document พร้อมส่วนหัว Accept: application/json
  2. ระบบการเจรจาเนื้อหาของเซิร์ฟเวอร์เริ่มทำงาน มันดูรายการรูปแบบสำหรับ /document และเห็นว่า /document.json เป็นรายการที่ตรงกันที่สุด
  3. จากนั้นเซิร์ฟเวอร์ก็ไปให้บริการ /document.json แต่เดี๋ยวก่อน — เซิร์ฟเวอร์ตรวจสอบการกำหนดค่าสำหรับ /document.json และพบว่ามันก็มีรายการรูปแบบด้วย!
  4. ตอนนี้เซิร์ฟเวอร์ต้องเจรจาว่าจะให้บริการ /document.json รูปแบบใด มันเข้าสู่กระบวนการเจรจาอีกครั้ง
  5. สิ่งนี้สร้างการวนลูปเชิงตรรกะ เซิร์ฟเวอร์ติดขัดอยู่กับการพยายามเจรจาทรัพยากรการเจรจาด้วยตัวมันเอง

จุดแตกหัก

หลังจากตรวจพบการวนลูปไม่รู้จบนี้ (หรือถึงขีดจำกัดการเรียกซ้ำ) เซิร์ฟเวอร์จะยอมแพ้และส่งคืนข้อผิดพลาด 506 Variant Also Negotiates โดยพื้นฐานแล้วมันกำลังบอกว่า "ฉันไม่สามารถให้บริการทรัพยากรนี้ได้ เพราะฉันติดอยู่ในวงวนไม่รู้จบของการพยายามตัดสินใจว่าจะให้บริการเวอร์ชันใด"

ทำไมคุณอาจจะไม่มีวันเห็นข้อผิดพลาด 506

รหัสสถานะ 506 อาจเป็นหนึ่งในรหัสสถานะ HTTP ที่หายากที่สุดที่คุณอาจพบเจอ นี่คือเหตุผล:

  1. การนำไปใช้งานที่จำกัด: ระบบการเจรจาเนื้อหาแบบโปร่งใสที่อธิบายไว้ใน RFC 2295 ไม่เคยถูกนำไปใช้งานอย่างแพร่หลายในเว็บเซิร์ฟเวอร์หรือเบราว์เซอร์กระแสหลัก เว็บส่วนใหญ่ใช้การเจรจาเนื้อหาที่เรียบง่ายกว่ามาก
  2. ต้องมีการกำหนดค่าที่ซับซ้อน: การสร้างข้อผิดพลาดนี้ต้องมีการกำหนดค่าเซิร์ฟเวอร์ที่เฉพาะเจาะจงมาก และค่อนข้างจะแย่ ผู้ดูแลระบบส่วนใหญ่จะไม่ตั้งค่าเซิร์ฟเวอร์ด้วยวิธีนี้
  3. ทางเลือกสมัยใหม่: ปัจจุบัน การเจรจาเนื้อหามักจะจัดการได้ง่ายกว่ามาก ไม่ว่าจะผ่านรูปแบบ URL (/api/users.json เทียบกับ /api/users.xml) หรือผ่านการแยกวิเคราะห์ส่วนหัว Accept แบบง่าย ๆ โดยไม่มีรายการรูปแบบที่ซับซ้อน
  4. การป้องกันข้อผิดพลาดที่ดีขึ้น: เว็บเซิร์ฟเวอร์สมัยใหม่น่าจะมีมาตรการป้องกันการวนลูปการกำหนดค่าดังกล่าว ซึ่งช่วยป้องกันไม่ให้เกิดข้อผิดพลาดตั้งแต่แรก

ตัวอย่างข้อผิดพลาด 506 ในโลกแห่งความเป็นจริง

ลองจินตนาการว่าคุณมีเว็บไซต์หลายภาษาที่เปิดใช้งานโมดูลการเจรจาเนื้อหาของ Apache (mod_negotiation) คุณมีไฟล์เช่น:

index.html.en
index.html.fr
index.html.de

จากนั้น โดยบังเอิญ คุณกำหนดค่า index.html ให้ทำการเจรจาด้วยเช่นกัน อาจโดยการตั้งค่าแฮนเดิลเลอร์หรือคำสั่งที่ไม่ถูกต้องใน .htaccess เมื่อ Apache พยายามให้บริการไฟล์ที่ถูกต้อง มันก็ตระหนักว่า:

"เดี๋ยวนะ… รูปแบบนี้ก็ต้องการเจรจาด้วย นั่นมันการวนลูปการกำหนดค่า!"

จากนั้น Apache ก็จะส่งข้อผิดพลาด 506 Variant Also Negotiates

พูดง่ายๆ คือ เว็บเซิร์ฟเวอร์ของคุณกำลังบอกว่า "ฉันไม่สามารถเลือกรูปแบบได้ เพราะรูปแบบของฉันไม่เด็ดขาดเกินไป"

506 เทียบกับข้อผิดพลาดเซิร์ฟเวอร์ 5xx อื่นๆ

แม้ว่าคุณจะแทบไม่เห็น 506 เลย แต่ก็เป็นประโยชน์ที่จะเข้าใจว่ามันเข้ากับตระกูล 5xx ได้อย่างไร:

506 มีเอกลักษณ์เฉพาะตัวเนื่องจากมันอธิบายข้อผิดพลาดเชิงตรรกะที่แม่นยำมาก แทนที่จะเป็นความล้มเหลวของเซิร์ฟเวอร์โดยทั่วไป

การทดสอบการเจรจาเนื้อหา (โดยไม่มี 506) ด้วย Apidog

Apidog UI ใหม่

แม้ว่าคุณอาจไม่จำเป็นต้องทดสอบ 506 โดยเฉพาะ แต่การทดสอบการเจรจาเนื้อหาเป็นส่วนสำคัญของการพัฒนา API Apidog เป็นเครื่องมือที่ยอดเยี่ยมสำหรับสิ่งนี้

  1. ทดสอบส่วนหัว Accept ที่แตกต่างกัน: แก้ไขส่วนหัว Accept ได้อย่างง่ายดายเพื่อร้องขอประเภทเนื้อหาที่แตกต่างกันจากเอนด์พอยต์เดียวกัน (เช่น application/json เทียบกับ application/xml)
  2. ตรวจสอบการตอบสนอง Content-Type: ตรวจสอบว่าเซิร์ฟเวอร์ตอบสนองด้วยส่วนหัว Content-Type ที่ถูกต้องซึ่งตรงกับสิ่งที่คุณร้องขอ
  3. ทดสอบการเจรจาภาษา: ใช้ส่วนหัว Accept-Language เพื่อทดสอบว่า API ของคุณจัดการคำขอโลแคลที่แตกต่างกันอย่างไร
  4. ตรวจสอบการบีบอัด: ทดสอบว่าเซิร์ฟเวอร์ของคุณจัดการค่า Accept-Encoding ที่แตกต่างกันอย่างไร และตรวจสอบว่าการตอบสนองถูกบีบอัดอย่างถูกต้อง
  5. สร้างการทดสอบ API ที่ครอบคลุม: สร้างชุดทดสอบที่รับรองว่า API ของคุณจัดการสถานการณ์การเจรจาเนื้อหาทั้งหมดที่คุณรองรับได้อย่างถูกต้อง
button

การทดสอบประเภทนี้ช่วยให้มั่นใจว่า API ของคุณแข็งแกร่งและสามารถให้บริการเนื้อหาที่ถูกต้องแก่ไคลเอนต์ที่ถูกต้องได้ การวินิจฉัยอัตโนมัติเป็นสิ่งที่มีค่าเมื่อคุณใช้งานเว็บไซต์ระหว่างประเทศหรือ API ที่มีการแปลเป็นภาษาท้องถิ่น

หากคุณพบข้อผิดพลาด 506 จริงๆ

เนื่องจากความหายาก หากคุณพบข้อผิดพลาด 506 ที่ถูกต้องตามกฎหมาย นี่คือความหมายของมัน:

สำหรับผู้ใช้ปลายทาง:

สำหรับผู้ดูแลระบบ/นักพัฒนา:

แนวทางปฏิบัติที่ดีที่สุดในการจัดการ 506 ในการใช้งานจริง

506 และข้อกำหนด HTTP

การเบี่ยงเบนเล็กน้อยสำหรับผู้ที่คลั่งไคล้เทคโนโลยี เพื่อความสมบูรณ์ของข้อมูล

สถานะ 506 Variant Also Negotiates ถูกนำมาใช้ครั้งแรกใน RFC 2295 ซึ่งอธิบายถึงการเจรจาเนื้อหาแบบโปร่งใส (Transparent Content Negotiation - TCN)

นี่คือสิ่งที่ข้อกำหนดระบุไว้:

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

สรุปคือ: เป็นการกำหนดค่าเซิร์ฟเวอร์ผิดพลาด

ไคลเอนต์ไม่สามารถแก้ไขได้ มีเพียงผู้ดูแลระบบเซิร์ฟเวอร์หรือนักพัฒนาเท่านั้นที่ทำได้

วิธีป้องกันข้อผิดพลาด 506 ในอนาคต

ด้วย Apidog คุณสามารถทำให้การทดสอบ API เป็นไปโดยอัตโนมัติเป็นระยะๆ กำหนดเงื่อนไขยืนยันเพื่อแจ้งเตือนการตอบสนองใดๆ ที่ส่งคืน สถานะ ≥ 500 ซึ่งรวมถึง 506 ด้วย

มรดกของ RFC 2295

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

อย่างไรก็ตาม ในทางปฏิบัติ ระบบนี้พิสูจน์แล้วว่าซับซ้อนเกินไปสำหรับการนำไปใช้ในวงกว้าง เว็บได้พัฒนาไปในทิศทางที่แตกต่างกัน โดยการเจรจาเนื้อหาที่เรียบง่ายกว่าได้กลายเป็นมาตรฐาน

รหัสสถานะ 506 ยังคงอยู่เป็นสิ่งประดิษฐ์ทางประวัติศาสตร์ของข้อกำหนดที่ทะเยอทะยานแต่สุดท้ายก็เป็นเพียงเฉพาะกลุ่ม

สรุป: ความอยากรู้อยากเห็นเชิงทฤษฎี

รหัสสถานะ HTTP 506 Variant Also Negotiates เป็นส่วนหนึ่งของประวัติศาสตร์โปรโตคอลเว็บที่น่าสนใจ ซึ่งทำหน้าที่เป็นเครื่องเตือนใจถึงความซับซ้อนที่ซ่อนอยู่เบื้องหลังสิ่งที่ดูเหมือนจะเป็นคำขอเว็บที่เรียบง่าย มันแสดงถึงความล้มเหลวเชิงตรรกะที่เฉพาะเจาะจงในระบบการเจรจาเนื้อหาที่ซับซ้อน ซึ่งไม่เคยได้รับการยอมรับในกระแสหลัก

สำหรับการพัฒนาเว็บในทางปฏิบัติ คุณจะใช้เวลาส่วนใหญ่ในการจัดการกับรหัสสถานะที่พบได้บ่อยกว่ามาก เช่น 200, 404, 500 และ 503 แต่การทำความเข้าใจรหัสอย่าง 506 จะช่วยให้คุณซาบซึ้งกับความลึกและความซับซ้อนของข้อกำหนด HTTP มากขึ้น

แม้ว่าคุณอาจไม่จำเป็นต้องจัดการข้อผิดพลาด 506 ในการใช้งานจริง แต่แนวคิดเบื้องหลังมัน — การเจรจาเนื้อหาและการกำหนดค่าเซิร์ฟเวอร์ที่เหมาะสม — ยังคงมีความสำคัญ และสำหรับการทดสอบการเจรจาเนื้อหาที่สำคัญจริงๆ ในเว็บปัจจุบัน เครื่องมืออย่าง Apidog มีคุณสมบัติที่ใช้งานได้จริงที่คุณต้องการเพื่อให้แน่ใจว่า API ของคุณให้บริการเนื้อหาที่ถูกต้องแก่ไคลเอนต์ที่ถูกต้องทุกครั้ง

button

ฝึกการออกแบบ API แบบ Design-first ใน Apidog

ค้นพบวิธีที่ง่ายขึ้นในการสร้างและใช้ API

ลงทะเบียนฟรีดาวน์โหลด