| एचटीटीपी स्टेटस कोड | स्टेटस कोड का अर्थ |
|---|
| 100 | क्लायंट साइड को अधिकारिक रूप से अनुरोध भेजना जारी रखना चाहिए। यह अस्थायी प्रतिक्रिया क्लायंट साइड को सूचित करने के लिए उपयोग की जाती है कि उसके कुछ अनुरोध सर्वर द्वारा प्राप्त किए गए हैं और अस्वीकृत नहीं हुए हैं। क्लायंट साइड को शेष अनुरोध भेजना जारी रखना चाहिए या अनुरोध पूरा होने पर प्रतिक्रिया को अनदेखा करना चाहिए। अनुरोध पूरा होने के बाद सर्वर को क्लायंट साइड को अंतिम प्रतिक्रिया भेजनी होगी。 |
| 101 | सर्वर ने क्लायंट के अनुरोध को समझा है और क्लायंट के तरफ को 'Upgrade' शीर्षक के माध्यम से सूचित करेगा कि वह एक अन्य प्रोटोकॉल का उपयोग करके अनुरोध को पूरा करे। प्रतिक्रिया में आखिरी खाली पंक्ति भेजने के बाद, सर्वर उन प्रोटोकॉलों को टूट जाएगा जो 'Upgrade' शीर्षक में निर्दिष्ट हैं। नए प्रोटोकॉल के लिए टूटने के दौरान केवल तब इस तरह की कदम उठाई जानी चाहिए जब यह अधिक लाभदायक हो। उदाहरण के लिए, नए HTTP संस्करण के लिए टूटना पुराने संस्करण की तुलना में लाभदायक है, या वास्तविक-समय और संगत प्रोटोकॉल को संसाधन डिलीवरी करने के लिए जो ऐसी विशेषताओं का लाभ उठाते हैं |
| 102 | WebDAV (RFC) द्वारा विस्तृत स्टेटस कोड 2518) इंगित करता है कि प्रसंस्करण जारी रहेगा |
| 200. | अनुरोध सफल हुआ है, और इच्छित प्रतिक्रिया शीर्षकों या डेटा शरीर को प्रतिक्रिया के साथ वापस किया गया है |
| 201 | अनुरोध पूरा हुआ है, और अनुरोध के आवश्यकताओं के अनुसार एक नया संसाधन बनाया गया है, और इसका URI 'Location' शीर्षक के साथ वापस किया गया है। यदि आवश्यक संसाधन समय पर बनाया नहीं जा सकता, '202 स्वीकार किया गया |
| 202 | सर्वर ने अनुरोध को स्वीकार किया है, लेकिन इसे अभी तक प्रसंस्कृत नहीं किया है। जैसा कि यह अस्वीकार किया जा सकता है, अनुरोध अंततः चलाया जा सकता है या नहीं। असंगत प्रक्रियाओं के मामले में, इस स्टेटस कोड भेजने से अधिक सुविधाजनक तरीका नहीं है। 'स्वीकार किया गया' को वापस करने का उद्देश्य 202 स्टेटस कोड प्रतिक्रिया का उद्देश्य सर्वर को अन्य प्रक्रियाओं (जैसे बैच) से अनुरोध ग्रहण करने की अनुमति देना है-एक दिन में एक बार काम करने वाला आधारभूत ऑपरेशन (बैच ऑपरेशन पूरा होने तक क्लायंट को सर्वर से जुड़े रहने के बगैर) के लिए। एक अनुरोध को प्रसंस्करण के लिए स्वीकार करने और एक प्रतिक्रिया के रूप में एक स्टेटस कोड वापस करने के जवाब में 202 स्टेटस कोड, वापस की इंटीटी में कुछ जानकारी शामिल होनी चाहिए जो प्रक्रिया के वर्तमान स्थिति को सूचित करे, साथ ही प्रक्रिया स्थिति मॉनिटर या पूर्वानुमान के लिए संदर्भ भी होना चाहिए, ताकि उपयोगकर्ता अनुमान लगा सके कि क्या प्रक्रिया पूर्ण हुई है। |
| 203 | सर्वर अनुरोध को सफलता से प्रसंस्कृत कर चुका है, लेकिन वापस की इंटीटी हेडर मेटा जानकारी उत्पुंजक सर्वर पर वैध अनिश्चित समूह नहीं है, बल्कि स्थानीय या तीसरा-पार्टी कॉपी। वर्तमान जानकारी मूल संस्करण का उपसमूह या उपसमूह हो सकती है। उदाहरण के लिए, संसाधनों वाली मेटाडाटा का उपयोग करते हुए मूल सर्वर को मेटा सुपर जानकारी हो सकती है। इस स्टेटस कोड का उपयोग आवश्यक नहीं है और यह केवल तभी उपयुक्त होता है जब प्रतिक्रिया को 200 ओके इस स्टेटस कोड के बिना। |
| 204 | सर्वर अनुरोध को सफलता से प्रसंस्कृत कर चुका है, लेकिन किसी भी भौतिक सामग्री को वापस करने की आवश्यकता नहीं है, और अपडेट मेटा जानकारी वापस करना चाहता है। प्रतिक्रिया किसी इंटीटी हेडर के रूप में हो सकती है, नई या अपडेट मेटा जानकारी वापस करती है। यदि इस हेडर जानकारी मौजूद है, तो यह अनुरोध की वारियबल से मेल खाना चाहिए। यदि क्लायंट दीवारा ब्राउज़र है, तो उपयोगकर्ता के ब्राउज़र को अनुरोध भेजने वाले पृष्ठ को बदले बिना दस्तावेज़ दृश्य के बिना रखना चाहिए, भले ही नई या अपडेट मेटा जानकारी को उपयोगकर्ता के ब्राउज़र के सक्रिय दृश्य में लागू करने के नियम के अनुसार होना चाहिए। क्योंकि 204 प्रतिक्रिया को किसी भी संदेश शरीर को शामिल करने से रोकने की आवश्यकता है, यह हेडर के बाद पहली खाली पंक्ति से समाप्त होती है। |
| 205 | सर्वर अनुरोध को सफलता से प्रसंस्कृत कर चुका है और कुछ नहीं वापस किया है। लेकिन 204 प्रतिक्रिया, जो यह स्टेटस कोड वापस करती है, यहाँ अनुरोधक को दस्तावेज़ दृश्य को रीसेट करने की आवश्यकता है। यह प्रतिक्रिया मुख्य रूप से उपयोग में आती है, ताकि उपयोगकर्ता आसानी से एक और इनपुट शुरू कर सके। जैसा कि 204 response, this response is also prohibited from including any message body and ends with the first blank line after the header. |
| 206 | प्रतिक्रिया, इस प्रतिक्रिया में भी कोई संदेश शरीर शामिल नहीं करना चाहिए और हेडर के बाद पहली खाली पंक्ति से समाप्त होती है।-सर्वर ने सफलता से GET अनुरोध का हिस्सा प्रसंस्कृत किया है। फ्लैशगेट या शुनली जैसे HTTP डाउनलोड टूल इस तरह की प्रतिक्रिया का उपयोग करते हैं ताकि ब्रेकपाइंट कान्तिकरण को लागू करें या एक बड़े दस्तावेज को कई डाउनलोड सेगमेंटों में विभाजित करके साथ-साथ डाउनलोड करें। अनुरोध में रेंज हेडर को शामिल करना चाहिए ताकि क्लायंट साइड द्वारा चाहिए वाले सामग्री के रेंज को संकेत करे, और इसके साथ If-रेंज एक अनुरोध शर्त के रूप में है। प्रतिक्रिया में निम्नलिखित हेडर फील्ड को शामिल करना चाहिए: कंटेंट-रेंज को इस प्रतिक्रिया में वापस मिलने वाले सामग्री के रेंज को संकेत करने के लिए इस्तेमाल करें; अगर यह बहु-सेगमेंट डाउनलोड के साथ कंटेंट/मल्टीपार्ट-कंटेंट बाइट रेंज है, तो प्रत्येक मल्टीपार्ट सेगमेंट में एक कंटेंट-रेंज फील्ड को इस खंड के सामग्री के रेंज को संकेत करने के लिए इस्तेमाल करें। अगर प्रतिक्रिया में कोई/या Content-Location, यदि एक ही अनुरोध को वापस प्रतिक्रिया देना चाहिए तो 200 प्रतिक्रिया। Expires, Cache-नियंत्रण और/लेंग्थ का उपयोग करता है, तो इसका मूल्य सामग्री के रेंज के वास्तविक बाइट की संख्या से मेल खाना चाहिए। तारीख ईटैग और-या वेरी, अगर इसका मूल्य अन्य प्रतिक्रियाओं की तुलना में अलग हो सकता है। अगर इस प्रतिक्रिया के अनुरोध में If-रेंज मजबूत कैश वैधीकरण, तो इस प्रतिक्रिया में अन्य एंटिटी हेडर्स को शामिल नहीं करना चाहिए; अगर इस प्रतिक्रिया के अनुरोध में If 2रेंज कमजोर कैश वैधीकरण है, तो इस प्रतिक्रिया में अन्य एंटिटी हेडर्स को शामिल नहीं करना चाहिए; यह कैशिंग एंटिटी सामग्री और अद्यतन एंटिटी हेडर सूचना के बीच असंगतियों को बचाता है।-00 प्रतिक्रिया में मिलने वाले सामग्री को मिलाने से निषिद्ध करना चाहिए। अगर ईटैग या लैस्ट 206 मॉडिफाइड हेडर्स को सही तरीके से मेल नहीं खाते, क्लायंट साइड कैश को इसके भीतर प्रतिक्रिया में मिलने वाले सामग्री को मिलाने से निषिद्ध करना चाहिए।-रेंज हेडर इसके द्वारा प्रतिक्रिया द्वारा वापस मिलने वाले सामग्री को कैशिंग करने से निषिद्ध है। कोई भी कैश की जो रेंज और सामग्री 206 प्रतिक्रिया. |
| 207 | वेबडेव (RFC) द्वारा विस्तारित स्टेटस कोड 2518बाद के संदेश का शरीर एक एक्सएमएल संदेश होगा, और पिछले उप-अनुरोधों की संख्या के आधार पर एक श्रृंखला स्वतंत्र प्रतिक्रिया कोड शामिल कर सकता है-अनुरोध |
| 300 | अनुरोधित संसाधन की एक श्रृंखला प्रतिप्रता विकल्प है, प्रत्येक के अपना विशेष पता और ब्राउज़र-ग्रीडवाइव निर्देश। उपयोगकर्ता या ब्राउज़र रीडायरेक्ट के लिए पसंदीदा पता चुन सकते हैं। यदि यह एक HEAD अनुरोध नहीं है, तो प्रतिक्रिया में संसाधन की विशेषताओं और पताओं की सूची शामिल करनी चाहिए जिनसे उपयोगकर्ता या ब्राउज़र सबसे उपयुक्त रीडायरेक्ट पता चुन सकते हैं। इस तत्व का फॉर्मेट कैंटेंट-टाइप। ब्राउज़र जवाब के फॉर्मेट और ब्राउज़र की अपनी क्षमताओं के आधार पर सबसे उपयुक्त विकल्प स्वचालित रूप से चुन सकता है। अन्यथा, RFC 2616 निर्देश यह निर्दिष्ट नहीं करता है कि ऐसा स्वचालित चयन कैसे किया जाना चाहिए। यदि सर्वर स्वयं पसंदीदा प्रतिप्रता चयन करता है, तो प्रतिप्रता की यूआरआई को 'स्थान' में निर्दिष्ट करना चाहिए; ब्राउज़र इस 'स्थान' मानक को स्वचालित रीडायरेक्ट के लिए पता के रूप में उपयोग कर सकते हैं। इसके अतिरिक्त, अगर अन्यथा निर्दिष्ट नहीं हो, तो प्रतिक्रिया कैशे भी रखी जा सकती है। |
| 301 | अनुरोधित संसाधन सदा निर्वाचित स्थान पर नए स्थान पर ले जाया गया है, और इस संसाधन के भविष्य की संदर्भ करने के लिए इस प्रतिक्रिया द्वारा प्रदान की गई कई यूआरआई का उपयोग करना चाहिए। यदि संभव हो, लिंक संपादन क्षमता वाले क्लायंट सदा सर्वर से प्राप्त की गई पता को अनुरोधित पता में बदलना स्वचालित रूप से कर सकता है। अगर अन्यथा निर्दिष्ट नहीं हो, तो यह प्रतिक्रिया कैशे भी रखी जा सकती है। नया स्थायी यूआरआई प्रतिक्रिया के 'स्थान' के क्षेत्र में प्रदान की जानी चाहिए। यदि यह एक HEAD अनुरोध नहीं है, तो प्रतिक्रिया के तत्व को नए यूआरआई के लिए हाइपरलिंक और एक संक्षिप्त वर्णन शामिल करना चाहिए। यदि यह GET या HEAD अनुरोध नहीं है, तो ब्राउज़र को उपयोगकर्ता की पुष्टि के बिना स्वचालित रूप से रीडायरेक्ट करने से रोकना चाहिए, क्योंकि अनुरोध की स्थिति बदल सकती है। नोट: कुछ ब्राउज़रों में एचटीटीपी/10 प्रोटोकॉल, जब वे पोस्ट रिक्वेस्ट भेजते हैं और एक 301 जवाब, अगला रेडीरेक्ट अनुरोध GET होगा. |
| 302 | अनुरोधित संसाधन अब अलग URI से अनुरोध को अस्थायी रूप से प्रतिस्पंदित कर रहा है. चूंकि इस तरह के रेडीरेक्ट्स अस्थायी हैं, ग्राहक साइड को भविष्य के अनुरोधों को मूल पते पर भेजना जारी रखना चाहिए. यह जवाब केवल जब आदेश दिया जाए तभी कैशे किया जा सकता है-कंट्रोल या Expires. नया अस्थायी URI, जवाब के लोकेशन में वापस लिया जाना चाहिए. यदि यह एक HEAD रिक्वेस्ट नहीं है, तो जवाब एंटिटी में नए URI के लिए एक हाइपरलिंक और एक संक्षिप्त वर्णन होना चाहिए. यदि यह GET या HEAD रिक्वेस्ट नहीं है, तो ब्राउज़र उपयोगकर्ता की पुष्टि के बिना स्वचालित रेडीरेक्टिंग को प्रतिबंधित करता है, क्योंकि रिक्वेस्ट की स्थिति इसी के परिणामस्वरूप बदल सकती है. नोट: हालांकि RFC 1945 को निर्देशित करते हैं. 2068 निर्देश नहीं देते हैं, जब रेडीरेक्टिंग के दौरान, कई मौजूदा ब्राउज़रों और RFC 302 जवाब को एक 303 जवाब और GET का उपयोग करके लोकेशन में निर्दिष्ट URI को पहुंचने के लिए, मूल रिक्वेस्ट विधि को नज़रअंदाज़ करते हुए. स्टेटस कोड 303 और 307 को जोड़ा गया है, ताकि सर्वर क्या ग्राहक साइड से अपेक्षा करता है, यह स्पष्ट करने के लिए. |
| 303 | वर्तमान रिक्वेस्ट के जवाब को एक अन्य URI पर ढूंढा जा सकता है, और क्लायंट साइड को उस संसाधन को पहुंचने के लिए GET अधिकार होना चाहिए. यह विधि मुख्य रूप से स्क्रिप्ट-पोस्ट रिक्वेस्ट आउटपुट को एक नए संसाधन को डायरेक्ट करने के लिए सक्रिय किया गया. यह नया URI मूल संसाधन के लिए प्रतिस्थापन संदर्भ नहीं है. अब भी, 303 responses are prohibited from being cached. Of course, a second request (redirect) may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlinke to the new URI and a brief description. Note: Many browsers prior to HTTP/1.1 प्रतिक्रियाएं कैश किए नहीं जा सकती हैं। ताकि दूसरा अनुरोध (डायरेक्ट) कैश किया जा सके। नई URI को प्रतिक्रिया के Location फील्ड में वापस किया जाना चाहिए। यदि यह HEAD अनुरोध नहीं है, तो प्रतिक्रिया एंटिटी में नई URI के लिए हाइपरलिंक और एक संक्षिप्त वर्णन शामिल होना चाहिए। नोट: HTTP के पहले के अनेक ब्राउज़र 303 समझते हैं 302 स्टेट कोड के पर्याप्त होना चाहिए, क्योंकि अधिकांश ब्राउज़र सही तरीके से स्टेट कोड का संभाल करते हैं। यदि आप इन ब्राउज़रों के साथ आपसी संचार को विचार करना चाहते हैं, तो 302 प्रतिक्रियाएं ठीक तरीके से उसी तरीके से प्राप्त करना चाहिए जिसे उपरोक्त विनिर्देश में क्लायंट साइड को काम करने के लिए कहा गया है 303 प्रतिक्रियाएं。 |
| 304 | यदि क्लायंट साइड एक शर्तीय GET अनुरोध भेजता है और अनुरोध को अनुमति दी गई है, और दस्तावेज़ की सामग्री बदली नहीं हुई है (पिछली यात्रा के बाद या अनुरोध की शर्तों के अनुसार), तो सर्वर को इस स्टेट कोड को वापस करना चाहिए。 304 प्रतिक्रियाओं को शीर्षकों को शामिल नहीं करने की निषेध की जाती है, इसलिए हमेशा शीर्षक के बाद पहली खाली पंक्ति से समाप्त होना चाहिए। प्रतिक्रिया में निम्नलिखित शीर्षक सूचना शामिल होनी चाहिए: Date, यदि इस सर्वर में घड़ी नहीं है तो.
यदि घड़ी वाला सर्वर भी इन नियमों का पालन करता है, तो प्रॉक्सी सर्वर और क्लायंट साइड स्वयं ग्रहित प्रतिक्रिया शीर्षक में डेट फील्ड जोड़ सकते हैं (RFC के अनुसार विनिर्दिष्ट किया गया है) 2068), और कैशिंग तंत्र ठीक से काम करेगा। ETag और/या Content-Location, यदि एक ही अनुरोध को वापस प्रतिक्रिया देना चाहिए तो 200 प्रतिक्रिया। Expires, Cache-नियंत्रण और/या 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-प्रमाणीकरण शीर्षक को अनुरोध के संसाधन के लिए उपयोगकर्ता से सूचना मांगने के लिए। क्लायंट तरफ को उचित प्रमाणीकरण शीर्षक सूचना के साथ अनुरोध को फिर से दाखिल कर सकता है। यदि मौजूदा अनुरोध प्रमाणीकरण प्रमाणपत्र को शामिल करता है, तो 401 प्रतिक्रिया के माध्यम से सर्वर उन प्रमाणपत्रों को अस्वीकार कर देता है। यदि 401 प्रतिक्रिया पिछली प्रतिक्रिया के समान प्रमाणीकरण प्रश्न को शामिल करती है और ब्राउज़र ने कम से कम एक बार प्रमाणीकरण की कोशिश की है, तो ब्राउज़र को प्रतिक्रिया में शामिल एंटिटी सूचना को उपयोगकर्ता को दिखाना चाहिए, क्योंकि इस एंटिटी सूचना में संबंधित निदान सूचना हो सकती है। देखें RFC 2617. |
| 402 | इस स्टेटस कोड को भविष्य की संभावित जरूरतों के लिए आरक्षित किया गया है。 |
| 403 | सर्वर ने अनुरोध को समझा है, लेकिन इसे कार्य करने से इनकार कर दिया है। इससे अलग, 401 प्रतिक्रिया, प्रमाणीकरण को मदद नहीं मिलता है और अनुरोध को फिर से दोहराया नहीं जाना चाहिए। यदि यह HEAD अनुरोध नहीं है और सर्वर इच्छा करता है कि अनुरोध क्यों नहीं कार्य किया जा सकता है इसका कारण सूचित करे, तो अस्वीकृति का कारण एंटिटी में वर्णित किया जाना चाहिए। निश्चित रूप से, सर्वर इसके साथ एंटिटी को भी वापस कर सकता है。 404 प्रतिक्रिया यदि वह इच्छा करता है कि क्लायंट तरफ को कोई भी सूचना नहीं मिले。 |
| 404 | अनुरोध विफल हुआ है और अचाही हुई संसाधन सर्वर पर नहीं मिली है। इस स्थिति को सामान्य या स्थायी क्या है इसकी कोई सूचना उपयोगकर्ता को नहीं दी जाती है। यदि सर्वर इस स्थिति के बारे में जानता है, तो 410 स्टेटस कोड का उपयोग पुराने संसाधन को सूचित करने के लिए किया जाना चाहिए कि यह स्थायी रूप से उपलब्ध नहीं है क्योंकि किसी आंतरिक कॉन्फ़िगरेशन मैकेनिज्म के कारण है और इसके लिए कोई पता नहीं है। 404 स्टेटस कोड सर्वर द्वारा यहीं कहा जाता है कि अनुरोध अस्वीकृत हुआ है या कोई अन्य उपयुक्त प्रतिक्रिया उपलब्ध नहीं है। |
| 405 | अनुरोध पंक्ति में निर्दिष्ट अनुरोध विधि को क्रियान्वित करने के लिए उपयोग नहीं किया जा सकता। प्रतिक्रिया को एक अनुरोध विधि की सूची वापस करने वाला Allow हेडर वापस करना चाहिए जो वर्तमान संसाधन द्वारा स्वीकार किया जा सकता है। क्योंकि PUT और DELETE विधियां सर्वर पर संसाधनों में लिखने के लिए हैं, अधिकांश वेब सर्वर इस अनुरोध विधि को मूलभूत रूप से समर्थित नहीं करते और नहीं अनुमति देते हैं और इसलिए वापस 405 ऐसे अनुरोधों के लिए त्रुटि |
| 406 | अनुरोध किए गए संसाधन की सामग्री की विशेषताएं अनुरोध हेडर में दी गई शर्तों को पूरा नहीं करती है, इसलिए प्रतिक्रिया संगठन नहीं बनाया जा सकता। इसके अलावा यह HEAD अनुरोध नहीं हो, तो प्रतिक्रिया को एक संगठन वापस करना चाहिए जो उपयोगकर्ता या ब्राउज़र को सबसे उपयुक्त संगठन विशेषताओं और पता सूची को चुनने की अनुमति देता है। संगठन का फॉर्मेट सामग्री के विषय हेडर में निर्धारित मीडिया टाइप द्वारा निर्धारित होता है-टाइप हेडर। ब्राउज़र फॉर्मेट और अपनी स्वयं की क्षमताओं के आधार पर सबसे अच्छा चयन कर सकता है। हालांकि, इस तरह के स्वचालित चयन के लिए कोई मानक निर्धारित नहीं है。 |
| 407 | इसी के समान 401 सबमित कर सकता है, सिवाय इसके कि क्लायंट पक्ष को प्रोक्सी सर्वर पर प्रमाणीकरण करना होगा। प्रोक्सी सर्वर को प्रोक्सी की प्रतिक्रिया वापस करनी होगी-सत्ता प्रमाणीकरण के लिए प्रमाणीकरण। क्लायंट पक्ष को प्रोक्सी की प्रतिक्रिया वापस कर सकता है-सत्ता प्रमाणीकरण के लिए ऑथेंटिकेशन हेडर। देखिए RFC 2617. |
| 408 | अनुरोध विफल हुआ। क्लायंट पक्ष ने सर्वर को प्रतीक्षा करने के लिए वक्त के भीतर अनुरोध भेजने का काम पूरा नहीं किया। क्लायंट पक्ष को बदले किए बिना किसी समय में अनुरोध को पुनःसबमित कर सकता है। |
| 409 | अनुरोध को अनुरोध किए गए संसाधन के वर्तमान स्थिति के साथ संघर्ष के कारण पूरा नहीं किया जा सकता है। इस कोड का उपयोग केवल तभी किया जा सकता है जब उपयोगकर्ता को संघर्ष को हल करने की क्षमता आशा की जाती है और वह एक नया अनुरोध पुनःसबमित करेगा। प्रतिक्रिया में पर्याप्त सूचना होनी चाहिए ताकि उपयोगकर्ता संघर्ष के स्रोत को खोज सके। संघर्ष आमतौर पर PUT अनुरोधों के प्रसंस्करण में होते हैं। उदाहरण के लिए, एक संसाधन-तड़ाश इकाई, यदि एक PUT के साथ जुड़ी संस्करण जानकारी-सबमिट किए गए संशोधन अनुरोध किसी विशेष संसाधन के लिए पिछले (तीसरे-पार्टी) अनुरोध, सर्वर को एक 409 उपयोगकर्ता को सूचित करने के लिए त्रुटि, जो अनुरोध को पूरा करने में असमर्थ है。
इस बिंदु पर, प्रतिक्रिया एंटिटी की संभावना से दो विरोधी संस्करणों के बीच अंतर की तुलना हो सकती है, ताकि उपयोगकर्ता को मिश्रित संस्करण को फिर से सबमिट कर सके। |
| 410 | अनुरोध किए गए संसाधन सर्वर पर अब उपलब्ध नहीं है और कोई ज्ञात फोरवर्डिंग एड्रेस नहीं है। इस स्थिति को स्थायी माना जाना चाहिए। यदि संभव हो, लिंक संपादन क्षमता वाले क्लायंट साइड को उपयोगकर्ता के अनुमति से इस एड्रेस के सभी संदर्भों को मिटाना चाहिए। यदि सर्वर इस स्थिति को स्थायी होने का पता नहीं लगता या निर्धारित नहीं कर सकता, तो एक 404 स्टेटस कोड का उपयोग करना चाहिए। अगर कोई अन्य विनिर्दिष्ट नहीं होता है, तो यह प्रतिक्रिया कैशेबल है। इसका उद्देश्य 410 प्रतिक्रिया मुख्य रूप से वेबमास्टर को वेबसाइट को बनाए रखने में मदद करने के लिए की जाती है, उपयोगकर्ता को सूचित करने के लिए कि संसाधन अब उपलब्ध नहीं है और सर्वर के मालिक को इस संसाधन के सभी दूरस्थ कनेक्शन को मिटाना चाहता है।
इस प्रकार की घटना समय में सामान्य है-सीमित, मूल्य-जोड़ी गई सेवाएं। इसी तरह, द 410 प्रतिक्रिया का उपयोग क्लायंट साइड को सूचित करने के लिए किया जाता है कि एक व्यक्ति के साथ संबंधित संसाधन वर्तमान सर्वर साइट पर अब उपलब्ध नहीं हैं। निश्चित रूप से, सर्वर के मालिक को पूरी तरह से ठीक है कि वह सभी सबसे अधिक अनुपलब्ध संसाधनों को 'गोने' के रूप में चिह्नित करे। 410 गोने ', और इस मार्क को कितने समय तक रखना है。 |
| 411 | सर्वर ने कंटेंट को परिभाषित किए बिना रिक्वेस्ट को स्वीकार करने से इनकार कर दिया-लेंग्थ हेडर। वैध कंटेंट जोड़ने के बाद-लेंग्थ हेडर जो रिक्वेस्ट बॉडी की लंबाई को सूचित करता है, क्लायंट साइड को फिर से रिक्वेस्ट सबमिट कर सकता है。 |
| 412 | सर्वर ने अनुरोध के हेडर क्षेत्र में दिए गए अवश्यकताओं की पुष्टि के दौरान एक या अधिक अवश्यकताओं को पूरा करने में असफल रहा। इस स्टेटस कोड के द्वारा क्लायंट साइड को संसाधनों को फेच करते समय अनुरोधित मेटाडाटा (अनुरोध हेडर क्षेत्र डेटा) में अवश्यकताओं को सेट करने की अनुमति है, इस तरह अनुरोध तरीके को इच्छित बाहर के संसाधनों पर लागू करने से रोकने की कोशिश की जाती है। |
| 413 | सर्वर वर्तमान अनुरोध को प्रसंस्करण करने से इनकार करता है क्योंकि अनुरोध एंटिटी डेटा को प्रस्तुत करता है जो सर्वर द्वारा सह्य या संभालने वाला है। इस मामले में सर्वर संपर्क को बंद कर सकता है ताकि क्लायंट साइड को अनुरोध भेजने को जारी न रखे। अगर यह स्थिति अस्थायी है, तो सर्वर को एक वापस करना चाहिए-अनुत्तर शीर्षक के बाद की सूचना के लिए क्लायंट साइड को बताने कि वह कितनी समय फिर से प्रयास कर सकता है。 |
| 414 | अनुरोधित यूरी सर्वर के अनुसार अनुवाद नहीं कर सकता, इसलिए सर्वर अनुरोध को सेवा नहीं देता। यह दुर्लभ है और सामान्य मामले शामिल हैं: एक फॉर्म सबमिशन जो पोस्ट तरीके का उपयोग करना चाहिए था, इसे गेट तरीके में बन जाता है, जिससे कि क्वेरी स्ट्रिंग (क्वेरी स्ट्रिंग) बहुत लंबी हो जाती है। रीडीरेक्ट यूरी "ब्लैक होल" जैसे कि प्रत्येक रीडीरेक्ट जो पुराने यूरी को नए यूरी के एक हिस्से के रूप में उपयोग करता है, जिससे कि कई रीडीरेक्ट के बाद यूरी बहुत लंबी हो जाती है। क्लायंट सर्वर को कुछ सर्वरों में मौजूद सुरक्षा दोषों के साथ हमला करने की कोशिश कर रहा है。
इस प्रकार के सर्वर एक निश्चित-लेंथ बफर को पढ़ने या अनुरोधित यूरी को काम करने के लिए स्थापित करता है। जब GET के बाद के पैरामीटर किसी निश्चित मान से अधिक होते हैं, तो बफर ओवरफ्लोव हो सकता है, जिससे कि एरिबीट्री वाइस कोड एक्शन हो सकता है [1]. ऐसी कोई दोषों के बिना होने वाले सर्वर को एक वापस करना चाहिए 414 स्टेटस कोड. |
| 415 | वर्तमान अनुरोध के तरीके और अनुरोधित संसाधन के लिए, अनुरोध में प्रस्तुत किए गए एंटिटी सर्वर द्वारा संभाले जाने वाले फॉर्मेट में नहीं है, इसलिए अनुरोध अस्वीकार कर दिया जाता है。 |
| 416 | अगर अनुरोध में रेंज हेडर है और रेंज में निर्दिष्ट किए गए किसी भी डेटा रेंज को वर्तमान संसाधन के उपलब्ध रेंज के साथ तालमेल नहीं होता है, और If-अनुरोध में रेंज हेडर नहीं परिभाषित है, सर्वर को एक वापस करना चाहिए 416 स्टेटस कोड। यदि रेंज बाइट रेंज का उपयोग करता है, तो इस स्थिति का मतलब है कि अनुरोध द्वारा निर्दिष्ट सभी डाटा रेंज का पहला बाइट स्थान वर्तमान संसाधन की लंबाई से अधिक है। सर्वर को इसके साथ अनुभव को भी समेत शामिल करना चाहिए-रेंज एंटिटी हेडर के साथ 416 स्टेटस कोड को वर्तमान संसाधन की लंबाई को संकेत करने के लिए। यह प्रतिक्रिया भी multipart का उपयोग करने से मना करती है/बाइट रेंज को उसके अनुभव के रूप में-टाइप. |
| 417 | अनुरोध से अपेक्षित सामग्री इंटरनेट प्रोटोकॉल के पते से सर्वर द्वारा पूरा नहीं किया जा सकता है, या सर्वर एक प्रॉक्सी सर्वर है जिसके पास इस रूट के अगले नोड पर अपेक्षित सामग्री को पूरा नहीं किया जा सकता है का साक्ष्य है। |
| 421 | इंटरनेट प्रोटोकॉल के पते से सर्वर को जोड़ने की संख्या वर्तमान क्लायंट साइड के स्थान पर सर्वर द्वारा अनुमति से अधिक है। आमतौर पर, इस इंटरनेट प्रोटोकॉल के पते का संदर्भ यहाँ क्लायंट साइड के पते के रूप में देखा जाता है (जैसे उपयोगकर्ता के गेटवे या प्रॉक्सी सर्वर का पता)। इस मामले में, कनेक्शन की संख्या में एक से अधिक उपयोगकर्ता शामिल हो सकते हैं। |
| 422 | इंटरनेट प्रोटोकॉल के पते से सर्वर को जोड़ने की संख्या वर्तमान क्लायंट साइड के स्थान पर सर्वर द्वारा अनुमति से अधिक है। आमतौर पर, इस इंटरनेट प्रोटोकॉल के पते का संदर्भ यहाँ क्लायंट साइड के पते के रूप में देखा जाता है (जैसे उपयोगकर्ता के गेटवे या प्रॉक्सी सर्वर का पता)। इस मामले में, कनेक्शन की संख्या में एक से अधिक उपयोगकर्ता शामिल हो सकते हैं। |
| 422 | अनुरोध शैली सही है, लेकिन अर्थविषयक त्रुटि के कारण जवाब नहीं दिया जा सका। (RFC 4918 वेबडेव) 423 लॉकेड वर्तमान संसाधन लॉक कर दिया है। (RFC 4918 वेबडेव) |
| 424 | वर्तमान अनुरोध पूर्व अनुरोध में एक त्रुटि के कारण विफल हुआ है, जैसे PROPPATCH। (RFC 4918 वेबडेव) |
| 425 | वेबडेव एडवांस्ड कलेक्शन्स ड्राफ्ट में परिभाषित, लेकिन वेबडेव सीक्वेंशियल सेट प्रोटोकॉल (RFC 3658). |
| 426 | क्लायंट साइड को TLS पर जाना चाहिए/1.0. (RFC 2817) |
| 449 | माइक्रोसॉफ्ट द्वारा विस्तारित, उचित कार्रवाई के प्रदर्शन के बाद अनुरोध को पुन: प्रयास करना चाहिए। |
| 500 | सर्वर ने अप्रत्याशित स्थिति का सामना किया जो इसे अनुरोध पूरा करने से रोका। आमतौर पर, यह समस्या सर्वर के कोड के विफल होने के कारण होती है。 |
| 501 | सर्वर वर्तमान अनुरोध के लिए आवश्यक एक विशेषता का समर्थन नहीं करता है। जब सर्वर अनुरोध की गई विधि को पहचान नहीं पाता है और किसी संसाधन के लिए अनुरोध को समर्थित नहीं कर सकता है। |
| 502 | जब एक सर्वर गेटवे या प्रॉक्सी के रूप में काम करता है और अनुरोध को कार्यान्वित करने की कोशिश करता है, तो इसे अधिकृत प्रतिक्रिया प्राप्त होती है। |
| 503 | सर्वर वर्तमान में अनुरोधों को प्रसंस्करण करने में असमर्थ है क्योंकि अस्थायी सर्वर रखरखाव या ओवरलोड है। यह स्थिति अस्थायी है और कुछ समय बाद वापस बहाल हो जाएगी। यदि विलंब काल को अनुमान किया जा सकता है, तो प्रतिक्रिया में Retry शामिल किया जा सकता है।-हेडर को विलंब काल को संकेत करने के लिए उपयोग करता है। यदि यह Retry-जबकि जानकारी नहीं दी गई है, ग्राहक पक्ष को इसे जैसे एक 500 प्रतिक्रिया. नोट: एक 503 स्टेटस कोड नहीं कहता कि सर्वर अवसर पर इसे उपयोग करना चाहिए। कुछ सर्वर सिर्फ ग्राहक के कनेक्शन को नकारना चाहते हैं。 |
| 504 | जब एक सर्वर गेटवे या प्रॉक्सी के रूप में काम करता है और अनुरोध को कार्यान्वित करने के प्रयास करता है, तो वह उपरी सर्वर (जैसे HTTP, FTP, LDAP) या द्वितीयक सर्वर (जैसे DNS) से समय पर प्रतिक्रिया प्राप्त नहीं कर पाता है (URI पर पहचाना, जैसे HTTP, FTP, LDAP) या द्वितीयक सर्वर (जैसे DNS) से समय पर प्रतिक्रिया प्राप्त नहीं कर पाता है. नोट: कुछ प्रॉक्सी सर्वरों द्वारा एक 400 या 500 त्रुटि जब DNS क्वेरी अवधि टालती है |
| 505 | सर्वर ने अनुरोध में उपयोग की जा रही HTTP संस्करण का समर्थन नहीं किया है या समर्थन करने से इनकार कर दिया है. यह संकेत देता है कि सर्वर ग्राहक पक्ष के समान संस्करण का उपयोग नहीं कर सकता या करने के लिए नहीं चाहता. प्रतिक्रिया में एक प्रतिबिंब शामिल होना चाहिए जो संस्करण को क्यों नहीं समर्थित है और सर्वर जो प्रोटोकॉल समर्थित करता है के बारे में बताता है。 |
| 506 | ट्रांसपेरेंट कंटेंट नेगोसिएशन प्रोटोकॉल (RFC 2295), यह सर्वर पर आंतरिक कॉन्फ़िगरेशन त्रुटि को प्रतिनिधित्व करता है: अनुरोध किए गए विनिमय वेरियेबल संसाधन को पारदर्शी सामग्री विनिमय में खुद को उपयोग में लाने के लिए कॉन्फ़िगर किया गया है, और इसलिए विनिमय प्रक्रिया में उचित केंद्र नहीं है。 |
| 507 | सर्वर ने अनुरोध को पूरा करने के लिए आवश्यक सामग्री को संग्रहीत नहीं कर सका. इस स्थिति को अस्थायी माना जाता है. WebDAV (RFC 4918) |
| 509 | सर्वर ने बैंडविड्थ लिमिट भर लिया है. यह एक आधिकारिक स्टेटस कोड नहीं है, लेकिन यह अभी भी व्यापक रूप से उपयोग में लिया जाता है. |
| 510 | संसाधन प्राप्त करने के लिए आवश्यक नीतियाँ पूरी नहीं हैं. (RFC 2774) |
