| รหัสสถานะ HTTP | ความหมายของรหัสสถานะ |
|---|
| 100 | ลูกค้าต้องยังคงส่งคำขอ. คำตอบชั่วคราวนี้ใช้เพื่อแจ้งให้ลูกค้าทราบว่าบางคำขอของเขาได้รับการรับของเซิร์ฟเวอร์และยังไม่ถูกปฏิเสธ. ลูกค้าต้องยังคงส่งคำขอที่เหลืออยู่ หรือละเลยคำตอบหากคำขอได้ทำเสร็จ. เซิร์ฟเวอร์ต้องส่งคำตอบสุดท้ายให้ลูกค้าหลังจากที่คำขอได้ทำเสร็จ. |
| 101 | เซิร์ฟเวอร์ได้เข้าใจคำขอของลูกค้าและจะแจ้งให้ทางลูกค้าผ่านหัวข้อ Upgrade ว่าต้องการใช้โปรโตคอลอื่นเพื่อทำการทำคำขอ. หลังจากที่ส่งแถวว่างสุดท้ายในตอบสนอง เซิร์ฟเวอร์จะเปลี่ยนไปใช้โปรโตคอลที่กำหนดในหัวข้อ Upgrade. มาตรการเหล่านี้ควรทำเมื่อการเปลี่ยนไปใช้โปรโตคอลใหม่มีประโยชน์มากขึ้น. ตัวอย่างเช่น การเปลี่ยนไปใช้สัญญาณ HTTP ใหม่มีประโยชน์มากกว่าสัญญาณเก่า หรือการเปลี่ยนไปใช้สัญญาณที่เป็นแท้}}-เวลาและโปรโตคอลที่เป็นทันสมัยเพื่อส่งมอบทรัพยากรที่ใช้ประโยชน์จากความหลากหลายนี้. |
| 102 | รหัสสถานะที่ขยายโดย WebDAV (RFC 2518) หมายถึงว่าการปฏิบัติการจะมีต่อเนื่อง. |
| 200. | คำขอได้รับการทำให้เสร็จสมบูรณ์ และหัวข้อตอบสนองหรือเนื้อหาที่ต้องการจะถูกส่งคืนด้วยตอบสนอง. |
| 201 | คำขอได้รับการทำให้เสร็จสมบูรณ์แล้ว และได้สร้างทรัพยากรใหม่ขึ้นตามความต้องการของคำขอ และ URI ของมันได้ถูกส่งคืนด้วยหัวข้อ Location. ถ้าทรัพยากรที่ต้องการไม่สามารถสร้างขึ้นในเวลาทันตาม202 'Accepted' ควรจะถูกส่งคืน. |
| 202 | เซิร์ฟเวอร์ได้รับคำขอแล้ว แต่ยังไม่ได้ปฏิบัติงานมัน. ก็เช่นกันกับที่มันอาจจะถูกปฏิเสธ คำขออาจจะปฏิบัติงานหรือไม่ได้ในที่สุด. ในกรณีของปฏิบัติการที่ไม่มีความเกี่ยวข้องกัน ไม่มีวิธีที่สะดวกขึ้นกว่าการส่งรหัสสถานะนี้. จุดประสงค์ของการส่งคืน 202 รหัสสถานะตอบสนองเพื่อให้เซิร์ฟเวอร์สามารถรับคำขอจากกระบวนการอื่น (เช่น แบบบัตช์-ปฏิบัติการซึ่งทำเพียงครั้งเดียวต่อวัน) โดยไม่ต้องทำให้ทางลูกค้ามีการเชื่อมต่อกับเซิร์ฟเวอร์จนกว่าปฏิบัติการแบบบัตช์จะเสร็จสิ้น. ในการตอบรับคำขอสำหรับการปฏิบัติงานและส่งคืน 202 รหัสสถานะ, ตอบสนองที่กลับคืนควรมีข้อมูลบางอย่างที่บอกถึงสถานะปัจจุบันของกระบวนการ รวมทั้งตัวชี้ว่าจะต้องเข้าถึงการตรวจสอบสถานะกระบวนการหรือการทำนายสถานะ ให้ผู้ใช้สามารถประเมินว่าการดำเนินการได้เสร็จหรือไม่ |
| 203 | เซิร์ฟเวอร์ประสบความสำเร็จในการประมวลผลคำขอ แต่ข้อมูลหัวข้อเอกษัทที่กลับคืนมีข้อมูลเมตาที่ไม่ใช่ชุดที่มีความเหมาะสมและไม่ใช่ที่มีอยู่ในเซิร์ฟเวอร์ต้นแบบ แต่เป็นท้องถิ่นหรือสาย-สำเนา. ข้อมูลปัจจุบันอาจเป็นชุดรายการหรือชุดที่มีมากกว่าเวอร์ชันต้นแบบ. ตัวอย่างเช่น โมเดลข้อมูลที่มีทรัพยากรอาจทำให้เซิร์ฟเวอร์ต้นแบบรู้เมตาเซิร์ฟเวอร์สูง. การใช้รหัสสถานะนี้ไม่จำเป็น และเหมาะสมเฉพาะตอนที่ตอบสนองกลับคืน 200 สำเร็จแบบที่ไม่มีรหัสสถานะนี้. |
| 204 | เซิร์ฟเวอร์ประสบความสำเร็จในการประมวลผลคำขอ แต่ไม่จำเป็นต้องกลับคืนเนื้อหาทางฟิสิกและต้องการกลับคืนข้อมูลเมตาที่ปรับปรุง. ตอบสนองอาจมีรูปแบบหัวข้อของเอกษัท กลับคืนข้อมูลเมตาใหม่หรือปรับปรุง. ถ้าข้อมูลหัวข้อนี้มีอยู่ มันควรสอดคล้องกับตัวแปรที่ขอ. ถ้าฝ่ายลูกค้าคือเบราเซอร์ ระบบการเบราเซอร์ของผู้ใช้ควรกลับคืนหน้าเว็บที่ส่งคำขอโดยไม่มีการเปลี่ยนแปลงในมองหน้าเอกสาร แม้ว่าข้อมูลเมตาที่ปรับปรุงหรือปรับปรุงใหม่จะต้องนำมาปรับปรุงในหน้าเว็บที่มองอยู่ในเบราเซอร์ของผู้ใช้ตามข้อกำหนด. เนื่องจาก 204 ตอบสนองที่ห้ามมีโมเดลข้อความใดๆ,มันจะจบด้วยบรรทัดว่างแรกหลังหัวข้อ. |
| 205 | เซิร์ฟเวอร์ประสบความสำเร็จในการประมวลผลคำขอและไม่มีสิ่งใดกลับคืน. แต่ต่างกับ 204 ตอบสนอง, ตอบสนองที่กลับคืนรหัสสถานะนี้ต้องการให้ผู้ขอเรียกคืนรับมองหน้าเอกสารใหม่อีกครั้ง. ตอบสนองนี้ใช้เพื่อรีเซ็ตฟอร์มทันทีหลังจากที่รับการเข้าออกจากผู้ใช้เพื่อให้ผู้ใช้สามารถเริ่มการเข้าออกอีกครั้งง่ายๆ. คล้ายกับ 204 ตอบรับ นี้ยังไม่อนุญาตให้มีข้อความที่แสดงในตอบรับ และจบด้วยช่องว่างแรกหลังหัวของตอบรับ. |
| 206 | เซิร์ฟเวอร์ได้ประสบความสำเร็จในการประมวลผลส่วนหนึ่งของการขอ GET นี้. โปรแกรมดาวน์โหลดแบบ HTTP อย่างเช่น FlashGet หรือ Xunlei ใช้การตอบรับนี้เพื่อทำการดาวน์โหลดที่หยุดตัดสายหรือแบ่งเอกสารใหญ่เป็นส่วนบุกเบิกหลายส่วนเพื่อดาวน์โหลดพร้อมกัน. การขอควรมีหัวของ Range ที่แสดงขอบเขตเนื้อหาที่ลูกค้าต้องการ และอาจมี If-Range ในฐานะของเงื่อนไขการขอ. ตอบรับควรมีหัวของตำแหน่งต่อไปนี้: Content-Range ที่แสดงขอบเขตเนื้อหาที่ตอบรับในตอบรับนี้; ถ้ามันเป็น multi-การดาวน์โหลดส่วนบุกเบิก multipart กับ Content-Type multipart/byteranges แต่ละส่วนของ multipart ควรมี Content-หัวของ Range ที่แสดงขอบเขตเนื้อหาของส่วนนี้. ถ้าตอบรับมี Content-Length แล้ว ค่าของมันควรตรงกันกับจำนวนไบต์ที่มีในขอบเขตเนื้อหาที่ตอบรับ. วันที่ ETag และ/หรือ Content-Location ถ้าคำขอเดียวกันควรกลับมาด้วย 2คำตอบ 00 response. Expires, Cache-Control และ/หรือ Vary หากค่าของมันอาจแตกต่างจากค่าที่สอดคล้องกับตอบรับอื่นๆ ที่เดียวกันกับตัวแปรก่อนหน้านี้. ถ้าการเรียกขอตอบรับนี้ใช้ If-หัวของ Range ที่แน่ชัดในการตรวจสอบเก็บความรู้เกี่ยวกับ ตอบรับนี้ควรไม่มีหัวของ entity อื่น; ถ้าการเรียกขอตอบรับนี้ใช้ If-หัวของ Range ที่ไม่แน่ชัดในการตรวจสอบเก็บความรู้เกี่ยวกับ ตอบรับนี้ควรไม่มีหัวของ entity อื่น; นี่หลีกเลี่ยงความไม่สอดคล้องระหว่างเนื้อหาที่ทำการทำเก็บความรู้เกี่ยวกับและข้อมูลหัวของ entity ที่ปรับปรุงขึ้น. อย่างไรก็ตาม ตอบรับนี้ควรมีหัวของ entity ทั้งหมดที่ควรจะทำการตอบรับใน 2ตอบรับ 00. ถ้า ETag หรือ Last-หัวของ Modified ไม่ตรงกันเหมือนกัน ความรู้เกี่ยวกับด้านลูกค้าควรห้ามการรวมเนื้อหาที่ตอบรับใน 206 ตอบรับกับเนื้อหาที่ทำการทำเก็บความรู้เกี่ยวกับก่อนหน้านี้. ความรู้เกี่ยวกับที่ไม่สนับสนุน Range และ-หัวของ Range ไม่อนุญาตให้ทำการทำเก็บความรู้เกี่ยวกับเนื้อหาที่ตอบรับโดย 206 ตอบรับ. |
| 207 | รหัสสatus code ที่ขยายโดย WebDAV (RFC 2518) represents that the body of the subsequent message will be an XML message, and may contain a series of independent response codes depending on the number of previous sub-requests. |
| 300 | The requested resource has a range of feedback options, each with its own specific address and browser-driven negotiation information. The user or browser can choose a preferred address for redirection. Unless this is a HEAD request, the response should include an entity with a list of resource attributes and addresses from which the user or browser can choose the most appropriate redirect address. The format of this entity is determined by the format defined by Content-Type. The browser may automatically make the most appropriate choice based on the format of the response and the browser's own capabilities. Of course, the RFC 2616 ประเภท. โปรแกรมบราวเซอร์อาจทำการเลือกความเหมาะสมที่สุดอัตโนมัติโดยอิงต่อรูปแบบของคำตอบและความสามารถของโปรแกรมบราวเซอร์เอง แน่นอนว่า RFC มีข้อมูลเจาะจงเกี่ยวกับการเจาะจงประกาศ |
| 301 | ทรัพยากรที่ขอได้ถูกย้ายไปยังที่อยู่ใหม่เป็นครั้งถาวร และการอ้างถึงทรัพยากรนี้ในอนาคตควรใช้หนึ่งในหลาย URI ที่กลับมาด้วยคำตอบนี้ ถ้าเป็นไปได้ โปรแกรมลูกค้าที่มีความสามารถแก้ไขลิงค์ควรเปลี่ยนที่อยู่ที่ขอไปเป็นที่อยู่ที่กลับมาจากเซิร์ฟเวอร์ ยกเว้นจากที่ระบุไว้ คำตอบนี้ยังเป็นไปได้ที่จะถูกเก็บเกี่ยว ที่อยู่ถาวรใหม่ควรถูกกลับมาในฟิลด์ Location ของคำตอบ ยกเว้นถ้ามีคำขอ HEAD ควรมีเนื้อหาที่มีลิงค์ไปยัง URI ใหม่และคำอธิบายสั้นๆ ถ้าไม่ใช่คำขอ GET หรือ HEAD โปรแกรมบราวเซอร์ไม่ควรทำการกู้ข้อมูลโดยอัตโนมัติเว้นเช่นที่ยืนยันโดยผู้ใช้ เนื่องจากเงื่อนไขของคำขออาจเปลี่ยนแปลงได้เนื่องจากการเปลี่ยนแปลงนี้ หมายเหตุ: สำหรับบราวเซอร์บางตัวที่ใช้นิยามนี้ มิได้ระบุว่าการเลือกอัตโนมัตินี้ควรทำได้อย่างไร ถ้าเซิร์ฟเวอร์มีการเลือกความกตึกต่อตอบกลับที่ชื่นชอบ ตำแหน่งของ URI ของความกตึกต่อตอบควรระบุใน Location; โปรแกรมบราวเซอร์อาจใช้ค่า Location นี้เป็นที่อยู่สำหรับการกู้ข้อมูลโดยอัตโนมัติ นอกจากนี้ ยกเว้นจากที่ระบุไว้ คำตอบยังเป็นไปได้ที่จะถูกเก็บเกี่ยว/1โปรโตคอล 0.0 ในขณะที่พวกเขาส่งคำขอ POST และได้ 301 คำตอบนี้ คำขอโอนทรัพยากรต่อไปจะเป็น GET. |
| 302 | ทรัพยากรที่ถูกขอความรับผิดชอบในขณะนี้ตอบคำขอจาก URI อื่น ๆ แล้ว. เพราะการโอนทรัพยากรนี้เป็นชั่วคราว ทางลูกค้าควรยังคงส่งคำขอในอนาคตไปยังที่อยู่เดิม. คำตอบนี้สามารถที่จะบันทึกความรับผิดชอบได้เมื่อกำหนดใน Cache-ควบคุมหรือ Expires. URI ชั่วคราวใหม่ควรถูกกลับค่าในฟิลด์ Location ของคำตอบ. แต่ถ้านี่ไม่ใช่คำขอ HEAD ความเป็นจริง ตัวเอกของคำตอบควรมีลิงก์ไปยัง URI ใหม่และคำอธิบายสั้นๆ ถ้านี่ไม่ใช่คำขอ GET หรือ HEAD บราวเซอร์ของคนไทยไม่อนุญาตการโอนทรัพยากรอัตโนมัติเว้นเป็นที่ยืนยันโดยผู้ใช้ เพราะเงื่อนไขของคำขออาจเปลี่ยนแปลงเนื่องจากนี้. หมายเหตุ: ถึงแม้ว่า RFC 1945 และ RFC 2068 รายละเอียดของการกำหนดไม่อนุญาตให้ทางลูกค้าเปลี่ยนวิธีการของคำขอเมื่อโอนทรัพยากร หลายเครื่องปฏิบัติการเครื่องคอมพิวเตอร์ที่มีอยู่ตามไปด้วย 302 คำตอบเป็น 303 คำตอบและใช้ GET เพื่อเข้าถึง URI ที่กำหนดใน Location โดยละเลยวิธีการของคำขอเดิม. รหัสสถานะ 303 และ 307 ถูกเพิ่มเข้ามาเพื่อชี้แจงว่าเซิร์ฟเวอร์คาดหวังอะไรจากทางลูกค้า. |
| 303 | คำตอบของคำขอปัจจุบันสามารถหาได้ที่ URI อื่น และเครื่องปฏิบัติการทางลูกค้าควรที่จะเข้าถึงทรัพยากรนี้ด้วยการ GET. วิธีนี้มีอยู่เพื่อที่จะอนุญาตให้สคริปต์-จัดการคำขอ POST ที่สามารถโอนความรับผิดชอบไปยังทรัพยากรใหม่. URI ใหม่นี้ไม่ใช่การอ้างอิงที่ทดแทนของทรัพยากรเดิม. และเช่นนั้น 303 หลายบราวเซอร์ก่อน HTTP/1.1 ไม่อนุญาตให้เก็บคลาชช์. ตัวเลือกที่สอง (การโหลดมาใหม่) อาจเก็บคลาชช์. ต้องการให้ URI ใหม่ถูกคืนค่าในฟิลด์ Location ของคำตอบ. แต่ถ้านี้เป็นคำขอ HEAD ควรมีลิงก์ไปยัง URI ใหม่และคำอธิบายสั้น. ให้เรียกเก็บคลาชช์มาก่อน. 303 ที่ไม่เข้าใจ คำตอบ. 302 ค่าสถานะควรเพียงพอ เพราะส่วนใหญ่บราวเซอร์จัดการสถานะ 302 คำตอบในแนวที่เห็นได้ในการกำหนดของลูกค้าที่กำหนดขึ้นเหนือ. 303 คำตอบ. |
| 304 | ถ้าทางลูกค้าส่งคำขอ GET ที่มีเงื่อนไขและคำขอได้รับอนุญาต และเนื้อหาของเอกสารไม่มีการเปลี่ยนแปลง (ตั้งแต่การเยี่ยมชมครั้งที่แล้วหรือตามเงื่อนไขของคำขอ), เซิร์ฟเวอร์ควรคืนค่าสถานะนี้. 304 ไม่อนุญาตให้คำตอบรวมเนื้อหาของข้อความ ดังนั้นควรจบด้วยบรรทัดว่างแรกหลังหัวข้อ. คำตอบควรมีข้อมูลหัวข้อต่อไปนี้: Date แต่ถ้าเซิร์ฟเวอร์นี้ไม่มีนาฬิกาเวลา.
ถ้าเซิร์ฟเวอร์ที่ไม่มีนาฬิกาเวลาเองตามกฎนี้ด้วย แล้วเซิร์ฟเวอร์ประสานงานและทางลูกค้าสามารถเพิ่มฟิลด์ Date ในหัวข้อตอบสนองที่ได้รับเอง (ตามที่กำหนดใน RFC 2068), และระบบการเก็บคลาชช์จะทำงานได้ดี. ETag และ/หรือ Content-Location ถ้าคำขอเดียวกันควรกลับมาด้วย 2คำตอบ 00 response. Expires, Cache-Control และ/หรือ Vary ถ้าค่าของมันอาจแตกต่างจากค่าที่สอดคล้องกับคำตอบของตัวทรัพย์สินอื่นที่เดียวกันกับตัวทรัพย์สินก่อนหน้านี้.
ถ้าคำขอตอบนี้ใช้การตรวจสอบคลาชช์ที่แข็งแกร่ง แล้วคำตอบนี้ควรไม่มีหัวข้อของตัวทรัพย์สินอื่น; ไม่ว่าจะเป็น (เช่น คำขอ GET ที่มีเงื่อนไขใช้การตรวจสอบคลาชช์ที่อ่อนแอ), คำตอบนี้ถูกห้ามมีหัวข้อของตัวทรัพย์สินอื่น; นี่หลีกเลี่ยงความไม่สอดคล้องระหว่างเนื้อหาตัวทรัพย์สินที่คลาชช์และข้อมูลหัวข้อตัวทรัพย์สินที่ปรับปรุงล่าสุด. ถ้ามี 304 คำตอบบอกว่าตัวเอกยะไม่ได้ถูกเก็บเคช์อยู่ตอนนี้ ระบบเคช์ควรละเลยคำตอบและส่งคำขอต่อไปโดยไม่มีข้อจำกัด
ถ้าคำตอบ 304 คำตอบที่ได้รับเพื่อปรับปรุงบันทึกเคช์ ระบบเคช์ควรปรับปรุงบันทึกทั้งหมดเพื่อแสดงค่าของทุกฟิลด์ที่ถูกปรับปรุงในคำตอบ |
| 305 | ทรัพยากรที่ขอใช้ต้องเข้าถึงผ่านโปรกซี่ที่กำหนด ข้อมูล URI ของโปรกซี่ที่กำหนดนี้มีในฟิลด์ Location ผู้รับควรส่งคำขอแยกต่างกันเพื่อเข้าถึงทรัพยากรตามโปรกซี่นี้. แต่เดียวโดยเฉพาะโซ่ซอฟต์แวร์เท่านั้นที่สามารถจัดตั้ง 305 คำตอบ. สัญญาณ: ไม่มีคำอธิบายชัดแจง 305 คำตอบใน RFC 2068 ในการกลับทางคำขอเดียว และสามารถจัดตั้งได้โดยเฉพาะโซ่ซอฟต์แวร์ การละเลยข้อจำกัดเหล่านี้อาจนำไปสู่ผลลัพธ์ความปลอดภัยที่ร้ายแรง |
| 306 | ในรุ่นล่าสุดของสูตรซอฟต์แวร์ 306 รหัสสถานะไม่ได้ถูกใช้ต่อไปนี้ |
| 307 | ทรัพยากรที่ขอใช้ตอนนี้กำลังตอบสนองคำขอจาก URI อื่น ๆ ตั้งแต่การกลับทางนี้เป็นชั่วคราว โดยที่ฝ่ายลูกค้าควรยังคงส่งคำขอในอนาคตไปยังที่อยู่เดิม คำตอบนี้สามารถถูกเก็บเคช์ได้เมื่อกำหนดใน Cache-การควบคุมหรือ Expires ต้องการให้กลับทางชั่วคราวของ URI ใหม่ในฟิลด์ Location ของคำตอบ ยกเว้นถ้านี้เป็นคำขอ HEAD ระบบตอบสนองควรมีลิงก์ฮิเปอร์ทางไปยัง URI ใหม่และบรรยายสั้นๆ ตั้งแต่บางระบบนี้ไม่รับรู้ 307 คำตอบ ต้องการเพิ่มข้อมูลดังกล่าวเพื่อให้ผู้ใช้สามารถเข้าใจและขอเข้าถึง URI ใหม่
ถ้านี้ไม่ใช่คำขอ GET หรือ HEAD ระบบนี้ขัดขวางการกระทำการกลับทางอัตโนมัติ ต้องการการยืนยันจากผู้ใช้ เพราะเงื่อนไขของคำขออาจเปลี่ยนแปลงเนื่องจากนั้น |
| 400 | 1เหมือนกัน และคำขอปัจจุบันไม่สามารถเข้าใจโดยเซิร์ฟเวอร์. หากไม่มีการปรับปรุง ทางเซิร์ฟเวอร์ควรไม่ส่งคำขอซ้ำ. 2ข้อมูลประมาณค่าของคำขอผิด. |
| 401 | คำขอปัจจุบันต้องการการรับรองผู้ใช้. คำตอบต้องมี WWW-หัวข้อ Authenticate สำหรับทรัพยากรที่ต้องการเพื่อขอข้อมูลจากผู้ใช้. ทางเซิร์ฟเวอร์อาจส่งคำขอซ้ำด้วยข้อมูลหัวข้อ Authorization ที่เหมาะสม. หากคำขอปัจจุบันมีหัวข้อ Authorization ในตัวเครื่องแสดง 401 คำตอบระบุว่าเซิร์ฟเวอร์ได้ปฏิเสธหนังสือรับรองนี้. หาก 401 คำตอบมีคำถามการรับรองเดียวกับคำตอบที่ผ่านมา และเบราเซอร์ได้ทำการรับรองอย่างน้อยหนึ่งครั้ง แล้วเบราเซอร์ควรแสดงข้อมูลตัวเครื่องแสดงที่มีในคำตอบให้ผู้ใช้ เพราะข้อมูลตัวเครื่องแสดงนี้อาจมีข้อมูลการวินิจฉัยที่เกี่ยวข้อง. ดู RFC 2617. |
| 402 | รหัสสถานะนี้ถูกบริจาคเพื่อความต้องการในอนาคต. |
| 403 | เซิร์ฟเวอร์ได้เข้าใจคำขอ แต่ปฏิเสธที่จะทำมัน. ต่างจาก 401 คำตอบ การรับรองไม่ช่วย และคำขอไม่ควรถูกส่งซ้ำ. หากนี้ไม่ใช่คำขอ HEAD และเซิร์ฟเวอร์ต้องการที่จะอธิบายสาเหตุที่ทำให้คำขอไม่สามารถทำได้ แล้วสาเหตุที่ทำให้ปฏิเสธควรถูกบรรยายภายในตัวเครื่องแสดง. ตัวเซิร์ฟเวอร์ก็สามารถ 404 คำตอบหากไม่ต้องการให้ทางเซิร์ฟเวอร์ได้รับข้อมูลใดๆ. |
| 404 | คำขอถูกปฏิเสธ และทรัพยากรที่ต้องการไม่พบบนเซิร์ฟเวอร์. ไม่มีข้อมูลที่จะบอกให้ผู้ใช้รู้ว่าสถานการณ์นี้เป็นชั่วคราวหรือไม่ถาวร. หากเซิร์ฟเวอร์รู้สึกถึงสถานการณ์นี้ ระบุ 410 รหัสสถานะควรถูกใช้เพื่อแจ้งให้ทราบแหล่งข้อมูลเก่าไม่สามารถใช้งานได้ตลอดไปเนื่องจากกลไกการกำหนดค่าภายในเซิร์ฟเวอร์ และไม่มีที่แปลงไปต่อ. ระบุ 404 รหัสสถานะที่ใช้ยังต่อเนื่องเมื่อเซิร์ฟเวอร์ไม่ต้องการเปิดเผยสาเหตุที่คำขอถูกปฏิเสธ หรือไม่มีคำตอบที่เหมาะสมสำหรับใช้. |
| 405 | 405 วิธีที่กำหนดในบรรทัดคำขอไม่สามารถใช้เพื่อขอทรัพยากรที่เกี่ยวข้องได้. คำตอบควรส่งหัวข้อ Allow ที่ระบุรายชื่อวิธีที่สามารถรับคำขอได้โดยทรัพยากรในขณะนี้ เนื่องจากวิธี PUT และ DELETE จะเขียนทรัพยากรบนเซิร์ฟเวอร์ โดยทั่วไปแล้วเซิร์ฟเวอร์ออนไลน์จะไม่สนับสนุนหรือไม่อนุญาตวิธีการขอที่กล่าวข้างต้นโดยเริ่มต้น และจะส่งคำตอบ |
| 406 | ของความผิดพลาดสำหรับคำขอเช่นนี้。-ลักษณะของสิ่งที่ขอร้องของทรัพยากรไม่เท่าสัมพันธ์กับเงื่อนไขในหัวข้อรับรองของคำขอ ดังนั้น จะไม่สามารถสร้างตัวเองตอบคำขอได้ ยกเว้นว่าเป็นคำขอ HEAD คำตอบควรส่งตัวเองที่อนุญาตให้ผู้ใช้หรือโปรแกรมนำเข้าเลือกลักษณะตัวเองที่เหมาะสมที่สุดและรายชื่อที่อยู่ รูปแบบของตัวเองนั้นนิยามโดยประเภทสื่อที่กำหนดใน |
| 407 | หัวข้อประเภท. โปรแกรมนำเข้าสามารถเลือกที่ดีที่สุดเพื่อแบบรูปแบบและความสามารถของตัวเอง อย่างไรก็ตาม รายละเอียดไม่ได้กำหนดมาตรฐานใดๆ สำหรับการเลือกอัตโนมัติเช่นนี้ 401 ที่คล้ายกับ-รับรองสำหรับการรับรองตัว. ฝ่ายลูกค้าสามารถส่งคำตอบรับรอง, แต่ฝ่ายลูกค้าต้องรับรองตัวที่เซิร์ฟเวอร์ตัวลูกมด. เซิร์ฟเวอร์ตัวลูกมดต้องส่งคำตอบรับรอง-หัวข้อรับรองเพื่อการรับรองตัว. ดู RFC 2617. |
| 408 | คำขอหมดเวลา โดยที่ฝ่ายลูกค้าไม่สามารถทำการส่งคำขอในช่วงเวลาที่เซิร์ฟเวอร์พร้อมที่จะรอ ฝ่ายลูกค้าสามารถส่งคำขอใหม่อีกครั้งได้ที่เวลาใดๆ โดยไม่ต้องเปลี่ยนแปลงใดๆ |
| 409 | คำขอไม่สามารถทำการเสร็จสมบูรณ์ได้เนื่องจากมีข้อขัดแย้งกับสถานะของทรัพยากรที่ขอร้องในขณะนี้ รหัสนี้สามารถใช้ได้เมื่อเป็นไปได้ที่ผู้ใช้จะสามารถแก้ปัญหาข้อขัดแย้งและจะส่งคำขอใหม่อีกครั้ง คำตอบควรมีข้อมูลเพียงพอให้ผู้ใช้สามารถตรวจสอบแหล่งของข้อขัดแย้งได้ ข้อขัดแย้งทั่วไปจะเกิดขึ้นในขั้นตอนการประมวลของคำขอ PUT ตัวอย่างเช่น ในรุ่น-checked environment, if the version information attached to a PUT-สภาพแวดล้อมที่ถูกตรวจสอบ หากข้อมูลเวอร์ชั่นที่แก้ตัวติดอยู่กับ PUT-คำขอการแก้ไขที่ยื่นยันเพื่อทรัพยากรเฉพาะที่มีข้อขัดแย้งกับคำขอที่เคยมีมา (สามัญ) 409 คำขอที่มีส่วนเกี่ยวข้อง (ทางฝ่ายที่ขอ) ซึ่งเซิร์ฟเวอร์ควรที่จะส่งคำตอบ
คำข้อความของความผิดพลาดที่แจ้งให้ผู้ใช้ทราบว่าคำขอไม่สามารถทำการสำเร็จได้。 |
| 410 | ตอนนี้ ตัวทางออกของคำตอบมีแนวโน้มที่จะมีการเปรียบเทียบระหว่างสองสัญญาณที่ขัดแย้งกัน เพื่อให้ผู้ใช้สามารถยื่นยันเวอร์ชั่นที่ผสมกันอีกครั้ง。 404 ทรัพยากรที่ถูกขอไม่ได้มีอยู่บนเซิร์ฟเวอร์และไม่มีที่อยู่การเสนอส่งที่ทราบกัน สถานะนี้ควรถูกพิจารณาว่าเป็นสถานะถาวร。หากทางลูกบาศกาลมีความสามารถในการแก้ไขลิงค์ และได้รับอนุญาตจากผู้ใช้ ลูกบาศกาลควรลบทุกอ้างอิงที่มีอยู่ต่อที่อยู่นี้ออก。 410 รหัสสถานะควรถูกใช้งาน。เว้นแต่ที่ระบุไว้โดยเฉพาะ คำตอบนี้สามารถเก็บเก็บไว้ได้ในคลังความรู้เรียกข้อมูลเดิมของเครื่องคอมพิวเตอร์ จุดประสงค์ของความยาวของ
คำตอบนี้ใช้หลักในการช่วยเจ้าหน้าที่เว็บไซต์ดูแลเว็บไซต์ให้ได้รับการแจ้งว่าทรัพยากรไม่ได้มีอยู่ต่อไป และเจ้าของเซิร์ฟเวอร์ต้องการให้ทุกการเชื่อมต่อที่เชื่อมโยงไปยังทรัพยากรนี้ถูกลบออก。-ข้อมูลเหตุการณ์นี้เป็นสิ่งที่พบบ่อยในระหว่างเวลา。-การเพิ่มบริการที่มีขนาดจำกัด และค่าที่เพิ่มเติม。 410 คำตอบเพื่อแจ้งให้ลูกบาศกาลทราบว่าทรัพยากรที่เดิมนั้นไม่ได้มีอยู่บนเว็บไซต์ของเซิร์ฟเวอร์ปัจจุบันอีกต่อไป。ต้องการบ้างหรือไม่ นั้นขึ้นอยู่กับเจ้าของเซิร์ฟเวอร์ว่าจะทำเครื่องหมายทรัพยากรที่ไม่สามารถใช้งานตลอดไปให้เป็น 'Gone'。 410 สถานะ 'Gone' และเวลาที่จะรักษาสัญลักษณ์นี้。 |
| 411 | เซิร์ฟเวอร์ปฏิเสธที่จะรับคำขอโดยไม่กำหนดความยาวของ Content。-หัวข้อความยาว。-หัวข้อความยาวที่แสดงความยาวของร่างของคำขอ，ลูกบาศกาลสามารถยื่นยันคำขออีกครั้ง。 |
| 412 | เซิร์ฟเวอร์ไม่สามารถเจอข้อกำหนดหนึ่งหรือมากกว่าขณะที่ตรวจสอบว่าข้อกำหนดนี้ถูกใส่ในหัวข้อฟิลด์ของคำขอ. รหัสสถานะนี้อนุญาตให้ฝ่ายลูกค้ากำหนดข้อกำหนดในข้อมูลที่ขอครอบคลุม (ข้อมูลฟิลด์หัวข้อคำขอ) ขณะที่หาทรัพยากร ดังนั้นป้องกันไม่ให้วิธีการขอครอบคลุมทรัพยากรที่ไม่ต้องการ |
| 413 | เซิร์ฟเวอร์ปฏิเสธที่จะประมวลคำขอปัจจุบันเพราะคำขอส่งมามีข้อมูลที่เป็นตัวเอกมากกว่าที่เซิร์ฟเวอร์ยินยอมหรือสามารถจัดการได้. ในกรณีนี้ เซิร์ฟเวอร์สามารถปิดการเชื่อมต่อเพื่อป้องกันให้ฝ่ายลูกค้าที่จะส่งคำขอต่อไป. ถ้าสถานการณ์นี้เป็นชั่วคราว เซิร์ฟเวอร์ควรส่งกลับค่า Retry-หลังจากหัวข้อคำตอบเพื่อแจ้งให้ลูกค้ารู้ว่าเวลาเท่าไหร่ที่เขาสามารถพยายามอีกครั้ง |
| 414 | URI ที่ขอไปยาวกว่าที่เซิร์ฟเวอร์สามารถแปลข้อมูลได้ ดังนั้นเซิร์ฟเวอร์ปฏิเสธที่จะให้บริการคำขอ นี่เป็นข้อน้อย และกรณีที่เกิดบ่อยที่สุดรวมทั้ง: การส่งฟอร์มที่ควรใช้วิธีการ POST กลายเป็นวิธีการ GET ทำให้ตัวอักษรของของตัวอ่าน (Query String) ยาวเกินไป. Redirect URI "หมู่บึง" อย่างเช่นการเปลี่ยนแปลง URI ด้วย URI ที่เก่าเป็นส่วนหนึ่งของ URI ใหม่ ทำให้ URI ยาวขึ้นหลังจากการเปลี่ยนแปลงหลายครั้ง. ลูกค้ากำลังพยายามโจมตีเซิร์ฟเวอร์ด้วยความอันตรายที่มีในบางเซิร์ฟเวอร์。
ชนิดเซิร์ฟเวอร์นี้ใช้บัฟเฟอร์-บัฟเฟอร์ขนาดเล็กเพื่ออ่านหรือจัดการ URI ที่ขอไป ขณะที่ตัวอักษรหลัง GET ขนาดเกินค่าที่กำหนด อาจเกิดฝายบัฟเฟอร์ ทำให้เกิดการปฏิบัติรหัสอัตราได้ [1]. เซิร์ฟเวอร์ที่ไม่มีความอันตรายนี้ควรส่งกลับค่า 414 รหัสสถานะ |
| 415 | สำหรับวิธีการของคำขอปัจจุบันและทรัพยากรที่ถูกขอ ตัวเอกของที่ส่งมาในคำขอไม่อยู่ในรูปแบบที่เซิร์ฟเวอร์สนับสนุน ดังนั้นคำขอถูกปฏิเสธ。 |
| 416 | ถ้าคำขอมีหัวข้อ Range และของข้อมูลที่กำหนดใน Range ไม่ตรงกับของข้อมูลที่มีอยู่ของทรัพยากรปัจจุบัน และ If-หัวข้อ Range ยังไม่ถูกกำหนดในคำขอ เซิร์ฟเวอร์ควรส่งกลับค่า 416 รหัสสถานะ. ถ้า Range ใช้ byte range แล้ว สถานการณ์นี้หมายความว่าตำแหน่งบิตแรกของทุกช่วงข้อมูลที่ระบุโดยคำขอเกินความยาวของทรัพยากรปัจจุบัน. เซิร์ฟเวอร์ควรรวม Content-ของ Range entity header พร้อมกับ 416 รหัสสถานะเพื่อบอกว่าความยาวของทรัพยากรปัจจุบัน. คำตอบนี้ยังถูกห้ามใช้ multipart/byteranges และ Content-Type. |
| 417 | เนื้อหาที่ระบุในหัวข้อคำขอ Expect ของคำขอไม่สามารถปฏิบัติได้โดยเซิร์ฟเวอร์ หรือเซิร์ฟเวอร์เป็นโปรกซี้ยะที่มีหลักฐานชัดเจนว่าเนื้อหาที่คาดคิดไม่สามารถปฏิบัติได้ในจุดต่อไปของระบบทางเส้นทางปัจจุบัน. |
| 421 | จำนวนการเชื่อมต่อไปยังเซิร์ฟเวอร์จาก Internet Protocol Address ที่ลูกค้าปัจจุบันตั้งอยู่เกินจำนวนที่อนุญาตโดยเซิร์ฟเวอร์. โดยทั่วไปแล้ว ที่แอดเดรสส์ Internet Protocol Address ที่ใช้ในที่นี้หมายถึงที่แอดเดรสของฝ่ายลูกค้าที่เห็นจากเซิร์ฟเวอร์ (เช่นที่แอดเดรสส์ของกลางส่งผ่านหรือโปรกซี้ยะของผู้ใช้) ในกรณีนี้ จำนวนการเชื่อมต่ออาจเกี่ยวข้องกับผู้ใช้งานหลายคน. |
| 422 | จำนวนการเชื่อมต่อไปยังเซิร์ฟเวอร์จาก Internet Protocol Address ที่ลูกค้าปัจจุบันตั้งอยู่เกินจำนวนที่อนุญาตโดยเซิร์ฟเวอร์. โดยทั่วไปแล้ว ที่แอดเดรสส์ Internet Protocol Address ที่ใช้ในที่นี้หมายถึงที่แอดเดรสของฝ่ายลูกค้าที่เห็นจากเซิร์ฟเวอร์ (เช่นที่แอดเดรสส์ของกลางส่งผ่านหรือโปรกซี้ยะของผู้ใช้) ในกรณีนี้ จำนวนการเชื่อมต่ออาจเกี่ยวข้องกับผู้ใช้งานหลายคน. |
| 422 | คำขอถูกจัดรูปแบบให้ถูกต้อง แต่ไม่สามารถตอบสนองได้เนื่องจากข้อผิดพลาดทางนัย. (RFC 4918 WebDAV) 423 ที่ถูกล็อค The ทรัพยากรปัจจุบันถูกล็อค. (RFC 4918 WebDAV) |
| 424 | คำขอปัจจุบันล้มเหลวเนื่องจากข้อผิดพลาดในคำขอก่อนหน้า เช่น PROPPATCH. (RFC 4918 WebDAV) |
| 425 | กำหนดในแบบร่าง WebDav Advanced Collections แต่ไม่ใช่ในโปรโตคอล WebDAV Sequential Set (RFC 3658). |
| 426 | ฝ่ายลูกค้าควรเปลี่ยนไปใช้ TLS/1.0. (RFC 2817) |
| 449 | เพิ่มเติมโดย Microsoft ควรที่จะทดลองคำขอใหม่หลังจากที่ทำการดำเนินการที่เหมาะสม. |
| 500 | เซิร์ฟเวอร์เผชิญกับสถานการณ์ที่ไม่คาดคิดที่ป้องกันมันจากการทำการตอบสนองคำขอ. โดยทั่วไปแล้ว ปัญหานี้เกิดขึ้นเมื่อโค้ดของเซิร์ฟเวอร์ล้มเหลว. |
| 501 | เซิร์ฟเวอร์ไม่สนับสนุนคุณสมบัติที่คำขอของคุณต้องการ ขณะที่เซิร์ฟเวอร์ไม่สามารถรับรู้วิธีที่ถูกขอและไม่สามารถสนับสนุนคำขอของมันสำหรับทรัพยากรใดๆ. |
| 502 | เมื่อเซิร์ฟเวอร์ที่ทำงานในฐานะกลางส่งผ่านหรือโปรกซี้ยะความรู้สึกถึงคำขอ มันจะได้รับคำตอบที่ผิดปกติจากเซิร์ฟเวอร์ของระดับบนระบบ. |
| 503 | เซิร์ฟเวอร์ในขณะนี้ไม่สามารถปฏิบัติการคำขอได้เนื่องจากการบำรุงรักษาเซิร์ฟเวอร์ชั่วคราวหรือการบรรทุกเกินขีด. สถานะนี้เป็นชั่วคราวและจะถูกฟื้นฟูหลังจากบางช่วงเวลา. หากเวลาที่ล่าช้าสามารถทำนายได้ คำตอบสามารถรวม Retry-หลังหัวข้อบอกเวลาที่ล่าช้า. หากเวลาที่เลื่อนการทดลองนี้-หลังจากไม่มีข้อมูลเปิดเผย ด้านลูกค้าควรจัดการกับมันเหมือนถ้ามันเป็น 500 คำตอบ. หมายเหตุ: การมีอยู่ของ 503 รหัสสถานะที่ไม่หมายความว่าเซิร์ฟเวอร์จะต้องใช้มันในกรณีที่มีการบรรทุกเกินขีด. บางเซิร์ฟเวอร์เพียงแค่ต้องการปฏิเสธการเชื่อมต่อของลูกค้า |
| 504 | เมื่อเซิร์ฟเวอร์ที่ทำงานเป็นตัวเกตเวย์หรือตัวประสานงานพยายามที่จะปฏิบัติการคำขอ มันล้มเหลวในการรับคำตอบจากเซิร์ฟเวอร์ขั้นบน (ที่ระบุด้วย URI อย่างเช่น HTTP, FTP, LDAP) หรือเซิร์ฟเวอร์ที่เป็นสำรับ (เช่น DNS) ในระยะเวลาที่เหมาะสม. หมายเหตุ: บางเซิร์ฟเวอร์ประสานงานจะ 400 หรือ 500 ของการหยุดการค้นหา DNS |
| 505 | เซิร์ฟเวอร์ไม่สนับสนุน หรือปฏิเสธที่จะสนับสนุน รุ่นของ HTTP ที่ใช้ในคำขอ. นี่หมายความว่าเซิร์ฟเวอร์ไม่สามารถหรือจะไม่ใช้รุ่นเดียวกับที่ด้านลูกค้า. คำตอบควรรวมตัวแปลเพื่ออธิบายว่าทำไมรุ่นนี้ไม่ถูกสนับสนุนและประโยคสำหรับเซิร์ฟเวอร์ที่สนับสนุน |
| 506 | ขยายโดยโปรโตคอลการเจรจาเนื้อหาที่แสดงให้เห็นโดยสะดวก (RFC 2295), นี่เป็นสัญญาณของความผิดพลาดการตั้งค่าภายในเซิร์ฟเวอร์: ตัวแปรการเจรจาที่ขอมาใช้ตัวเองในการเจรจาเนื้อหาที่แสดงให้เห็นโดยสะดวก และดังนั้นไม่เหมาะสมสำหรับการเจรจา |
| 507 | เซิร์ฟเวอร์ไม่สามารถเก็บข้อมูลที่จำเป็นสำหรับการเสร็จทำการขอความร่วมมือ. สถานะของเงื่อนไขนี้ถือว่าเป็นชั่วคราว. WebDAV (RFC 4918) |
| 509 | เซิร์ฟเวอร์ได้ถึงขีดจำกัดของบاندเวด |
| 510 | นโยบายที่จำเป็นสำหรับการขอทรัพยากรไม่ผ่านเกณฑ์. (RFC 2774) |
