| HTTP स्थिति कोड |
स्थिति कोड का अर्थ |
| 100 |
क्लाइंट को अनुरोध भेजना जारी रखना चाहिए। यह अस्थायी उत्तर सूचित करने के लिए है कि सर्वर ने उसके अनुच्छेद में से कुछ अनुरोध प्राप्त कर लिए हैं, और अभी तक अस्वीकार नहीं किए गए हैं। क्लाइंट को शेष अनुरोध भेजना जारी रखना चाहिए, या यदि अनुरोध पूरा हो गया है, तो इस उत्तर की अनदेखी करें। सर्वर को एक अंतिम उत्तर क्लाइंट को भेजना चाहिए जब अनुरोध पूरा हो जाए। |
| 101 |
सर्वर ने क्लाइंट के अनुरोध को समझ लिया है और विभिन्न प्रोटोकॉल को अपनाने के लिए क्लाइंट को सूचना देने के लिए Upgrade संदेश हेडर का उपयोग करेगा। इस उत्तर के अंतिम खाली लाइन को भेजने के बाद, सर्वर उन प्रोटोकॉल में स्विच करेगा जिन्हें Upgrade संदेश हेडर में परिभाषित किया गया है। केवल तभी नए प्रोटोकॉल का स्विच करना चाहिए जब यह अधिक फायदेमंद हो। उदाहरण के लिए, नए HTTP संस्करण पर स्विच करना पुराने संस्करण की तुलना में अधिक फायदेमंद होगा, या ऐसे संसाधनों को वितरित करने के लिए वास्तविक समय और समकालिक प्रोटोकॉल में स्विच करना। |
| 102 |
WebDAV (RFC 2518) द्वारा विस्तारित स्थिति कोड, जो दर्शाता है कि प्रोसेस आगे चल रहा है। |
| 200 |
अनुरोध सफल रहा, अनुरोधित प्रतिक्रिया हेडर या डेटा शरीर इस प्रतिक्रिया के साथ लौटाया जाएगा। |
| 201 |
अनुरोध को अमल में लाया गया है, और एक नया संसाधन उस अनुरोध की आवश्यकताओं के अनुसार स्थापित किया गया है, और इसका URI Location हेडर जानकारी के साथ लौटाया गया है। यदि आवश्यक संसाधन तुरंत स्थापित नहीं किया जा सकता है, तो '202 Accepted' वापस किया जाना चाहिए। |
| 202 |
सर्वर ने अनुरोध को स्वीकार कर लिया है, लेकिन अभी तक संसाधित नहीं किया है। जैसा कि यह अस्वीकार किया जा सकता है, अंतिम अनुरोध को माना जा सकता है या नहीं। असिंक्रोनस ऑपरेशनों के मामले में, इससे बेहतर कुछ नहीं है कि इस स्थिति कोड को भेजना ही सबसे उचित है। 202 स्थिति कोड के साथ लौटाए गए उत्तर का उद्देश्य सर्वर को अन्य प्रक्रियाओं का अनुरोध स्वीकार करने की अनुमति देना है (उदाहरण के लिए, एक ऐसा ऑपरेशन जो केवल एक बार दिन में करता है), बिना क्लाइंट को सर्वर के साथ कनेक्शन बनाए रखे हुए सभी बैच प्रक्रियाओं के संपन्न होने तक। 202 स्थिति कोड के साथ लौटाए गए उत्तर में कुछ संकेत प्रदान करने वाले संकेत शामिल होने चाहिए, जो वर्तमान स्थिति पर नज़र रखते हैं या स्थिरता की वस्तुओं की ओर संकेत करते हैं, ताकि उपयोगकर्ता अनुमान लगा सके कि कार्य पूरा हो चुका है या नहीं। |
| 203 |
सर्वर ने अनुरोध को सफलतापूर्वक संसाधित किया है, लेकिन लौटाए गए सजीव हेडर डेटा मूल सर्वर पर मान्य सेट से नहीं है, बल्कि स्थानीय या तीसरे पक्ष की कॉपी से आया है। वर्तमान जानकारी मूल संस्करण का उपसमुच्चय या सुपरसेट हो सकती है। उदाहरण के लिए, संसाधनों की मेटाडेटा मूल सर्वर को जानकारी की सुपरसेट का पता लगाने का कारण बन सकती है। इस स्थिति कोड का उपयोग अनिवार्य नहीं है, और केवल उस स्थिति में उचित है जब प्रतिक्रिया इस स्थिति कोड का उपयोग किए बिना 200 OK लौटाएगी। |
| 204 |
सर्वर ने अनुरोध को सफलतापूर्वक संसाधित किया है, लेकिन कोई सजीव सामग्री लौटाने की आवश्यकता नहीं है, और अद्यतन सजीव जानकारी लौटाने की उम्मीद करता है। उत्तर नए या अद्यतन किए गए सजीव जानकारी के रूप में सजीव हेडर में लौटाया जा सकता है। यदि ये ट्रैफ़िकिंग मौजूद हैं, तो उन्हें अनुरोधित परिवर्तनों के साथ मेल खाना चाहिए। यदि क्लाइंट एक ब्राउज़र है, तो उपयोगकर्ता का ब्राउज़र उस पृष्ठ को बनाए रखेगा जिसने इस अनुरोध को भेजा था, और दस्तावेज़ दृश्य पर कोई परिवर्तन नहीं होगा, भले ही मानक के अनुसार नवीनतम या अद्यतन की गई सजीव जानकारी用户 के ब्राउज़र सक्रिय दृश्य में लागू होनी चाहिए। क्योंकि 204 प्रतिक्रिया में कोई सजीव सामग्री नहीं होनी चाहिए, यह हमेशा संदेश हेडर के बाद पहले खाली पंक्ति के साथ समाप्त होता है। |
| 205 |
सर्वर ने अनुरोध को सफलतापूर्वक संसाधित किया है, और कोई सामग्री नहीं लौटाई है। लेकिन 204 प्रतिक्रिया के विपरीत, इस स्थिति कोड के साथ लौटाए गए उत्तर में अनुरोधकर्ता से दस्तावेज़ दृश्य को रीसेट करने का अनुरोध किया गया है। यह उत्तर मुख्यतः उपयोगकर्ता इनपुट के बाद तुरंत फॉर्म को रीसेट करने के लिए उपयोग किया जाता है, ताकि उपयोगकर्ता आसानी से अगले इनपुट को आरंभ कर सके। 204 प्रतिक्रिया के समान, यह प्रतिक्रिया भी कोई सजीव सामग्री नहीं होनी चाहिए, और संदेश हेडर के बाद पहले खाली पंक्ति के साथ समाप्त होती है। |
| 206 |
सर्वर ने भाग में GET अनुरोध को सफलतापूर्वक संसाधित किया है। FlashGet या Xunlei जैसे HTTP डाउनलोड टूल्स ऐसी प्रतिक्रियाओं का उपयोग करके ब्रेकपॉइंट रिसुम किया जाता है या एक बड़े दस्तावेज़ को एक से अधिक डाउनलोड खंडों में विभाजित करता है और उन्हें एक साथ डाउनलोड किया जाता है। इस अनुरोध में यह दर्शाने के लिए एक Range हेडर होना चाहिए कि क्लाइंट किस सामग्री की सीमा चाहता है, और यह If-Range को अनुरोध की शर्त के रूप में शामिल कर सकता है। उत्तर में निम्नलिखित हेडर फ़ील्ड शामिल होनी चाहिए: Content-Range इस प्रतिक्रिया में लौटाए गए सामग्री के सीमा को दिखाने के लिए; यदि Content-Typemultipart/byteranges के मल्टीपार्ट डाउनलोड का है तो हर एक मल्टीपार्ट खंड में एक Content-Range फ़ील्ड होना चाहिए जो उस खंड के सीमा को दर्शाता है। यदि उत्तर में Content-Length शामिल है, तो उसका मान उस सामग्री सीमा की वास्तविक बाइट्स की संख्या के साथ मेल करना चाहिए जो वह लौटाता है। Date ETag और/या Content-Location, यदि समान अनुरोध को 200 प्रतिक्रिया देनी चाहिए। Expires,Cache-Control, और/या Vary, यदि उनके मान पिछले समान चर के अन्य प्रतिक्रियाओं के मानों से भिन्न हो सकते हैं। यदि इस प्रतिक्रिया अनुरोध ने If-Range के मजबूत कैशिंग प्रमाणीकरण का उपयोग किया है, तो इस बार की प्रतिक्रिया में अन्य सजीव हेडर नहीं होनी चाहिए; यदि इस प्रतिक्रिया का अनुरोध If-Range के कमजोर कैशिंग प्रमाणीकरण का उपयोग करता है, तो इस बार की प्रतिक्रिया अन्य सजीव हेडर को मना करती है; ऐसा कैश किए गए आपकी सामग्री और अद्यतन सजीव हेडर जानकारी के बीच असंगति से रोका जाता है। अन्यथा, इस बार की प्रतिक्रिया में सभी सजीव हेडर फ़ील्ड शामिल होनी चाहिए जो इसे एक ऐसे 200 प्रतिक्रिया के रूप में लौटाने वाले थे। यदि ETag या Last-Modified हेडर सटीक मेल नहीं करते हैं, तो क्लाइंट कैश को 206 प्रतिक्रियाओं को पिछले किसी भी कैश की गई सामग्री के साथ जोड़ने की अनुमति नहीं है। कोई भी कैश जो Range और Content-Range हेडर का समर्थन नहीं करता है, उसे 206 प्रतिक्रियाओं को कैश करने की अनुमति नहीं है। |
| 207 |
WebDAV (RFC 2518) द्वारा विस्तारित स्थिति कोड, जो दर्शाता है कि बाद में संदेश का शरीर एक XML संदेश होगा, और इसमें पहले उप-अनुरोधों की संख्या के मुताबिक एक श्रृंखला स्वतंत्र प्रतिक्रिया कोड हो सकते हैं। |
| 300 |
अनुरोधित संसाधन के पास कई ठोस विकल्प हैं, प्रत्येक का अपना विशिष्ट पता और ब्राउज़र के ड्रिवन से व्यावसायिक जानकारी होती है। उपयोगकर्ता या ब्राउज़र एक प्राथमिक पता के आधार पर पुनर्निर्देशित हो सकते हैं। जब तक यह एक HEAD अनुरोध नहीं है, तब तक इस प्रतिक्रिया में संसाधन की विशेषताओं और पते की मात्रा के एक सूचीवाले संलग्न की जरूरत हैं, ताकि उपयोगकर्ता या ब्राउज़र सबसे उपयुक्त पुनर्निर्देशित पते का चयन कर सकें। इस सामग्री का प्रारूप Content-Type द्वारा परिभाषित प्रारूप द्वारा निर्धारित किया जाता है। ब्राउज़र सामग्री के प्रारूप और अपने स्वयं के क्षमताओं के आधार पर स्वचालित रूप से सबसे उपयुक्त चयन कर सकता है। बेशक, RFC 2616 मानक ने इस तरह के स्वचालित चयन के लिए कोई विशिष्टता निर्धारित नहीं की है। यदि सर्वर के पास पहले से कोई प्राथमिक प्रतिक्रिया विकल्प है, तो इस प्रक्रिया में उस उत्तर के URI को Location में संकेत किया जाना चाहिए; ब्राउज़र इस Location मान को स्वचालित पुनर्निर्देशन के पते के रूप में मान सकता है। इसके अलावा, जब तक अतिरिक्त रूप से निर्दिष्ट नहीं किया गया हो, यह प्रतिक्रिया कैश के लिए भी होनी चाहिए। |
| 301 |
अनुरोधित संसाधन को स्थायी रूप से नए स्थान पर स्थानांतरित कर दिया गया है, और भविष्य में इस संसाधन के लिए किसी भी संदर्भ को इस उत्तर में लौटाए गए URI में से एक का उपयोग करना चाहिए। यदि संभव हो, तो लिंक संपादकीय क्षमताओं वाले क्लाइंट को स्वचालित रूप से अनुरोधित पते को सर्वर द्वारा वापस लौटाए गए पते में संशोधित करना चाहिए। जब तक अतिरिक्त रूप से निर्दिष्ट नहीं किया गया, यह प्रतिक्रिया कैश के लिए भी होनी चाहिए। नए स्थायी URI को प्रतिक्रिया के Location फ़ील्ड में वापस लौटाया जाना चाहिए। यानी यह HEAD अनुरोध नहीं है, नहीं और यदि यह GET या HEAD अनुरोध नहीं है, तो ब्राउज़र स्वचालित रूप से पुनर्निर्देशित नहीं कर सकता है, जब तक उपयोगकर्ता की पुष्टि न हो, क्योंकि अनुरोध की शर्तें बदल सकती हैं। ध्यान दें: कुछ HTTP/1.0 प्रोटोकॉल के लिए ब्राउज़र जब उन्होंने POST अनुरोध के लिए 301 प्रतिक्रिया दी, तो अगले पुनर्निर्देश अनुरोध GET विधि बन जाएगा। |
| 302 |
अनुरोधित संसाधन अब अस्थायी रूप से विभिन्न URI से अनुरोध को प्रतिक्रिया देता है। चूंकि यह पुनर्निर्देशन अस्थायी है, क्लाइंट को प्रारंभिक पते में बाद के अनुरोध भेजना जारी रखना चाहिए। केवल तब, यदि Cache-Control या Expires में निर्दिष्ट किया गया है, तो यह प्रतिक्रिया कैश हो सकती है। नए अस्थायी URI को प्रतिक्रिया के Location फ़ील्ड में लौटाया जाना चाहिए। यदि यह HEAD अनुरोध नहीं है, तो प्रतिक्रिया के शरीर में नए URI के लिए लिंक और संक्षिप्त विवरण शामिल होना चाहिए। यदि यह GET या HEAD अनुरोध नहीं है, तो ब्राउज़र स्वचालित रूप से पुनर्निर्देशन नहीं कर सकता है, जब तक उपयोगकर्ता की पुष्टि न हो, क्योंकि अनुरोध की शर्तें बदल सकती हैं। ध्यान दें: हालांकि RFC 1945 और RFC 2068 मानक क्लाइंट को अनुरोधित विधि के पुनर्निर्देशन में बदलाव की अनुमति नहीं देते हैं, लेकिन कई मौजूदा ब्राउज़र 302 प्रतिक्रिया को 303 प्रतिक्रिया के रूप में मानते हैं और Location में निर्धारित URI पर GET विधि का उपयोग करते हैं, वर्तमान विधि की अनदेखी करते हैं। स्थिति कोड 303 और 307 को स्पष्ट रूप से जोड़ा गया है, ताकि सर्वर क्लाइंट से किस प्रकार की प्रतिक्रिया की अपेक्षा करता है, इसे बताने के लिए। |
| 303 |
वर्तमान अनुरोध का उत्तर दूसरे URI पर पाया जा सकता है, और क्लाइंट को उस संसाधन तक पहुंचने के लिए GET विधि का उपयोग करना चाहिए। इस विधि का महत्त्व मुख्यतः स्क्रिप्ट द्वारा सक्रिय GET अनुरोध के बाद नए संसाधन पर पुनर्निर्देशित करने के लिए है। इस नए URI को मूल संसाधन के विकल्प के रूप में नहीं माना जाता है। साथ ही, 303 प्रतिक्रिया को कैश करने की अनुमति नहीं है। बेशक, दूसरा अनुरोध (पुनर्निर्देशन) कैश किया जा सकता है। नए URI को प्रतिक्रिया के Location फ़ील्ड में लौटाया जाना चाहिए। यानी यह HEAD अनुरोध नहीं है, तो दूसरे उत्तर में एक नए URI के लिए Hyperlink और संक्षिप्त विवरण होना चाहिए। ध्यान दें: कई HTTP/1.1 के पूर्व के ब्राउज़र सही ढंग से 303 स्थिति को समझ नहीं पाते हैं। यदि इन ब्राउज़रों के बीच बातचीत का विचार करने की आवश्यकता है, तो 302 स्थिति कोड उपयुक्त होना चाहिए, क्योंकि अधिकांश ब्राउज़र 302 प्रतिक्रियाओं को इस प्रकार व्यवहार करते हैं जैसा कि मानक में क्लाइंट को 303 प्रतिक्रियाओं को ठीक से व्यवहार करना चाहिए। |
| 304 |
यदि क्लाइंट ने एक शर्तीय GET अनुरोध भेजा है जिसे स्वीकार किया गया है, और प्रपत्र की सामग्री (अंतिम बार देखे जाने के बाद या अनुरोध की शर्तों के अनुसार) नहीं बदली गई है, तो सर्वर को यह स्थिति कोड लौटाना चाहिए। 304 प्रतिक्रिया में संदेश सामग्री नहीं होनी चाहिए, इसीलिए यह हमेशा संदेश हेडर के बाद पहले खाली पंक्ति के लक्जरी है। इस प्रतिक्रिया में निम्नलिखित हेडर शामिल होना चाहिए: Date, जब तक सर्वर का घड़ी ना हो। यदि घड़ी न होने वाला सर्वर भी इन नियमों का पालन करता है, तो फिर प्रॉक्सी सर्वर और क्लाइंट भी उत्तर हेडर में Date फ़ील्ड को जोड़ सकते हैं (जैसा कि RFC 2068 में परिभाषित किया गया है), और कैशिंग तंत्र सही रूप से कार्य करेगा। ETag और/या Content-Location, यदि समान अनुरोध को 200 प्रतिक्रिया वितरित करनी चाहिए। Expires,Cache-Control, और/या Vary, यदि उनके मान पिछले समान चर के अन्य प्रतिक्रियाओं से भिन्न हो सकते हैं। यदि इस प्रतिक्रिया अनुरोध ने मजबूत कैशिंग प्रमाणीकरण का उपयोग किया है, तो इस बार की प्रतिक्रिया में सजीव हेडर नहीं होनी चाहिए; अन्यथा (उदाहरण के लिए, जब एक शर्तीय GET अनुरोध में कमजोर कैशिंग प्रमाणीकरण का उपयोग किया गया हो), इस बार की प्रतिक्रिया में अन्य सजीव हेडर नहीं होनी चाहिए; यह कैश की गई सामग्री और अद्यतन स्थितियों के हेडर जानकारी के बीच असंगति से बचाता है। यदि 304 प्रतिक्रिया इस बात का संकेत देती है कि वर्तमान में कोई सामग्री कैश नहीं है, तो कैशिंग तंत्र को इस उत्तर की अनुपस्थिति की अनदेखी करनी चाहिए और कुछ नई सीमाओं के बिना अनुरोध को फिर से भेजना चाहिए। यदि 304 प्रतिक्रिया किसी कैश रिकॉर्ड को अद्यतन करने के लिए प्राप्त हुए, तो सभी अद्यतन क्षेत्रों के मूल्य को दर्शाने के लिए सिस्टम को समर्पित कैश प्रविष्टियों को अद्यतन करना चाहिए। |
| 305 |
अनुरोधित संसाधन को निर्दिष्ट प्रॉक्सी के माध्यम से पहुँचना आवश्यक है। Location हेडर में निर्दिष्ट प्रॉक्सी के URI की जानकारी दी जाएगी, प्राप्तकर्ता को पुनः अनुरोध भेजने की आवश्यकता होगी ताकि ग्राहक उस संसाधन तक पहुँच सके। केवल मूल सर्वर 305 प्रतिक्रिया बना सकता है। ध्यान दें: RFC 2068 में स्पष्ट रूप से नहीं कहा गया है कि 305 प्रतिक्रिया एक अलग अनुरोध को पुनर्निर्देशित करती है, और केवल मूल सर्वर बनाता है। इन प्रतिबंधों की अनदेखी सुरक्षा के लिए गंभीर परिणाम पैदा कर सकती है। |
| 306 |
नवीनतम मानक में, 306 स्थिति कोड अब उपयोग में नहीं है। |
| 307 |
अनुरोधित संसाधन अब अस्थायी रूप से विभिन्न URI से अनुरोधों को प्रतिक्रिया देता है। चूंकि यह पुनर्निर्देशन अस्थायी है, क्लाइंट को प्रारंभिक पते पर बाद के अनुरोध भेजना जारी रखना चाहिए। केवल तब, यदि Cache-Control या Expires में निर्दिष्ट किया गया हो, तो यह प्रतिक्रिया कैश हो सकती है। नए अस्थायी URI को प्रतिक्रिया के Location फ़ील्ड में लौटाया जाना चाहिए। यदि यह HEAD अनुरोध नहीं है, तो प्रतिक्रिया के शरीर में एक नए URI के लिए लिंक और संक्षिप्त विवरण होना चाहिए। चूंकि कुछ ब्राउज़र 307 प्रतिक्रिया की पहचान नहीं कर सकते हैं, इसलिए यह आवश्यक जानकारी जोड़ने की आवश्यकता है ताकि उपयोगकर्ताओं को समझने में और नए URI को अनुरोध करने में सहायता हो सके। यदि यह GET या HEAD अनुरोध नहीं है, तो ब्राउज़र स्वचालित रूप से पुनर्निर्देशित नहीं कर सकता है, जब तक उपयोगकर्ता के अवबोधन का पालन न किया जाए, क्योंकि अनुरोध की शर्तें फिर से बदल सकती हैं। |
| 400 |
1. अर्थ में कुछ त्रुटि है, वर्तमान अनुरोध को सर्वर नहीं समझ सकता है। परिवर्तन किए बिना क्लाइंट को फिर से अनुरोध नहीं करना चाहिए। 2. अनुरोध में कोई त्रुटि है। |
| 401 |
वर्तमान अनुरोध के लिए उपयोगकर्ता प्रमाणन की आवश्यकता है। इस प्रतिक्रिया में अनुरोधित संसाधन के लिए WWW-Authenticate हेडर होना चाहिए, ताकि उपयोगकर्ता की जानकारी पूछी जा सके। क्लाइंट सही पहचान प्रमाणपत्र के साथ एक अनुरोध पुनः सबमिट कर सकता है। यदि वर्तमान अनुरोध पहले से ही पहचान प्रमाण पत्र है, तो 401 उत्तर का तात्पर्य है कि सर्वर ने उन प्रमाण पत्रों को अस्वीकृत कर दिया है। यदि 401 प्रतिक्रिया में एक ही पहचान प्रमाणन अनुरोध है और ब्राउज़र ने कम से कम एक बार पहचान प्रमाणन करने का प्रयास किया है, तो ब्राउज़र को उपयोगकर्ता की जानकारी दिखानी चाहिए, क्योंकि यह जानकारी को संबोधित किया जा सकता है ताकि उपयोगकर्ता के पास उपयोगी निदान जानकारी हो सके। इसे RFC 2617 के अनुसार संदर्भित किया गया है। |
| 402 |
यह स्थिति कोड भविष्य में संभावित आवश्यकताओं के लिए आरक्षित है। |
| 403 |
सर्वर ने अनुरोध को समझ लिया है, लेकिन इसे निष्पादित करने से मना कर दिया है। 401 उत्तर से भिन्न, प्रमाणीकरण कोई मदद नहीं करेगा और इस अनुरोध को पुनः नही किया जाना चाहिए। यदि यह HEAD अनुरोध नहीं है और सर्वर यह स्पष्ट रूप से बताना चाहता है कि अनुरोध क्यों नहीं निष्पादित हो सकता है, तो इसे उत्तर में विस्तार से कहा जाना चाहिए। बेशक, यदि सर्वर चाहे, तो 404 के रूप में भी जवाब दे सकता है, यदि वह क्लाइंट को कुछ जानकारी नहीं देना चाहता। |
| 404 |
अनुरोध असफल रहा है, अनुरोध किया गया संसाधन सर्वर पर नहीं पाया गया। यह नहीं कह सकता है कि यह स्थिति अस्थायी है या स्थायी है। यदि सर्वर को स्थिति का ज्ञान है, तो स्थिति को सूचित करने के लिए 410 स्थिति कोड का उपयोग किया जाना चाहिए कि पुराना रिसोर्स किसी आंतरिक कॉन्फ़िगरेशन प्रणाली की समस्या के कारण स्थायी रूप से अनुपलब्ध है, और इसके लिए कोई स्थानांतरण पते नहीं है। 404 स्थिति कोड व्यापक रूप से तब उपयोग में होता है जब सर्वर यह नहीं चाहता है कि इसका अनुरोध अस्वीकृत क्यों हुआ या कोई अन्य सही प्रतिक्रिया उपलब्ध नहीं है। |
| 405 |
अनुरोध पंक्ति में निर्दिष्ट अनुरोध विधि अनुरोधित संसाधन के लिए उपयोग नहीं किया जा सकता। इसमें वर्तमान संसाधन को स्वीकार करने के लिए अनुरोध विधियों की एक सूची के अनुसार एक Allow हेडर होना चाहिए। चूंकि PUT और DELETE विधियाँ सर्वर पर संसाधनों के लिए लिखने की कार्रवाई करती हैं, इसलिए अधिकतर वेब सर्वर ये अनुरोध विधियाँ समर्थन नहीं करते या डिफ़ॉल्ट कॉन्फ़िगरेशन में अनुमति नहीं देते हैं, इसलिए ऐसे अनुरोधों के लिए 405 त्रुटि लौटाई जाएगी। |
| 406 |
अनुरोधित संसाधन की सामग्री की विशेषताएँ अनुरोध हेडर की शर्तों को संतुष्ट नहीं कर पाती हैं, इसलिए उत्तर की सजीव वस्तु का निर्माण नहीं किया जा सकता। जब तक यह एक HEAD अनुरोध नहीं है, उस उत्तर में एक फ़ाइल होनी चाहिए जो उपयोगकर्ता या ब्राउज़र को सबसे उपयुक्त सामग्री की विशेषताएँ और पते की सूची प्रदान करे। सामग्री का प्रारूप Content-Type हेडर में निर्दिष्ट मीडिया प्रकार द्वारा निर्धारित किया जाता है। ब्राउज़र फ़ॉर्मेट और अपने खुद के क्षमताओं के अनुसार सबसे उपयुक्त चयन कर सक सकता है। लेकिन मानक में इस तरह के स्वचालित चयन के लिए कोई मानक नहीं है। |
| 407 |
401 उत्तर के समान, मगर क्लाइंट को प्रॉक्सी सर्वर पर प्रमाणीकरण होना जरूरी है। प्रॉक्सी सर्वर को प्रमाणीकरण की मांग करने के लिए एक Proxy-Authenticate लौटाना चाहिए। क्लाइंट एक Proxy-Authorization हेडर के साथ प्रमाणीकरण कर सकता है। इसे RFC 2617 के रूप में संदर्भित किया गया है। |
| 408 |
अनुरोध समय समाप्त हो गया। क्लाइंट ने सर्वर द्वारा तैयार रहने के लिए निर्धारित समय में अनुरोध नहीं भेजा। क्लाइंट बिना किसी संशोधन के फिर से अनुरोध कर सकता है। |
| 409 |
अनुरोध वर्तमान संसाधन की स्थिति के साथ संघर्ष के कारण पूरा नहीं हो सका। यह कोड केवल तब उपयोग किया जा सकता है: जब उपयोगकर्ता को संघर्ष हल करने की अपेक्षा की जाती है, और उसे फिर से नया अनुरोध सबमिट करना चाहिए। इस उत्तर में पर्याप्त जानकारी होनी चाहिए ताकि उपयोगकर्ता संघर्ष के स्रोत को खोज सके। संघर्ष आमतौर पर PUT अनुरोध को संसाधित करते समय उत्पन्न होती है। उदाहरण के लिए, यदि संस्करण की जांच के वातावरण में, कोई PUT की जाने वाली संशोधन का अनुरोध होता है और जो स्वीकृत संस्करण संख्या से टकराता है, तो सर्वर को 409 त्रुटि लौटानी चाहिए और यह बताना चाहिए कि अनुरोध पूरा नहीं हो सका। इस समय, उत्तर की सामग्री में संभवतः उन दोनों संस्करणों के बीच के अंतर का तुलनात्मक विवरण होगा ताकि उपयोगकर्ता उसे वापस लाना फिर से अपने संस्करण में सहायता दे सके। |
| 410 |
अनुरोधित संसाधन अब सर्वर पर उपलब्ध नहीं है, और कोई ज्ञात स्थानांतरण पता नहीं है। इस स्थिति को स्थायी माना जाता है। यदि संभव हो, तो लिंक संपादकीय क्षमताओं वाले क्लाइंट को उपयोगकर्ता की अनुमति के बाद इस पते की ओर सभी संदर्भों को हटाना चाहिए। यदि सर्वर नहीं जानता या पता नहीं लगाता है कि यह स्थिति स्थायी है, तो 404 स्थिति कोड का उपयोग करना चाहिए। जब तक अतिरिक्त रूप से निर्दिष्ट नहीं किया गया हो, यह प्रतिक्रिया कैश के लिए होनी चाहिए। 410 प्रतिक्रिया का उद्देश्य मुख्य रूप से साइट व्यवस्थापक को साइट को बनाए रखने, उपयोगकर्ताओं को सूचित करना है कि संसाधन अब अनुपलब्ध है, और सर्वर के स्वामी को सभी दूरस्थ कनेक्शन को इस संसाधन के लिए हटाने की उम्मीद है। ये घटनाएँ अक्सर अस्थायी या मान्यता प्राप्त सेवाओं में होती हैं। इसी प्रकार, 410 प्रतिक्रिया का उपयोग यह सूचित करने के लिए किया जा सकता है कि वर्तमान सर्वर साइट पर किसी व्यक्तिगत उपयोगकर्ता का संसाधन अब अनुपलब्ध है। बेशक, क्या इसे सभी स्थायी अनुपलब्ध संसाधनों का '410 Gone' के रूप में टैग किया जाए, और यह टैग रखने का समय उपयोगकर्ता के स्वामी पर निर्भर करता है। |
| 411 |
सर्वर बिना Content-Length हेडर को परिभाषित किए अनुरोध को अस्वीकार करता है। मान्य Content-Length हेडर जोड़ने के बाद, क्लाइंट एक बार फिर से उस अनुरोध को सबमिट कर सकता है। |
| 412 |
जब सर्वर ने अनुरोध की हेडर फ़ील्ड में दिए गए प्री-कंडीशंस की जांच की, तो वह एक या अधिक को सफल नहीं बना सका। यह स्थिति कोड क्लाइंट को अनुरोध किए गए संसाधनों पर प्री-कंडीशंस सेट करने की अनुमति देता है, ताकि अनुरोध विधि को सामग्री के अलावा किसी अन्य संसाधन पर लागू नहीं किया जा सके। |
| 413 |
सर्वर वर्तमान अनुरोध को संसाधित करने से अस्वीकार करता है क्योंकि अनुरोध में जमा की गई सामग्री का आकार सर्वर की इसे संसाधित करने की क्षमता से अधिक होता है। इस स्थिति में सर्वर कनेक्शन को बंद कर सकता है ताकि क्लाइंट आगे इस अनुरोध को न भेज सके। यदि यह स्थिति अस्थायी है, तो सर्वर को Retry-After हेडर लौटाना चाहिए ताकि यह सूचित कर सके कि क्लाइंट कितनी देर बाद पुनः प्रयास कर सकता है। |
| 414 |
अनुरोधित URI की लंबाई उस सीमा से अधिक है जिसे सर्वर समझ सकता है, और इस प्रकार सर्वर उस अनुरोध को सेवा देने से इनकार कर देता है। यह काफी कम ही होता है, सामान्य स्थितियों में शामिल हैं: जिसके लिए POST विधि का उपयोग किया जाना चाहिए था, लेकिन इसे GET विधि के रूप में प्रस्तुत किया गया जिससे क्वेरी स्ट्रिंग (Query String) लंबी हो गई। एक पुनर्निर्देशन URI "काला छिद्र" जैसे, उदाहरण के लिए, प्रत्येक बार पुनर्निर्देशन पुराने URI को नए URI के हिस्से के रूप में होने की स्थिति में, यही प्रभाव पढ़ने के कई बार के कारण बना। क्लाइंट सर्वर में ज्ञात सुरक्षा भेद्यता का लाभ उठाने का प्रयास कर रहा है। इस तरह के सर्वर निश्चित लंबाई के बफ़र का उपयोग करके या अनुरोध के URI को पढ़ने/संवर्धित करने के लिए, GET के बाद के पैरामीटर अधिक मूल्य की होने पर, बफर ओवरफ्लो उत्पन्न करते हैं, जिसकी वजह से कोई भी कोड निष्पादित हो सकता है [1]। ऐसे ब्राउज़रों के बिना, सर्वर को 414 स्थिति कोड लौटाना चाहिए। |
| 415 |
वर्तमान अनुरोध की विधि और अनुरोधित संसाधन के लिए, अनुरोध में प्रस्तुत सामग्री सर्वर में समर्थित स्वरूप नहीं है, इस प्रकार अनुरोध को अस्वीकार कर दिया गया। |
| 416 |
यदि अनुरोध में Range अनुरोध हेडर होता है, और Range में निर्दिष्ट कोई भी डेटा सीमा वर्तमान संसाधन की उपलब्ध सीमाओं से मेल नहीं खाती है, और अनुरोध में If-Range अनुरोध हेडर नहीं है, तो सर्वर 416 स्थिति कोड को लौटाना चाहिए। यदि रेंज बाइट्स रेंज का उपयोग कर रहा है, तो इस स्थिति का तात्पर्य है कि अनुरोध द्वारा निर्दिष्ट सभी डेटा रेंज का पहला बाइट स्थान वर्तमान सामग्री की लंबाई से अधिक है। सर्वर को 416 स्थिति कोड लौटाते समय एक Content-Range हेडर शामिल करने की आवश्यकता है, जो यह दर्शाता है कि वर्तमान सामग्री की लंबाई है। इस उत्तर में multipart/byteranges को Content-Type के रूप में उपयोग करने की अनुमति नहीं है। |
| 417 |
अनुरोध हेडर में Expect में निर्दिष्ट अपेक्षित सामग्री सर्वर से संतुष्ट नहीं हो पाई, या यह सर्वर एक प्रॉक्सी सर्वर है, जिसके पास स्पष्ट सबूत हैं कि वर्तमान मार्ग में अगला नोड, Expect की सामग्री को पूरा नहीं कर सकता है। |
| 421 |
वर्तमान क्लाइंट के IP पते से.Server के लिए बेशुमार कनेक्शन अधिकतम सीमा से अधिक हैं। सामान्यतः, यहां IP पता सर्वर पर मरे हुए क्लाइंट पते को संदर्भित करता है (जैसे उपयोगकर्ता के गेटवे या प्रॉक्सी सर्वर का पता)। इस स्थिति में, कनेक्शन की गिनती में एक से अधिक अंतिम उपयोगकर्ता शामिल हो सकते हैं। |
| 422 |
अनुरोध स्वरूप सही है, लेकिन अर्थ समस्या के कारण प्रतिक्रिया नहीं हो पाती है। (RFC 4918 WebDAV) 423 Locked वर्तमान संसाधन लॉक्ड है। (RFC 4918 WebDAV) |
| 424 |
पिछले किसी अनुरोध के कारण उत्पन्न त्रुटि के कारण वर्तमान अनुरोध असफल हो गया, जैसे PROPPATCH। (RFC 4918 WebDAV) |
| 425 |
WebDav Advanced Collections ड्राफ्ट में परिभाषित, लेकिन WebDAV सीक्वेंस प्रोटोकॉल (RFC 3658) में नहीं दिखाई देता। |
| 426 |
क्लाइंट को TLS/1.0 पर स्विच करने की आवश्यकता है। (RFC 2817) |
| 449 |
माइक्रोसॉफ्ट द्वारा विस्तारित, दर्शाता है कि अनुरोध को उचित क्रियाओं को पूरा करने के बाद फिर से प्रयास करना चाहिए। |
| 500 |
सर्वर को एक अप्रत्याशित स्थिति का सामना करना पड़ा, जिसके कारण वह अनुरोध को पूरा नहीं कर सका। आमतौर पर, यह मुद्दा सर्वर के कोड (कोड) में त्रुटि होने पर होती है। |
| 501 |
सर्वर वर्तमान अनुरोध के लिए आवश्यक किसी एक फ़ीचर का समर्थन नहीं करता है। जब सर्वर अनुरोध की विधि को नहीं पहचानता है और संसाधन के लिए उसका समर्थन नहीं करता है। |
| 502 |
एक गेटवे या प्रॉक्सी की तरह काम करने वाले सर्वर ने अनुरोध करते समय ऊपर के सर्वर से अव्यवस्थित प्रतिक्रिया प्राप्त की। |
| 503 |
अस्थायी सर्वर रखरखाव या ओवरलोड के कारण सर्वर वर्तमान में अनुरोध को संसाधित नहीं कर सकता। यह स्थिति अस्थायी होती है, और थोड़े समय में ठीक हो जाएगी। यदि देरी की अवधि की भविष्यवाणी की जा सके, तो प्रतिक्रिया में एक Retry-After हेडर हो सकता है, यह बताने के लिए कि Clients कितनी देर बाद पुनः प्रयास कर सकता है। यदि Retry-After जानकारी नहीं दी गई है, तो क्लाइंट को इसे 500 प्रतिक्रिया के तरीकों से हैंडल करना चाहिए। ध्यान दें: 503 स्थिति कोड का होना उस बात का मतलब नहीं है कि सर्वर को ओवरलोड पर इसका उपयोग करना चाहिए। कुछ सर्वर बस क्लाइंट के कनेक्शन को अस्वीकार करना चाहते हैं। |
| 504 |
एक गेटवे या प्रॉक्सी की तरह काम करने वाले सर्वर ने अनुरोध करते समय सही समय पर ऊपर के सर्वर (URI के द्वारा चिह्नित सर्वर, जैसे HTTP, FTP, LDAP) या सहायक सर्वर (जैसे DNS) से प्रतिक्रिया प्राप्त करने में असफल रही। ध्यान दें: कुछ प्रॉक्सी सर्वर DNS क्वेरी के टाइमआउट पर 400 या 500 त्रुटि लौटाते हैं। |
| 505 |
सर्वर उस HTTP संस्करण का समर्थन नहीं करता है जिसका अनुरोध में उपयोग किया गया था, या समर्थन करने से इंकार करता है। इसका तात्पर्य है कि सर्वर क्लाइंट के समान संस्करण का उपयोग नहीं करने के लिए तैयार है। इस प्रतिक्रिया में यह शामिल होना चाहिए कि क्यों संस्करण का समर्थन नहीं किया जाता है, और सर्वर किस तरह के प्रोटोकॉल का समर्थन करता है। |
| 506 |
पारदर्शी सामग्री समायोजन प्रोटोकॉल (RFC 2295) द्वारा विस्तारित, दर्शाता है कि सर्वर में एक आंतरिक कॉन्फ़िगरेशन त्रुटि है: अनुरोधित समायोजन वेरिएंट संसाधन को पारदर्शी सामग्री समायोजन में अपने रूप में कॉन्फ़िगर किया गया है, इसलिए यह एक समायोजन प्रोसेसिंग में उपयुक्त हो नहीं सकता। |
| 507 |
सर्वर वह सामग्री संग्रहीत करने में असमर्थ है जिसे वर्तमान अनुरोध पूरा करने के लिए आवश्यक है। यह स्थिति को अस्थायी माना जाता है। WebDAV(RFC 4918) |
| 509 |
सर्वर ने बैंडविड्थ सीमा को पार कर लिया। यह एक आधिकारिक स्थिति कोड नहीं है, लेकिन फिर भी व्यापक रूप से उपयोग किया जाता है। |
| 510 |
संसाधन प्राप्त करने के लिए आवश्यक नीतियों को पूरा नहीं किया गया है। (RFC 2774) |