HTTP स्थिति कोड: प्रत्येक संभावित कोड सूचीबद्ध

प्रकटीकरण: आपका समर्थन साइट को चालू रखने में मदद करता है! हम इस पृष्ठ पर हमारे द्वारा सुझाई गई कुछ सेवाओं के लिए एक रेफरल शुल्क कमाते हैं.


Contents

HTTP स्थिति कोड मूल बातें

ज्यादातर लोग यह नहीं सोचते हैं कि जब वे किसी वेब पेज पर जाते हैं तो वास्तव में क्या होता है। वे सिर्फ अपना ब्राउज़र खोलते हैं, कुछ क्लिक करते हैं, और वहाँ यह मेरी स्क्रीन पर है!

विशिष्ट कोड के लिए खोज रहे हैं? दाईं ओर सामग्री की तालिका देखें!

हम अपने कंप्यूटर के वेब ब्राउजर और सर्वर से दूर, किसी डेटा सेंटर में अनदेखी, (आमतौर पर) यहां तक ​​कि वेबसाइट के सिस्टम प्रशासक और आईटी कर्मचारियों द्वारा किए जा रहे अनुरोधों और प्रतिक्रियाओं के जटिल नृत्य के बारे में नहीं सोचना पसंद करते हैं.

लेकिन फिर, हर अब और फिर, हम एक त्रुटि में भागते हैं। हमें एक मजेदार तस्वीर के साथ एक चतुर 404 नॉट फाउंड पेज मिलता है। या हमें अपने स्वयं के ब्राउज़र से एक नोट के साथ एक खाली पृष्ठ मिलता है जो हमें किसी अज्ञात 501 त्रुटि के बारे में बताता है.

एक आकस्मिक वेबसाइट आगंतुक के रूप में, यह केवल कष्टप्रद है। हम आमतौर पर फिर से कोशिश करते हैं – ताज़ा करें, वापस जाएं, फिर से क्लिक करें। कभी-कभी यह काम करता है – हम कहते हैं कि एक गड़बड़ और तुरंत इसके बारे में भूल जाओ। कभी-कभी यह काम नहीं करता है – हम कहते हैं कि “एक बुरी वेबसाइट” और आमतौर पर इसके बारे में तुरंत भूल जाते हैं.

लेकिन अगर आप वास्तव में एक वेबसाइट चला रहे हैं – जो सब कुछ बदल देती है। HTTP त्रुटियां कष्टप्रद नहीं हैं। वे पागल हो रहे हैं। वे शर्मनाक हैं.

यदि आप विशेष रूप से तकनीकी जानकार हैं, या यदि आपके पास एक अच्छी आईटी टीम है, तो यह उतना बड़ा सौदा नहीं हो सकता है। इस तरह की अधिकांश समस्याएं ठीक करना आसान है। लेकिन अगर आप एक छोटे व्यवसाय के मालिक हैं, तो अपनी वेबसाइट चलाने के लिए, HTTP स्थिति और त्रुटि कोड आपको पागल बना सकते हैं.

आप HTTP त्रुटियों को कैसे ठीक करते हैं? आप HTTP त्रुटियों से कैसे बचते हैं? इन सभी HTTP स्टेटस कोड का क्या मतलब है, यहां तक ​​कि?

इस बारे में जानकारी के साथ ही यह मार्गदर्शिका शामिल है:

  • अच्छा HTTP स्टेटस कोड (जिन्हें आप आमतौर पर नहीं देखते हैं)
  • उपयोगी HTTP स्थिति कोड
  • आपको किस प्रकार का पुनर्निर्देश करना चाहिए (और क्यों).

लेकिन सबसे पहले, HTTP स्थिति कोड को समझने के लिए, आपको यह समझना होगा कि HTTP पहले स्थान पर कैसे काम करता है.

HTTP अनुरोध और प्रतिक्रियाएँ

HTTP का अर्थ “हाइपर टेक्स्ट ट्रांसफर प्रोटोकॉल” है।

क्या एक प्रोटोकॉल है?

जब आप एक नौसेना जहाज पर चढ़ते हैं, तो चीजों को करने का एक निश्चित तरीका होता है। पहले आप झंडे को सलामी देते हैं, फिर आप अधिकारी को ड्यूटी पर सलामी देते हैं, फिर आप बोर्ड की अनुमति मांगते हैं.

वह एक प्रोटोकॉल है.

एक प्रोटोकॉल एक निश्चित प्रकार के इंटरैक्शन के लिए नियमों का एक सेट है.

कभी-कभी एक प्रोटोकॉल बहुत कठोर और परिभाषित होता है:

  • जहाज पर चढ़ने के लिए:
    • झंडे को सलामी
    • ड्यूटी पर मौजूद अधिकारी
    • बोर्ड से अनुमति के लिए पूछें.

कभी-कभी प्रोटोकॉल थोड़ा शिथिल और अलिखित होते हैं, लेकिन फिर भी प्रसिद्ध होते हैं:

  • जब आपका जन्मदिन केक आता है:
    • गायकी खत्म करने के लिए सभी का इंतजार
    • एक इच्छा करें
    • मोमबत्तियों को बाहर उड़ा दें, अधिमानतः एक सांस में.

कंप्यूटर इंटरैक्शन सभी प्रोटोकॉल के बारे में हैं। जब दो कंप्यूटर (या कंप्यूटर का एक नेटवर्क) एक दूसरे से बात करते हैं, तो उनके पास संचार के लिए अच्छी तरह से परिभाषित नियमों का एक सेट होना चाहिए.

आपके स्थानीय कंप्यूटर का वेब ब्राउज़र वेब सर्वर के साथ कैसे संवाद करता है, जो उस साइट को होस्ट करता है जिसे आप देखने की कोशिश कर रहे हैं, HTTP (हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल) है।.

क्यों हम हाइपरटेक्स्ट स्थानांतरित कर रहे हैं?

मूल रूप से, वेब पेज मुख्य रूप से दस्तावेज थे। एक “वेब पेज” एक वास्तविक “पेज” के रूप में सोचा गया था। एक साइट दस्तावेजों का एक संग्रह थी। किसी साइट के लिए मुख्य पृष्ठ उपलब्ध दस्तावेजों का एक “सूचकांक” था.

किस प्रकार के दस्तावेज? हाइपरटेक्स्ट दस्तावेज़.

हाइपरटेक्स्ट का मतलब है कि दस्तावेज़ “हाइपरलिंक” के साथ एक दूसरे से लिंक होते हैं। आज हम उन्हें केवल पुराने-पुराने “लिंक” कहते हैं – वे अब इतने सामान्य हैं कि अब हम उन्हें “हाइपर” नहीं कहते हैं.

पाठ में क्लिक करने योग्य “हाइपर” लिंक – वह विचार, जो अब इतना सामान्य है, इतना क्रांतिकारी था जब पहली बार इनरनेट बनाया जा रहा था कि सब कुछ उसके नाम पर रखा गया था.

इन दस्तावेजों को संलेखन के लिए भाषा? हाइपरटेक्स्ट मार्कअप लैंग्वेज (HTML)। और इन दस्तावेजों के अनुरोध और प्राप्त करने के लिए प्रोटोकॉल? एचटीटीपी.

तो HTTP है …

HTTP नियमों और प्रक्रियाओं का एक सेट है कि कैसे एक वेब ब्राउज़र (या अन्य “क्लाइंट”) किसी अन्य कंप्यूटर (“सर्वर”) से संसाधनों का अनुरोध करता है, और कैसे अन्य कंप्यूटर उन अनुरोधों का जवाब देता है.

HTTP अनुरोध

इसलिए, जब आप एक पता लिखते हैं, तो एक लिंक पर क्लिक करें, या अन्यथा एक वेब पेज खोलें, आपका ब्राउज़र किसी अन्य सर्वर के लिए अनुरोध भेज रहा है.

अनुरोध का लक्ष्य URL और DNS सिस्टम द्वारा परिभाषित किया गया है। डीएनएस सिस्टम एक और दिन के लिए एक विषय है, लेकिन मूल रूप से – डीएनएस एक एड्रेस बुक है जो विशिष्ट कंप्यूटर आईपी पते के लिए डोमेन नामों से मेल खाती है.

अनुरोध का लक्ष्य डोमेन नाम द्वारा परिभाषित किया गया है, और संपूर्ण URL अनुरोध का सबसे महत्वपूर्ण हिस्सा है – डोमेन नाम के बाद सब कुछ सर्वर द्वारा अनुरोधित विशिष्ट संसाधन को बताता है। अनुरोध में अन्य जानकारी भी शामिल हैं:

  • अनुरोध प्रकार। दो सबसे आम हैं:
    • प्राप्त करें – “कृपया मुझे यह संसाधन भेजें।”
    • पोस्ट – “यहां कुछ डेटा प्रोसेस करना है।”
  • हेडर फ़ील्ड – वैकल्पिक मेटा डेटा फ़ील्ड क्लाइंट के बारे में सर्वर को बताता है (उदाहरण के लिए ब्राउज़र का प्रकार).
  • शरीर – ग्राहक द्वारा भेजा गया डेटा (POST के साथ उपयोग के लिए).

सर्वर को यह अनुरोध मिलता है और (कुछ प्रसंस्करण के बाद) एक प्रतिक्रिया भेजता है.

HTTP रिस्पांस

प्रतिक्रिया की पहली पंक्ति है HTTP स्थिति.

स्टेटस लाइन के दो भाग होते हैं, एक संख्या कोड (जैसे 200) और एक पाठ स्पष्टीकरण (जैसे सफलता).

जब सब कुछ ठीक काम करता है, तो आपको 200 मिलता है: सफलता की स्थिति (जिसे आप एक मानव उपयोगकर्ता के रूप में कभी नहीं देखते हैं), तो कुछ हेडर डेटा (जिसे आप भी नहीं देखते हैं), और फिर आपके द्वारा अनुरोधित संसाधन (जो आप देखते हैं वह है) ).

संसाधन एक संपूर्ण वेब पेज, एक छवि, एक वीडियो, एक ध्वनि फ़ाइल हो सकता है। यह कुछ ऐसी चीज भी हो सकती है, जिसे आप जावास्क्रिप्ट फाइल या स्टाइलशीट की तरह नहीं देख सकते.

जब चीजें इतनी अच्छी तरह से काम नहीं करती हैं, तो आप स्थिति के बारे में एक संदेश देख सकते हैं। आमतौर पर ऐसा तब होता है जब आपको 404 या 501 कोड जैसा कुछ मिलता है। वे त्रुटि कोड हैं। कुछ गलत हो गया.

404 या 501 त्रुटि कोड वाली प्रतिक्रियाएं आपके द्वारा अनुरोधित संसाधन के साथ वापस नहीं आती हैं। कभी-कभी वे एक अलग संसाधन (जैसे चतुर 404 पृष्ठ) के साथ वापस आते हैं। कभी-कभी कोई संसाधन नहीं होता है (जब आपको ब्राउज़र का रिक्त पृष्ठ और डिफ़ॉल्ट त्रुटि संदेश मिलता है).

स्टेटस कोड भी हैं जो ब्राउज़र को कहीं और देखने के लिए कहते हैं, जैसे 301 रीडायरेक्ट। ये प्रतिक्रियाएँ अनुरोधित संसाधन भी नहीं आती हैं.

इसके बजाय, हेडर डेटा ब्राउज़र को किसी अन्य URL के साथ एक नया अनुरोध करने के लिए कहता है। जब ऐसा होता है तो आप आमतौर पर नोटिस नहीं करते हैं, क्योंकि आपका ब्राउज़र वही करता है जो उसने बताया है और दूसरा अनुरोध करता है.

फिर यह आपको दूसरी प्रतिक्रिया से संसाधन दिखाता है, बिना यह बताए कि कुछ भी हुआ। रीडायरेक्ट प्रतिक्रिया कोड आमतौर पर उपयोगकर्ताओं को समाप्त करने के लिए महत्वपूर्ण नहीं है, लेकिन उन्हें वेबसाइट प्रशासकों के लिए बहुत मायने रखना चाहिए.

स्थिति कोड कक्षाएं

आपने शायद देखा है कि सभी स्थिति कोड तीन-अंकीय संख्या हैं। क्या आपने देखा कि पहला अंक हमेशा 1 और 5 के बीच होता है?

स्थिति कोडों को पाँच “वर्गों” कोड में बांटा गया है। 404: नहीं मिला त्रुटि स्थिति कोड के 400 (या, कभी-कभी, 4xx) वर्ग का हिस्सा है। प्रत्येक वर्ग मुद्दों या राज्यों की एक विशेष श्रेणी को शामिल करता है.

  • 1xx – सूचनात्मक – ये अनंतिम प्रतिक्रियाएं हैं जिनका उपयोग किया जाना है जबकि सर्वर अनुरोध को संसाधित करना जारी रखता है। वे शायद ही कभी इस्तेमाल किया जाता है.
  • 2xx – सफलता – जब उपयोग की जाने वाली चीजों के रूप में काम करने वाले कोड का उपयोग किया जाए। अलग-अलग सफलता कोड क्या, विशेष रूप से, अनुरोध करने के प्रयास के आधार पर वापस किए जाते हैं.
  • 3xx – पुनर्निर्देशन – कोड क्लाइंट को अनुरोधित संसाधन को कहीं और देखने के लिए कहते थे.
  • 4xx – क्लाइंट त्रुटि – ये कोड क्लाइंट को बताते हैं कि उसने कुछ गलत किया है.
  • 5xx – सर्वर त्रुटि – सर्वर पर कुछ के लिए कोड अपेक्षित रूप से काम नहीं कर रहा है.

हम प्रत्येक वर्ग से अपने स्वयं के वर्गों में अधिक गहराई से विशिष्ट कोड को कवर करेंगे.

HTTP स्थिति (और त्रुटि) कोड से निपटना

यह मार्गदर्शिका सभी संभावित HTTP स्टेटस और HTTP एरर कोड्स को कवर करती है – आम से लेकर कभी भी उपयोग नहीं किए जाने वाले। हम बताएंगे कि प्रत्येक कोड का क्या मतलब है, वे क्यों उत्पन्न हो रहे हैं, जब कोड एक समस्या हो सकती है, और समस्याओं से कैसे निपटना है.

HTTP स्थिति कोड 1xx – सूचनात्मक

ज्ञान ही शक्ति है। सूचना मुक्ति है.

—कोफी अन्नान

1xx वर्ग में HTTP स्थिति कोड अनंतिम होने का इरादा है, एक पूर्ण और पूर्ण दूसरी प्रतिक्रिया से पहले सर्वर द्वारा भेजा जाता है.

उन्हें HTTP / 1.1 में पेश किया गया था, इसलिए HTTP / 1.0 को लागू करने वाले शुरुआती ब्राउज़र उन्हें संभाल नहीं सकते हैं, और सर्वर को उन मामलों में 1xx कोड समाप्त नहीं करना चाहिए.

HTTP 100 जारी रखें

आमतौर पर अनुरोध-प्रतिक्रिया क्रम सीधा होता है। एक एकल अनुरोध किया जाता है, प्राप्त किया जाता है, और इसका जवाब दिया जाता है.

लेकिन कभी-कभी एक अनुरोध को भागों में तोड़ने की आवश्यकता होती है। यदि अनुरोध बहुत बड़ा है तो यह हो सकता है। यदि हेडर ठीक से स्वरूपित किया गया है, या सर्वर वास्तव में अनुरोध प्राप्त करने के लिए तैयार है या नहीं, तो यह हो सकता है कि रिक्वेस्टर की जरूरत है।.

इन मामलों में, क्लाइंट (ब्राउज़र) एक हेडर के साथ प्रारंभिक अनुरोध भेज सकता है जिसमें एक्सपेक्ट: 100-जारी है.

जब ऐसा होता है, तो सर्वर को प्रारंभिक अनुरोध प्राप्त होगा और – यदि सब कुछ ठीक है – 100 के साथ प्रतिक्रिया करें: स्थिति जारी रखें। यह क्लाइंट को अनुरोध पूरा करने के लिए संकेत देता है.

यदि सब कुछ ठीक नहीं है, तो सर्वर 417 उम्मीद विफलता वापस भेज देगा.

HTTP 101 स्विचिंग प्रोटोकॉल

एक क्लाइंट प्रोटोकॉल को स्विच करने के लिए पूछ सकता है, उदाहरण के लिए HTTP / 1.1 से HTTP / 2.0.

यदि सर्वर उस अनुरोध का अनुपालन करने के लिए तैयार है, तो यह प्रतिक्रिया 101 को वापस भेज देगा: प्रोटोकॉल स्विच करना, हेडर डेटा के साथ जिसमें नए प्रोटोकॉल का नाम शामिल है।.

HTTP 102 प्रोसेसिंग

इस कोड का उपयोग केवल WebDAV के साथ किया जाता है, जो HTTP का एक विस्तार है जो फ़ाइल हेरफेर की क्षमता प्रदान करता है, जो कुछ हद तक FTP के समान है (हालांकि वास्तविक कार्यान्वयन में बहुत अलग है).

WebDAV अनुरोध में बहुत सारे उप-अनुरोध शामिल हो सकते हैं। 102: प्रोसेसिंग स्टेटस से क्लाइंट को पता चलता है कि सर्वर को रिक्वेस्ट मिली है और वह इस पर काम कर रहा है, लेकिन अभी भी काम करना बाकी है। यह क्लाइंट को यह मानने से रोकता है कि अनुरोध खो गया था और समय समाप्त हो गया था.

HTTP स्थिति कोड 2xx – सफलता

इस जीवन में आपको केवल अज्ञानता और आत्मविश्वास की आवश्यकता है, और फिर सफलता सुनिश्चित है.

-मार्क ट्वेन

2xx वर्ग में HTTP स्थिति कोड का उपयोग तब किया जाता है जब कोई अनुरोध पूरा हो गया हो.

इनमें से कई कोड कभी नहीं, या शायद ही कभी, वास्तव में उपयोग किए जाते हैं, या लागू भी होते हैं.

HTTP 200 ठीक है

यह सफल अनुरोधों के लिए मानक प्रतिक्रिया है – यह वह स्थिति कोड है जिसे आप आमतौर पर चाहते हैं और अपेक्षा करते हैं.

जब अनुरोध GET (संसाधन के लिए पूछ रहा है) हो, तो प्रतिक्रिया में संसाधन शामिल होगा। जब अनुरोध एक POST (या अन्य प्रकार) है, तो प्रतिक्रिया में एक संसाधन शामिल होगा जो कार्रवाई का परिणाम बताता है या उसमें शामिल है.

HTTP 201 बनाया गया

कुछ अनुरोधों का उद्देश्य एक नया संसाधन बनाना है। जब ये सफलतापूर्वक पूर्ण हो जाते हैं, तो 201 स्थिति को यह इंगित करने के लिए भेजा जाता है कि नया संसाधन बनाया गया है। यह आमतौर पर PUT अनुरोध प्रकार के साथ संयोजन में उपयोग किया जाता है.

HTTP 202 स्वीकृत

अनुरोध स्वीकार कर लिया गया है, लेकिन कार्रवाई नहीं की गई है। अनुरोध पर कार्रवाई की जा सकती है या नहीं.

HTTP 203 गैर-आधिकारिक सूचना

प्रतिक्रिया में अनुरोधित संसाधन शामिल हैं, लेकिन संसाधन किसी अन्य स्रोत से प्राप्त किया जा सकता है, और इसलिए अविश्वसनीय हो सकता है – सर्वर संसाधन की वैधता या प्रामाणिकता के लिए वाउचर नहीं कर रहा है.

HTTP 204 कोई सामग्री नहीं

यह तब भेजा जाता है जब सर्वर ने अनुरोध को सफलतापूर्वक संसाधित किया है, लेकिन किसी भी सामग्री को वापस करने की आवश्यकता नहीं है। ज्यादातर, यह एक DELETE अनुरोध के परिणाम के रूप में होता है.

जब 204 अनुरोध भेजा जाता है, तो उपयोगकर्ता एजेंट (क्लाइंट या वेब ब्राउज़र) को विशेष रूप से अपना दृष्टिकोण बदलना नहीं चाहिए.

उदाहरण के लिए, यदि अनुरोध को पृष्ठ पर फ़ॉर्म के माध्यम से भेजा गया था, तो प्रतिक्रिया के कारण फ़ॉर्म को ताज़ा नहीं होना चाहिए या ब्राउज़र को किसी अन्य पृष्ठ पर जाने के लिए – उपयोगकर्ता में मौजूदा सामग्री को बदलने के अनुरोध में कोई नई सामग्री नहीं है राय.

HTTP 205 रीसेट सामग्री

205 की प्रतिक्रिया 204 के समान है, लेकिन उपयोगकर्ता एजेंट को वर्तमान दस्तावेज़ की डिफ़ॉल्ट स्थिति को वापस देखने के लिए माना जाता है.

HTTP 206 आंशिक सामग्री

इसका उपयोग तब किया जाता है जब सर्वर केवल अनुरोधित संसाधन के एक हिस्से को भेज रहा होता है, क्योंकि उपयोगकर्ता केवल संसाधन के एक हिस्से को प्राप्त करने का अनुरोध करता है.

यह तब होता है जब एक संसाधन पर्याप्त बड़ा होता है, या कनेक्शन अविश्वसनीय रूप से पर्याप्त होता है, जो कि उपयोगकर्ता एजेंट संसाधन को “chunked” अनुरोधों की एक श्रृंखला में विभाजित करना चाहता है, जैसा कि चित्र में दिखाया गया है:

  • ग्राहक: मुझे पहले १/४ दे दो.
    • सर्वर: 206 आंशिक सामग्री
  • ग्राहक: मुझे दूसरा दे दो

    1/4.

    • सर्वर: 206 आंशिक सामग्री.
  • और इसी तरह…
    • …इत्यादि.

ये आंशिक अनुरोध क्लाइंट द्वारा श्रेणी हेडर का उपयोग करके किए जाते हैं। वे एक के बाद एक हो सकते हैं (डाउनलोड विफलता के खिलाफ गार्ड करने के लिए), या सभी एक साथ कई थ्रेड्स में (डाउनलोड को गति देने के लिए).

HTTP 207 मल्टी-स्टेटस

103 की तरह, यह केवल WebDAV के साथ प्रयोग किया जाता है.

एक WebDAV अनुरोध में कई उप अनुरोध हो सकते हैं, प्रत्येक की अपनी स्थिति और प्रतिक्रिया हो सकती है। 207 स्थिति इंगित करती है कि प्रतिक्रिया के मुख्य भाग में प्रत्येक उप-अनुरोध की स्थिति और प्रतिक्रियाओं का विवरण देने वाला XML दस्तावेज़ शामिल होगा.

HTTP 208 पहले से ही रिपोर्ट की गई

एक अन्य WebDAV- केवल स्थिति कोड। इसका मतलब यह है कि DAV बाइंडिंग के सदस्यों को वर्तमान अनुरोध के पिछले उत्तर में पहले ही गणना की जा चुकी है, और उन्हें फिर से शामिल किया जा रहा है.

HTTP 226 IM उपयोग किया जाता है

सर्वर ने संसाधन के लिए एक अनुरोध पूरा किया है, और प्रतिक्रिया वर्तमान उदाहरण पर लागू एक या अधिक उदाहरण-जोड़तोड़ के परिणाम का प्रतिनिधित्व है.

HTTP स्थिति कोड 3xx – पुनर्निर्देशन

जब भी आप किसी चीज को छोड़ते हैं, तो आपको उसे किसी चीज से बदलना चाहिए.

-लॉ होल्त्ज़

अनुरोध को पूरा करने के लिए क्लाइंट की ओर से अतिरिक्त कार्रवाई की आवश्यकता होने पर 3xx वर्ग में स्टेटस भेजे जाते हैं। यह आमतौर पर एक URL को दूसरे में रीडायरेक्ट करने के लिए उपयोग किया जाता है, हालांकि हमेशा नहीं.

GET अनुरोधों के मामले में, ब्राउज़र आमतौर पर उपयोगकर्ता से किसी भी इनपुट या अतिरिक्त इंटरैक्शन के बिना दूसरा अनुरोध करेगा। अन्य मामलों में, अतिरिक्त उपयोगकर्ता के हस्तक्षेप की आवश्यकता है.

अनंत पुनर्निर्देशन छोरों से बचने के लिए, आमतौर पर ब्राउज़र एक ही अनुरोध के पांच से अधिक क्रमिक पुनर्निर्देशन का पालन नहीं करेंगे.

HTTP 300 बहुविकल्पी

जब संसाधन के लिए कई विकल्पों में परिणाम का अनुरोध होता है, तो ब्राउज़र द्वारा 300 स्थिति लौटा दी जाती है। सिद्धांत रूप में, इसका उपयोग विभिन्न फ़ाइल प्रारूप विकल्पों, एक ही सामग्री के विभिन्न मीडिया प्रस्तुतियों, या यहां तक ​​कि शब्द बोध भंग करने के लिए भी किया जा सकता है।.

300 मल्टीपल चॉइस स्थिति में बहुत अधिक क्षमता है, लेकिन अक्सर इसका उपयोग नहीं किया जाता है.

HTTP 301 ने स्थायी रूप से स्थानांतरित कर दिया

यह स्थिति इंगित करती है कि संसाधन स्थायी रूप से URL बदल गया है.

खोज इंजन इसके आधार पर अपने सूचकांक को अपडेट करते हैं, आमतौर पर मूल URL से नए URL पर कोई रैंकिंग प्रदान करते हैं.

ब्राउज़रों और अन्य प्रकार के क्लाइंट अक्सर नए URL को कैश करते हैं और बाद के अनुरोधों के लिए मूल की सीधे जाँच किए बिना स्वचालित रूप से रीडायरेक्ट URL का अनुसरण करते हैं, भले ही मूल URL मैन्युअल रूप से आपूर्ति की गई हो। सहेजे गए बुकमार्क भी आमतौर पर अपडेट किए जाते हैं.

आम तौर पर, यदि आप URL संरचना के डोमेन नाम में बदलाव के कारण रीडायरेक्ट सेट कर रहे हैं, तो आपको 301 का उपयोग करना चाहिए: मूव किए हुए स्थायी रीडायरेक्ट.

इन्हें आपके सर्वर पर .htaccess या httpd.conf फ़ाइल में या अक्सर आपके सामग्री प्रबंधन प्रणाली में सेट किया जा सकता है। (उदाहरण के लिए, 301 रीडायरेक्ट को प्रबंधित करने के लिए कई वर्डप्रेस प्लगइन्स हैं।)

जब किसी वेबसाइट को नया रूप दिया जाता है और एक URL संरचना बदली जाती है, तो मूल साइट से प्रत्येक URL के लिए 301 पुनर्निर्देशित करना बहुत महत्वपूर्ण है। ऐसा करने में विफलता के कारण टूटे हुए लिंक और निराश आगंतुक होंगे.

HTTP 302 मिला

302 स्थिति कोड का उपयोग आमतौर पर अस्थायी रीडायरेक्ट के लिए किया जाता है। 301 रीडायरेक्ट वाले उद्योग अभ्यास में मूल विनिर्देश से भिन्न है, और उद्योग अभ्यास को पूरा करने के लिए विनिर्देश विकसित हुआ है.

मूल रूप से, विनिर्देश ने कहा कि 302 स्थिति के कारण ब्राउज़र को नए URL के लिए दूसरा, समान अनुरोध करना चाहिए। हालाँकि, कई प्रथम-पीढ़ी के वेब ब्राउज़रों ने इसे इस तरह से लागू किया कि पोस्ट अनुरोध GET अनुरोधों के रूप में फिर से लिखे गए.

स्थिति को स्पष्ट करने का प्रयास करने के लिए, अद्यतन विनिर्देश HTTP / 1.1 ने दो अतिरिक्त स्थिति कोड, 303 और 307 जोड़े.

302 पाया गया था कि “GET के लिए स्विच” व्यवहार की नकल की गई थी, जबकि 307 अस्थायी रीडायरेक्ट का उद्देश्य मूल 302 अपेक्षित व्यवहार को बदलना था।.

हालाँकि, अधिकांश सर्वर और वेब फ्रेमवर्क ने नए ब्राउज़रों को लागू करने वाले ब्राउज़रों के साथ पीछे की संगतता के लिए 302 का उपयोग करना जारी रखा.

बाद में HTTP विनिर्देश मानक अभ्यास से परिचित हो गए, जिससे ब्राउज़र को GET अनुरोधों के लिए POST अनुरोधों को फिर से लिखने की अनुमति मिली.

इस सबका परिणाम यह है कि यदि आप एक URL पर 302 रीडायरेक्ट का उपयोग कर रहे हैं, जिसे POST डेटा स्वीकार करना था, तो संभवतः वह डेटा दूसरे अनुरोध में शामिल नहीं होगा.

इस कारण से, 302 का उपयोग केवल उन URL पर किया जाना चाहिए जो POST डेटा (वेब ​​फॉर्म) को स्वीकार करते हैं यदि सर्वर वास्तव में मूल URL पर सबमिट किए गए डेटा को स्वीकार कर सकता है, और डेटा स्वीकार किए जाने के बाद पृष्ठ को डिलीवर करने के लिए रीडायरेक्ट का उपयोग कर सकता है।.

यह सब, व्यवहार में, 303 को बेमानी बनाता है.

आम तौर पर, 302 रीडायरेक्ट का उपयोग नहीं किया जाना चाहिए

HTTP 303 अन्य देखें

व्यवहार में, यह 302 स्थिति के समान है। इसका मतलब है कि प्रतिक्रिया या संसाधन किसी अन्य URL पर GET विधि का उपयोग करके पाया जा सकता है। POST अनुरोध के जवाब में प्राप्त होने पर, ब्राउज़र को यह मान लेना चाहिए कि डेटा प्राप्त हो गया है.

HTTP 304 संशोधित नहीं है

वेब ब्राउज़र एक हेडर के साथ एक अनुरोध भेज सकता है जो पूछता है कि क्या किसी विशेष डेटा और समय के बाद एक संसाधन को संशोधित किया गया है। यह तब किया जाता है जब ब्राउज़र ने पहले ही संसाधन डाउनलोड कर लिया हो और उसे सहेज लिया हो.

यदि यह उस समय से संशोधित किया गया है, तो सर्वर संसाधन और 200 सफलता की स्थिति के साथ जवाब देगा.

यदि, हालाँकि, संसाधन को संशोधित नहीं किया गया है, तो सर्वर 304 स्थिति को संशोधित नहीं करेगा और संसाधन को भी नहीं भेजा जाएगा। ब्राउज़र को तब संसाधन के सहेजे गए संस्करण की सेवा देनी चाहिए, क्योंकि यह परिवर्तित नहीं हुआ है.

HTTP 305 प्रॉक्सी का उपयोग करें

अनुरोधित संसाधन केवल प्रॉक्सी के माध्यम से उपलब्ध है। प्रतिक्रिया में प्रॉक्सी का पता प्रदान किया गया है। वेब ब्राउज़र को प्रॉक्सी के माध्यम से अनुरोध को पुनः प्राप्त करने की उम्मीद है। सभी ग्राहक मानक के अनुसार इसे लागू नहीं करते हैं, क्योंकि सुरक्षा कारणों से.

HTTP 306 स्विच प्रॉक्सी

मूल रूप से 306 स्थिति का अर्थ है “बाद के अनुरोधों को निर्दिष्ट प्रॉक्सी का उपयोग करना चाहिए।” यह अब उपयोग में नहीं है.

HTTP 307 अस्थायी पुनर्निर्देश

यह स्थिति 302 स्थिति के मूल इरादे को दोहराने के लिए बनाई गई थी (ऊपर देखें).

307: अस्थायी पुनर्निर्देशित स्थिति का अर्थ है कि अनुरोध को इस बार किसी अन्य URL के साथ दोहराया जाना चाहिए, लेकिन भविष्य में, हालांकि, अनुरोधों को अभी भी मूल URL का उपयोग करना चाहिए.

302 ऐतिहासिक रूप से ग्राहकों द्वारा कैसे लागू किया गया है, इसके विपरीत, दूसरा अनुरोध भेजते समय अनुरोध विधि को नहीं बदला जाना चाहिए। उदाहरण के लिए, एक POST अनुरोध को दूसरे POST अनुरोध का उपयोग करके दोहराया जाना चाहिए, और सभी मूल POST डेटा के साथ.

HTTP 308 स्थायी पुनर्निर्देश

वर्तमान अनुरोध को दूसरे URL का उपयोग करके दोहराया जाना चाहिए, और भविष्य के सभी अनुरोधों को उस URL पर भी भेजा जाना चाहिए.

307 और 302 की तरह, यह स्थिति 301 के मूल विनिर्देश में निर्दिष्ट कार्यक्षमता को दोहराती है। 308 के साथ, हालांकि, (307 के साथ) दूसरा अनुरोध मूल अनुरोध के समान होना चाहिए – एक ही विधि का उपयोग करना और एक ही डेटा युक्त होना.

HTTP 308 फिर से शुरू करें

यह स्थिति कोड Google द्वारा बनाया और उपयोग किया जाता है। यह फिर से शुरू करने योग्य HTTP रिक्वेस्ट प्रपोजल का एक हिस्सा है, और इसका उपयोग PUT या POST अनुरोधों को फिर से शुरू करने के लिए किया जाता है.

HTTP स्थिति कोड 4xx – क्लाइंट त्रुटि

कोई भी गलती कर सकता है, लेकिन केवल एक बेवकूफ गलती में बनी रहती है.

—मर्कस टुलियस सिसेरो

HTTP स्टेटस कोड्स के पाँच वर्गों में से, उनमें से केवल दो ही “एरर कोड”, 4xx और 5xx वर्ग हैं.

HTTP त्रुटियों की 4xx श्रृंखला का उपयोग तब किया जाता है जब क्लाइंट से त्रुटि आ रही लगती है – अर्थात अनुरोध के साथ कुछ है.

त्रुटि स्थिति और अन्य हेडर जानकारी के साथ, सर्वर अक्सर एक पूर्ण प्रतिक्रिया प्रदान करते हैं (जिसे “संसाधन” के बजाय “इकाई” कहा जाता है, लेकिन अन्यथा वही) जो उपयोगकर्ता को प्रदर्शित किया जाना चाहिए.

इसका उद्देश्य उपयोगकर्ता को क्लाइंट त्रुटि जो भी हो उसे ठीक करने का तरीका प्रदान करना है। इन संस्थाओं का सबसे अधिक देखा जाने वाला रूप 404 पृष्ठ है, जिसकी चर्चा नीचे की गई है.

HTTP 400 खराब अनुरोध

यह कुछ समस्या के अनुरोध के लिए एक सामान्य प्रतिक्रिया है। समस्या विकृत सिंटैक्स, अमान्य स्वरूपण या भ्रामक अनुरोध रूटिंग हो सकती है। सर्वर अक्सर इस बारे में अतिरिक्त जानकारी प्रदान करेंगे कि विशेष रूप से अनुरोध के साथ क्या गलत हुआ.

HTTP 401 अनधिकृत

इसका उपयोग तब किया जाता है जब संसाधन कुछ प्रमाणित उपयोगकर्ताओं के लिए प्रतिबंधित होता है। स्टेटस का अर्थ है कि वापस लेने से कोई प्रमाणीकरण नहीं हुआ है, या वह प्रमाणीकरण विफल हो गया है। मानक के अनुसार, इस कोड के साथ एक प्रतिक्रिया को प्रमाणीकरण के एक साधन को शामिल करना चाहिए.

HTTP 402 भुगतान आवश्यक है

आमतौर पर उपयोग नहीं किया जाता है, क्योंकि विनिर्देश एक वर्तमान कार्यान्वयन के लिए पर्याप्त जानकारी प्रदान नहीं करता है (इसे नाम दिया गया है और भविष्य के उपयोग के लिए आरक्षित है, लेकिन एक पूर्ण कल्पना नहीं अपनाया गया है).

इस कोड का उपयोग कुछ प्रकार के डिजिटल कैश या माइक्रोएमेंट सिस्टम के हिस्से के रूप में करने का इरादा है.

यदि वे एक ही आईपी पते से बहुत अधिक अनुरोध प्राप्त करते हैं तो YouTube इस स्थिति का उपयोग करता है। प्रतिक्रिया के लिए उपयोगकर्ता को सत्यापित करने के लिए कैप्चा की आवश्यकता होती है जो एक मानव है.

HTTP 403 निषिद्ध

401 के समान, इसका मतलब है कि अनुरोध मान्य था, लेकिन सर्वर इसका जवाब नहीं देगा क्योंकि उपयोगकर्ता के पास संसाधन देखने की अनुमति नहीं है। 401 के विपरीत: अनधिकृत त्रुटि, प्रमाणीकरण से कोई फर्क नहीं पड़ेगा.

HTTP 404 नहीं मिला

यह सबसे अधिक देखा जाने वाला 4xx वर्ग त्रुटि है, और शायद औसत उपयोगकर्ता के लिए सबसे अधिक देखा जाने वाला HTTP स्थिति है.

यदि अनुरोध मान्य है, तो 404 लौटा दिए जाते हैं, लेकिन अनुरोधित संसाधन को सर्वर पर नहीं पाया जा सकता है.

अधिकांश वेब फ्रेमवर्क वेबसाइट व्यवस्थापक को “404 पेज” बनाने की क्षमता देते हैं। यह एक ऐसा पृष्ठ है जिसे उपयोगकर्ता 404 त्रुटि होने पर देखता है.

आमतौर पर, यह समस्या के उपयोगकर्ता को सूचित करता है, असुविधा के लिए माफी मांगता है, और उस सामग्री को खोजने के वैकल्पिक तरीके प्रदान करता है जिसे उपयोगकर्ता खोज रहा है, जैसे कि खोज.

कुछ वेबसाइट अनुरोध URL में किसी भी कीवर्ड को देखती हैं और यह निर्धारित करने का प्रयास करती हैं कि उपयोगकर्ता किस पेज या संसाधन को देख रहा है और वैकल्पिक पृष्ठों के लिए एक या अधिक विकल्प प्रदान कर सकता है।.

भले ही 4xx त्रुटियां तकनीकी रूप से “क्लाइंट त्रुटियां” हों, 404 त्रुटि अक्सर मृत लिंक का एक परिणाम है – URL जिसमें पहले सामग्री थी लेकिन अब बदल गई है.

इस कारण से, 404 पृष्ठ वितरित करना वेबसाइटों के लिए थोड़ा शर्मनाक हो सकता है, क्योंकि अक्सर इसका अर्थ है उचित URL पुनर्निर्देशन प्रदान करने में विफलता। निहितार्थ यह नहीं है कि “आपने अपना अनुरोध गड़बड़ कर दिया है,” बल्कि “हमने वह चीज़ खो दी है जिसकी आप तलाश कर रहे हैं।”

इस वजह से, वेबसाइटों के लिए अपने 404 पेजों को हास्य के लिए एक जगह में बदलना बहुत आम है.

HTTP 405 विधि अनुमति नहीं है

यह तब उपयोग किया जाता है जब अनुरोध अच्छी तरह से बनता है और जिस संसाधन के लिए पूछता है वह मौजूद है, लेकिन अनुरोध विधि (जैसे कि GET या POST) संसाधन के लिए उपयुक्त नहीं है.

उदाहरण के लिए, प्रपत्र डेटा प्राप्त करने वाले URL को POST अनुरोध के साथ एक्सेस किया जाना चाहिए। GET अनुरोध के परिणामस्वरूप 405 हो सकता है: विधि अनुमति नहीं है प्रतिक्रिया। पुत का उपयोग केवल पढ़ने के लिए संसाधन पर भी ऐसी प्रतिक्रिया हो सकती है.

HTTP 406 स्वीकार्य नहीं है

अनुरोध, और अक्सर करते हैं, MIME प्रकारों का उपयोग करके वे जिस प्रकार की सामग्री की तलाश कर रहे हैं, उसे निर्दिष्ट करते हैं.

यदि अनुरोधित संसाधन एक प्रकार का है जो अनुरोध के स्वीकार शीर्षलेख में सूचीबद्ध प्रकार (ओं) से मेल नहीं खाता है, तो सर्वर 406 लौटाएगा: स्वीकार्य त्रुटि नहीं.

HTTP 407 प्रॉक्सी प्रमाणीकरण आवश्यक है

अनुरोधित संसाधन तक पहुंच दिए जाने से पहले, ग्राहक को पहले प्रतिक्रिया में निर्दिष्ट प्रॉक्सी के साथ खुद को प्रमाणित करना होगा.

HTTP 408 अनुरोध टाइमआउट

यह त्रुटि तब होती है जब अनुरोध का इंतजार करते समय सर्वर बाहर निकल जाता है.

विनिर्देशन से:

क्लाइंट ने उस समय के भीतर अनुरोध का उत्पादन नहीं किया, जिसके लिए सर्वर प्रतीक्षा करने के लिए तैयार था। ग्राहक किसी भी समय बाद में संशोधन के बिना अनुरोध दोहरा सकता है.

HTTP 409 संघर्ष

इंगित करता है कि अनुरोध संसाधित नहीं किया जा सका क्योंकि यह स्वयं के साथ विरोध करता है। यह हो सकता है, उदाहरण के लिए, कई अद्यतनों के मामले में जो एक दूसरे के साथ संपादित संघर्ष का कारण बनते हैं.

HTTP 410 गॉन

यह त्रुटि 404 त्रुटि के समान है, लेकिन यह इंगित करने का इरादा है कि अनुरोधित संसाधन को जानबूझकर हटा दिया गया है और अब आपके URL पर उपलब्ध नहीं होगा.

संसाधन को शुद्ध करके ग्राहकों को इस प्रतिक्रिया पर प्रतिक्रिया करनी चाहिए – बुकमार्क को हटा दिया जाना चाहिए और खोज इंजनों को अपने सूचकांक से संसाधन को हटा देना चाहिए.

अधिकांश उपयोग मामलों को इसकी आवश्यकता नहीं होती है, और 404 आमतौर पर एक अधिक उपयुक्त त्रुटि है.

HTTP 411 लंबाई आवश्यक है

अनुरोधित संसाधन के लिए अनुरोध है कि अनुरोध उनकी लंबाई निर्दिष्ट करें, और अनुरोध ऐसा नहीं किया.

HTTP 412 पूर्वधारणा विफल

अनुरोधकर्ता ने अनुरोध के शीर्षक में पूर्व शर्त या आवश्यकताओं को रखा, और सर्वर उन आवश्यकताओं में से एक या अधिक को पूरा करने में असमर्थ है.

HTTP 413 रिक्वेस्ट एंटिटी बहुत बड़ी

अनुरोध सर्वर से संसाधित होने की तुलना में बड़ा है.

HTTP 414 अनुरोध-URI बहुत लंबा

सर्वर को संसाधित करने के लिए प्रदान किया गया URI (URL) बहुत लंबा था.

यह अक्सर तब होता है जब GET अनुरोध में डेटा की अनुचित मात्रा को URL में क्वेरी स्ट्रिंग के रूप में बताया जा रहा है। सामान्य उपाय अनुरोध को POST में बदलना और डेटा को अनुरोध के निकाय में रखना है.

HTTP 415 असमर्थित मीडिया प्रकार

यह आमतौर पर फ़ाइल अपलोड के लिए उपयोग किया जाता है, जब अनुरोध इकाई (अपलोड की जा रही फ़ाइल) सर्वर द्वारा समर्थित नहीं प्रकार का होता है.

HTTP 416 अनुरोधित सीमा संतोषजनक नहीं है

रेंज हेडर का उपयोग करके फ़ाइल के एक हिस्से के लिए अनुरोध करने पर यह वापस कर दिया जाता है, लेकिन अनुरोधित भाग मौजूद नहीं होता है। उदाहरण के लिए, यदि अनुरोध फ़ाइल के एक हिस्से के लिए पूछता है जो फ़ाइल के अंत से परे है.

HTTP 417 अपेक्षा विफल

यह स्थिति सर्वर द्वारा लौटा दी जाती है यदि यह अनुरोध में अपेक्षित शीर्ष लेख द्वारा निर्धारित अपेक्षा को पूरा नहीं कर सकता है.

100 शीर्ष स्थिति के लिए सर्वर से पूछने के लिए उम्मीद हैडर का सबसे अधिक उपयोग किया जाता है.

HTTP 418 मैं एक चायदानी हूँ

यह त्रुटि कोड इंटरनेट से जुड़े चायदानी द्वारा लौटाया जाता है, इस घटना में उन्हें कॉफी के लिए अनुरोध भेजा जाता है.

HTTP 419 ऑथेंटिकेशन टाइमआउट

यह वास्तव में HHTP मानक का हिस्सा नहीं है, लेकिन कुछ क्लाइंट और सर्वर इसका उपयोग करते हैं। यह तब लौटाया जाता है जब किसी अनुरोधकर्ता को एक प्रमाणित उपयोगकर्ता की आवश्यकता होती है जिसे एक अनुरोधकर्ता द्वारा भेजा जाता है जिसका प्रमाणीकरण समाप्त हो गया है.

HTTP 420 विधि विफलता (स्प्रिंग फ्रेमवर्क)

HTTP मानक का हिस्सा नहीं है, लेकिन स्प्रिंग द्वारा उनके वेब ढांचे में परिभाषित किया गया है, जब एक विधि विफल हो गई थी। यह पदावनत है.

HTTP 420 अपना कलमा बढ़ाएँ (ट्विटर)

HTTP मानक का हिस्सा नहीं है, लेकिन ट्विटर द्वारा पेश किया गया है। इसका उपयोग उनके एपीआई के संस्करण 1 द्वारा किया गया था जब किसी विशेष ग्राहक से अनुरोध दर सीमित किया जा रहा था.

ऐसी स्थिति के लिए अधिक मानक स्थिति 429 है: बहुत सारे अनुरोध.

HTTP 421 गलत अनुरोधित

यह स्थिति HTTP / 2 में पेश की गई थी। इसका उपयोग तब किया जाता है जब अनुरोध एक सर्वर पर निर्देशित किया गया था जो वर्तमान में प्रतिक्रिया उत्पन्न करने में सक्षम नहीं है.

HTTP 422 असंगत एंटिटी

यह वेस्डएवी एक्सटेंशन से संबंधित है। यह तब लौटाया जाता है जब शब्दार्थ त्रुटियां अनुरोध को अप्राप्य बना देती हैं.

HTTP 423 लॉक किया गया

वेस्डएवी के साथ उपयोग किया जाता है। इसका मतलब है कि अनुरोधित संसाधन लॉक है.

HTTP 424 असफलता निर्भरता

WebDav के साथ प्रयोग किया जाता है। पिछला अनुरोध विफल हो गया क्योंकि पिछला अनुरोध, जिस पर वर्तमान अनुरोध निर्भर है, विफल रहा.

HTTP 426 अपग्रेड आवश्यक है

क्लाइंट को एक अलग प्रोटोकॉल पर स्विच करना चाहिए, जैसा कि अपग्रेड हेडर में निर्दिष्ट है.

HTTP 428 पूर्व शर्त

इसका उपयोग तब किया जाता है जब सर्वर को अनुरोध करना पड़ता है कि अनुरोध सशर्त हो.

उदाहरण के लिए, सर्वर को आवश्यकता हो सकती है कि अनुरोध में एक शर्त है कि अनुरोध को केवल तभी संसाधित किया जाना चाहिए जब किसी विशेष तिथि और समय के बाद संसाधन को अपडेट नहीं किया गया हो। यदि कोई शर्त निर्दिष्ट नहीं है, तो अनुरोध विफल हो जाता है और यह स्थिति वापस आ जाती है.

विनिर्देश के अनुसार, यह स्थिति “खोई हुई अद्यतन” समस्या को रोकने के उद्देश्य से थी, जहाँ एक ग्राहक एक संसाधन की स्थिति प्राप्त करता है, इसे संशोधित करता है, और इसे सर्वर पर वापस लाता है, जब इस बीच किसी तृतीय पक्ष ने सर्वर पर राज्य को संशोधित किया है , एक संघर्ष के लिए अग्रणी।

HTTP 429 बहुत सारे अनुरोध

क्लाइंट (आमतौर पर आईपी पते द्वारा परिभाषित) ने एक निर्दिष्ट अवधि के भीतर बहुत सारे अनुरोध भेजे हैं.

HTTP 431 रिक्वेस्ट हैडर फील्ड्स बहुत बड़ा है

यह तब लौटाया जाता है जब एक ही हेडर फील्ड या उनमें से सभी सामूहिक रूप से सर्वर पर प्रोसेस करने के लिए बहुत बड़े होते हैं.

HTTP 440 लॉगिन टाइमआउट (Microsoft)

मानक का हिस्सा नहीं है, लेकिन Microsoft द्वारा उपयोग किया जाता है। इंगित करता है कि सत्र समाप्त हो गया है.

HTTP 444 कोई प्रतिक्रिया नहीं (Nginx)

मानक का हिस्सा नहीं है। वास्तव में उपयोग के रूप में प्रतिक्रिया की स्थिति नहीं.

यह उनके सर्वर लॉग के लिए Nginx द्वारा पेश किया गया था, यह इंगित करने के लिए कि सर्वर ने बस एक प्रतिक्रिया नहीं भेजी और कनेक्शन बंद कर दिया, आमतौर पर एक संदिग्ध मैलवेयर हमले की स्थिति में.

HTTP (449) Microsoft के साथ पुन: प्रयास करें

मानक का हिस्सा नहीं है, लेकिन Microsoft द्वारा उपयोग किया जाता है.

प्रतिक्रिया में वर्णित कार्रवाई करने के बाद अनुरोध को वापस लिया जाना चाहिए.

HTTP 450 विंडोज पेरेंटल कंट्रोल (Microsoft) द्वारा अवरुद्ध

मानक का हिस्सा नहीं है, लेकिन Microsoft द्वारा उपयोग किया जाता है.

यह त्रुटि तब दी जाती है जब विंडोज पेरेंटल कंट्रोल चालू होते हैं और दिए गए वेबपेज तक पहुंच को रोक रहे हैं। त्रुटि WPC अनुप्रयोग से उत्पन्न होती है, सर्वर से नहीं.

HTTP 451 कानूनी कारणों के लिए अनुपलब्ध (ड्रॉफ्ट)

यह स्थिति अभी तक मानक का हिस्सा नहीं है, लेकिन प्रारूप के रूप में उपलब्ध है.

जब एक संसाधन सेंसरशिप या अन्य कानूनी कारणों के कारण प्रदान नहीं किया जा सकता है तो इसका उपयोग किया जाता है। कोड संख्या फ़ारेनहाइट 451 पुस्तक का संदर्भ है.

HTTP 451 पुनर्निर्देशित (Microsoft)

मानक का हिस्सा नहीं है, लेकिन Microsoft द्वारा उपयोग किया जाता है। Exchange ActiveSync में होता है यदि या तो उपयोग करने के लिए एक अधिक कुशल सर्वर है या सर्वर उपयोगकर्ताओं के मेलबॉक्स तक नहीं पहुंच सकता है.

HTTP 494 अनुरोध हैडर बहुत बड़ा (Nginx)

मानक का हिस्सा नहीं है, लेकिन Nginx द्वारा उपयोग किया गया था। अब पदावनत कर दिया.

इसका अर्थ 431 के समान था, लेकिन इससे पहले कि स्टेटस HTTP मानक का एक हिस्सा था, पेश किया गया था.

HTTP 495 प्रमाणपत्र त्रुटि (Nginx)

मानक का हिस्सा नहीं है। नहीं वास्तव में एक प्रतिक्रिया की स्थिति के रूप में इस्तेमाल किया, लेकिन एक क्लाइंट क्लाइंट प्रमाणपत्र त्रुटि तब होती है जब Nginx लॉग में प्रकट होता है.

HTTP 496 नो सर्टिफिकेट (Nginx)

मानक का हिस्सा नहीं है। वास्तव में उपयोग के रूप में एक प्रतिक्रिया की स्थिति नहीं है, लेकिन जब ग्राहक प्रमाण पत्र प्रदान नहीं करता है, तो नग्नेक्स लॉग में दिखाई देता है.

HTTP 497 HTTP to HTTPS (Nginx)

मानक का हिस्सा नहीं है। वास्तव में उपयोग के रूप में एक प्रतिक्रिया की स्थिति नहीं है, लेकिन सादे HTTP अनुरोध HTTPS पोर्ट पर भेजे जाने पर Nginx लॉग में दिखाई देता है.

HTTP 498 टोकन समाप्त / अमान्य (Esri)

सर्वर के लिए ArcGIS द्वारा लौटाया गया। 498 का ​​एक कोड एक समाप्त या अन्यथा अमान्य टोकन इंगित करता है.

HTTP 499 क्लाइंट बंद अनुरोध (Nginx)

मानक का हिस्सा नहीं है। उपयोग के रूप में वास्तव में एक प्रतिक्रिया की स्थिति नहीं है, लेकिन जब ग्राहक अभी भी अपने अनुरोध को संसाधित कर रहा है, तो सर्वर द्वारा एक स्थिति कोड वापस भेजने में असमर्थ होने पर, नगनेक्स लॉग में प्रकट होता है।.

HTTP 499 टोकन आवश्यक (Esri)

सर्वर के लिए ArcGIS द्वारा लौटाया गया। 499 का कोड बताता है कि एक टोकन की आवश्यकता है (यदि कोई टोकन जमा नहीं किया गया था).

HTTP स्थिति कोड 5xx – सर्वर त्रुटि

मैं वास्तव में चकित हूं जब मैं विचार करता हूं कि मेरा दिमाग कितना कमजोर है और त्रुटि का खतरा कैसे है.

-रेने डेस्कर्टेस

4xx श्रृंखला के साथ, HTTP स्थिति कोड के 5xx वर्ग त्रुटि कोड हैं, जब कुछ गलत हो जाता है तो जारी किया जाता है। 5xx त्रुटि कोड सर्वर त्रुटि कोड हैं, जिसका अर्थ है कि वे क्लाइंट के बजाय सर्वर पर समस्या होने पर वापस आ जाते हैं.

जब भी संभव हो, सर्वर को एक प्रतिक्रिया इकाई वापस करनी चाहिए जो क्लाइंट को त्रुटि का वर्णन करती है। उपयोगकर्ता एजेंटों (वेब ​​ब्राउज़र) को उपयोगकर्ता को यह जानकारी दिखानी चाहिए.

HTTP 500 आंतरिक सर्वर त्रुटि

यह सबसे सामान्य सर्वर त्रुटि है, और वेब सर्वर द्वारा तब जारी किया जाता है जब कुछ अनिश्चित हो जाता है.

आमतौर पर, यह सुनिश्चित करने के लिए कि 500: आंतरिक सर्वर त्रुटि उत्पन्न नहीं होती है, किसी वेबसाइट या सर्वर कॉन्फ़िगरेशन में किसी भी बदलाव का पूरी तरह से परीक्षण किया जाना चाहिए.

जब 500 त्रुटि उत्पन्न होती है, तो सर्वर लॉग को देखकर अक्सर यह निर्धारित करने में मदद मिल सकती है कि त्रुटि कहां से आ रही है। यह अक्सर .htaccess फ़ाइल में टाइपोग्राफिक त्रुटियों के रूप में सरल हो सकता है.

HTTP 501 लागू नहीं है

जब HTTP अनुरोध विधि (जैसे PUT या DELETE), कुछ मामलों में API विधि वापस आ जाती है, तो इसे अभी तक लागू नहीं किया गया है। इसका उपयोग वेब सेवा एपीआई के लिए किया जाता है। आमतौर पर, 501 त्रुटि का निहितार्थ यह है कि भविष्य के कार्यान्वयन के लिए अनुरोध विधि की योजना बनाई जाती है.

HTTP 502 खराब गेटवे

यह तब होता है जब सर्वर प्रॉक्सी या गेटवे के रूप में कार्य कर रहा होता है, और अपस्ट्रीम सर्वर से अवैध प्रतिक्रिया प्राप्त करता है.

HTTP 503 सेवा अनुपलब्ध

वर्तमान में सर्वर अनुपलब्ध है। उदाहरण के लिए, क्योंकि यह रखरखाव के लिए अतिभारित या नीचे है.

503 त्रुटि का निहितार्थ यह है कि आउटेज अस्थायी है.

HTTP 504 गेटवे टाइमआउट

यह त्रुटि तब होती है जब सर्वर प्रॉक्सी या गेटवे के रूप में कार्य कर रहा होता है, और आवंटित समय के दौरान अपस्ट्रीम सर्वर से प्रतिक्रिया नहीं मिलती है.

HTTP 505 HTTP संस्करण समर्थित नहीं है

इस त्रुटि का अर्थ है कि सर्वर अनुरोध में उपयोग किए गए HTTP प्रोटोकॉल संस्करण का समर्थन नहीं करता है.

HTTP 506 वेरिएंट भी वार्ता

506 त्रुटि को समझने के लिए, आपको पारदर्शी सामग्री बातचीत को समझना होगा.

सामग्री बातचीत के साथ, एक एकल URL एक ही संसाधन या जानकारी को कई प्रारूपों में वितरित कर सकता है। उदाहरण के लिए, एक ही छवि को JPEG और GIF के रूप में एन्कोड किया जा सकता है.

506 त्रुटि तब होती है जब यह सामग्री बातचीत लूप का कारण बनती है। उदाहरण के लिए: अनुरोधित संसाधन A में दो भिन्नताएँ हैं – B और C. इन दोनों में A एक प्रकार के रूप में है.

इसे और अधिक तकनीकी भाषा में रखने के लिए, विनिर्देश 506 त्रुटि का वर्णन करता है:

अनुरोध के लिए पारदर्शी सामग्री बातचीत एक परिपत्र संदर्भ में परिणाम देती है.

HTTP 507 अपर्याप्त संग्रहण (WebDAV; RFC 4918)

यह स्थिति WebDAV प्रोटोकॉल का उपयोग करती है। यह तब दिया जाता है जब सर्वर अनुरोध को पूरा करने के लिए आवश्यक प्रतिनिधित्व को संग्रहीत करने में असमर्थ होता है.

HTTP 508 लूप का पता लगाया गया

अनुरोधित संसाधन की सेवा करने का प्रयास करते समय सर्वर को एक अनंत लूप का सामना करना पड़ा.

HTTP 509 बैंडविड्थ की सीमा (अपाचे)

HTTP मानक का हिस्सा नहीं है, लेकिन Apache द्वारा प्रस्तुत और उपयोग किया जाता है। यह तब जारी किया जाता है जब सर्वर बैंडविड्थ की सीमा पार हो गई होती है.

HTTP 510 विस्तारित नहीं

इस त्रुटि का अर्थ है कि सर्वर को पूरा करने के लिए अनुरोध के आगे के विस्तार की आवश्यकता है.

HTTP 511 नेटवर्क प्रमाणीकरण आवश्यक है

511 त्रुटि वापस आती है जब क्लाइंट को नेटवर्क एक्सेस हासिल करने के लिए प्रमाणित करने की आवश्यकता होती है.

यह स्थिति उपयोग के लिए अभिप्रेत है, जब नेटवर्क तक पहुंच को नियंत्रित करने के लिए इस्तेमाल की जाने वाली समीपवर्ती अवरोधन – यानी “कैप्टिव पोर्टल” का उपयोग वाईफाई पोर्टल के माध्यम से इंटरनेट तक पहुंच प्रदान करने से पहले लॉगिन या सेवा की शर्तों की आवश्यकता होती है।.

(यदि आपने कभी किसी हवाई अड्डे या होटल में ऑनलाइन प्राप्त करने की कोशिश की है, तो आपको 511 त्रुटि का सामना करना पड़ेगा।)

HTTP 520 अज्ञात त्रुटि

यह त्रुटि कोड HTTP मानक का हिस्सा नहीं है, लेकिन सर्वर इन्फ्रास्ट्रक्चर के कई बड़े प्रदाताओं द्वारा उपयोग किया जाता है, जैसे कि CloudFlare। यह अज्ञात समस्याओं के लिए एक सामान्य “कैच-ऑल” त्रुटि के रूप में उपयोग किया जाता है जिसके परिणामस्वरूप अनुरोध नहीं भरा जाता है.

HTTP 598 नेटवर्क टाइमआउट त्रुटि (Microsoft) पढ़ें

यह त्रुटि कोड HTTP मानक का हिस्सा नहीं है, लेकिन इसका उपयोग Microsoft HTTP प्रॉक्सी द्वारा प्रॉक्सी के सामने क्लाइंट के पीछे नेटवर्क पढ़ने के समय के संकेत देने के लिए किया जाता है।.

HTTP 599 नेटवर्क कनेक्ट टाइमआउट त्रुटि (Microsoft)

यह त्रुटि कोड HTTP मानक का हिस्सा नहीं है, लेकिन इसका उपयोग Microsoft HTTP प्रॉक्सी द्वारा प्रॉक्सी से क्लाइंट के सामने नेटवर्क कनेक्ट टाइमआउट को प्रॉक्सी के सामने सिग्नल देने के लिए किया जाता है।.

साधन

  • IANA: इंटरनेट असाइन की गई संख्या प्राधिकरण की वेबसाइट.
  • HTTP स्थिति कोड रजिस्ट्री: प्रत्येक कोड के लिए RFC के लिंक के साथ आधिकारिक IANA पृष्ठ.

आगे की पढाई

हमारे पास वेब विकास से संबंधित अधिक गाइड, ट्यूटोरियल और इन्फोग्राफिक्स हैं:

  • मैं बैठता हूँ? 50 शीर्ष होस्टिंग प्रदाताओं के लिए स्थिति पृष्ठ: यहां तक ​​कि सबसे अच्छे सर्वर समय-समय पर नीचे जाते हैं। यह लेख शीर्ष होस्टिंग कंपनियों में से 50 के लिए स्थिति पृष्ठों की एक सूची प्रदान करता है.
  • इंटरनेट सॉकेट के साथ नेटवर्क प्रोग्रामिंग: यदि आप हार्ड कोर नेटवर्किंग सीखना चाहते हैं, तो यह आपको आरंभ करने का लेख है.
  • वेबमास्टर टूल्स A-Z की अंतिम सूची: कोडिंग से लेकर मार्केटिंग तक, इस लेख में यह सब है.

वेब होस्टिंग के लिए अंतिम गाइड

वेब होस्टिंग के लिए हमारी अंतिम गाइड देखें। यह एक सूचित विकल्प बनाने के लिए आपको जो कुछ भी जानने की आवश्यकता है, उसे समझाएगा.

वेब होस्टिंग के लिए अंतिम गाइड
वेब होस्टिंग के लिए अंतिम गाइड

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map