किसी भी HTTP स्टेटस कोड के बारे में जानें: उसका मतलब, सर्वर उसे कब भेजते हैं और कौन-सा स्पेसिफ़िकेशन उसे परिभाषित करता है। नंबर या कीवर्ड से खोजें, क्लास के अनुसार फ़िल्टर करें और सीधे किसी कोड का लिंक साझा करें।
सर्वर को रिक्वेस्ट हेडर मिल गए हैं और क्लाइंट अब बॉडी भेज सकता है। यह तब दिखता है, जब क्लाइंट बड़ी बॉडी अपलोड करने से पहले “Expect: 100-continue” भेजता है।
सर्वर ने WebDAV रिक्वेस्ट स्वीकार कर ली है, लेकिन उसे अभी पूरा नहीं किया है। इसे बाद के WebDAV स्पेसिफ़िकेशन से हटा दिया गया था और आज इसका इस्तेमाल बहुत कम होता है।
अंतिम जवाब से पहले भेजा जाता है, ताकि ब्राउज़र Link हेडर में दी गई रिसोर्स को पहले से लोड करना शुरू कर सके। पेज तेज़ी से लोड करने के लिए CDN और सर्वर इसका इस्तेमाल करते हैं।
रिक्वेस्ट प्रोसेसिंग के लिए स्वीकार कर ली गई है, लेकिन अभी पूरी नहीं हुई। एक्सपोर्ट या बैच जॉब जैसे कामों को कतार में लगाने वाली API इसका इस्तेमाल करती हैं।
सर्वर सिर्फ़ वही बाइट रेंज लौटाता है जिसकी क्लाइंट ने माँग की थी। वीडियो स्ट्रीम होने, डाउनलोड फिर से शुरू होने या क्लाइंट के Range हेडर भेजने पर यह दिखता है।
रिसोर्स स्थायी रूप से Location हेडर में दिए गए URL पर चला गया है। ब्राउज़र और सर्च इंजन अपने लिंक अपडेट करते हैं; कुछ क्लाइंट इसे फ़ॉलो करते समय POST को GET में बदल देते हैं।
रिसोर्स अस्थायी रूप से Location हेडर में दिए गए दूसरे URL पर है। लॉगिन के बाद और कम समय वाले रीडायरेक्ट के लिए यह आम है; ब्राउज़र आमतौर पर इसे GET के साथ फ़ॉलो करते हैं।
क्लाइंट को GET के ज़रिए किसी दूसरे URL से नतीजा फ़ेच करना चाहिए। फ़ॉर्म POST के बाद पुष्टि वाले पेज पर रीडायरेक्ट करने के लिए इस्तेमाल होता है (Post/Redirect/Get पैटर्न)।
कैश की गई कॉपी अब भी मान्य है, इसलिए सर्वर कोई बॉडी नहीं भेजता। ब्राउज़र द्वारा If-None-Match या If-Modified-Since के ज़रिए कैश की गई फ़ाइल की दोबारा जाँच करने पर यह दिखता है।
संसाधन अस्थायी रूप से किसी दूसरे URL पर उपलब्ध है और क्लाइंट को उसी मेथड और बॉडी के साथ अनुरोध दोहराना होगा। ब्राउज़र इसे HTTPS पर आंतरिक HSTS रीडायरेक्ट के लिए भी इस्तेमाल करते हैं।
संसाधन स्थायी रूप से स्थानांतरित हो गया है और क्लाइंट को नए URL पर उसी मेथड और बॉडी का उपयोग करना होगा। यह 307 का स्थायी समकक्ष है और POST अनुरोधों को रीडायरेक्ट करने के लिए सुरक्षित है।
सर्वर अनुरोध को संसाधित नहीं कर सकता, क्योंकि उसका फ़ॉर्मैट गलत है। उदाहरण के लिए, JSON अमान्य हो सकता है, क्वेरी पैरामीटर गलत हो सकता है या कुकी खराब हो सकती है।
अनुरोध में मान्य प्रमाणीकरण क्रेडेंशियल नहीं हैं। नाम के बावजूद, इसका अर्थ है “प्रमाणित नहीं”; सर्वर लॉग इन करने का तरीका बताने वाला WWW-Authenticate हेडर भेजता है।
सर्वर अनुरोध को समझता है, लेकिन उसे अस्वीकार करता है। दोबारा लॉग इन करने से समस्या हल नहीं होगी। यह तब दिख सकता है, जब अनुमतियाँ न हों, डायरेक्टरी लिस्टिंग बंद हो या फ़ायरवॉल क्लाइंट को रोक रहा हो।
संसाधन मौजूद है, लेकिन इस्तेमाल किया गया HTTP मेथड समर्थित नहीं है; जैसे, केवल पढ़ने के लिए बने URL पर POST करना। जवाब में Allow हेडर के ज़रिए अनुमत मेथड बताए जाते हैं।
अनुरोध हेडर में दी गई कोई शर्त पूरी नहीं हुई; जैसे, If-Match। इसका उपयोग तब से बदले हुए संसाधन को ओवरराइट होने से रोकने के लिए किया जाता है, जब क्लाइंट ने उसे पिछली बार पढ़ा था।
URL सर्वर द्वारा संसाधित किए जा सकने वाले आकार से लंबा है। आम तौर पर इसकी वजह GET के ज़रिए बहुत ज़्यादा डेटा भेजने वाला फ़ॉर्म या पैरामीटर जोड़ते रहने वाला रीडायरेक्ट लूप होता है।
1998 के Hyper Text Coffee Pot Control Protocol का अप्रैल फूल्स मज़ाक: कॉफ़ी बनाने से इनकार करता एक चायदानी। HTTP में यह कोड अप्रयुक्त आरक्षित है, लेकिन कुछ सर्वर इसे मज़ाकिया संकेत के तौर पर या अनचाहे बॉट को रोकने के लिए लौटाते हैं।
मानक कोड नहीं। Laravel इसे तब लौटाता है, जब फ़ॉर्म का CSRF टोकन मौजूद न हो या उसकी समय-सीमा समाप्त हो गई हो। आम तौर पर ऐसा सेशन का समय समाप्त होने के बाद होता है।
अनुरोध का फ़ॉर्मैट सही है, लेकिन उसकी सामग्री अमान्य है; जैसे, ऐसा फ़ॉर्म जो सत्यापन नियमों पर खरा न उतरे। API में सत्यापन त्रुटियों के लिए इसका व्यापक उपयोग होता है।
क्लाइंट ने तय समय में बहुत ज़्यादा अनुरोध भेजे हैं। API इसका उपयोग अनुरोधों की दर सीमित करने के लिए करती हैं और अक्सर Retry-After हेडर में बताती हैं कि दोबारा कब कोशिश करें।
मानक कोड नहीं। nginx इसका उपयोग आंतरिक रूप से बिना कोई जवाब भेजे कनेक्शन बंद करने के लिए करता है, अक्सर अनचाहे ट्रैफ़िक को रोकने के लिए; क्लाइंट को यह कोड वास्तव में कभी नहीं मिलता।
मानक कोड नहीं। सर्वर के जवाब देने से पहले क्लाइंट द्वारा कनेक्शन बंद करने पर nginx इसे लॉग करता है; जैसे, उपयोगकर्ता का धीमे पेज को रद्द करना या क्लाइंट की समय-सीमा समाप्त होना।
सर्वर में अप्रत्याशित त्रुटि आई और वह अनुरोध पूरा नहीं कर सका। बग, क्रैश या गलत कॉन्फ़िगरेशन की वजह से होने वाली सामान्य त्रुटि; अधिक जानकारी सर्वर लॉग में होती है।
गेटवे या प्रॉक्सी को अपस्ट्रीम सर्वर से अमान्य जवाब मिला। आम तौर पर ऐसा तब होता है, जब nginx या लोड बैलेंसर के पीछे मौजूद ऐप क्रैश हो गया हो या फिर से शुरू हो रहा हो।
सर्वर पर बहुत ज़्यादा भार होने या रखरखाव के लिए बंद होने के कारण वह अस्थायी रूप से अनुरोध संभाल नहीं सकता। Retry-After हेडर में दोबारा कोशिश करने का समय दिया हो सकता है।
गेटवे या प्रॉक्सी को अपस्ट्रीम सर्वर से समय पर जवाब नहीं मिला। ऐसा तब हो सकता है जब बैकएंड अनुरोध बहुत धीमा हो, जैसे लंबे समय तक चलने वाली डेटाबेस क्वेरी।
यह मानक कोड नहीं है। Cloudflare इसे तब लौटाता है, जब ओरिजिन सर्वर कनेक्शन से इनकार करता है। आम तौर पर ऐसा तब होता है, जब वेब सर्वर बंद हो या Cloudflare के IP पते ब्लॉक कर रहा हो।
यह मानक कोड नहीं है। Cloudflare इसे तब लौटाता है, जब वह ओरिजिन से कनेक्ट तो हो जाता है, लेकिन उसे तय समय में (डिफ़ॉल्ट रूप से 100 सेकंड) HTTP जवाब नहीं मिलता।
यह मानक कोड नहीं है। Cloudflare इसे तब लौटाता है, जब ओरिजिन का SSL प्रमाणपत्र अमान्य हो और Full (strict) SSL मोड चालू हो।
Cloudflare में परिभाषित
इस्तेमाल करने का तरीका
कोड नंबर डालें (जैसे 404 या सभी सर्वर एरर के लिए सिर्फ़ 5) या “redirect” या “timeout” जैसा कीवर्ड डालें।
क्लास फ़िल्टर से सूची को सीमित करें: जानकारी, सफलता, रीडायरेक्शन, क्लाइंट एरर या सर्वर एरर।
किसी भी कोड का सीधा लिंक साझा करने के लिए “लिंक कॉपी करें” इस्तेमाल करें, जैसे बग रिपोर्ट में।
यह कैसे काम करता है
हर HTTP रिस्पॉन्स तीन अंकों के स्टेटस कोड से शुरू होता है। पहला अंक उसकी श्रेणी बताता है: 1xx सूचना देने वाले रिस्पॉन्स, 2xx सफलता, 3xx रीडायरेक्शन, 4xx अनुरोध के कारण हुई त्रुटियाँ और 5xx सर्वर-साइड की त्रुटियाँ। जो क्लाइंट किसी विशिष्ट कोड को नहीं पहचानते, वे उसे उसकी श्रेणी के x00 कोड की तरह समझते हैं; इसलिए किसी अनजान 4xx कोड को 400 की तरह संभाला जाता है।
मुख्य कोड RFC 9110 (HTTP Semantics, 2022) में परिभाषित हैं, जिसने पुराने RFC 7231 की जगह ली। अन्य कोड एक्सटेंशन से आते हैं: WebDAV (RFC 4918), 428, 429, 431 और 511 के लिए RFC 6585, 451 के लिए RFC 7725 और 425 के लिए RFC 8470। RFC 9110 ने दो कोडों के नाम भी बदले: 413 अब “Content Too Large” है और 422 “Unprocessable Content” है। इनके पुराने नाम “Payload Too Large” और “Unprocessable Entity” भी अब तक दिख सकते हैं।
लॉग में दिखने वाले कुछ कोड मानक नहीं हैं। nginx आंतरिक रूप से 444 और 494–499 का इस्तेमाल करता है (499 का मतलब है कि क्लाइंट ने इंतज़ार करना छोड़ दिया), और जब Cloudflare को ओरिजिन सर्वर से सही जवाब नहीं मिल पाता, तो वह 520–526 लौटाता है। सूची में इन्हें “Non-standard” के रूप में चिह्नित किया गया है। कारण बताने वाले वाक्यांश (जैसे “Not Found”) विनिर्देशों में दिए गए अंग्रेज़ी रूप में दिखाए गए हैं; HTTP/2 और HTTP/3 में सिर्फ़ नंबर भेजा जाता है।
उदाहरण
साइट स्थानांतरित करते समय 301 या 308
दोनों स्थायी रीडायरेक्शन हैं। सामान्य पेज स्थानांतरण के लिए 301 इस्तेमाल करें; जब क्लाइंट को नए URL पर POST या PUT अनुरोध दोबारा भेजना ज़रूरी हो, तो 308 इस्तेमाल करें, क्योंकि कुछ क्लाइंट 301 के बाद POST को GET में बदल देते हैं।
401 और 403 में अंतर
जब टोकन न भेजा जाए या उसकी समय-सीमा समाप्त हो चुकी हो, तो API 401 लौटाता है; ऐसे में क्लाइंट को लॉग इन करना चाहिए। टोकन मान्य हो, लेकिन उपयोगकर्ता के पास अनुमति न हो, तो API 403 लौटाता है; ऐसे में दोबारा लॉग इन करने से मदद नहीं मिलेगी।
nginx के पीछे 502 की समस्या का पता लगाना
nginx से मिला 502 Bad Gateway का मतलब है कि उसके पीछे चल रहे ऐप्लिकेशन ने सही जवाब नहीं दिया। जाँचें कि ऐप प्रोसेस चल रही है या नहीं और उसके लॉग में क्या दर्ज है; 504 का मतलब है कि जवाब आने में बहुत देर हुई।
अक्सर पूछे जाने वाले सवाल
404 और 410 में क्या अंतर है?
404 का मतलब है कि सर्वर को रिसोर्स नहीं मिल रहा; इससे उसके भविष्य के बारे में कुछ नहीं पता चलता। 410 बताता है कि रिसोर्स जानबूझकर हटाया गया है और वापस नहीं आएगा, जिससे सर्च इंजन उस URL को जल्द हटाने में मदद मिलती है।
वैलिडेशन की गड़बड़ी पर 400 लौटाना चाहिए या 422?
दोनों का इस्तेमाल होता है। ऐसी रिक्वेस्ट के लिए 400 सही है जिसे सर्वर पार्स नहीं कर सकता, जैसे खराब JSON। 422 उन रिक्वेस्ट के लिए है जिन्हें सही ढंग से पार्स किया जा सकता है, लेकिन उनमें अमान्य वैल्यू होती हैं, जैसे @ के बिना ईमेल फ़ील्ड।
क्या 418 I'm a teapot सचमुच एक स्टेटस कोड है?
यह 1998 के अप्रैल फूल्स RFC से आया है। RFC 9110 में 418 को अप्रयुक्त रखा गया है, ताकि इसे किसी और चीज़ के लिए असाइन न किया जाए। कुछ सर्वर मज़ाक में इसे लौटाते हैं, लेकिन इसका कोई मानक अर्थ नहीं है।
499 कहाँ से आया?
499 केवल nginx में इस्तेमाल होता है। यह nginx लॉग में तब दिखता है, जब सर्वर के जवाब भेजने से पहले क्लाइंट कनेक्शन बंद कर देता है। क्लाइंट को 499 कभी नहीं मिलता; यह आमतौर पर धीमे जवाबों या क्लाइंट-साइड टाइमआउट की ओर इशारा करता है।
क्या सर्च इंजन 302 को 301 की तरह मानते हैं?
302 अस्थायी स्थानांतरण का संकेत देता है, इसलिए सर्च इंजन आमतौर पर शुरुआत में मूल URL को इंडेक्स में रखते हैं। अगर 302 लंबे समय तक लागू रहे, तो Google इसे स्थायी रीडायरेक्ट मान सकता है। स्थायी स्थानांतरण के लिए 301 या 308 इस्तेमाल करें।
गोपनीयता
यह सूची इसी पेज का हिस्सा है। खोज और फ़िल्टर आपके ब्राउज़र में होते हैं; आपके खोज शब्द कहीं भेजे नहीं जाते और एनालिटिक्स में शामिल नहीं होते।