मोफत HTTP स्टेटस कोड संदर्भ

Expect: 100-continue असलेल्या विनंत्यांसाठी वापरले जाते. सर्व्हर बॉडी येण्याआधी ती स्वीकारण्यास तयार असल्याचे कळवतो. आधुनिक वेब अ‍ॅप्समध्ये क्वचितच दिसते.

बहुतेक वेळा WebSocket अपग्रेडसाठी वापरले जाते — क्लायंट Upgrade: websocket विनंती करतो आणि सर्व्हर स्विच करण्यासाठी 101 प्रतिसाद देतो.

दीर्घ प्रक्रियेदरम्यान क्लायंट टाइमआउट टाळण्यासाठी पाठवला जाणारा WebDAV मध्यंतरी प्रतिसाद. कालबाह्य — आधुनिक सर्व्हरनी तो पाठवू नये.

अंतिम प्रतिसाद अद्याप तयार होत असतानाच सर्व्हरना Link हेडर्स (preload/preconnect) पाठवू देते, त्यामुळे ब्राउझर महत्त्वाचे संसाधन आधीच आणू लागतात.

मानक यश प्रतिसाद. अर्थ HTTP पद्धतीवर अवलंबून असतो: GET → संसाधन परत मिळते, POST/PUT → कृती पूर्ण झाली.

POST नंतर सामान्यतः वापरले जाते. प्रतिसादात नव्या संसाधनाच्या URL कडे निर्देश करणारा Location हेडर असायला हवा.

असिंक्रोनस कामासाठी — सर्व्हर काम रांगेत टाकत आहे. क्लायंटने स्टेटस एंडपॉइंट तपासावा किंवा नंतर पुन्हा तपासावे.

विनंती यशस्वी झाली, पण एका मध्यस्थाने (जसे की कॅशिंग किंवा ट्रान्सफॉर्मिंग प्रॉक्सी) मूळ सर्व्हरचा पेलोड बदलला — उदा. इमेज पुन्हा-कॉम्प्रेस करणे. प्रत्यक्षात दुर्मिळ.

बॉडी परत करण्याची गरज नसलेल्या DELETE कृती किंवा PUT अद्ययावतांसाठी अनेकदा वापरले जाते. क्लायंटने सध्याच्या पानावरून जाऊ नये.

204 प्रमाणेच, बॉडी परत मिळत नाही — पण क्लायंटला विनंती तयार करणारा फॉर्म किंवा व्ह्यू रीसेट करण्यासही सांगितले जाते (उदा. पुढील नोंदीसाठी फॉर्म फील्ड्स रिकामी करणे).

Range विनंतीला प्रतिसाद. व्हिडिओ प्लेयर आणि डाउनलोड मॅनेजर्स अडलेले डाउनलोड पुन्हा सुरू करण्यासाठी किंवा मोठ्या फाइल्स स्ट्रीम करण्यासाठी वापरतात.

WebDAV: एक XML बॉडी अनेक उप-कृतींचा निकाल स्वतंत्रपणे नोंदवते — उदा. काही आयटम यशस्वी झाल्याचे आणि इतर अयशस्वी झाल्याचे दाखवणारे बॅच मूव्ह.

WebDAV: बाइंडिंगमुळे लूप तयार झाल्यास त्याच संग्रहाचे सदस्य वारंवार सूचीबद्ध होऊ नयेत म्हणून 207 Multi-Status प्रतिसादांमध्ये वापरले जाते.

डेल्टा एन्कोडिंग: सर्व्हर संपूर्ण संसाधनाऐवजी मागील आवृत्तीशी फरक (diff) पाठवतो, ज्यामुळे बँडविड्थ वाचते. फार क्वचितच वापरले जाते.

सर्व्हर अनेक पर्याय देतो (उदा. वेगवेगळे फॉरमॅट किंवा भाषा) आणि क्लायंटने एक निवडावा. क्वचितच वापरले जाते, कारण स्वयंचलित कंटेंट निगोशिएशन सहसा हे हाताळते.

कायमस्वरूपी URL बदलांसाठी वापरा — सर्च इंजिन त्यांची अनुक्रमणिका अद्ययावत करतील. SEO अधिकार नवीन URL कडे हस्तांतरित होतो.

हे दर्शवते की रीडायरेक्ट कायमस्वरूपी नाही. कॅशिंग 301 पेक्षा कमी आक्रमक असते. 'लॉगिन आवश्यक, /login वर रीडायरेक्ट करत आहे' अशा गोष्टींसाठी वापरा.

POST सबमिशननंतर वापरले जाते — प्रतिसाद सांगतो 'तुमचा POST यशस्वी झाला, परिणामासाठी हा GET URL पहा'. ब्राउझर नेहमी नवीन URL GET करतात.

कंडिशनल रिक्वेस्टला (If-None-Match किंवा If-Modified-Since हेडरसह) प्रतिसाद. बँडविड्थ वाचवते — बॉडी परत केली जात नाही.

मूळ POST असेल, तर रीडायरेकटही POST वापरते. पद्धत टिकवून ठेवणे महत्त्वाचे असताना 302 चा आधुनिक पर्याय.

रीडायरेक्टनंतर POST रिक्वेस्ट POST च राहावी असे हवे असल्यास 301 चा आधुनिक पर्याय.

सामान्य कारणे: बॉडीमध्ये चुकीचा JSON, अवैध क्वेरी पॅरामीटर्स, किंवा आवश्यक फील्ड गहाळ. रिक्वेस्ट बॉडी आणि हेडर तपासा.

क्लायंटने प्रमाणीकरण क्रेडेन्शियल्स (Authorization हेडर, कुकी, टोकन) समाविष्ट करणे आवश्यक आहे. 'Unauthorized' हा चुकीचा शब्द आहे — याचा खरा अर्थ 'प्रमाणीकृत नाही' असा होतो.

मूळतः डिजिटल पेमेंटसाठी उद्देशित. आधुनिक वापर: वापरकर्त्याने त्याचा सशुल्क कोटा ओलांडल्यास API कधीकधी 402 परत करतात.

401 पेक्षा वेगळे — वापरकर्ता लॉग इन आहे, पण त्याच्या खात्याला या संसाधनासाठी परवानगी नाही. भूमिका/परवानगी लॉजिक तपासा.

एकतर URL चुकीचा आहे, संसाधन हटवले गेले आहे, किंवा ते कधीच अस्तित्वात नव्हते. 403 अधिक अचूक असेल हे लपवण्यासाठी सर्व्हर कधीकधी 404 परत करतात.

उदाहरणार्थ, फक्त POST स्वीकारणाऱ्या एंडपॉइंटला GET रिक्वेस्ट. प्रतिसादात वैध पद्धती सूचीबद्ध करणारा Allow हेडर असावा.

क्लायंटने Accept, Accept-Language, Accept-Encoding द्वारे मागितलेला कंटेंट प्रकार, भाषा किंवा एन्कोडिंग सर्व्हर पुरवू शकत नाही. अनेक सर्व्हर काटेकोर निगोशिएशन वगळून डिफॉल्ट परत करतात.

401 सारखेच, पण प्रॉक्सीकडून जारी केले जाते: क्लायंटने Proxy-Authorization क्रेडेन्शियल्स पाठवणे आवश्यक आहे. प्रमाणीकरण करणाऱ्या प्रॉक्सीसह कॉर्पोरेट नेटवर्कवर आढळते.

क्लायंटने रिक्वेस्ट बॉडी पाठवण्यास खूप वेळ घेतला किंवा कनेक्शन निष्क्रिय ठेवले. रिक्वेस्ट पुन्हा प्रयत्न करा.

सामान्यतः एकाचवेळी संपादन संघर्ष किंवा डुप्लिकेट संसाधन निर्मितीसाठी (उदा. आधीच अस्तित्वात असलेल्या ईमेलसह वापरकर्ता तयार करणे) परत केले जाते.

404 पेक्षा अधिक ठाम — सर्व्हरला स्पष्टपणे माहीत आहे की संसाधन पूर्वी अस्तित्वात होते पण ते कायमचे काढून टाकले गेले आहे. सर्च इंजिन त्याला अनुक्रमणिकेतून काढून टाकतील.

Content-Length हेडर नसल्यामुळे रिक्वेस्ट नाकारली गेली आणि सर्व्हर अज्ञात आकाराच्या बॉडी नाकारतो. हेडर जोडा आणि पुन्हा प्रयत्न करा.

If-Match किंवा If-Unmodified-Since सारख्या कंडिशनल हेडर अयशस्वी झाल्यास परत केले जाते — सामान्यतः ऑप्टिमिस्टिक लॉकिंग: तुमच्या आवृत्तीनंतर कुणीतरी दुसऱ्याने संसाधन बदलले आहे. पुन्हा फेच करा आणि पुन्हा प्रयत्न करा.

मोठ्या फायली अपलोड करताना सामान्यतः आढळते. सर्व्हर कॉन्फिगरेशन (nginx, apache) कमाल बॉडी आकार सेट करते. सर्व्हरचे कॉन्फिगरेशन तपासा.

सहसा खूप लांब क्वेरी स्ट्रिंगमुळे (उदा. GET मध्ये डेटा एन्कोड करणे) होते. POST बॉडीकडे वळा, किंवा सर्व्हर तुमच्या नियंत्रणात असल्यास मर्यादा वाढवा.

उदाहरणार्थ, फक्त application/json स्वीकारणाऱ्या सर्व्हरला application/xml पाठवणे. Content-Type हेडर योग्यरित्या सेट करा.

Range हेडर फाइलमध्ये नसलेला भाग मागतो — उदा. फाइलच्या शेवटपलीकडे डाउनलोड पुन्हा सुरू करणे. प्रतिसादात वास्तविक आकारासह Content-Range असावा.

सर्व्हर Expect: 100-continue ला समर्थन देत नसल्यास पाठवले जाते. काही क्लायंट डीफॉल्टने मोठ्या POST वर हे हेडर पाठवतात; ते बंद केल्याने सहसा त्रुटी सुटते.

1998 (RFC 2324) मधील एप्रिल फूल विनोद. काही खरी API यासाठी विनोद म्हणून किंवा deprecated एंडपॉइंट दर्शवण्यासाठी वापरतात. उत्पादनासाठी नाही.

HTTP/2 कनेक्शन पुनर्वापरात सामान्य: रिक्वेस्ट अशा सर्व्हरपर्यंत पोहोचली जो लक्ष्य होस्टनेमसाठी कॉन्फिगर केलेला नाही. क्लायंटने नवीन कनेक्शनवर पुन्हा प्रयत्न करावा.

उदाहरणार्थ, JSON योग्यरित्या पार्स झाला पण आवश्यक फील्ड गहाळ होते, किंवा फील्ड व्हॅल्यू मर्यादेबाहेर होती. REST API व्हॅलिडेशन प्रतिसादांमध्ये सामान्य.

WebDAV: स्रोत किंवा गंतव्य संसाधन दुसऱ्या क्लायंटने लॉक केलेले आहे, त्यामुळे कार्य पुढे जाऊ शकत नाही. लॉक सुटण्याची वाट पहा किंवा योग्य टोकनसह तो तोडा.

WebDAV: अवलंबित कार्यांच्या साखळीत, आधीची क्रिया अयशस्वी झाली, त्यामुळे ही केली गेली नाही. मूळ कारणासाठी आधीची अयशस्वी क्रिया पहा.

TLS 1.3 0-RTT (early data) शी संबंधित: पुन्हा वापरली गेलेली रिक्वेस्ट प्रक्रिया करण्याचा धोका सर्व्हर घेणार नाही. हँडशेक पूर्ण झाल्यावर क्लायंटने पुन्हा प्रयत्न करावा.

सध्याच्या प्रोटोकॉलवर रिक्वेस्ट सेवा देण्यास सर्व्हर नकार देतो पण अपग्रेडनंतर देईल — प्रतिसादात आवश्यक प्रोटोकॉल नमूद करणारा Upgrade हेडर असतो.

गमावलेले अपडेट संघर्ष टाळण्यासाठी सर्व्हर कंडिशनल हेडर (जसे If-Match) मागतो. संसाधन फेच करा, त्याचा ETag घ्या, आणि If-Match सह पुन्हा पाठवा.

वेग कमी करा. प्रतिसादात पुन्हा कधी प्रयत्न करावा हे दर्शवणारा Retry-After हेडर असावा. रिक्वेस्ट कोटा असलेल्या API मध्ये सामान्य.

एकतर एक हेडर किंवा एकूण हेडर आकार मर्यादेपेक्षा जास्त आहे — बहुतेकदा खूप मोठ्या कुकीजमुळे. कुकीज साफ करा किंवा तुमचे अॅप कुकीजमध्ये किती डेटा साठवते ते कमी करा.

संसाधन कायदेशीर कारणांमुळे — सेन्सॉरशिप, कोर्ट ऑर्डर किंवा प्रादेशिक नियमांमुळे — अवरोधित आहे. हा क्रमांक Fahrenheit 451 कादंबरीचा संदर्भ आहे.

सर्व्हर-साइड त्रुटींसाठी सामान्य सर्वसमावेशक कोड. वास्तविक कारणासाठी सर्व्हर लॉग तपासा: न हाताळलेला अपवाद, डेटाबेस त्रुटी, इत्यादी.

उदाहरणार्थ, सर्व्हर HTTP पद्धत ओळखत नाही. प्रत्यक्षात क्वचितच आढळते — बहुतेकदा तुम्हाला 405 दिसेल.

मायक्रोसर्व्हिस आर्किटेक्चरमध्ये सामान्य. तुमच्या लोड बॅलन्सर किंवा रिव्हर्स प्रॉक्सीला बॅकएंड सेवेकडून विकृत प्रतिसाद मिळाला.

एकतर देखभालीसाठी बंद आहे किंवा ओव्हरलोडेड आहे. प्रतिसादात Retry-After हेडर असावा. डिप्लॉयमेंट दरम्यान अनेकदा परत केले जाते.

बॅकएंड सेवेने पुरेसे लवकर प्रतिसाद दिला नाही. अपस्ट्रीम सेवेचे आरोग्य आणि टाइमआउट कॉन्फिगरेशन तपासा.

रिक्वेस्टची मुख्य HTTP आवृत्ती सर्व्हर समर्थित करत नाही. आधुनिक क्लायंटसह जवळजवळ कधीच दिसत नाही.

ट्रान्सपरंट कंटेंट निगोशिएशन लूपमध्ये संपले: निवडलेला व्हेरियंट स्वतःच निगोशिएट करण्यासाठी कॉन्फिगर केलेला आहे. सर्व्हर कॉन्फिगरेशन त्रुटी दर्शवते.

मूळतः WebDAV-विशिष्ट पण कधीकधी सामान्य सर्व्हरद्वारेही वापरले जाते. याचा अर्थ साठ्याच्या मर्यादेमुळे सर्व्हर रिक्वेस्ट साठवू शकत नाही.

WebDAV: Depth: infinity रिक्वेस्ट प्रक्रिया करताना लूपमध्ये अडकले (उदा. वर्तुळाकार बाइंडिंग). कार्य थांबवले गेले.

जुन्या HTTP Extension Framework मधून: रिक्वेस्ट पूर्ण करण्याआधी सर्व्हरला आणखी माहिती हवी आहे. आधुनिक वेबवर व्यावहारिकदृष्ट्या न वापरलेले.

बाह्य साइट्सवर प्रवेश करण्यापूर्वी वापरकर्त्याने नेटवर्कमध्ये लॉग इन करणे आवश्यक आहे हे दर्शवण्यासाठी कॅप्टिव्ह पोर्टल्स (हॉटेल/एअरपोर्ट WiFi) वापरतात.