อ้างอิง HTTP Status Code ฟรี

ใช้สำหรับคำขอที่มี Expect: 100-continue เซิร์ฟเวอร์ยอมรับว่าพร้อมจะรับเนื้อหาก่อนที่ไคลเอนต์จะส่ง ไม่ค่อยเห็นในแอพเว็บสมัยใหม่

ใช้บ่อยที่สุดสำหรับการอัปเกรด WebSocket — ไคลเอนต์ร้องขอ Upgrade: websocket และเซิร์ฟเวอร์ตอบกลับด้วย 101 เพื่อสลับ

การตอบสนองชั่วคราว WebDAV ที่ส่งเพื่อป้องกันการหมดเวลาของไคลเอนต์ระหว่างการดำเนินการที่นาน เลิกใช้แล้ว — เซิร์ฟเวอร์สมัยใหม่ไม่ควรส่ง

ให้เซิร์ฟเวอร์ส่งส่วนหัว Link (preload/preconnect) ในขณะที่กำลังเตรียมการตอบสนองสุดท้าย เพื่อให้เบราว์เซอร์เริ่มดึงสินทรัพย์ที่สำคัญได้เร็วขึ้น

การตอบสนองความสำเร็จมาตรฐาน ความหมายขึ้นอยู่กับวิธี HTTP: GET → ทรัพยากรที่ส่งกลับ POST/PUT → การดำเนินการเสร็จสิ้น

ทั่วไปหลังจาก POST การตอบสนองควรรวมส่วนหัว Location ที่ชี้ไปที่ URL ของทรัพยากรใหม่

สำหรับการดำเนินการแบบอะซิงโครนัส — เซิร์ฟเวอร์กำลังจัดคิวการทำงาน ไคลเอนต์ควรโพล endpoint สถานะหรือตรวจสอบภายหลัง

คำขอสำเร็จ แต่ตัวกลาง (เช่น แคช หรือพร็อกซีแปลง) ได้เปลี่ยนแปลงข้อมูล จากเซิร์ฟเวอร์ต้นทาง — ตัวอย่างเช่น การบีบอัดภาพใหม่ หายากในทางปฏิบัติ

มักใช้สำหรับการดำเนินการ DELETE หรือการอัปเดต PUT ที่ไม่จำเป็นต้องส่งคืนเนื้อหา ไคลเอนต์ไม่ควรนำทางออกจากหน้าปัจจุบัน

เช่นเดียวกับ 204 ไม่มีเนื้อหาที่ส่งคืน — แต่ไคลเอนต์ยังได้รับการบอกให้รีเซ็ตแบบฟอร์มหรือมุมมองที่สร้างคำขอ (เช่น ล้างช่องแบบฟอร์มสำหรับรายการถัดไป)

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

WebDAV: เนื้อหา XML รายงานผลลัพธ์ของการดำเนินการย่อยหลายอย่างอย่างอิสระ — เช่น การย้ายแบบชุดที่การย้ายบางรายการสำเร็จและอื่น ๆ ล้มเหลว

WebDAV: ใช้ภายในการตอบสนอง 207 Multi-Status เพื่อหลีกเลี่ยงการแสดงรายชื่อสมาชิกของคอลเลกชันเดียวกันซ้ำ ๆ เมื่อการผูกมัดสร้างลูป

การเข้ารหัส Delta: เซิร์ฟเวอร์ส่งความแตกต่างจากเวอร์ชันก่อนหน้าแทนทรัพยากรทั้งหมด ประหยัดแบนด์วิดท์ แทบไม่มีการนำไปใช้

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

ใช้สำหรับการเปลี่ยนแปลง URL ถาวร — เครื่องมือค้นหาจะอัปเดตดัชนีของพวกเขา SEO authority ถูกโอนไปยัง URL ใหม่

ระบุว่าการเปลี่ยนเส้นทางไม่ถาวร แคชจะน้อยกว่า 301 ใช้สำหรับสิ่งต่างๆ เช่น 'ต้องมีการเข้าสู่ระบบ กำลังเปลี่ยนเส้นทางไปยัง /login'

ใช้หลังจากการส่งแบบฟอร์ม POST — การตอบสนองบอกว่า 'POST ของคุณสำเร็จ ดูผลลัพธ์ที่ GET URL นี้' เบราว์เซอร์จะ GET URL ใหม่เสมอ

การตอบสนองต่อคำขออย่างมีเงื่อนไข (ด้วยส่วนหัว If-None-Match หรือ If-Modified-Since) ประหยัดแบนด์วิดท์ — ไม่มีการส่งคืนเนื้อหา

ถ้าของเดิมคือ POST การเปลี่ยนเส้นทางก็ใช้ POST ด้วย ทางเลือกสมัยใหม่ของ 302 เมื่อการรักษาวิธีสำคัญ

การแทนที่สมัยใหม่สำหรับ 301 เมื่อคุณต้องการให้คำขอ POST ยังคงเป็น POST หลังจากการเปลี่ยนเส้นทาง

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

ไคลเอนต์ต้องแนบข้อมูลประจำตัว (ส่วนหัว Authorization คุกกี้ โทเค็น) 'Unauthorized' เป็นชื่อที่เรียกคลาดเคลื่อน — จริง ๆ แล้วหมายถึง 'ยังไม่ได้พิสูจน์ตัวตน'

เดิมมีวัตถุประสงค์เพื่อการชำระเงินดิจิทัล การใช้งานสมัยใหม่: API บางครั้งส่งกลับ 402 เมื่อผู้ใช้เกินโควตาการชำระเงิน

แตกต่างจาก 401 — ผู้ใช้เข้าสู่ระบบแล้ว แต่บัญชีของพวกเขาไม่มีสิทธิ์สำหรับทรัพยากรนี้ ตรวจสอบตรรกะบทบาท/สิทธิ์

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

ตัวอย่างเช่น คำขอ GET ไปยัง endpoint ที่ยอมรับเฉพาะ POST การตอบสนองควรรวมส่วนหัว Allow ที่แสดงรายวิธีที่ถูกต้อง

ไคลเอนต์ขอประเภทเนื้อหา ภาษา หรือการเข้ารหัส (ผ่าน Accept Accept-Language Accept-Encoding) ที่เซิร์ฟเวอร์ไม่สามารถตอบสนองได้ เซิร์ฟเวอร์จำนวนมากข้ามการเจรจาที่เข้มงวดและส่งกลับค่าเริ่มต้น

เช่นเดียวกับ 401 แต่ออกโดยพร็อกซี: ไคลเอนต์ต้องส่งข้อมูลประจำตัว Proxy-Authorization พบบนเครือข่ายองค์กรที่มีพร็อกซีพิสูจน์ตัวตน

ไคลเอ็นต์ใช้เวลานานเกินไปในการส่งบอดี้ของคำขอหรือเก็บการเชื่อมต่อไว้เฉยๆ ลองส่งคำขออีกครั้ง

มักจะส่งกลับสำหรับความขัดแย้งในการแก้ไขพร้อมกันหรือการสร้างทรัพยากรที่ซ้ำกัน (เช่น การสร้างผู้ใช้ด้วยอีเมลที่มีอยู่แล้ว)

รุนแรงกว่า 404 — เซิร์ฟเวอร์รู้อย่างชัดเจนว่าทรัพยากรเคยมีอยู่แต่ถูกลบออกอย่างถาวรแล้ว เสิร์ชเอนจินจะลบออกจากดัชนี

คำขอถูกปฏิเสธเพราะหัว Content-Length หายไปและเซิร์ฟเวอร์ปฏิเสธบอดี้ที่ไม่ทราบขนาด เพิ่มหัวและลองใหม่

ส่งกลับเมื่อหัวแบบมีเงื่อนไขเช่น If-Match หรือ If-Unmodified-Since ล้มเหลว — มักเป็นการล็อกแบบ optimistic: มีคนอื่นแก้ไขทรัพยากรหลังจากเวอร์ชันของคุณ ดึงข้อมูลใหม่และลองอีกครั้ง

เกิดขึ้นบ่อยครั้งเมื่ออัปโหลดไฟล์ขนาดใหญ่ การตั้งค่าเซิร์ฟเวอร์ (nginx, apache) กำหนดขนาดบอดี้สูงสุด ตรวจสอบการตั้งค่าเซิร์ฟเวอร์

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

เช่น การส่ง application/xml ไปยังเซิร์ฟเวอร์ที่ยอมรับเฉพาะ application/json ตั้งหัว Content-Type ให้ถูกต้อง

หัว Range ขอส่วนที่ไฟล์ไม่มี — เช่น การดาวน์โหลดต่อจากตำแหน่งที่เกินท้ายไฟล์ การตอบสนองควรรวม Content-Range ที่ระบุขนาดจริง

ส่งเมื่อเซิร์ฟเวอร์ไม่รองรับ Expect: 100-continue ไคลเอ็นต์บางตัวส่งหัวนี้โดยค่าเริ่มต้นบน POST ขนาดใหญ่ การปิดใช้งานมักจะแก้ไขข้อผิดพลาด

เรื่องตลกวันเอพริลฟูลส์ปี 1998 (RFC 2324) API บางตัวใช้เป็นเรื่องตลกหรือทำเครื่องหมาย endpoint ที่เลิกใช้ ไม่ใช่สำหรับใช้งานจริง

พบบ่อยเมื่อนำการเชื่อมต่อ HTTP/2 กลับมาใช้ซ้ำ: คำขอไปถึงเซิร์ฟเวอร์ที่ไม่ได้กำหนดค่าสำหรับชื่อโฮสต์เป้าหมาย ไคลเอ็นต์ควรลองใหม่บนการเชื่อมต่อใหม่

เช่น JSON แยกวิเคราะห์อย่างถูกต้องแต่ช่องที่จำเป็นหายไปหรือค่าช่องนอกช่วง พบบ่อยในการตอบสนองการตรวจสอบ REST API

WebDAV: ทรัพยากรต้นทางหรือปลายทางถูกล็อกโดยไคลเอ็นต์อื่น จึงไม่สามารถดำเนินการได้ รอให้ปลดล็อกหรือปลดล็อกด้วยโทเค็นที่ถูกต้อง

WebDAV: ในห่วงโซ่ของการดำเนินการที่ขึ้นต่อกัน การกระทำก่อนหน้านี้ล้มเหลว ดังนั้นจึงไม่ได้ทำการดำเนินการนี้ ดูความล้มเหลวก่อนหน้านี้เพื่อหาสาเหตุหลัก

เกี่ยวข้องกับ TLS 1.3 0-RTT (early data): เซิร์ฟเวอร์จะไม่เสี่ยงประมวลผลคำขอที่อาจถูกส่งซ้ำ ไคลเอ็นต์ควรลองใหม่หลังจากแฮนด์เชคเสร็จสิ้น

เซิร์ฟเวอร์ปฏิเสธที่จะให้บริการคำขอผ่านโปรโตคอลปัจจุบัน แต่จะหลังจากอัปเกรด — การตอบสนองรวมหัว Upgrade ที่ตั้งชื่อโปรโตคอลที่ต้องการ

เซิร์ฟเวอร์เรียกร้องหัวแบบมีเงื่อนไข (เช่น If-Match) เพื่อป้องกันความขัดแย้งของการปรับปรุงที่สูญหาย ดึงทรัพยากร จับ ETag ของมัน และส่งใหม่ด้วย If-Match

ช้าลง การตอบสนองควรรวมหัว Retry-After ที่ระบุเวลาที่จะลองใหม่ พบบ่อยกับ API ที่มีโควตาคำขอ

หัวตัวใดตัวหนึ่งหรือขนาดหัวทั้งหมดเกินขีดจำกัด — มักเกิดจากคุกกี้ขนาดใหญ่ล้น ล้างคุกกี้หรือลดสิ่งที่แอปของคุณเก็บไว้ในนั้น

ทรัพยากรถูกบล็อกด้วยเหตุผลทางกฎหมาย — การเซนเซอร์ คำสั่งศาล หรือกฎระเบียบระดับภูมิภาค หมายเลขนี้เป็นการคารวะนวนิยายเรื่อง Fahrenheit 451

ข้อผิดพลาดแบบครอบคลุมทั่วไปฝั่งเซิร์ฟเวอร์ ตรวจสอบบันทึกเซิร์ฟเวอร์เพื่อหาสาเหตุจริง: ข้อยกเว้นที่ไม่ได้จัดการ ข้อผิดพลาดของฐานข้อมูล เป็นต้น

เช่น เซิร์ฟเวอร์ไม่รู้จักเมธอด HTTP พบได้น้อยในทางปฏิบัติ — โดยทั่วไปคุณมักจะเจอ 405 มากกว่า

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

อยู่ระหว่างปิดปรับปรุงหรือโอเวอร์โหลด การตอบสนองควรรวมหัว Retry-After มักส่งกลับในระหว่างการปรับใช้

บริการแบ็กเอนด์ไม่ตอบสนองเร็วพอ ตรวจสอบสถานะการทำงานของบริการต้นน้ำและการตั้งค่าหมดเวลา

หมายเลข HTTP เวอร์ชันหลักของคำขอไม่รองรับโดยเซิร์ฟเวอร์ ไม่เคยเห็นกับไคลเอ็นต์สมัยใหม่

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

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

WebDAV: การประมวลผลคำขอ Depth: infinity เข้าสู่ลูป (เช่น การเชื่อมโยงแบบวงกลม) การดำเนินการถูกยกเลิก

จากเฟรมเวิร์ก HTTP Extension ที่ล้าสมัย: เซิร์ฟเวอร์ต้องการข้อมูลเพิ่มเติมก่อนที่จะตอบสนอง ไม่มีการใช้งานบนเว็บสมัยใหม่

ใช้โดย captive portal (WiFi โรงแรม/สนามบิน) เพื่อระบุว่าผู้ใช้ต้องเข้าสู่ระบบเครือข่ายก่อนเข้าถึงไซต์ภายนอก