| HTTP स्थिति कोड | स्थिति कोड का अर्थ |
|---|
| 100 | ग्राहक को अनुरोध भेजना जारी रखना चाहिए. इस अनंतिम प्रतिक्रिया का उपयोग क्लाइंट को यह सूचित करने के लिए किया जाता है कि उसके अनुरोध का कुछ हिस्सा सर्वर द्वारा प्राप्त कर लिया गया है और अभी तक अस्वीकार नहीं किया गया है। ग्राहक को शेष अनुरोध भेजना जारी रखना चाहिए, या यदि अनुरोध पहले ही पूरा हो चुका है तो इस प्रतिक्रिया को अनदेखा कर देना चाहिए। अनुरोध पूरा होने के बाद सर्वर को क्लाइंट को अंतिम प्रतिक्रिया भेजनी होगी। |
| 101 | सर्वर ने क्लाइंट के अनुरोध को समझ लिया है और अनुरोध को पूरा करने के लिए एक अलग प्रोटोकॉल का उपयोग करने के लिए अपग्रेड संदेश हेडर के माध्यम से क्लाइंट को सूचित करेगा। इस प्रतिक्रिया की अंतिम रिक्त पंक्ति भेजने के बाद, सर्वर अपग्रेड हेडर में परिभाषित प्रोटोकॉल पर स्विच हो जाएगा। ऐसे उपाय केवल तभी उठाए जाने चाहिए जब नए प्रोटोकॉल पर स्विच करना अधिक फायदेमंद हो। उदाहरण के लिए, नए HTTP संस्करण पर स्विच करने से पुराने संस्करण की तुलना में फायदे हैं, या ऐसी सुविधाओं का लाभ उठाने वाले संसाधनों को वितरित करने के लिए वास्तविक समय और सिंक्रोनस प्रोटोकॉल पर स्विच करना। |
| 102 | WebDAV (RFC 2518) द्वारा विस्तारित एक स्थिति कोड यह दर्शाता है कि प्रसंस्करण जारी रहेगा। |
| 200 | अनुरोध सफल रहा और अनुरोध द्वारा अपेक्षित प्रतिक्रिया शीर्षलेख या डेटा बॉडी इस प्रतिक्रिया के साथ वापस कर दी जाएगी। |
| 201 | अनुरोध पूरा हो गया है, अनुरोध की जरूरतों के आधार पर एक नया संसाधन बनाया गया है, और इसका यूआरआई स्थान हेडर के साथ वापस कर दिया गया है। यदि आवश्यक संसाधन समय पर नहीं बनाए जा सकते हैं, तो '202 स्वीकृत' लौटाया जाना चाहिए। |
| 202 | सर्वर ने अनुरोध स्वीकार कर लिया है लेकिन अभी तक इसे संसाधित नहीं किया है। जिस प्रकार इसे अस्वीकार किया जा सकता है, उसी प्रकार अनुरोध अंततः निष्पादित हो भी सकता है और नहीं भी। अतुल्यकालिक संचालन के मामले में, इस स्थिति कोड को भेजने से अधिक सुविधाजनक कोई तरीका नहीं है। 202 स्थिति कोड प्रतिक्रिया लौटाने का उद्देश्य सर्वर को बैच ऑपरेशन तक क्लाइंट को सर्वर से कनेक्ट किए बिना अन्य प्रक्रियाओं (जैसे बैच-आधारित ऑपरेशन जो दिन में केवल एक बार किया जाता है) से अनुरोध स्वीकार करने की अनुमति देना है। बन चूका है। एक प्रतिक्रिया जो अनुरोध प्रसंस्करण को स्वीकार करती है और 202 स्थिति कोड लौटाती है, उसमें लौटाई गई इकाई में प्रसंस्करण की वर्तमान स्थिति को इंगित करने वाली कुछ जानकारी होनी चाहिए, साथ ही प्रसंस्करण स्थिति मॉनिटर या स्थिति भविष्यवाणी के लिए एक संकेतक भी होना चाहिए ताकि उपयोगकर्ता अनुमान लगा सके कि क्या ऑपरेशन पूरा हो गया है। |
| 203 | सर्वर ने अनुरोध को सफलतापूर्वक संसाधित कर दिया है, लेकिन लौटाई गई इकाई हेडर मेटाइनफॉर्मेशन मूल सर्वर पर मान्य एक निश्चित सेट नहीं है, बल्कि स्थानीय या तीसरे पक्ष की एक प्रति है। वर्तमान जानकारी मूल संस्करण का उपसमूह या सुपरसेट हो सकती है। उदाहरण के लिए, किसी संसाधन के लिए मेटाडेटा रखने से मूल सर्वर को मेटाडेटा के बारे में सुपर जानकारी मिल सकती है। इस स्थिति कोड का उपयोग करना आवश्यक नहीं है और यह केवल तभी उचित है जब प्रतिक्रिया इस स्थिति कोड के बिना 200 ओके लौटाती। |
| 204 | सर्वर ने अनुरोध को सफलतापूर्वक संसाधित कर दिया है, लेकिन उसे किसी इकाई सामग्री को वापस करने की आवश्यकता नहीं है और वह अद्यतन मेटा जानकारी लौटाना चाहता है। प्रतिक्रिया इकाई हेडर के रूप में नई या अद्यतन मेटा जानकारी लौटा सकती है। ये हेडर, यदि मौजूद हैं, तो अनुरोधित चर के अनुरूप होने चाहिए। यदि क्लाइंट एक ब्राउज़र है, तो उपयोगकर्ता के ब्राउज़र को उस पृष्ठ को बनाए रखना चाहिए जिसके लिए दस्तावेज़ दृश्य में कोई बदलाव किए बिना अनुरोध किया गया था, भले ही दस्तावेज़ के विनिर्देश के अनुसार उपयोगकर्ता की ब्राउज़र गतिविधि पर नई या अद्यतन मेटाइनफॉर्मेशन लागू की जानी चाहिए। चूंकि 204 प्रतिक्रिया में किसी भी संदेश का मुख्य भाग शामिल होना प्रतिबंधित है, यह हमेशा संदेश शीर्षलेख के बाद पहली खाली पंक्ति के साथ समाप्त होता है। |
| 205 | सर्वर ने अनुरोध को सफलतापूर्वक संसाधित किया और कुछ भी नहीं लौटाया। लेकिन 204 प्रतिक्रिया के विपरीत, इस स्थिति कोड को लौटाने वाली प्रतिक्रिया के लिए अनुरोधकर्ता को दस्तावेज़ दृश्य को रीसेट करने की आवश्यकता होती है। इस प्रतिक्रिया का उपयोग मुख्य रूप से उपयोगकर्ता इनपुट स्वीकार करने के तुरंत बाद फॉर्म को रीसेट करने के लिए किया जाता है ताकि उपयोगकर्ता आसानी से दूसरा इनपुट शुरू कर सके। 204 प्रतिक्रिया की तरह, इस प्रतिक्रिया में किसी भी संदेश का मुख्य भाग शामिल होना प्रतिबंधित है और संदेश शीर्षलेख के बाद पहली रिक्त पंक्ति के साथ समाप्त होता है। |
| 206 | सर्वर ने GET अनुरोध के भाग को सफलतापूर्वक संसाधित कर दिया है। फ्लैशगेट या थंडर जैसे HTTP डाउनलोड टूल बाधित डाउनलोड को फिर से शुरू करने या एक साथ डाउनलोड करने के लिए एक बड़े दस्तावेज़ को कई डाउनलोड सेगमेंट में तोड़ने के लिए इस प्रकार की प्रतिक्रिया का उपयोग करते हैं। अनुरोध में ग्राहक द्वारा अपेक्षित सामग्री की सीमा को इंगित करने के लिए एक रेंज हेडर शामिल होना चाहिए, और अनुरोध शर्त के रूप में एक इफ़-रेंज शामिल हो सकता है। प्रतिक्रिया में निम्नलिखित हेडर फ़ील्ड शामिल होने चाहिए: सामग्री-रेंज का उपयोग इस प्रतिक्रिया में लौटाई गई सामग्री की सीमा को इंगित करने के लिए किया जाता है; यदि यह सामग्री-प्रकार मल्टीपार्ट/बाइटरेंज के साथ एक बहु-भाग डाउनलोड है, तो प्रत्येक मल्टीपार्ट भाग में सामग्री-रेंज शामिल होनी चाहिए। डोमेन का उपयोग इस अनुच्छेद की सामग्री के दायरे को इंगित करने के लिए किया जाता है। यदि प्रतिक्रिया में सामग्री-लंबाई शामिल है, तो इसका मान उसके द्वारा लौटाई गई सामग्री श्रेणी में बाइट्स की वास्तविक संख्या से मेल खाना चाहिए। दिनांक ईटैग और/या सामग्री-स्थान, यदि समान अनुरोध है तो 200 प्रतिक्रिया लौटानी चाहिए। समाप्त, कैश-कंट्रोल, और/या भिन्न, यदि इसका मान समान चर के अन्य पिछले प्रतिक्रियाओं के अनुरूप मान से भिन्न हो सकता है। यदि यह प्रतिक्रिया अनुरोध इफ-रेंज मजबूत कैश सत्यापन का उपयोग करता है, तो इस प्रतिक्रिया में अन्य इकाई हेडर शामिल नहीं होने चाहिए; यदि यह प्रतिक्रिया अनुरोध इफ-रेंज कमजोर कैश सत्यापन का उपयोग करता है, तो इस प्रतिक्रिया में अन्य इकाई हेडर शामिल होने से प्रतिबंधित है; यह बीच की विसंगतियों को हल करने से बचता है कैश्ड इकाई सामग्री और अद्यतन इकाई हेडर जानकारी। अन्यथा, इस प्रतिक्रिया में सभी इकाई हेडर फ़ील्ड शामिल होने चाहिए जिन्हें 200 प्रतिक्रिया में लौटाया जाना चाहिए। यदि ईटैग या अंतिम-संशोधित हेडर बिल्कुल मेल नहीं खाते हैं, तो क्लाइंट कैश को 206 प्रतिक्रिया द्वारा लौटाई गई सामग्री को किसी भी पहले से कैश की गई सामग्री के साथ संयोजित नहीं करना चाहिए। कोई भी कैश जो रेंज और कंटेंट-रेंज हेडर का समर्थन नहीं करता है, उसे 206 प्रतिक्रिया द्वारा लौटाई गई सामग्री को कैशिंग करने से प्रतिबंधित किया गया है। |
| 207 | WebDAV (RFC 2518) द्वारा विस्तारित स्थिति कोड का अर्थ है कि आगामी संदेश का मुख्य भाग एक XML संदेश होगा और इसमें पिछले उपअनुरोधों की संख्या के आधार पर स्वतंत्र प्रतिक्रिया कोड की एक श्रृंखला हो सकती है। |
| 300 | अनुरोधित संसाधन में वैकल्पिक प्रतिक्रियाओं की एक श्रृंखला होती है, प्रत्येक का अपना विशिष्ट पता और ब्राउज़र ड्राइवर बातचीत जानकारी होती है। उपयोगकर्ता या ब्राउज़र पुनर्निर्देशन के लिए पसंदीदा पता चुन सकता है। जब तक यह एक HEAD अनुरोध न हो, प्रतिक्रिया में संसाधन विशेषताओं और पतों की एक सूची के साथ एक इकाई शामिल होनी चाहिए, जिसमें से उपयोगकर्ता या ब्राउज़र सबसे उपयुक्त रीडायरेक्ट पता चुन सकते हैं। इस इकाई का प्रारूप सामग्री-प्रकार द्वारा परिभाषित प्रारूप द्वारा निर्धारित किया जाता है। प्रतिक्रिया के प्रारूप और ब्राउज़र की अपनी क्षमताओं के आधार पर ब्राउज़र स्वचालित रूप से सबसे उपयुक्त विकल्प चुन सकता है। बेशक, आरएफसी 2616 विनिर्देश यह निर्दिष्ट नहीं करता है कि इस तरह का स्वचालित चयन कैसे किया जाना चाहिए। यदि सर्वर के पास पहले से ही पसंदीदा फीडबैक विकल्प है, तो इस फीडबैक का यूआरआई स्थान में निर्दिष्ट किया जाना चाहिए; ब्राउज़र स्वचालित पुनर्निर्देशन के लिए पते के रूप में इस स्थान मान का उपयोग कर सकता है। इसके अतिरिक्त, यह प्रतिक्रिया कैश करने योग्य है जब तक कि अन्यथा निर्दिष्ट न हो। |
| 301 | अनुरोधित संसाधन को स्थायी रूप से एक नए स्थान पर ले जाया गया है, और इस संसाधन के किसी भी भविष्य के संदर्भ में इस प्रतिक्रिया के साथ लौटाए गए कई यूआरआई में से एक का उपयोग करना चाहिए। यदि संभव हो, तो लिंक संपादन क्षमताओं वाले क्लाइंट को अनुरोधित पते को सर्वर से लौटाए गए पते पर स्वचालित रूप से संशोधित करना चाहिए। जब तक अन्यथा निर्दिष्ट न हो, यह प्रतिक्रिया भी कैश करने योग्य है। नया स्थायी यूआरआई प्रतिक्रिया के स्थान फ़ील्ड में लौटाया जाना चाहिए। जब तक यह एक HEAD अनुरोध न हो, प्रतिक्रिया इकाई में नए URI के लिए एक हाइपरलिंक और एक संक्षिप्त विवरण होना चाहिए। यदि यह GET या HEAD अनुरोध नहीं है, तो ब्राउज़र उपयोगकर्ता द्वारा पुष्टि किए जाने तक स्वचालित पुनर्निर्देशन को प्रतिबंधित करता है, क्योंकि अनुरोध की शर्तें तदनुसार बदल सकती हैं। नोट: HTTP/1.0 प्रोटोकॉल का उपयोग करने वाले कुछ ब्राउज़रों के लिए, जब उनके द्वारा भेजे गए POST अनुरोध को 301 प्रतिक्रिया मिलती है, तो बाद का रीडायरेक्ट अनुरोध एक GET विधि बन जाएगा। |
| 302 | अनुरोधित संसाधन अब अस्थायी रूप से एक अलग यूआरआई से अनुरोधों का जवाब देता है। क्योंकि ऐसे रीडायरेक्ट अस्थायी होते हैं, क्लाइंट को भविष्य के अनुरोधों को मूल पते पर भेजना जारी रखना चाहिए। यह प्रतिक्रिया कैश-कंट्रोल या एक्सपायर्स में निर्दिष्ट होने पर ही कैश करने योग्य होती है। नया अस्थायी यूआरआई प्रतिक्रिया के स्थान फ़ील्ड में लौटाया जाना चाहिए। जब तक यह एक HEAD अनुरोध न हो, प्रतिक्रिया इकाई में नए URI के लिए एक हाइपरलिंक और एक संक्षिप्त विवरण होना चाहिए। यदि यह GET या HEAD अनुरोध नहीं है, तो ब्राउज़र उपयोगकर्ता द्वारा पुष्टि किए जाने तक स्वचालित पुनर्निर्देशन को प्रतिबंधित करता है, क्योंकि अनुरोध की शर्तें तदनुसार बदल सकती हैं। ध्यान दें: हालाँकि RFC 1945 और RFC 2068 विनिर्देश क्लाइंट को रीडायरेक्ट करते समय अनुरोध विधि को बदलने की अनुमति नहीं देते हैं, कई मौजूदा ब्राउज़र 302 प्रतिक्रिया को 303 प्रतिक्रिया के रूप में मानते हैं, और स्थान में निर्दिष्ट URI तक पहुँचने के लिए GET विधि का उपयोग करते हैं, भले ही मूल अनुरोध की विधि का. स्थिति कोड 303 और 307 यह स्पष्ट करने के लिए जोड़े गए थे कि सर्वर क्लाइंट से किस प्रतिक्रिया की अपेक्षा करता है। |
| 303 | वर्तमान अनुरोध की प्रतिक्रिया किसी अन्य यूआरआई पर पाई जा सकती है, और क्लाइंट को उस संसाधन तक पहुंचने के लिए GET का उपयोग करना चाहिए। यह विधि मुख्य रूप से स्क्रिप्ट-सक्रिय POST अनुरोध आउटपुट को एक नए संसाधन पर पुनर्निर्देशित करने की अनुमति देने के लिए मौजूद है। यह नया यूआरआई मूल संसाधन का प्रतिस्थापन संदर्भ नहीं है। वहीं, 303 प्रतिक्रियाओं को कैश्ड होने से रोका गया है। बेशक, दूसरा अनुरोध (रीडायरेक्ट) कैश किया जा सकता है। नया यूआरआई प्रतिक्रिया के स्थान फ़ील्ड में लौटाया जाना चाहिए। जब तक यह एक HEAD अनुरोध न हो, प्रतिक्रिया इकाई में नए URI के लिए एक हाइपरलिंक और एक संक्षिप्त विवरण होना चाहिए। ध्यान दें: कई प्री-HTTP/1.1 ब्राउज़र 303 स्थिति को सही ढंग से नहीं समझते हैं। यदि आपको इन ब्राउज़रों के साथ इंटरेक्शन पर विचार करने की आवश्यकता है, तो 302 स्थिति कोड पर्याप्त होना चाहिए, क्योंकि अधिकांश ब्राउज़र 302 प्रतिक्रियाओं को ठीक उसी तरह संभालते हैं जिस तरह उपरोक्त विनिर्देशन के लिए ग्राहकों को 303 प्रतिक्रियाओं को संभालने की आवश्यकता होती है। |
| 304 | यदि क्लाइंट एक सशर्त GET अनुरोध भेजता है और अनुरोध की अनुमति है, लेकिन दस्तावेज़ की सामग्री नहीं बदली है (अंतिम पहुंच के बाद से या अनुरोध की शर्तों के अनुसार), तो सर्वर को यह स्थिति कोड वापस करना चाहिए। 304 प्रतिक्रिया में संदेश का मुख्य भाग शामिल करना प्रतिबंधित है, इसलिए यह हमेशा संदेश शीर्षलेख के बाद पहली रिक्त पंक्ति के साथ समाप्त होता है। प्रतिक्रिया में निम्नलिखित हेडर जानकारी होनी चाहिए: दिनांक, जब तक कि सर्वर में घड़ी न हो। यदि बिना घड़ियों वाले सर्वर भी इन नियमों का अनुपालन करते हैं, तो प्रॉक्सी सर्वर और क्लाइंट स्वयं प्राप्त प्रतिक्रिया हेडर में दिनांक फ़ील्ड जोड़ सकते हैं (जैसा कि RFC 2068 में निर्दिष्ट है), और कैशिंग तंत्र सामान्य रूप से काम करेगा। ईटैग और/या सामग्री-स्थान, यदि समान अनुरोध है तो 200 प्रतिक्रिया लौटानी चाहिए। समाप्त, कैश-कंट्रोल, और/या भिन्न, यदि इसका मान उसी चर के अन्य पिछले प्रतिक्रियाओं के अनुरूप मान से भिन्न हो सकता है। यदि यह प्रतिक्रिया अनुरोध मजबूत कैश सत्यापन का उपयोग करता है, तो इस प्रतिक्रिया में अन्य इकाई हेडर शामिल नहीं होने चाहिए; अन्यथा (उदाहरण के लिए, एक सशर्त GET अनुरोध कमजोर कैश सत्यापन का उपयोग करता है), इस प्रतिक्रिया में अन्य इकाई हेडर शामिल होने से प्रतिबंधित है; यह कैश्ड के बीच विसंगतियों को हल करने से बचता है इकाई सामग्री और अद्यतन इकाई हेडर जानकारी। यदि 304 प्रतिक्रिया इंगित करती है कि कोई इकाई वर्तमान में कैश्ड नहीं है, तो कैशिंग सिस्टम को प्रतिक्रिया को अनदेखा करना होगा और बिना किसी प्रतिबंध के अनुरोध को दोहराना होगा। यदि 304 प्रतिक्रिया प्राप्त होती है जिसके लिए कैश प्रविष्टि को अपडेट करने की आवश्यकता होती है, तो कैश सिस्टम को प्रतिक्रिया में अपडेट किए गए सभी फ़ील्ड के मानों को प्रतिबिंबित करने के लिए संपूर्ण प्रविष्टि को अपडेट करना होगा। |
| 305 | अनुरोधित संसाधन को निर्दिष्ट प्रॉक्सी के माध्यम से एक्सेस किया जाना चाहिए। निर्दिष्ट प्रॉक्सी की यूआरआई जानकारी स्थान फ़ील्ड में दी जाएगी। प्राप्तकर्ता को इस प्रॉक्सी के माध्यम से संबंधित संसाधनों तक पहुंचने के लिए बार-बार एक अलग अनुरोध भेजने की आवश्यकता है। केवल मूल सर्वर ही 305 प्रतिक्रिया स्थापित कर सकता है। ध्यान दें: आरएफसी 2068 यह निर्दिष्ट नहीं करता है कि 305 प्रतिक्रिया का उद्देश्य एकल अनुरोध को पुनर्निर्देशित करना है और इसे केवल मूल सर्वर द्वारा ही स्थापित किया जा सकता है। इन प्रतिबंधों को नजरअंदाज करने से गंभीर सुरक्षा परिणाम हो सकते हैं। |
| 306 | विनिर्देश के नवीनतम संस्करण में, 306 स्थिति कोड का अब उपयोग नहीं किया जाता है। |
| 307 | अनुरोधित संसाधन अब अस्थायी रूप से एक अलग यूआरआई से अनुरोधों का जवाब देता है। क्योंकि ऐसे रीडायरेक्ट अस्थायी होते हैं, क्लाइंट को भविष्य के अनुरोधों को मूल पते पर भेजना जारी रखना चाहिए। यह प्रतिक्रिया कैश-कंट्रोल या एक्सपायर्स में निर्दिष्ट होने पर ही कैश करने योग्य होती है। नया अस्थायी यूआरआई प्रतिक्रिया के स्थान फ़ील्ड में लौटाया जाना चाहिए। जब तक यह एक HEAD अनुरोध न हो, प्रतिक्रिया इकाई में नए URI के लिए एक हाइपरलिंक और एक संक्षिप्त विवरण होना चाहिए। क्योंकि कुछ ब्राउज़र 307 प्रतिक्रिया को नहीं पहचान सकते हैं, इसलिए उपरोक्त आवश्यक जानकारी जोड़ने की आवश्यकता है ताकि उपयोगकर्ता समझ सकें और नए यूआरआई तक पहुंच अनुरोध कर सकें। यदि यह GET या HEAD अनुरोध नहीं है, तो ब्राउज़र उपयोगकर्ता द्वारा पुष्टि किए जाने तक स्वचालित पुनर्निर्देशन को प्रतिबंधित करता है, क्योंकि अनुरोध की शर्तें तदनुसार बदल सकती हैं। |
| 400 | 1. शब्दार्थ गलत हैं और वर्तमान अनुरोध को सर्वर द्वारा नहीं समझा जा सकता है। जब तक संशोधित न किया जाए, क्लाइंट को यह अनुरोध दोबारा सबमिट नहीं करना चाहिए। 2. अनुरोध पैरामीटर ग़लत हैं. |
| 401 | वर्तमान अनुरोध के लिए उपयोगकर्ता प्रमाणीकरण की आवश्यकता है। प्रतिक्रिया में अनुरोधित संसाधन के लिए उपयुक्त एक WWW-प्रमाणीकरण हेडर शामिल होना चाहिए जो उपयोगकर्ता की जानकारी मांगता है। ग्राहक बार-बार उचित प्राधिकरण हेडर जानकारी वाला अनुरोध सबमिट कर सकता है। यदि वर्तमान अनुरोध में पहले से ही प्राधिकरण प्रमाणपत्र शामिल हैं, तो 401 प्रतिक्रिया इंगित करती है कि सर्वर सत्यापन ने उन प्रमाणपत्रों को अस्वीकार कर दिया है। यदि 401 प्रतिक्रिया में पिछली प्रतिक्रिया के समान प्रमाणीकरण क्वेरी शामिल है, और ब्राउज़र ने कम से कम एक बार प्रमाणीकरण का प्रयास किया है, तो ब्राउज़र को उपयोगकर्ता की प्रतिक्रिया में निहित इकाई जानकारी प्रदर्शित करनी चाहिए, क्योंकि इस इकाई जानकारी में प्रासंगिक नैदानिक जानकारी हो सकती है। आरएफसी 2617 देखें। |
| 402 | यह स्थिति कोड संभावित भविष्य की जरूरतों के लिए आरक्षित है। |
| 403 | सर्वर ने अनुरोध को समझ लिया है, लेकिन इसे निष्पादित करने से इनकार कर दिया है। 401 प्रतिक्रिया के विपरीत, प्रमाणीकरण कोई सहायता प्रदान नहीं करता है, और अनुरोध दोबारा सबमिट नहीं किया जाना चाहिए। यदि यह एक HEAD अनुरोध नहीं है और सर्वर यह समझाने में सक्षम होना चाहता है कि अनुरोध निष्पादित क्यों नहीं किया जा सकता है, तो अस्वीकृति का कारण इकाई में वर्णित किया जाना चाहिए। बेशक, सर्वर 404 प्रतिक्रिया भी लौटा सकता है यदि वह नहीं चाहता कि ग्राहक कोई जानकारी प्राप्त करे। |
| 404 | अनुरोध विफल रहा. अनुरोधित संसाधन सर्वर पर नहीं मिला. उपयोगकर्ता को यह बताने के लिए कोई जानकारी नहीं है कि स्थिति अस्थायी है या स्थायी। यदि सर्वर को स्थिति पता है, तो उसे यह सूचित करने के लिए 410 स्थिति कोड का उपयोग करना चाहिए कि पुराना संसाधन कुछ आंतरिक कॉन्फ़िगरेशन तंत्र समस्याओं के कारण स्थायी रूप से अनुपलब्ध है, और कोई जंप पता नहीं है। 404 स्टेटस कोड का व्यापक रूप से उपयोग तब किया जाता है जब सर्वर यह नहीं बताना चाहता कि अनुरोध क्यों अस्वीकार किया गया या कोई अन्य उपयुक्त प्रतिक्रिया उपलब्ध नहीं है। |
| 405 | अनुरोध पंक्ति में निर्दिष्ट अनुरोध विधि का उपयोग संबंधित संसाधन का अनुरोध करने के लिए नहीं किया जा सकता है। प्रतिक्रिया को अनुरोध विधियों की सूची को इंगित करने के लिए एक अनुमति हेडर जानकारी लौटानी चाहिए जिसे वर्तमान संसाधन स्वीकार कर सकता है। चूँकि PUT और DELETE विधियाँ सर्वर पर संसाधन लिखेंगी, अधिकांश वेब सर्वर डिफ़ॉल्ट कॉन्फ़िगरेशन के तहत उपरोक्त अनुरोध विधियों का समर्थन नहीं करते हैं या अनुमति नहीं देते हैं, और ऐसे अनुरोधों के लिए 405 त्रुटि लौटा दी जाएगी। |
| 406 | अनुरोधित संसाधन की सामग्री विशेषताएँ अनुरोध शीर्षलेख में शर्तों को पूरा नहीं करती हैं, इसलिए प्रतिक्रिया इकाई उत्पन्न नहीं की जा सकती है। जब तक यह एक HEAD अनुरोध न हो, प्रतिक्रिया में इकाई विशेषताओं और पतों की एक सूची वाली एक इकाई वापस आनी चाहिए जिसमें से उपयोगकर्ता या ब्राउज़र सबसे उपयुक्त चुन सकता है। इकाई का प्रारूप सामग्री-प्रकार शीर्षलेख में परिभाषित मीडिया प्रकार द्वारा निर्धारित किया जाता है। ब्राउज़र प्रारूप और अपनी क्षमताओं के आधार पर अपना सर्वश्रेष्ठ विकल्प चुन सकता है। हालाँकि, विनिर्देश ऐसे स्वचालित चयन करने के लिए कोई मानदंड परिभाषित नहीं करता है। |
| 407 | 401 प्रतिक्रिया के समान, सिवाय इसके कि क्लाइंट को प्रॉक्सी सर्वर से प्रमाणित करना होगा। पहचान क्वेरी के लिए प्रॉक्सी सर्वर को प्रॉक्सी-प्रमाणीकरण लौटाना होगा। ग्राहक सत्यापन के लिए प्रॉक्सी-प्राधिकरण हेडर लौटा सकता है। आरएफसी 2617 देखें। |
| 408 | अनुरोध का समय समाप्त। क्लाइंट ने उस समय के भीतर अनुरोध भेजना पूरा नहीं किया जब सर्वर प्रतीक्षा करने के लिए तैयार था। ग्राहक बिना कोई बदलाव किए किसी भी समय इस अनुरोध को दोबारा सबमिट कर सकता है। |
| 409 | अनुरोधित संसाधन की वर्तमान स्थिति के साथ विरोध के कारण अनुरोध पूरा नहीं किया जा सकता है। इस कोड का उपयोग केवल तभी किया जाना चाहिए जब उपयोगकर्ता को यह विश्वास हो कि वह विवाद को हल करने और नया अनुरोध पुनः सबमिट करने में सक्षम है। प्रतिक्रिया में उपयोगकर्ता के लिए संघर्ष के स्रोत का पता लगाने के लिए पर्याप्त जानकारी होनी चाहिए। आमतौर पर PUT अनुरोधों के प्रसंस्करण में टकराव होता है। उदाहरण के लिए, संस्करण जाँच का उपयोग करने वाले वातावरण में, यदि PUT द्वारा प्रस्तुत किसी विशिष्ट संसाधन के लिए संशोधन अनुरोध से जुड़ी संस्करण जानकारी पिछले (तृतीय-पक्ष) अनुरोध के साथ टकराव करती है, तो सर्वर को इस समय 409 त्रुटि लौटानी चाहिए। उपयोगकर्ता को सूचित करें कि अनुरोध पूरा नहीं किया जा सकता। इस समय, प्रतिक्रिया इकाई में दो परस्पर विरोधी संस्करणों के बीच अंतर तुलना शामिल होने की संभावना है, ताकि उपयोगकर्ता विलय के बाद नए संस्करण को फिर से सबमिट कर सके। |
| 410 | अनुरोधित संसाधन अब सर्वर पर उपलब्ध नहीं है और उसका कोई ज्ञात अग्रेषण पता नहीं है। ऐसी स्थिति को स्थायी मानना चाहिए। यदि संभव हो, तो लिंक संपादन क्षमताओं वाले ग्राहकों को उपयोगकर्ता की अनुमति से इस पते के सभी संदर्भ हटा देना चाहिए। यदि सर्वर को पता नहीं है या यह निर्धारित नहीं कर सकता कि स्थिति स्थायी है या नहीं, तो 404 स्थिति कोड का उपयोग किया जाना चाहिए। जब तक अन्यथा उल्लेख न किया गया हो, यह प्रतिक्रिया कैश करने योग्य है। 410 प्रतिक्रिया का उद्देश्य मुख्य रूप से वेबसाइट प्रशासकों को वेबसाइट बनाए रखने में मदद करना है, उपयोगकर्ताओं को सूचित करना है कि संसाधन अब उपलब्ध नहीं है, और सर्वर मालिक को उम्मीद है कि इस संसाधन की ओर इशारा करने वाले सभी दूरस्थ कनेक्शन भी हटा दिए जाएंगे। इस प्रकार की घटना सीमित समय, मूल्यवर्धित सेवाओं के बीच आम है। इसी प्रकार, 410 प्रतिक्रिया का उपयोग क्लाइंट को सूचित करने के लिए भी किया जाता है कि मूल रूप से किसी व्यक्ति से संबंधित संसाधन अब वर्तमान सर्वर साइट पर उपलब्ध नहीं हैं। बेशक, यह पूरी तरह से सर्वर मालिक पर निर्भर है कि क्या सभी स्थायी रूप से अनुपलब्ध संसाधनों को '410 गॉन' के रूप में चिह्नित करने की आवश्यकता है, और उन्हें इस चिह्न को कितने समय तक रखने की आवश्यकता है। |
| 411 | कंटेंट-लेंथ हेडर परिभाषित किए बिना सर्वर अनुरोध स्वीकार करने से इंकार कर देता है। अनुरोध संदेश के मुख्य भाग की लंबाई दर्शाने वाला एक वैध सामग्री-लंबाई शीर्षलेख जोड़ने के बाद, ग्राहक फिर से अनुरोध सबमिट कर सकता है। |
| 412 | सर्वर अनुरोध के हेडर फ़ील्ड को सत्यापित करते समय दी गई एक या अधिक शर्तों को पूरा करने में विफल रहा। यह स्थिति कोड क्लाइंट को संसाधन पुनर्प्राप्त करते समय अनुरोध मेटाइनफॉर्मेशन (अनुरोध हेडर फ़ील्ड डेटा) में पूर्व शर्ते सेट करने की अनुमति देता है, जिससे अनुरोध विधि को संसाधन पर उसकी अपेक्षा के अलावा लागू होने से रोका जा सकता है। |
| 413 | सर्वर वर्तमान अनुरोध को संसाधित करने से इंकार कर रहा है क्योंकि अनुरोध प्रस्तुत इकाई डेटा जो सर्वर की इच्छा या संभालने में सक्षम से बड़ा है। इस स्थिति में, क्लाइंट को यह अनुरोध भेजने से रोकने के लिए सर्वर कनेक्शन बंद कर सकता है। यदि स्थिति अस्थायी है, तो सर्वर को क्लाइंट को सूचित करने के लिए रिट्री-आफ्टर रिस्पॉन्स हेडर लौटाना चाहिए कि वह कितनी देर तक दोबारा प्रयास कर सकता है। |
| 414 | अनुरोधित यूआरआई सर्वर की व्याख्या से अधिक लंबा है, इसलिए सर्वर अनुरोध को पूरा करने से इंकार कर देता है। यह अपेक्षाकृत दुर्लभ है। सामान्य स्थितियों में शामिल हैं: फॉर्म सबमिशन जिसमें POST विधि का उपयोग किया जाना चाहिए वह GET विधि बन जाता है, जिसके परिणामस्वरूप क्वेरी स्ट्रिंग (क्वेरी स्ट्रिंग) बहुत लंबी हो जाती है। पुनर्निर्देशन यूआरआई "ब्लैक होल", उदाहरण के लिए, प्रत्येक पुनर्निर्देशन नए यूआरआई के हिस्से के रूप में पुराने यूआरआई का उपयोग करता है, जिससे कई पुनर्निर्देशन के बाद यूआरआई बहुत लंबा हो जाता है। क्लाइंट कुछ सर्वरों में मौजूद सुरक्षा भेद्यता का फायदा उठाकर सर्वर पर हमला करने का प्रयास कर रहा है। इस प्रकार का सर्वर अनुरोधित यूआरआई को पढ़ने या संचालित करने के लिए एक निश्चित लंबाई वाले बफर का उपयोग करता है। जब GET के बाद के पैरामीटर एक निश्चित मान से अधिक हो जाते हैं, तो बफर ओवरफ्लो हो सकता है, जिससे मनमाना कोड निष्पादित हो सकता है [1]। ऐसी कमजोरियों के बिना सर्वर को 414 स्थिति कोड लौटाना चाहिए। |
| 415 | वर्तमान में अनुरोधित विधि और अनुरोधित संसाधन के लिए, अनुरोध में सबमिट की गई इकाई सर्वर द्वारा समर्थित प्रारूप में नहीं है, इसलिए अनुरोध अस्वीकार कर दिया गया है। |
| 416 | यदि अनुरोध में रेंज अनुरोध हेडर शामिल है, और रेंज में निर्दिष्ट कोई भी डेटा रेंज वर्तमान संसाधन की उपलब्ध सीमा से मेल नहीं खाती है, और यदि-रेंज अनुरोध हेडर अनुरोध में परिभाषित नहीं है, तो सर्वर को 416 स्थिति लौटानी चाहिए कोड. यदि रेंज बाइट रेंज का उपयोग करती है, तो इस स्थिति का मतलब है कि अनुरोध में निर्दिष्ट सभी डेटा रेंज की पहली बाइट स्थिति वर्तमान संसाधन की लंबाई से अधिक है। 416 स्थिति कोड लौटाते समय सर्वर को वर्तमान संसाधन की लंबाई इंगित करने के लिए एक कंटेंट-रेंज इकाई हेडर भी शामिल करना चाहिए। इस प्रतिक्रिया को इसके सामग्री-प्रकार के रूप में मल्टीपार्ट/बाइटरेंज का उपयोग करने से भी प्रतिबंधित किया गया है। |
| 417 | अनुरोध हेडर एक्सपेक्ट में निर्दिष्ट अपेक्षित सामग्री सर्वर द्वारा संतुष्ट नहीं की जा सकती है, या सर्वर एक प्रॉक्सी सर्वर है और इसका स्पष्ट प्रमाण है कि एक्सपेक्ट की सामग्री वर्तमान रूट में अगले नोड पर संतुष्ट नहीं हो सकती है। |
| 421 | वर्तमान क्लाइंट के आईपी पते से सर्वर से कनेक्शन की संख्या सर्वर की अधिकतम अनुमत सीमा से अधिक है। आमतौर पर, यहां आईपी एड्रेस सर्वर से देखे गए क्लाइंट एड्रेस (जैसे उपयोगकर्ता का गेटवे या प्रॉक्सी सर्वर एड्रेस) को संदर्भित करता है। इस मामले में, कनेक्शन संख्या में एक से अधिक अंतिम उपयोगकर्ता शामिल हो सकते हैं। |
| 422 | वर्तमान क्लाइंट के आईपी पते से सर्वर से कनेक्शन की संख्या सर्वर की अधिकतम अनुमत सीमा से अधिक है। आमतौर पर, यहां आईपी एड्रेस सर्वर से देखे गए क्लाइंट एड्रेस (जैसे उपयोगकर्ता का गेटवे या प्रॉक्सी सर्वर एड्रेस) को संदर्भित करता है। इस मामले में, कनेक्शन संख्या में एक से अधिक अंतिम उपयोगकर्ता शामिल हो सकते हैं। |
| 422 | अनुरोध अच्छी तरह से प्रारूपित है, लेकिन अर्थ संबंधी त्रुटियों के कारण इसका उत्तर नहीं दिया जा सकता। (आरएफसी 4918 वेबडीएवी) 423 लॉक किया गया वर्तमान संसाधन लॉक है। (आरएफसी 4918 वेबडीएवी) |
| 424 | वर्तमान अनुरोध पिछले अनुरोध, जैसे PROPPATCH, में त्रुटि के कारण विफल हो गया। (आरएफसी 4918 वेबडीएवी) |
| 425 | WebDav Advanced Collections ड्राफ्ट में परिभाषित, लेकिन "WebDAV अनुक्रम संग्रह प्रोटोकॉल" (RFC 3658) में प्रकट नहीं होता है। |
| 426 | ग्राहकों को टीएलएस/1.0 पर स्विच करना चाहिए। (आरएफसी 2817) |
| 449 | माइक्रोसॉफ्ट द्वारा विस्तारित, इंगित करता है कि उचित कार्रवाई करने के बाद अनुरोधों का पुनः प्रयास किया जाना चाहिए। |
| 500 | सर्वर को एक अप्रत्याशित स्थिति का सामना करना पड़ा जिसने उसे अनुरोध की प्रोसेसिंग पूरी करने से रोक दिया। सामान्यतया, यह समस्या तब उत्पन्न होगी जब सर्वर के प्रोग्राम कोड में कोई त्रुटि होगी। |
| 501 | सर्वर वर्तमान अनुरोध के लिए आवश्यक सुविधा का समर्थन नहीं करता है। जब सर्वर अनुरोधित विधि को नहीं पहचानता है और किसी भी संसाधन के लिए उसके अनुरोध का समर्थन नहीं कर सकता है। |
| 502 | गेटवे या प्रॉक्सी के रूप में काम करने वाले सर्वर को अनुरोध निष्पादित करने का प्रयास करते समय अपस्ट्रीम सर्वर से एक अमान्य प्रतिक्रिया प्राप्त हुई। |
| 503 | अस्थायी सर्वर रखरखाव या अधिभार के कारण, सर्वर वर्तमान में अनुरोधों को संसाधित करने में असमर्थ है। यह स्थिति अस्थायी है और कुछ समय के बाद बहाल हो जाएगी। यदि देरी के समय की उम्मीद की जा सकती है, तो प्रतिक्रिया में देरी के समय को इंगित करने के लिए रिट्री-आफ्टर हेडर शामिल हो सकता है। यदि यह पुनः प्रयास-आफ्टर संदेश नहीं दिया गया है, तो क्लाइंट को इसे उसी तरह संभालना चाहिए जैसे वह 500 प्रतिक्रिया को संभालता है। नोट: 503 स्टेटस कोड की उपस्थिति का मतलब यह नहीं है कि सर्वर को ओवरलोड होने पर इसका उपयोग करना चाहिए। कुछ सर्वर केवल ग्राहकों से कनेक्शन अस्वीकार करना चाहते हैं। |
| 504 | जब गेटवे या प्रॉक्सी के रूप में काम करने वाला सर्वर किसी अनुरोध को निष्पादित करने का प्रयास करता है, तो यह अपस्ट्रीम सर्वर (यूआरआई द्वारा पहचाना गया सर्वर, जैसे HTTP, FTP, LDAP) या सहायक सर्वर (जैसे DNS) से समय पर प्रतिक्रिया प्राप्त करने में विफल रहता है। ). ध्यान दें: DNS क्वेरी का समय समाप्त होने पर कुछ प्रॉक्सी सर्वर 400 या 500 त्रुटि लौटाएंगे। |
| 505 | सर्वर अनुरोध में उपयोग किए गए HTTP संस्करण का समर्थन नहीं करता है, या समर्थन करने से इनकार करता है। इसका तात्पर्य यह है कि सर्वर क्लाइंट के समान संस्करण का उपयोग करने में असमर्थ या अनिच्छुक है। प्रतिक्रिया में एक इकाई होनी चाहिए जो यह बताए कि संस्करण समर्थित क्यों नहीं है और सर्वर किन प्रोटोकॉल का समर्थन करता है। |
| 506 | पारदर्शी सामग्री बातचीत प्रोटोकॉल (आरएफसी 2295) द्वारा विस्तारित, इंगित करता है कि सर्वर में एक आंतरिक कॉन्फ़िगरेशन त्रुटि है: अनुरोधित बातचीत तर्क संसाधन पारदर्शी सामग्री बातचीत में स्वयं का उपयोग करने के लिए कॉन्फ़िगर किया गया है और इसलिए बातचीत प्रक्रिया में उचित फोकस नहीं है। |
| 507 | सर्वर अनुरोध को पूरा करने के लिए आवश्यक सामग्री संग्रहीत नहीं कर सकता। यह स्थिति अस्थायी मानी जाती है. वेबडीएवी (आरएफसी 4918) |
| 509 | सर्वर अपनी बैंडविड्थ सीमा तक पहुंच गया है. यह कोई आधिकारिक स्थिति कोड नहीं है, लेकिन अभी भी व्यापक रूप से उपयोग किया जाता है। |
| 510 | संसाधन प्राप्त करने के लिए आवश्यक रणनीतियाँ अभी तक संतुष्ट नहीं हैं। (आरएफसी 2774) |