HTTP स्टेटस कोड इंटरनेट का सर्वर और क्लाइंट के बीच संवाद करने का तरीका है। हर बार जब आपका ब्राउज़र किसी वेबपेज का अनुरोध करता है, कोई API कॉल करता है, या कोई सर्वर डेटा प्रोसेस करता है, ये तीन अंकों के कोड आपको बिल्कुल बताते हैं कि क्या हुआ। इन कोड को समझना वेब डेवलपर्स, SEO विशेषज्ञों और वेब टेक्नोलॉजी के साथ काम करने वाले किसी भी व्यक्ति के लिए आवश्यक है।
यह संपूर्ण गाइड 100 से 511 तक सभी मानक HTTP स्टेटस कोड को श्रेणी के अनुसार व्यवस्थित करके कवर करती है। प्रत्येक स्टेटस कोड में व्यावहारिक स्पष्टीकरण, वास्तविक दुनिया के उपयोग के मामले, कार्यान्वयन मार्गदर्शन और बचने के लिए सामान्य गलतियाँ शामिल हैं।
HTTP स्टेटस कोड त्वरित संदर्भ
| स्टेटस कोड | नाम | श्रेणी | जाएं |
|---|---|---|---|
| 100 | Continue | सूचनात्मक | विवरण |
| 101 | Switching Protocols | सूचनात्मक | विवरण |
| 102 | Processing | सूचनात्मक | विवरण |
| 103 | Early Hints | सूचनात्मक | विवरण |
| 200 | OK | सफलता | विवरण |
| 201 | Created | सफलता | विवरण |
| 202 | Accepted | सफलता | विवरण |
| 203 | Non-Authoritative Information | सफलता | विवरण |
| 204 | No Content | सफलता | विवरण |
| 205 | Reset Content | सफलता | विवरण |
| 206 | Partial Content | सफलता | विवरण |
| 207 | Multi-Status | सफलता | विवरण |
| 208 | Already Reported | सफलता | विवरण |
| 226 | IM Used | सफलता | विवरण |
| 300 | Multiple Choices | रीडायरेक्शन | विवरण |
| 301 | Moved Permanently | रीडायरेक्शन | विवरण |
| 302 | Found | रीडायरेक्शन | विवरण |
| 303 | See Other | रीडायरेक्शन | विवरण |
| 304 | Not Modified | रीडायरेक्शन | विवरण |
| 305 | Use Proxy (पदावनत) | रीडायरेक्शन | विवरण |
| 307 | Temporary Redirect | रीडायरेक्शन | विवरण |
| 308 | Permanent Redirect | रीडायरेक्शन | विवरण |
| 400 | Bad Request | क्लाइंट एरर | विवरण |
| 401 | Unauthorized | क्लाइंट एरर | विवरण |
| 403 | Forbidden | क्लाइंट एरर | विवरण |
| 404 | Not Found | क्लाइंट एरर | विवरण |
| 405 | Method Not Allowed | क्लाइंट एरर | विवरण |
| 406 | Not Acceptable | क्लाइंट एरर | विवरण |
| 407 | Proxy Authentication Required | क्लाइंट एरर | विवरण |
| 408 | Request Timeout | क्लाइंट एरर | विवरण |
| 409 | Conflict | क्लाइंट एरर | विवरण |
| 410 | Gone | क्लाइंट एरर | विवरण |
| 418 | I’m a teapot | क्लाइंट एरर | विवरण |
| 422 | Unprocessable Entity | क्लाइंट एरर | विवरण |
| 429 | Too Many Requests | क्लाइंट एरर | विवरण |
| 451 | Unavailable For Legal Reasons | क्लाइंट एरर | विवरण |
| 500 | Internal Server Error | सर्वर एरर | विवरण |
| 501 | Not Implemented | सर्वर एरर | विवरण |
| 502 | Bad Gateway | सर्वर एरर | विवरण |
| 503 | Service Unavailable | सर्वर एरर | विवरण |
| 504 | Gateway Timeout | सर्वर एरर | विवरण |
| 505 | HTTP Version Not Supported | सर्वर एरर | विवरण |
| 507 | Insufficient Storage | सर्वर एरर | विवरण |
| 508 | Loop Detected | सर्वर एरर | विवरण |
| 511 | Network Authentication Required | सर्वर एरर | विवरण |
1xx सूचनात्मक रिस्पॉन्स
ये कोड इंगित करते हैं कि अनुरोध प्राप्त हो गया और प्रक्रिया जारी है।
100 स्टेटस कोड क्या है?
HTTP: 100 Continue
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर कह रहा है “मुझे आपके अनुरोध का पहला भाग मिल गया, और अब तक यह अच्छा लग रहा है - आगे बाकी भेजें!” यह तब होता है जब आप कुछ बड़ा (जैसे वीडियो) अपलोड करने की कोशिश कर रहे हैं, और सर्वर यह जांचना चाहता है कि पूरी फाइल भेजने में समय बर्बाद करने से पहले आपको अपलोड करने की अनुमति है या नहीं।
व्यावहारिक उपयोग के मामले: क्लाउड स्टोरेज में बड़ी फाइलें अपलोड करना जहां सर्वर पहले जांचता है कि आपके पास पर्याप्त स्थान है या नहीं, बड़े फॉर्म जमा करना जहां सर्वर सभी डेटा स्वीकार करने से पहले आपके लॉगिन को सत्यापित करता है, या कोई भी स्थिति जहां बहुत सारा डेटा ट्रांसफर करने से पहले अनुमतियों की जांच करना समझदारी है।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: आपका ब्राउज़र या ऐप तुरंत बाकी डेटा भेजना शुरू कर देना चाहिए। ज्यादातर समय, यह पर्दे के पीछे स्वचालित रूप से होता है - आप इसे होते हुए नोटिस भी नहीं करेंगे।
गलत उपयोग या गलत कार्यान्वयन: इसे पुराने ब्राउज़रों को भेजना जो इसे नहीं समझते, जब किसी ने इसके लिए नहीं कहा तो इसे बेतरतीब ढंग से भेजना, या इसका उपयोग करने से पहले यह जांचना भूल जाना कि क्या क्लाइंट वास्तव में इस दो-चरणीय प्रक्रिया को चाहता है।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
101 स्टेटस कोड क्या है?
HTTP: 101 Switching Protocols
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर आपके साथ संवाद करने के तरीके को बदलने के लिए सहमत होता है। यह टेक्स्टिंग से फोन कॉल पर स्विच करने जैसा है - आपने कनेक्शन अपग्रेड करने के लिए कहा, और सर्वर ने कहा “ज़रूर, चलो करते हैं!”
व्यावहारिक उपयोग के मामले: जब कोई चैट एप्लिकेशन रीयल-टाइम मैसेजिंग के लिए सामान्य HTTP से WebSocket में अपग्रेड होता है, जब कोई ब्राउज़र HTTP के तेज़ संस्करण का उपयोग करने के लिए कहता है, या जब किसी एप्लिकेशन को बेहतर सुविधाओं के लिए अलग संचार विधि पर स्विच करने की आवश्यकता होती है।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: तुरंत नए संचार प्रोटोकॉल का उपयोग शुरू करें। यह बातचीत के बीच में भाषा बदलने जैसा है - एक बार जब आप दोनों सहमत हो जाते हैं, तो आप तुरंत नई भाषा बोलना शुरू कर देते हैं।
गलत उपयोग या गलत कार्यान्वयन: बिना पूछे स्विच करना, किसी ऐसी चीज़ पर स्विच करने की कोशिश करना जिसे सर्वर वास्तव में सपोर्ट नहीं करता, या यह निर्दिष्ट करना भूल जाना कि आप किस प्रोटोकॉल पर स्विच कर रहे हैं।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
102 स्टेटस कोड क्या है?
HTTP: 102 Processing
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर कह रहा है “मैं अभी भी आपके अनुरोध पर काम कर रहा हूं - मुझ पर हार मत मानिए!” इसका उपयोग तब किया जाता है जब किसी चीज़ को प्रोसेस करने में वास्तव में लंबा समय लगता है, इसलिए सर्वर यह संदेश भेजता है ताकि आप यह न सोचें कि यह क्रैश हो गया।
व्यावहारिक उपयोग के मामले: एक बड़ी वीडियो फाइल को अलग फॉर्मेट में कन्वर्ट करना, एक साथ सैकड़ों फाइलें प्रोसेस करना, जटिल रिपोर्ट चलाना जिन्हें जेनरेट होने में मिनट लगते हैं, या कोई भी ऑपरेशन जो सामान्य से अधिक समय लेता है।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: धैर्यपूर्वक प्रतीक्षा करते रहें। सर्वर अंततः आपको वास्तविक परिणाम देने से पहले इनमें से कई “अभी भी काम कर रहा हूं” संदेश भेज सकता है। अनुरोध को दोबारा न करें - इससे पूरी प्रक्रिया फिर से शुरू हो जाएगी।
गलत उपयोग या गलत कार्यान्वयन: त्वरित ऑपरेशनों के लिए इसका उपयोग करना जिन्हें इसकी आवश्यकता नहीं है, बहुत सारे “अभी भी काम कर रहा हूं” संदेश भेजना, या प्रोसेसिंग कर रहे हैं कहने के बाद अंतिम रिस्पॉन्स भेजना भूल जाना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
103 स्टेटस कोड क्या है?
HTTP: 103 Early Hints
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर आपको उन संसाधनों के बारे में पहले से संकेत दे रहा है जिनकी आपको शायद जल्द ही आवश्यकता होगी। यह एक रेस्तरां की तरह है जो कहता है “जब तक मैं आपका ऑर्डर तैयार करता हूं, आप अपने नैपकिन और कटलरी तैयार रखना चाहेंगे।”
व्यावहारिक उपयोग के मामले: ब्राउज़रों को CSS और JavaScript फाइलें लोड करना शुरू करने के लिए कहना जबकि सर्वर HTML तैयार करता है, उन फोंट को प्रीलोड करना जिनकी पेज को आवश्यकता होगी, या अन्य सर्वरों से कनेक्शन वार्म अप करना जिनका पेज उपयोग करेगा।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: वास्तविक रिस्पॉन्स की प्रतीक्षा करते समय बैकग्राउंड में सुझाए गए संसाधनों को लोड करना शुरू करें। इससे पेज तेज़ महसूस होते हैं क्योंकि कुछ काम जल्दी शुरू हो जाता है।
गलत उपयोग या गलत कार्यान्वयन: हिंट भेजना लेकिन वास्तविक रिस्पॉन्स कभी नहीं भेजना, ऐसे संसाधनों का सुझाव देना जिनकी वास्तव में आवश्यकता नहीं है, या क्लाइंट को बहुत सारे अनावश्यक प्रीलोड हिंट से ओवरलोड करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
2xx सफलता
ये कोड इंगित करते हैं कि अनुरोध सफलतापूर्वक प्राप्त, समझा और स्वीकार किया गया था।
200 स्टेटस कोड क्या है?
HTTP: 200 OK
सर्वर कब और क्यों इसे रिटर्न करता है: यह “सब कुछ पूरी तरह से काम कर गया” रिस्पॉन्स है। सर्वर ने वह पाया जो आप चाहते थे, वह किया जो आपने कहा, और यह रहा आपका परिणाम। यह सबसे आम सफलता संदेश है जो आप देखेंगे।
व्यावहारिक उपयोग के मामले: किसी भी वेबपेज को सफलतापूर्वक लोड करना, API से डेटा प्राप्त करना, फाइल डाउनलोड करना, सही तरीके से काम करने वाला फॉर्म जमा करना, या मूल रूप से कोई भी समय जब अनुरोध बिना किसी समस्या के सफल होता है।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: वापस आए डेटा का उपयोग करें - वेबपेज दिखाएं, JSON डेटा प्रोसेस करें, फाइल सेव करें, या जो भी आपके एप्लिकेशन के लिए समझ में आए। यह “सामान्य” रिस्पॉन्स है जिसे संभालने के लिए सब कुछ डिज़ाइन किया गया है।
गलत उपयोग या गलत कार्यान्वयन: “200 OK” कहना लेकिन रिस्पॉन्स में एरर मैसेज शामिल करना (भ्रमित करने वाला!), जब आपने कुछ नया बनाया तो 200 का उपयोग करना (इसके बजाय 201 का उपयोग करें), या जब डेटा अपेक्षित था तब बिना डेटा के 200 रिटर्न करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
201 स्टेटस कोड क्या है?
HTTP: 201 Created
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर ने आपके अनुरोध के आधार पर सफलतापूर्वक कुछ नया बनाया। यह सिर्फ “OK” नहीं है - यह विशेष रूप से “मैंने वह नई चीज़ बना दी जो आपने मांगी थी!”
व्यावहारिक उपयोग के मामले: नया यूजर अकाउंट बनाना, नया ट्वीट या स्टेटस अपडेट पोस्ट करना, एक फाइल अपलोड करना जो नए रिसोर्स के रूप में सेव हो जाती है, शॉपिंग कार्ट में नया प्रोडक्ट जोड़ना, या कोई भी समय जब आपका अनुरोध कुछ नया स्टोर होने का परिणाम देता है।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: Location हेडर देखें जो आमतौर पर आपको बताता है कि नई बनाई गई चीज़ कहाँ मिलेगी। आप नए रिसोर्स पर रीडायरेक्ट कर सकते हैं या अपने UI को अपडेट कर सकते हैं यह दिखाने के लिए कि क्रिएशन सफल रहा।
गलत उपयोग या गलत कार्यान्वयन: मौजूदा चीज़ों को अपडेट करते समय 201 का उपयोग करना (उसके लिए 200 है), नए रिसोर्स का लोकेशन शामिल करना भूल जाना, या जब वास्तव में कुछ भी नहीं बना तब 201 का उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
202 स्टेटस कोड क्या है?
HTTP: 202 Accepted
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर ने आपका अनुरोध स्वीकार कर लिया लेकिन अभी तक इसे प्रोसेस करना समाप्त नहीं किया है। यह ड्राई क्लीनिंग छोड़ने जैसा है - उन्होंने आपके कपड़े ले लिए और आपको रसीद दी, लेकिन सफाई अभी नहीं हुई है।
व्यावहारिक उपयोग के मामले: ईमेल भेजना (डिलीवरी के लिए स्वीकार किया गया लेकिन अभी भेजा नहीं गया), बड़ा डेटा एक्सपोर्ट शुरू करना जो तैयार होने पर ईमेल किया जाएगा, वीडियो प्रोसेसिंग जॉब्स, या कोई भी टास्क जो बाद में प्रोसेसिंग के लिए कतार में लगाया जाता है।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: तत्काल परिणामों की अपेक्षा न करें। आपको जॉब पूरा हुआ या नहीं यह जांचने के लिए किसी अन्य तरीके की आवश्यकता होगी - शायद दूसरे एंडपॉइंट को पोल करें, ईमेल की प्रतीक्षा करें, या webhook नोटिफिकेशन की जांच करें।
गलत उपयोग या गलत कार्यान्वयन: उन चीज़ों के लिए 202 का उपयोग करना जो वास्तव में पहले ही पूरी हो चुकी हैं, बाद में स्टेटस जांचने का कोई तरीका प्रदान न करना, या जब टास्क फेल हो सकता है तब 202 का उपयोग करना (इस संभावना के बारे में क्लाइंट को चेतावनी दिए बिना)।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
203 स्टेटस कोड क्या है?
HTTP: 203 Non-Authoritative Information
सर्वर कब और क्यों इसे रिटर्न करता है: अनुरोध सफल रहा, लेकिन रिस्पॉन्स को बीच में किसी चीज़ (जैसे प्रॉक्सी या कैश) द्वारा संशोधित किया गया है। यह टेलीफोन गेम खेलने जैसा है - संदेश पहुंच गया, लेकिन रास्ते में थोड़ा बदल गया हो सकता है।
व्यावहारिक उपयोग के मामले: जब कोई कंपनी प्रॉक्सी कुछ हेडर जोड़ता या हटाता है, जब कोई कैशिंग सर्वर बैंडविड्थ बचाने के लिए रिस्पॉन्स को संशोधित करता है, या जब कंटेंट फिल्टर पॉलिसी के आधार पर आप जो देखते हैं उसे एडजस्ट करते हैं।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: रिस्पॉन्स का सामान्य रूप से उपयोग करें, लेकिन जान लें कि यह वही नहीं हो सकता जो मूल सर्वर ने भेजा था। यह अभी भी वैध है, बस संभावित रूप से संशोधित।
गलत उपयोग या गलत कार्यान्वयन: संशोधनों के बारे में पारदर्शी न होना, जब वास्तव में कुछ भी नहीं बदला था तब 203 का उपयोग करना, या रिस्पॉन्स को ऐसे तरीकों से संशोधित करना जो कार्यक्षमता को तोड़ देते हैं।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
204 स्टेटस कोड क्या है?
HTTP: 204 No Content
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर ने सफलतापूर्वक वह किया जो आपने कहा लेकिन वापस भेजने के लिए कुछ नहीं है। यह कुछ को सफलतापूर्वक डिलीट करने जैसा है - डिलीशन काम कर गया, लेकिन आपको दिखाने के लिए कुछ नहीं है क्योंकि वह चला गया!
व्यावहारिक उपयोग के मामले: रिकॉर्ड्स डिलीट करना, सेटिंग्स अपडेट करना जहां आपको कन्फर्मेशन डेटा वापस नहीं चाहिए, बैकग्राउंड में चुपचाप प्रेफरेंस सेव करना, या कोई भी सफल एक्शन जहां रिस्पॉन्स बॉडी व्यर्थ होगी।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: इसे सफलता के रूप में मानें लेकिन किसी डेटा की अपेक्षा न करें। AJAX अनुरोधों के लिए परफेक्ट जहां आपको बस यह जानना है कि कुछ काम कर गया। जब तक आपका JavaScript कुछ अपडेट करने का फैसला नहीं करता, पेज रिफ्रेश या बदलना नहीं चाहिए।
गलत उपयोग या गलत कार्यान्वयन: 204 के साथ रिस्पॉन्स डेटा शामिल करना (यह अनुमति नहीं है!), जब क्लाइंट शायद अपडेटेड डेटा देखना चाहता है तब 204 का उपयोग करना, या एररों के लिए 204 का उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
205 स्टेटस कोड क्या है?
HTTP: 205 Reset Content
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर आपके एप्लिकेशन को अपना फॉर्म क्लियर करने या अपना व्यू रीसेट करने के लिए कह रहा है। यह सफलतापूर्वक सर्वे जमा करने और अगले व्यक्ति के लिए फॉर्म का स्वचालित रूप से खुद को क्लियर कर लेने जैसा है।
व्यावहारिक उपयोग के मामले: डेटा एंट्री फॉर्म जमा करने के बाद जिसे बार-बार उपयोग करने की आवश्यकता है, एक सर्वे पूरा करने के बाद जिसे अगले रिस्पॉन्डेंट के लिए रीसेट होना चाहिए, या कोई भी स्थिति जहां UI को सफलता के बाद अपनी शुरुआती स्थिति में वापस आना चाहिए।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: सभी फॉर्म फील्ड्स क्लियर करें, डॉक्यूमेंट व्यू रीसेट करें, या इंटरफेस को उसकी मूल स्थिति में वापस लाएं। इस रिस्पॉन्स के साथ कोई डेटा नहीं आता - यह सिर्फ रीसेट करने का निर्देश है।
गलत उपयोग या गलत कार्यान्वयन: 205 रिस्पॉन्स के साथ डेटा भेजना (यह खाली होना चाहिए), जब आप वास्तव में फॉर्म क्लियर नहीं चाहते तब 205 का उपयोग करना, या जब सिंपल 204 बेहतर होगा तब इसका उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
206 स्टेटस कोड क्या है?
HTTP: 206 Partial Content
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर फाइल का केवल एक हिस्सा भेज रहा है क्योंकि आपने यही मांगा था। यह पूरी किताब के बजाय किताब के पेज 50-60 मांगने जैसा है।
व्यावहारिक उपयोग के मामले: स्ट्रीमिंग वीडियो जहां आप अलग-अलग हिस्सों पर जंप कर सकते हैं, बाधित डाउनलोड को जहां रुके थे वहां से फिर से शुरू करना, बड़ी फाइलों को चंक्स में डाउनलोड करना, या “लोड मोर” फीचर्स को कुशलता से लागू करना।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: आंशिक कंटेंट को प्रोसेस करें और यदि आवश्यक हो तो और पार्ट्स का अनुरोध करें। वीडियो प्लेयर्स इसका उपयोग सीकिंग के लिए करते हैं, और डाउनलोड मैनेजर्स इसका उपयोग रिज्यूमिंग के लिए करते हैं।
गलत उपयोग या गलत कार्यान्वयन: जब किसी ने आंशिक कंटेंट नहीं मांगा तब 206 भेजना, गलत बाइट रेंज भेजना, जब वे मददगार होंगे तब रेंज रिक्वेस्ट्स को सपोर्ट न करना, या Content-Range हेडर्स को गड़बड़ करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
207 स्टेटस कोड क्या है?
HTTP: 207 Multi-Status
सर्वर कब और क्यों इसे रिटर्न करता है: कई ऑपरेशन किए गए और प्रत्येक का अपना परिणाम है। यह जॉब एप्लिकेशंस का एक बैच जमा करने और एक ही लिफाफे में प्रत्येक के लिए अलग-अलग जवाब प्राप्त करने जैसा है।
व्यावहारिक उपयोग के मामले: बल्क ऑपरेशंस जहां आप एक साथ कई आइटम्स अपडेट कर रहे हैं, कई फाइलों पर WebDAV ऑपरेशंस, बैच API रिक्वेस्ट्स, या कोई भी समय जब आपको कई ऑपरेशंस के लिए अलग-अलग रिजल्ट्स रिपोर्ट करने की आवश्यकता हो।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: प्रत्येक ऑपरेशन के लिए व्यक्तिगत परिणाम देखने के लिए रिस्पॉन्स बॉडी (आमतौर पर XML) को पार्स करें। कुछ सफल हो सकते हैं जबकि अन्य फेल हो सकते हैं, और आपको प्रत्येक को उचित रूप से संभालना होगा।
गलत उपयोग या गलत कार्यान्वयन: सिंगल ऑपरेशंस के लिए 207 का उपयोग करना, मल्टी-स्टेटस रिस्पॉन्स को सही ढंग से स्ट्रक्चर न करना, या जब सभी ऑपरेशंस का एक ही रिजल्ट था तब इसका उपयोग करना (बस उस सिंगल स्टेटस कोड का उपयोग करें)।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
208 स्टेटस कोड क्या है?
HTTP: 208 Already Reported
सर्वर कब और क्यों इसे रिटर्न करता है: मल्टी-स्टेटस रिस्पॉन्स में, यह इंगित करता है कि इस रिसोर्स के बारे में जानकारी पहले ही शामिल की जा चुकी थी। यह खुद को दोहराने से बचने के लिए “ऊपर देखें” कहने जैसा है।
व्यावहारिक उपयोग के मामले: डायरेक्टरी कंटेंट्स लिस्ट करते समय जिसमें सिंबॉलिक लिंक्स शामिल हैं, रिकर्सिव ऑपरेशंस में इनफिनिट लूप्स को रोकना, या जटिल WebDAV रिस्पॉन्सेज में डुप्लिकेट जानकारी से बचना।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: इस रिसोर्स को प्रोसेस करना स्किप करें क्योंकि आपने इसे पहले ही रिस्पॉन्स में हैंडल कर लिया था। यह डबल-प्रोसेसिंग और इनफिनिट लूप्स को रोकता है।
गलत उपयोग या गलत कार्यान्वयन: उचित मल्टी-स्टेटस कॉन्टेक्स्ट के बाहर 208 का उपयोग करना, चीज़ों को “पहले ही रिपोर्ट किया गया” के रूप में मार्क करना जब वे नहीं थीं, या इस स्टेटस का अत्यधिक उपयोग करके भ्रमित करने वाले रिस्पॉन्सेज बनाना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
226 स्टेटस कोड क्या है?
HTTP: 226 IM Used
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर ने रिस्पॉन्स पर एक या अधिक ट्रांसफॉर्मेशंस लागू किए। यह एक डॉक्यूमेंट ऑर्डर करने और बैंडविड्थ बचाने के लिए कंप्रेस्ड या ऑप्टिमाइज्ड वर्जन प्राप्त करने जैसा है।
व्यावहारिक उपयोग के मामले: डेल्टा एनकोडिंग जहां केवल पिछली बार से बदलाव भेजे जाते हैं, कंप्रेशन सिस्टम्स जो ऑन-द-फ्लाई कंटेंट को ट्रांसफॉर्म करते हैं, या कोई भी बैंडविड्थ-बचत ट्रांसफॉर्मेशन जो क्लाइंट ने अनुरोध किया।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: हेडर्स में इंडिकेट की गई मेथड का उपयोग करके ट्रांसफॉर्म्ड कंटेंट को प्रोसेस करें। क्लाइंट को रिस्पॉन्स का ठीक से उपयोग करने के लिए ट्रांसफॉर्मेशन को समझने की आवश्यकता है।
गलत उपयोग या गलत कार्यान्वयन: यह इंडिकेट किए बिना 226 का उपयोग करना कि कौन से ट्रांसफॉर्मेशंस लागू किए गए, ऐसे ट्रांसफॉर्मेशंस लागू करना जो क्लाइंट ने नहीं मांगे, या स्टैंडर्ड कंप्रेशन के लिए 226 का उपयोग करना (जिसे स्पेशल स्टेटस की आवश्यकता नहीं है)।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
3xx रीडायरेक्शन
ये कोड इंगित करते हैं कि अनुरोध को पूरा करने के लिए आगे की कार्रवाई की आवश्यकता है।
300 स्टेटस कोड क्या है?
HTTP: 300 Multiple Choices
सर्वर कब और क्यों इसे रिटर्न करता है: अनुरोधित रिसोर्स के कई वर्जन हैं और सर्वर स्वचालित रूप से एक नहीं चुन सकता। यह “मैनुअल” मांगने जैसा है जब विभिन्न भाषाओं में वर्जन हैं।
व्यावहारिक उपयोग के मामले: जब कंटेंट कई भाषाओं या फॉर्मेट्स में उपलब्ध हो, जब विभिन्न डिवाइसों के लिए अलग-अलग वर्जन हों, या जब सर्वर वास्तव में तय नहीं कर सकता कि आप कौन सा वर्जन चाहते हैं।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: यूजर को चॉइसेज प्रेजेंट करें या प्रेफरेंसेज (जैसे लैंग्वेज सेटिंग्स) के आधार पर एक चुनें। रिस्पॉन्स में सभी उपलब्ध विकल्प लिस्ट होने चाहिए।
गलत उपयोग या गलत कार्यान्वयन: जब सर्वर उचित रूप से एक डिफ़ॉल्ट चुन सकता है तब 300 का उपयोग करना, उपलब्ध विकल्पों को स्पष्ट रूप से प्रस्तुत न करना, या सिंपल रीडायरेक्ट्स के लिए इसका उपयोग करना (इसके बजाय 301/302 का उपयोग करें)।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
301 स्टेटस कोड क्या है?
HTTP: 301 Moved Permanently
सर्वर कब और क्यों इसे रिटर्न करता है: रिसोर्स स्थायी रूप से नए एड्रेस पर चला गया है। यह तब जैसा है जब कोई बिजनेस नई लोकेशन पर जाता है और स्थायी फॉरवर्डिंग साइन लगाता है - अपनी एड्रेस बुक अपडेट करें!
व्यावहारिक उपयोग के मामले: जब वेबसाइट्स स्थायी रूप से अपने URLs को रीस्ट्रक्चर करती हैं, HTTP से HTTPS पर जाना, जब कंपनियां रीब्रांड करती हैं और डोमेन बदलती हैं, या बेहतर ऑर्गनाइजेशन के लिए कई पेजों को एक में कंसोलिडेट करना।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: स्वचालित रूप से नए URL पर जाएं और अगली बार के लिए याद रखें। ब्राउज़र बुकमार्क्स अपडेट करते हैं, और सर्च इंजन नई लोकेशन को पॉइंट करने के लिए अपने इंडेक्सेज अपडेट करते हैं।
गलत उपयोग या गलत कार्यान्वयन: टेम्पररी मूव्स के लिए 301 का उपयोग करना (इसके बजाय 302 का उपयोग करें), रीडायरेक्ट चेन्स बनाना जो यूजर्स को इधर-उधर बाउंस करती हैं, या जब आप इसे बाद में वापस बदलना चाहते हों तब 301 का उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
302 स्टेटस कोड क्या है?
HTTP: 302 Found
सर्वर कब और क्यों इसे रिटर्न करता है: रिसोर्स अस्थायी रूप से किसी अलग लोकेशन पर है। यह एक स्टोर साइन जैसा है जो कहता है “हम आज फार्मर्स मार्केट में हैं” - वे कल अपनी सामान्य जगह पर वापस आ जाएंगे।
व्यावहारिक उपयोग के मामले: साइट मेंटेनेंस के दौरान यूजर्स को रीडायरेक्ट करना, A/B टेस्टिंग जहां कुछ यूजर्स अलग वर्जन पर जाते हैं, सीजनल प्रमोशंस जो स्पेशल पेजों पर रीडायरेक्ट करते हैं, या सर्वरों के बीच लोड बैलेंसिंग।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: अभी के लिए टेम्पररी लोकेशन पर जाएं, लेकिन भविष्य के अनुरोधों के लिए ओरिजिनल URL का उपयोग करते रहें। बुकमार्क्स या परमानेंट रेफरेंसेज अपडेट न करें।
गलत उपयोग या गलत कार्यान्वयन: परमानेंट मूव्स के लिए 302 का उपयोग करना (उनके लिए 301 का उपयोग करें), रीडायरेक्ट लूप्स बनाना जहां A, B को भेजता है और B वापस A को भेजता है, या जब आपको विशेष रूप से HTTP मेथड को प्रिजर्व करने की आवश्यकता हो तब 302 का उपयोग करना (307 का उपयोग करें)।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
303 स्टेटस कोड क्या है?
HTTP: 303 See Other
सर्वर कब और क्यों इसे रिटर्न करता है: आपके अनुरोध को प्रोसेस करने के बाद (आमतौर पर POST), सर्वर चाहता है कि आप GET का उपयोग करके एक अलग पेज देखें। यह फॉर्म सबमिट करने और “थैंक यू” पेज पर रीडायरेक्ट होने जैसा है।
व्यावहारिक उपयोग के मामले: फॉर्म सबमिट करने के बाद, कन्फर्मेशन पेज पर रीडायरेक्ट करें; पेमेंट करने के बाद, रिसीट पर रीडायरेक्ट करें; कोई भी समय जब आप यूजर्स द्वारा पेज रिफ्रेश करने पर डुप्लिकेट सबमिशंस को रोकना चाहते हैं।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: नए URL पर एक नया GET रिक्वेस्ट करें। यह यूजर्स द्वारा पेज रिफ्रेश करने पर एक्सीडेंटल री-सबमिशन को रोकता है, क्योंकि रिफ्रेश करने से फॉर्म री-सबमिट होने के बजाय सिर्फ फाइनल पेज रीलोड होगा।
गलत उपयोग या गलत कार्यान्वयन: जब आप ओरिजिनल मेथड को प्रिजर्व करना चाहते हैं तब 303 का उपयोग करना (307 का उपयोग करें), परमानेंट रीडायरेक्ट्स के लिए इसका उपयोग करना (301 का उपयोग करें), या यह भूल जाना कि ओरिजिनल मेथड की परवाह किए बिना रीडायरेक्ट हमेशा GET का उपयोग करेगा।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
304 स्टेटस कोड क्या है?
HTTP: 304 Not Modified
सर्वर कब और क्यों इसे रिटर्न करता है: आपने जब आखिरी बार इसका अनुरोध किया था तब से रिसोर्स नहीं बदला है, इसलिए अपनी कैश्ड कॉपी का उपयोग करें। यह यह जांचने जैसा है कि क्या कोई डॉक्यूमेंट अपडेट हुआ और बताया जाना “नहीं, अभी भी वही है।”
व्यावहारिक उपयोग के मामले: ब्राउज़र कैशिंग जहां यह जांचता है कि इमेज/CSS/JavaScript फाइलें बदली हैं या नहीं, API रिस्पॉन्सेज जो शायद ही कभी बदलते हैं, या कोई भी स्थिति जहां आप अपरिवर्तित डेटा को दोबारा न भेजकर बैंडविड्थ बचाना चाहते हैं।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: वह कैश्ड वर्जन उपयोग करें जो आपके पास पहले से है। इस रिस्पॉन्स के साथ कोई नया डेटा नहीं आता - यह सिर्फ कन्फर्म कर रहा है कि आपकी कैश्ड कॉपी अभी भी अच्छी है।
गलत उपयोग या गलत कार्यान्वयन: 304 के साथ डेटा भेजना (यह खाली होना चाहिए), “नॉट मॉडिफाइड” कहना जब वास्तव में मॉडिफाई हुआ था, या इसे काम करने वाले स्पेशल हेडर्स को ठीक से हैंडल न करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
305 स्टेटस कोड क्या है?
HTTP: 305 Use Proxy
सर्वर कब और क्यों इसे रिटर्न करता है: यह स्टेटस कोड डेप्रिकेटेड है और कभी भी उपयोग नहीं किया जाना चाहिए। इसमें सिक्योरिटी प्रॉब्लम्स थीं और वेब कम्युनिटी द्वारा इसे छोड़ दिया गया है।
व्यावहारिक उपयोग के मामले: कोई नहीं - यह स्टेटस कोड रिटायर्ड है और किसी भी मॉडर्न एप्लिकेशन में उपयोग नहीं किया जाना चाहिए।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: मॉडर्न क्लाइंट्स को सिक्योरिटी कंसर्न्स के कारण इस स्टेटस कोड को इग्नोर करना चाहिए। यह एक हिस्टोरिकल आर्टिफैक्ट है।
गलत उपयोग या गलत कार्यान्वयन: इस स्टेटस कोड का उपयोग करना ही एक गलती है। इसे अच्छे सिक्योरिटी कारणों से डेप्रिकेट किया गया है और मॉडर्न एप्लिकेशंस में कभी नहीं दिखना चाहिए।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
307 स्टेटस कोड क्या है?
HTTP: 307 Temporary Redirect
सर्वर कब और क्यों इसे रिटर्न करता है: अस्थायी रूप से किसी अन्य URL पर रीडायरेक्ट करें, लेकिन 302 के विपरीत, क्लाइंट को वही मेथड उपयोग करनी चाहिए। यदि ओरिजिनल रिक्वेस्ट POST थी, तो रीडायरेक्ट भी POST होनी चाहिए।
व्यावहारिक उपयोग के मामले: मेंटेनेंस के तहत API एंडपॉइंट्स जिन्हें मेथड प्रिजर्व करने की आवश्यकता है, लोड बैलेंसिंग जो रिक्वेस्ट इंटीग्रिटी मेंटेन करती है, या कोई भी टेम्पररी रीडायरेक्ट जहां POST से GET में बदलना चीज़ों को तोड़ देगा।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: ओरिजिनल रिक्वेस्ट के बिल्कुल उसी मेथड और बॉडी का उपयोग करके नए URL पर रीडायरेक्ट करें। यह 302 रीडायरेक्ट्स से स्ट्रिक्टर है।
गलत उपयोग या गलत कार्यान्वयन: परमानेंट मूव्स के लिए 307 का उपयोग करना (308 का उपयोग करें), जब मेथड प्रिजर्वेशन मायने नहीं रखता तब इसका उपयोग करना (302 सिंपलर है), या यह नहीं समझना कि क्लाइंट्स को रिक्वेस्ट बॉडी फिर से भेजनी होगी।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
308 स्टेटस कोड क्या है?
HTTP: 308 Permanent Redirect
सर्वर कब और क्यों इसे रिटर्न करता है: 301 की तरह, लेकिन गारंटी देता है कि मेथड नहीं बदलेगी। यदि आपने पुराने URL पर POST किया, तो आपको नए URL पर भी POST करना होगा।
व्यावहारिक उपयोग के मामले: POST/PUT/DELETE स्वीकार करने वाले API एंडपॉइंट्स को स्थायी रूप से मूव करना, मेथड इंटीग्रिटी मेंटेन करते हुए RESTful सर्विसेज को रीस्ट्रक्चर करना, या कोई भी परमानेंट मूव जहां HTTP मेथड प्रिजर्व होनी चाहिए।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: नए URL का उपयोग करने के लिए रेफरेंसेज को स्थायी रूप से अपडेट करें, और रीडायरेक्ट फॉलो करते समय हमेशा ओरिजिनल रिक्वेस्ट के समान HTTP मेथड का उपयोग करें।
गलत उपयोग या गलत कार्यान्वयन: टेम्पररी मूव्स के लिए 308 का उपयोग करना (307 का उपयोग करें), जब मेथड प्रिजर्वेशन मायने नहीं रखता तब इसका उपयोग करना (301 अधिक व्यापक रूप से सपोर्टेड है), या यह भूल जाना कि यह एक नया स्टेटस कोड है जिसे पुराने क्लाइंट्स शायद नहीं समझें।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
4xx क्लाइंट एरर
ये कोड इंगित करते हैं कि क्लाइंट ने एक एरर की है।
400 स्टेटस कोड क्या है?
HTTP: 400 Bad Request
सर्वर कब और क्यों इसे रिटर्न करता है: आपका अनुरोध किसी तरह से गलत या अमान्य है। यह फोन नंबर फील्ड में अपना ईमेल भरने जैसा है - सर्वर इसे प्रोसेस नहीं कर सकता क्योंकि यह समझ में नहीं आता।
व्यावहारिक उपयोग के मामले: रिक्वेस्ट बॉडी में अमान्य JSON, आवश्यक पैरामीटर्स का गायब होना, गलत डेटा टाइप्स (जब नंबर अपेक्षित हो तब टेक्स्ट भेजना), गलत URLs, या रिक्वेस्ट में कोई भी सिंटैक्स एरर।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: वही रिक्वेस्ट दोबारा न करें - यह फिर फेल होगी। पहले समस्या ठीक करें। क्या गलत है इसके बारे में डिटेल्स के लिए रिस्पॉन्स बॉडी चेक करें और दोबारा कोशिश करने से पहले इसे ठीक करें।
गलत उपयोग या गलत कार्यान्वयन: ऑथेंटिकेशन प्रॉब्लम्स के लिए 400 का उपयोग करना (401 का उपयोग करें), सर्वर एररों के लिए 400 रिटर्न करना (5xx का उपयोग करें), अस्पष्ट एरर मैसेजेज देना जो समस्या ठीक करने में मदद नहीं करते, या किसी भी एरर के लिए 400 को कैच-ऑल के रूप में उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
401 स्टेटस कोड क्या है?
HTTP: 401 Unauthorized
सर्वर कब और क्यों इसे रिटर्न करता है: इस रिसोर्स को एक्सेस करने के लिए आपको लॉग इन करने या क्रेडेंशियल्स प्रदान करने की आवश्यकता है। यह अपना मेंबरशिप कार्ड दिखाए बिना मेंबर्स-ओनली एरिया में प्रवेश करने की कोशिश करने जैसा है।
व्यावहारिक उपयोग के मामले: टोकन के बिना प्रोटेक्टेड API एंडपॉइंट्स को एक्सेस करना, एक्सपायर्ड लॉगिन सेशंस, मिसिंग API कीज़, या किसी भी रिसोर्स के लिए रिक्वेस्ट जिसके लिए आपको साबित करना होगा कि आप कौन हैं।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: यूजर को लॉग इन करने के लिए प्रॉम्प्ट करें, लॉगिन पेज पर रीडायरेक्ट करें, या रीट्राई करने से पहले वैलिड क्रेडेंशियल्स प्राप्त करें। APIs के लिए, एक फ्रेश ऑथेंटिकेशन टोकन प्राप्त करें।
गलत उपयोग या गलत कार्यान्वयन: जब क्रेडेंशियल्स वैलिड हैं लेकिन इंसफिशिएंट हैं तब 401 का उपयोग करना (403 का उपयोग करें), ऑथेंटिकेट कैसे करें इसकी जानकारी शामिल करना भूल जाना, या ऑथेंटिकेशन (आप कौन हैं) को ऑथराइजेशन (आपको क्या करने की अनुमति है) से कंफ्यूज करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
403 स्टेटस कोड क्या है?
HTTP: 403 Forbidden
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर समझता है कि आप कौन हैं लेकिन आपको इस रिसोर्स को एक्सेस करने नहीं देगा। यह VIP एरिया में प्रवेश करने के लिए अपना ID दिखाने जैसा है लेकिन बताया जाना कि आप लिस्ट में नहीं हैं।
व्यावहारिक उपयोग के मामले: रेगुलर यूजर के रूप में एडमिन फीचर्स एक्सेस करने की कोशिश करना, किसी अन्य यूजर का प्राइवेट डेटा देखने की कोशिश करना, जियोग्राफिक रिस्ट्रिक्शंस (कंटेंट आपके देश में उपलब्ध नहीं है), या IP एड्रेस ब्लॉकिंग।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: उन्हीं क्रेडेंशियल्स के साथ रीट्राई करने की जहमत न उठाएं - वे काम नहीं करेंगे। “एक्सेस डिनाइड” मैसेज दिखाएं और संभवतः बताएं कि अगर एप्लिकेबल हो तो प्रॉपर एक्सेस कैसे प्राप्त करें।
गलत उपयोग या गलत कार्यान्वयन: जब यूजर लॉग इन नहीं है तब 403 का उपयोग करना (401 का उपयोग करें), उन रिसोर्सेज के लिए 403 का उपयोग करना जो एग्जिस्ट नहीं करते उनके एग्जिस्टेंस को छुपाने के लिए (डिबेटेबल - 404 का उपयोग कर सकते हैं), या एक्सेस क्यों फॉरबिडन है इसके बारे में क्लियर न होना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
404 स्टेटस कोड क्या है?
HTTP: 404 Not Found
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर आपके द्वारा अनुरोधित URL पर कुछ भी नहीं ढूंढ सकता। यह एक स्ट्रीट एड्रेस पर जाने जैसा है जहां सिर्फ एक खाली प्लॉट है - या तो आपने एड्रेस गलत लिया, या जो कुछ भी वहां था वह चला गया।
व्यावहारिक उपयोग के मामले: URL गलत टाइप करना (जैसे google.com के बजाय gooogle.com), डिलीट किए गए पेजों पर पुराने बुकमार्क्स क्लिक करना, अन्य वेबसाइटों से ब्रोकन लिंक्स फॉलो करना, API एंडपॉइंट्स में टाइपो करना, या उन फाइलों को एक्सेस करने की कोशिश करना जो मूव या रीनेम हो गई हैं।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: एक एरर पेज दिखाएं जो यूजर्स को यह समझने में मदद करता है कि आगे क्या करना है। अच्छे 404 पेजों में सर्च बॉक्स, पॉपुलर पेजों के लिंक्स, ब्रोकन लिंक रिपोर्ट करने का तरीका, या एरर को कम फ्रस्ट्रेटिंग बनाने के लिए मज़ेदार मैसेज शामिल होते हैं।
गलत उपयोग या गलत कार्यान्वयन: जब एक्सेस डिनाइड है तब 404 का उपयोग करना (“आप इसे नहीं देख सकते” के लिए 403 का उपयोग करें), जानबूझकर हमेशा के लिए हटाई गई चीज़ों के लिए 404 रिटर्न करना (410 “Gone” पर विचार करें), जेनेरिक अनहेल्पफुल एरर पेज दिखाना, या अनऑथराइज्ड यूजर्स से कुछ एग्जिस्ट करता है यह छुपाने के लिए 404 का उपयोग करना (हालांकि यह सिक्योरिटी के लिए डिबेटेबल है)।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
405 स्टेटस कोड क्या है?
HTTP: 405 Method Not Allowed
सर्वर कब और क्यों इसे रिटर्न करता है: रिसोर्स एग्जिस्ट करता है लेकिन आपने जो HTTP मेथड उपयोग की वह सपोर्ट नहीं करता। यह एक ऐसा दरवाज़ा धकेलने की कोशिश करने जैसा है जो केवल खींचकर खुलता है - दरवाज़ा है, आपको बस इसे सही तरीके से उपयोग करना है।
व्यावहारिक उपयोग के मामले: किसी रीड-ओनली रिसोर्स को DELETE करने की कोशिश करना, जो एंडपॉइंट केवल GET एक्सेप्ट करता है उस पर POST भेजना, जो रिसोर्सेज अपडेट नहीं किए जा सकते उन पर PUT की कोशिश करना, या कस्टम मेथड्स उपयोग करना जिन्हें सर्वर सपोर्ट नहीं करता।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: कौन सी मेथड्स सपोर्टेड हैं देखने के लिए Allow हेडर चेक करें, फिर एप्रोप्रिएट मेथड के साथ रीट्राई करें। वही मेथड ट्राई करते न रहें - यह सपोर्टेड नहीं है।
गलत उपयोग या गलत कार्यान्वयन: सपोर्टेड मेथड्स लिस्ट करने वाला रिक्वायर्ड Allow हेडर शामिल न करना, जब रिसोर्स एग्जिस्ट नहीं करता तब 405 का उपयोग करना (404 का उपयोग करें), या उन मेथड्स के लिए 405 रिटर्न करना जिन्हें सर्वर सपोर्ट तो करना चाहिए लेकिन अभी तक इम्प्लीमेंट नहीं किया है (501 पर विचार करें)।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
406 स्टेटस कोड क्या है?
HTTP: 406 Not Acceptable
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर आपके द्वारा एक्सेप्ट किए जाने वाले फॉर्मेट में रिसोर्स प्रदान नहीं कर सकता। यह एक ऐसे रेस्तरां में फ्रेंच में मेन्यू मांगने जैसा है जिसमें केवल इंग्लिश और स्पैनिश वर्जन हैं।
व्यावहारिक उपयोग के मामले: किसी एंडपॉइंट से JSON रिक्वेस्ट करना जो केवल XML प्रदान करता है, इमेज फॉर्मेट मांगना जिसे सर्वर सपोर्ट नहीं करता, लैंग्वेज नेगोशिएशन फेलियर्स, या कोई भी कंटेंट नेगोशिएशन मिसमैच।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: सर्वर जो फॉर्मेट प्रदान कर सकता है उसका रिक्वेस्ट करने के लिए अपने Accept हेडर्स मॉडिफाई करें, या अवेलेबल फॉर्मेट्स को हैंडल करें। रिस्पॉन्स में लिस्ट हो सकती है कि कौन से फॉर्मेट्स अवेलेबल हैं।
गलत उपयोग या गलत कार्यान्वयन: फॉर्मेट्स के बारे में बहुत स्ट्रिक्ट होना जब आप रीज़नेबल डिफ़ॉल्ट प्रदान कर सकते हैं, नॉन-कंटेंट नेगोशिएशन एररों के लिए 406 का उपयोग करना, या कौन से फॉर्मेट्स अवेलेबल हैं यह क्लियरली इंडिकेट न करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
407 स्टेटस कोड क्या है?
HTTP: 407 Proxy Authentication Required
सर्वर कब और क्यों इसे रिटर्न करता है: आपके और डेस्टिनेशन के बीच एक प्रॉक्सी सर्वर को ऑथेंटिकेशन की आवश्यकता है। यह जिस बिल्डिंग में आप जाना चाहते हैं वहां पहुंचने से पहले सिक्योरिटी गार्ड को ID दिखाने की आवश्यकता जैसा है।
व्यावहारिक उपयोग के मामले: कॉर्पोरेट प्रॉक्सी सर्वर जिन्हें एम्प्लॉई लॉगिन की आवश्यकता है, नेटवर्क गेटवेज़ जिन्हें ऑथेंटिकेशन चाहिए, पेड प्रॉक्सी सर्विसेज जिन्हें क्रेडेंशियल्स चाहिए, या कोई भी ऑथेंटिकेटेड प्रॉक्सी सेटअप।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: Proxy-Authenticate हेडर में स्पेसिफाइड मेथड का उपयोग करके प्रॉक्सी सर्वर (डेस्टिनेशन सर्वर नहीं) के साथ ऑथेंटिकेट करें, फिर ओरिजिनल रिक्वेस्ट रीट्राई करें।
गलत उपयोग या गलत कार्यान्वयन: इसे रेगुलर 401 ऑथेंटिकेशन से कंफ्यूज करना, Proxy-Authenticate हेडर शामिल न करना, या जब डेस्टिनेशन सर्वर (प्रॉक्सी नहीं) ऑथेंटिकेशन रिक्वायर करता है तब 407 का उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
408 स्टेटस कोड क्या है?
HTTP: 408 Request Timeout
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर ने आपके पूरा रिक्वेस्ट भेजने का इंतज़ार किया, लेकिन आपने बहुत लंबा समय लिया। यह एक रेस्तरां में ऑर्डर देना शुरू करने जैसा है लेकिन इतनी लंबी पॉज़ करना कि वेटर चला जाए।
व्यावहारिक उपयोग के मामले: स्लो नेटवर्क कनेक्शंस जो डिलेज़ का कारण बनते हैं, पुअर कनेक्शंस पर बड़ी फाइल अपलोड्स, क्लाइंट एप्लिकेशंस जो रिक्वेस्ट ट्रांसमिशन के दौरान फ्रीज़ हो जाती हैं, या डेटा भेजते समय नेटवर्क इंटरप्शंस।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: आप रिक्वेस्ट रीट्राई कर सकते हैं, प्रेफरेबली बेहतर कनेक्शन या स्मॉलर पेलोड के साथ। बड़े रिक्वेस्ट्स को छोटे चंक्स में ब्रेक करने या नेटवर्क कंडीशंस इम्प्रूव करने पर विचार करें।
गलत उपयोग या गलत कार्यान्वयन: जब सर्वर स्लो है तब 408 का उपयोग करना (वह 504 है), अनरीज़नेबली शॉर्ट टाइमआउट्स सेट करना, या नेटवर्क-लेवल वालों के बजाय एप्लिकेशन-लेवल टाइमआउट्स के लिए 408 का उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
409 स्टेटस कोड क्या है?
HTTP: 409 Conflict
सर्वर कब और क्यों इसे रिटर्न करता है: आपका रिक्वेस्ट रिसोर्स की करंट स्टेट के साथ कॉन्फ्लिक्ट करता है। यह एक ऐसा यूज़रनेम बनाने की कोशिश करने जैसा है जो पहले से लिया हुआ है - ऑपरेशन समझ में आता है, लेकिन अभी नहीं किया जा सकता।
व्यावहारिक उपयोग के मामले: डुप्लिकेट रिकॉर्ड बनाने की कोशिश करना, एक डॉक्यूमेंट एडिट करना जिसे कोई और करंटली एडिट कर रहा है, कोलैबोरेटिव सिस्टम्स में वर्जन कॉन्फ्लिक्ट्स, या बिज़नेस रूल्स वायलेट करना (जैसे रिसोर्स को डबल-बुक करना)।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: अलग वैल्यू चुनकर, चेंजेज़ मर्ज करके, या कॉन्फ्लिक्ट क्लियर होने का इंतज़ार करके कॉन्फ्लिक्ट रिज़ॉल्व करें। रिस्पॉन्स में बताना चाहिए कि कॉन्फ्लिक्ट क्या है और इसे कैसे रिज़ॉल्व करें।
गलत उपयोग या गलत कार्यान्वयन: वैलिडेशन एररों के लिए 409 का उपयोग करना (422 पर विचार करें), कॉन्फ्लिक्ट कैसे रिज़ॉल्व करें यह न बताना, परमिशन इश्यूज़ के लिए 409 का उपयोग करना (403 का उपयोग करें), या ऐसे कॉन्फ्लिक्ट्स रिपोर्ट करना जो वास्तव में क्लाइंट द्वारा रिज़ॉल्व नहीं किए जा सकते।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
410 स्टेटस कोड क्या है?
HTTP: 410 Gone
सर्वर कब और क्यों इसे रिटर्न करता है: रिसोर्स यहां हुआ करता था लेकिन जानबूझकर हटा दिया गया और वापस नहीं आएगा। यह एक डिमॉलिश्ड बिल्डिंग विज़िट करने जैसा है - यह सिर्फ टेम्परेरिली क्लोज़्ड नहीं है, यह परमानेंटली गई है।
व्यावहारिक उपयोग के मामले: पॉलिसी वायलेशंस के लिए डिलीट किए गए आर्टिकल्स या पोस्ट्स, हमेशा के लिए डिस्कंटीन्यूड प्रोडक्ट्स, पुराने API वर्जन जो सनसेट हो गए हैं, या कोई भी कंटेंट जो जानबूझकर और परमानेंटली रिमूव किया गया।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: बुकमार्क्स रिमूव करें, लिंक्स अपडेट करें, और यूज़र्स को इन्फॉर्म करें कि कंटेंट परमानेंटली गया है। सर्च इंजन्स को इन URLs को अपने इंडेक्स से रिमूव करना चाहिए। चेक करते न रहें - यह वापस नहीं आ रहा।
गलत उपयोग या गलत कार्यान्वयन: टेम्पररी रिमूवल्स के लिए 410 का उपयोग करना (503 का उपयोग करें), जब आप कंटेंट रिस्टोर कर सकते हैं तब 410 का उपयोग करना, उन चीज़ों के लिए 410 का उपयोग करना जो कभी एग्जिस्ट नहीं थीं (404 का उपयोग करें), या रिमूवल परमानेंट है इसके बारे में सर्टेन न होना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
418 स्टेटस कोड क्या है?
HTTP: 418 I’m a teapot
सर्वर कब और क्यों इसे रिटर्न करता है: यह कॉफी पॉट्स को कंट्रोल करने के बारे में एक अप्रैल फूल RFC से एक जोक स्टेटस कोड है। इसका मतलब है “मैं एक चायदानी हूं, और आपने मुझसे कॉफी बनाने को कहा, जो मैं नहीं कर सकता।”
व्यावहारिक उपयोग के मामले: एप्लिकेशंस में ईस्टर एग्स, प्रोग्रामिंग कोर्सेज में HTTP की एक्सटेंसिबिलिटी दिखाना, डेवलपमेंट/टेस्ट एनवायरनमेंट्स में ह्यूमर जोड़ना, या एप्रोप्रिएट कॉन्टेक्स्ट्स में प्लेफुल रिस्पॉन्स के रूप में।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: इसे ह्यूमरस रिस्पॉन्स के रूप में रिकॉग्नाइज़ करें और एप्रोप्रिएटली हैंडल करें - शायद फन एरर मैसेज या टी-रिलेटेड इमेजरी डिस्प्ले करें। सीरियस प्रोडक्शन एनवायरनमेंट्स में इसकी अपेक्षा न करें।
गलत उपयोग या गलत कार्यान्वयन: प्रोडक्शन सिस्टम्स में एक्चुअल एररों के लिए 418 का उपयोग करना, अनॉयन्स की हद तक इसका ओवरयूज़ करना, या इसे उन यूज़र्स को रिटर्न करना जो जोक नहीं समझेंगे।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
422 स्टेटस कोड क्या है?
HTTP: 422 Unprocessable Entity
सर्वर कब और क्यों इसे रिटर्न करता है: आपका रिक्वेस्ट फॉर्मेट सही है, लेकिन कंटेंट समझ में नहीं आता। यह एक फॉर्म सही तरीके से भरने जैसा है लेकिन इम्पॉसिबल डेटा एंटर करना - जैसे 300 साल की उम्र होना या फ्यूचर में बॉर्न होना।
व्यावहारिक उपयोग के मामले: फॉर्म वैलिडेशन फेलियर्स (@ सिंबल के बिना ईमेल), बिज़नेस रूल वायलेशंस (एंड डेट स्टार्ट डेट से पहले), API रिक्वेस्ट्स में सेमांटिक एररों, या करेक्टली फॉर्मेटेड डेटा में कोई भी लॉजिकल एररों।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: कौन सा वैलिडेशन फेल हुआ यह समझने के लिए एरर डिटेल्स पढ़ें, डेटा को रिक्वायरमेंट्स मीट करने के लिए फिक्स करें, और रीसबमिट करें। स्ट्रक्चर ठीक था; कंटेंट में एडजस्टमेंट चाहिए।
गलत उपयोग या गलत कार्यान्वयन: सिंटैक्स एररों के लिए 422 का उपयोग करना (400 का उपयोग करें), स्पेसिफिक वैलिडेशन एरर डिटेल्स प्रदान न करना, ऑथेंटिकेशन/ऑथराइजेशन इश्यूज़ के लिए 422 का उपयोग करना, या 422 बनाम 400 किसे ट्रिगर करता है इसमें इनकंसिस्टेंट होना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
429 स्टेटस कोड क्या है?
HTTP: 429 Too Many Requests
सर्वर कब और क्यों इसे रिटर्न करता है: आप बहुत तेज़ी से बहुत सारे रिक्वेस्ट्स भेज रहे हैं। यह किसी को बार-बार कॉल करने जैसा है - आखिरकार वे जवाब देना बंद कर देंगे और आपको स्लो डाउन करने को कहेंगे।
व्यावहारिक उपयोग के मामले: API रेट लिमिटिंग (जैसे, प्रति घंटे 100 रिक्वेस्ट्स), एब्यूज़ या DDoS अटैक्स रोकना, सर्वरों को ओवरव्हेल्म होने से बचाना, या फेयर यूसेज पॉलिसीज़ एनफोर्स करना।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: रिक्वेस्ट्स करना बंद करें और प्रतीक्षा करें। कब फिर से ट्राई कर सकते हैं देखने के लिए Retry-After हेडर चेक करें। एक्सपोनेंशियल बैकऑफ इम्प्लीमेंट करें - प्रत्येक रीट्राई अटेम्प्ट के बीच अधिक समय प्रतीक्षा करें।
गलत उपयोग या गलत कार्यान्वयन: क्लाइंट्स को गाइड करने के लिए Retry-After हेडर शामिल न करना, नॉर्मल यूसेज के लिए बहुत कम लिमिट्स सेट करना, अन्य टाइप्स के ओवरलोड के लिए 429 का उपयोग करना (503 पर विचार करें), या रेट लिमिट्स क्लियरली डॉक्यूमेंट न करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
451 स्टेटस कोड क्या है?
HTTP: 451 Unavailable For Legal Reasons
सर्वर कब और क्यों इसे रिटर्न करता है: कंटेंट लीगल रिक्वायरमेंट्स के कारण ब्लॉक है। रे ब्रैडबरी की सेंसरशिप के बारे में “फारेनहाइट 451” के नाम पर रखा गया, यह स्टेटस गवर्नमेंट या लीगल ब्लॉकिंग इंडिकेट करता है।
व्यावहारिक उपयोग के मामले: कोर्ट ऑर्डर द्वारा ब्लॉक किया गया कंटेंट, DMCA टेकडाउन नोटिसेज़, लोकल लॉज़ के कारण जियोग्राफिक रिस्ट्रिक्शंस, गवर्नमेंट सेंसरशिप रिक्वायरमेंट्स, या कोई भी लीगली मैंडेटेड कंटेंट ब्लॉकिंग।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: यूज़र्स को इन्फॉर्म करें कि कंटेंट लीगली रिस्ट्रिक्टेड है। रिस्पॉन्स में डिटेल्स शामिल हो सकती हैं कि ब्लॉक किसने डिमांड किया (अगर यह शेयर करना लीगली अलाउड है)।
गलत उपयोग या गलत कार्यान्वयन: नॉन-लीगल ब्लॉक्स के लिए 451 का उपयोग करना (एप्रोप्रिएट 4xx कोड का उपयोग करें), जब पॉसिबल हो तब लीगल ब्लॉक्स के बारे में ट्रांसपेरेंट न होना, या लीगल रिक्वायरमेंट्स के बजाय वॉलंटरी कंटेंट पॉलिसीज़ के लिए 451 का उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
5xx सर्वर एरर
ये कोड इंगित करते हैं कि सर्वर एक वैलिड रिक्वेस्ट को फुलफिल करने में फेल हुआ।
500 स्टेटस कोड क्या है?
HTTP: 500 Internal Server Error
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर की तरफ कुछ गलत हो गया, और यह नहीं जानता कि इसे कैसे हैंडल करे। यह एक स्टोर में कैश रजिस्टर क्रैश होने जैसा है - प्रॉब्लम आपके पेमेंट मेथड से नहीं है, उनका सिस्टम बस टूट गया।
व्यावहारिक उपयोग के मामले: जब डेटाबेस कनेक्शन फेल होता है, जब सर्वर कोड में बग होता है, जब सर्वर की मेमोरी खत्म हो जाती है, या कोई भी अनएक्सपेक्टेड क्रैश जिसका प्रोग्रामर्स ने अनुमान नहीं लगाया था।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: यूज़र्स को बताएं कि कुछ गलत हो गया और बाद में फिर से ट्राई करने का सुझाव दें। आप डिले के बाद ऑटोमैटिकली रीट्राई कर सकते हैं, क्योंकि ये एररों अक्सर टेम्पररी होती हैं।
गलत उपयोग या गलत कार्यान्वयन: यूज़र एररों के लिए 500 का उपयोग करना (उनके लिए 4xx कोड्स का उपयोग करें), यूज़र्स को डिटेल्ड एरर मैसेजेज़ दिखाना (सिक्योरिटी रिस्क!), प्रॉब्लम फिक्स करने के लिए पर्याप्त डिटेल्स लॉग न करना, या किसी भी एरर के लिए 500 को लेज़ी कैच-ऑल के रूप में उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
501 स्टेटस कोड क्या है?
HTTP: 501 Not Implemented
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर आपके द्वारा मांगी गई फंक्शनैलिटी सपोर्ट नहीं करता। यह एक बेसिक कैलकुलेटर से फंक्शंस ग्राफ करने के लिए कहने जैसा है - यह समझता है आप क्या चाहते हैं लेकिन उसमें वह फीचर नहीं है।
व्यावहारिक उपयोग के मामले: HTTP मेथड्स उपयोग करना जिन्हें सर्वर रिकॉग्नाइज़ नहीं करता, ऐसे फीचर्स रिक्वेस्ट करना जो प्लान तो हैं लेकिन अभी बिल्ट नहीं हुए, लीगेसी सर्वर जो मॉडर्न फंक्शनैलिटी सपोर्ट नहीं करते, या कस्टम मेथड्स जो इम्प्लीमेंटेड नहीं हैं।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: यह रिक्वेस्ट रीट्राई न करें - सर्वर इसे हैंडल नहीं कर सकता। अलग एप्रोच उपयोग करें या चेक करें कि जो आपको चाहिए वह अचीव करने का कोई अल्टरनेटिव तरीका है या नहीं।
गलत उपयोग या गलत कार्यान्वयन: टेम्परेरिली डिसेबल्ड फीचर्स के लिए 501 का उपयोग करना (503 का उपयोग करें), उन मेथड्स के लिए 501 का उपयोग करना जिन्हें आप रिकॉग्नाइज़ करते हैं लेकिन अलाउ नहीं करते (405 का उपयोग करें), या मिसिंग फीचर्स के लिए 501 को एक्सक्यूज़ के रूप में उपयोग करना जो इम्प्लीमेंटेड होने चाहिए।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
502 स्टेटस कोड क्या है?
HTTP: 502 Bad Gateway
सर्वर कब और क्यों इसे रिटर्न करता है: गेटवे या प्रॉक्सी के रूप में एक्ट करने वाले सर्वर को अपस्ट्रीम सर्वर से इनवैलिड रिस्पॉन्स मिला। यह किसी से मैसेज रिले करने को कहने जैसा है, लेकिन वे वापस आकर कहते हैं “जिससे मैंने पूछा उसने मुझे गिबरिश दिया।”
व्यावहारिक उपयोग के मामले: लोड बैलेंसर बैकएंड सर्वरों तक नहीं पहुंच सकता, API गेटवे को माइक्रोसर्विसेज़ से एररों मिल रही हैं, रिवर्स प्रॉक्सी को मैलफॉर्म्ड रिस्पॉन्सेज़ मिल रही हैं, या CDN ओरिजिन सर्वर से फेच नहीं कर पा रहा।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: यह आमतौर पर टेम्पररी है, इसलिए शॉर्ट डिले के बाद रीट्राई करें। प्रॉब्लम सर्वरों के बीच है, आपके रिक्वेस्ट के साथ नहीं, इसलिए जब वे अपने कम्युनिकेशन इश्यूज़ फिक्स कर लें तो रीट्राई करना काम कर सकता है।
गलत उपयोग या गलत कार्यान्वयन: ओरिजिन सर्वर की अपनी एररों के लिए 502 का उपयोग करना (500 का उपयोग करें), “कैन’t रीच” और “इनवैलिड रिस्पॉन्स” सीनेरियोज़ में डिस्टिंगुइश न करना, या जब गेटवे खुद में प्रॉब्लम्स है तब 502 का उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
503 स्टेटस कोड क्या है?
HTTP: 503 Service Unavailable
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर टेम्परेरिली रिक्वेस्ट्स हैंडल करने में अनेबल है। यह एक स्टोर द्वारा “मेंटेनेंस के लिए बंद” साइन लगाने जैसा है - वे वापस आएंगे, लेकिन अभी नहीं।
व्यावहारिक उपयोग के मामले: शेड्यूल्ड मेंटेनेंस विंडोज़, सर्वर ओवरलोड सिचुएशंस, अपडेट्स के लिए टेम्पररी आउटेजेज़, सर्वर लेवल पर रेट लिमिटिंग, या रिक्वेस्ट्स सर्व करने में कोई भी टेम्पररी इनेबिलिटी।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: प्रतीक्षा करें और बाद में रीट्राई करें। कब वापस आना है इसके गाइडेंस के लिए Retry-After हेडर चेक करें। जब सर्वर रिटर्न हो तब उसे ओवरव्हेल्म करने से बचने के लिए रीट्राइज़ के लिए एक्सपोनेंशियल बैकऑफ इम्प्लीमेंट करें।
गलत उपयोग या गलत कार्यान्वयन: परमानेंट प्रॉब्लम्स के लिए 503 का उपयोग करना (एप्रोप्रिएट एरर का उपयोग करें), जब आपको पता है कितना समय लगेगा तब Retry-After शामिल न करना, सर्वर-वाइड प्रॉब्लम्स के बजाय क्लाइंट-स्पेसिफिक इश्यूज़ के लिए 503 का उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
504 स्टेटस कोड क्या है?
HTTP: 504 Gateway Timeout
सर्वर कब और क्यों इसे रिटर्न करता है: गेटवे या प्रॉक्सी के रूप में एक्ट करने वाले सर्वर को अपस्ट्रीम सर्वर से टाइमली रिस्पॉन्स नहीं मिला। यह किसी से मैसेज रिले करने को कहने जैसा है, लेकिन वे वापस आकर कहते हैं “मैंने इंतज़ार किया और इंतज़ार किया, लेकिन उन्होंने कभी रिस्पॉन्ड नहीं किया।”
व्यावहारिक उपयोग के मामले: डेटाबेस क्वेरीज़ जो बहुत लंबा समय ले रही हैं, ओवरलोडेड बैकएंड सर्विसेज़, सर्वरों के बीच नेटवर्क इश्यूज़, माइक्रोसर्विसेज़ जो जल्दी पर्याप्त रिस्पॉन्ड नहीं कर रहीं, या सर्वर-टू-सर्वर कम्युनिकेशन में कोई भी टाइमआउट।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: आप रीट्राई कर सकते हैं, लेकिन अवेयर रहें कि ऑपरेशन एक्सपेंसिव या स्लो हो सकता है। विचार करें कि क्या रिक्वेस्ट रीट्राई करने के लिए पर्याप्त क्रिटिकल है, और रीज़नेबल रीट्राई लिमिट्स इम्प्लीमेंट करें।
गलत उपयोग या गलत कार्यान्वयन: जब क्लाइंट्स स्लो हैं तब 504 का उपयोग करना (408 का उपयोग करें), रीज़नेबल ऑपरेशंस के लिए टाइमआउट्स बहुत शॉर्ट सेट करना, डिफरेंट टाइमआउट सीनेरियोज़ में डिस्टिंगुइश न करना, या ओरिजिन सर्वर के अपने टाइमआउट्स के लिए 504 का उपयोग करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
505 स्टेटस कोड क्या है?
HTTP: 505 HTTP Version Not Supported
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर रिक्वेस्ट में यूज़ की गई HTTP वर्जन सपोर्ट नहीं करता। यह DVD प्लेयर में Blu-ray डिस्क प्ले करने की कोशिश करने जैसा है - प्लेयर समझता है आप क्या चाहते हैं लेकिन उस फॉर्मेट को हैंडल नहीं कर सकता।
व्यावहारिक उपयोग के मामले: पुराने सर्वर जो केवल HTTP/1.0 सपोर्ट करते हैं और HTTP/2 रिक्वेस्ट्स रिसीव करते हैं, सर्वर जो नई HTTP वर्जन सपोर्ट करने के लिए अभी तक अपग्रेड नहीं हुए, या कस्टम/एक्सपेरिमेंटल HTTP वर्जन जिन्हें सर्वर रिकॉग्नाइज़ नहीं करता।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: अलग HTTP वर्जन यूज़ करके रिक्वेस्ट रीट्राई करें, टिपिकली HTTP/1.1 पर फॉलबैक करें जो यूनिवर्सली सपोर्टेड है। चेक करें सर्वर कौन सी वर्जन्स सपोर्ट करता है।
गलत उपयोग या गलत कार्यान्वयन: वर्जन के भीतर अनसपोर्टेड फीचर्स के लिए 505 का उपयोग करना (501 का उपयोग करें), वर्जन नेगोशिएशन ग्रेसफुली हैंडल करने की कोशिश न करना, या स्टैंडर्ड HTTP वर्जन्स रिजेक्ट करना जो सपोर्टेड होनी चाहिए।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
507 स्टेटस कोड क्या है?
HTTP: 507 Insufficient Storage
सर्वर कब और क्यों इसे रिटर्न करता है: सर्वर के पास रिक्वेस्ट कंप्लीट करने के लिए पर्याप्त स्टोरेज स्पेस नहीं है। यह फाइल सेव करने की कोशिश करने जैसा है जब हार्ड ड्राइव फुल है।
व्यावहारिक उपयोग के मामले: फुल डिस्क के कारण फाइल अपलोड फेलियर्स, डेटाबेस ऑपरेशंस जो स्टोरेज कोटा हिट कर रहे हैं, अलोकेटेड स्पेस एक्सीड करने वाले WebDAV ऑपरेशंस, या कोई भी ऑपरेशन जिसे अवेलेबल से ज़्यादा स्टोरेज रिक्वायर होती है।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: यूज़र्स को स्टोरेज लिमिट्स के बारे में इन्फॉर्म करें। पुराना कंटेंट डिलीट करना, मोर स्टोरेज रिक्वेस्ट करना, या जो स्टोर करने की कोशिश कर रहे हैं उसका साइज़ रिड्यूस करना पड़ सकता है।
गलत उपयोग या गलत कार्यान्वयन: टेम्पररी स्टोरेज इश्यूज़ के लिए 507 का उपयोग करना जो क्लियर हो जाएंगे (503 पर विचार करें), स्टोरेज प्रॉपरली मॉनिटर न करना, फिज़िकल स्टोरेज से अनरिलेटेड कोटा इश्यूज़ के लिए 507 का उपयोग करना, या स्टोरेज लिमिट्स के बारे में इन्फॉर्मेशन प्रदान न करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
508 स्टेटस कोड क्या है?
HTTP: 508 Loop Detected
सर्वर कब और क्यों इसे रिटर्न करता है: रिक्वेस्ट प्रोसेस करते समय सर्वर ने इनफिनिट लूप डिटेक्ट किया। यह ऐसे डायरेक्शंस फॉलो करने जैसा है जो आखिर में कहती हैं “स्टेप 1 देखें” - आप हमेशा के लिए सर्कल्स में घूमते रहेंगे।
व्यावहारिक उपयोग के मामले: सर्कुलर रेफरेंसेज़ वाले WebDAV ऑपरेशंस, रीडायरेक्ट चेन्स जो खुद पर लूप बैक करती हैं, साइक्ल्स क्रिएट करने वाले सिंबॉलिक लिंक्स, या कोई भी सर्वर ऑपरेशन जो डिटेक्ट करता है कि यह एंडलेसली रिपीट हो रहा है।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: वही रिक्वेस्ट रीट्राई न करें - यह उसी लूप में हिट करेगी। अपने डेटा स्ट्रक्चर में सर्कुलर रेफरेंसेज़ चेक करें और फिर से ट्राई करने से पहले उन्हें फिक्स करें।
गलत उपयोग या गलत कार्यान्वयन: नॉन-लूप एररों के लिए 508 का उपयोग करना, प्रॉपर लूप डिटेक्शन इम्प्लीमेंट न करना, क्लाइंट-साइड रीडायरेक्ट लूप्स के लिए 508 का उपयोग करना (वे डिफरेंटली शो होती हैं), या फॉल्स पॉज़िटिव्स को लूप्स के रूप में डिटेक्ट करना।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक
511 स्टेटस कोड क्या है?
HTTP: 511 Network Authentication Required
सर्वर कब और क्यों इसे रिटर्न करता है: इंटरनेट एक्सेस करने से पहले आपको नेटवर्क के साथ ही ऑथेंटिकेट करने की आवश्यकता है। यह किसी भी वेबसाइट ब्राउज़ करने से पहले होटल WiFi में साइन इन करने की आवश्यकता जैसा है।
व्यावहारिक उपयोग के मामले: होटल या एयरपोर्ट WiFi लॉगिन पेजेज़, कॉर्पोरेट नेटवर्क एक्सेस पोर्टल्स, पब्लिक WiFi जिसमें टर्म्स ऑफ सर्विस एक्सेप्ट करना रिक्वायर होता है, या कोई भी कैप्टिव पोर्टल सिचुएशन।
क्लाइंट को इस स्टेटस पर कैसे प्रतिक्रिया देनी चाहिए: यूज़र्स को नेटवर्क लॉगिन पेज पर रीडायरेक्ट करें (आमतौर पर रिस्पॉन्स में प्रदान किया जाता है)। एक बार जब वे नेटवर्क के साथ ऑथेंटिकेट कर लें, वे अपना ओरिजिनल रिक्वेस्ट रीट्राई कर सकते हैं।
गलत उपयोग या गलत कार्यान्वयन: वेबसाइट लॉगिन रिक्वायरमेंट्स के लिए 511 का उपयोग करना (401 का उपयोग करें), प्रॉक्सी ऑथेंटिकेशन के लिए 511 का उपयोग करना (407 का उपयोग करें), या कैप्टिव पोर्टल्स को ऐसे तरीकों से इम्प्लीमेंट करना जो सिक्योर कनेक्शंस ब्रेक करते हैं।
अतिरिक्त संदर्भ के लिए Mozilla.org डेवलपर डॉक