मुख्य सामग्रीमा जानुहोस्
LibraTool logoLibraTool

निःशुल्क HTTP स्टाटस कोड सन्दर्भ

सबै HTTP status codes का लागि खोज्न मिल्ने सन्दर्भ — प्रत्येकको अर्थ, कहिले प्रयोग हुन्छ, र सामान्य कारणहरू। १०० देखि ५११ सम्म।

लोड भएपछि अफलाइन काम गर्छ

61 स्टेटस कोड

100

जारी राखनुहोस्

सर्भरले अनुरोध हेडरहरु प्राप्त गरेको छ र क्लायन्टले शरीरसँग अगाडि बढ्नु पर्छ।

Expect: 100-continue सहितको अनुरोधहरुको लागि प्रयोग गरिन्छ। सर्भरले स्वीकार गर्छ कि यो शरीर प्राप्त गर्न इच्छुक छ क्लायन्ट यो पठाउनु अघि। आधुनिक वेब अनुप्रयोगमा विरलै देखिन्छ।

RFC 9110 ↗
101

प्रोटोकल स्विच गर्दै

सर्भर क्लायन्टद्वारा अनुरोध गरिएको प्रोटोकल स्विच गर्दैछ।

सर्वाधिक सामान्यतः WebSocket अपग्रेडहरुको लागि प्रयोग गरिन्छ — क्लायन्टले Upgrade: websocket अनुरोध गर्छ र सर्भरले 101 सँग प्रतिक्रिया गर्छ।

RFC 9110 ↗
102

प्रक्रिया गर्दै

सर्भरले अनुरोध प्राप्त गरेको छ र यो प्रक्रिया गर्दैछ, तर कुनै प्रतिक्रिया अभी उपलब्ध छैन।

WebDAV अन्तरिम प्रतिक्रिया लामो अपरेशनहरु को समय क्लायन्ट टाइमआउट रोक्न पठाइन्छ। बहिष्कृत — आधुनिक सर्भरहरु यो पठाउनु हुँदैन।

RFC 2518 ↗
103

प्रारम्भिक सङ्केत

अन्तिम प्रतिक्रिया अघि प्रारम्भिक हेडरहरु पठाइन्छ।

सर्भरहरुलाई Link हेडरहरु (preload/preconnect) पठाउन अनुमति दिन्छ जबकि अन्तिम प्रतिक्रिया अझै तयार गरिएको छैन, ताकि ब्राउजरहरु महत्त्वपूर्ण सम्पत्तिहरु द्रुत फेच गर्न सक्छन्।

RFC 8297 ↗
200

ठीक छ

अनुरोध सफल भयो।

मानक सफलता प्रतिक्रिया। अर्थ HTTP विधिमा निर्भर गर्छ: GET → संसाधन फर्काइयो, POST/PUT → कार्य पूरा गरियो।

RFC 9110 ↗
201

बनाइएको

नयाँ संसाधन सफलतापूर्वक बनाइएको छ।

POST पछि सामान्य। प्रतिक्रिया नयाँ संसाधनको URL लाई संकेत गर्दै Location हेडर समावेश गर्नु पर्छ।

RFC 9110 ↗
202

स्वीकृत

अनुरोध प्रक्रियाको लागि स्वीकृत गरिएको छ, तर प्रक्रिया पूरा भएको छैन।

एसिङ्क अपरेशनहरुको लागि — सर्भर कार्य कतारमा राखिएको छ। क्लायन्टले स्थिति endpoint मा पोल गर्नु पर्छ वा पछि जाँच गर्नु पर्छ।

RFC 9110 ↗
203

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

प्रतिक्रिया एक रूपान्तरण प्रॉक्सी द्वारा परिवर्तन गरिएको थियो।

अनुरोध सफल भयो, तर एक मध्यवर्ती (जस्तै क्यासिङ वा रूपान्तरण प्रॉक्सी) मूल सर्भरबाट पेलोड परिवर्तन गरेको छ — उदाहरणको लागि, छविहरु पुनः संपीडन। व्यावहारमा विरल।

RFC 9110 ↗
204

कुनै सामग्री छैन

अनुरोध सफल भयो तर कुनै प्रतिक्रिया शरीर छैन।

DELETE अपरेशन वा PUT अपडेटहरुको लागि सर्वथा प्रयोग गरिन्छ जुन शरीर फर्काउन आवश्यक छैन। क्लायन्टले वर्तमान पृष्ठबाट दूर जान हुँदैन।

RFC 9110 ↗
205

सामग्री रीसेट गर्नुहोस्

अनुरोध सफल भयो; क्लायन्टले दस्तावेज दृश्य रीसेट गर्नु पर्छ।

२०४ जस्तै, कुनै शरीर फर्काइएको छैन — तर क्लायन्टलाई फिर्ता गर्न बताइन्छ अनुरोध गरिएको फार्म वा दृश्य (उदा. अगलो प्रविष्टिको लागि फार्म क्षेत्रहरु स्पष्ट गर्नुहोस्)।

RFC 9110 ↗
206

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

सर्भरले संसाधनको केवल भाग दिएको छ।

Range अनुरोधमा प्रतिक्रिया। भिडियो प्लेयरहरु र डाउनलोड प्रबन्धकहरु द्वारा प्रयोग गरिन्छ बाधित डाउनलोडहरु पुनः सुरु गर्न वा ठूला फाइलहरु स्ट्रिम गर्न।

RFC 9110 ↗
207

बहु-स्थिति

प्रतिक्रिया शरीर बहु अपरेशनहरुको लागि बहु स्थिति कोडहरु समावेश गर्छ।

WebDAV: XML शरीरले बहु उप-अपरेशनको परिणाम स्वतन्त्र रूपमा रिपोर्ट गर्छ — उदा. बैच सार्नुहोस जहाँ कुछ वस्तुहरु सफल भएका छन् र अन्यहरु असफल।

RFC 4918 ↗
208

पहिले नै रिपोर्ट गरिएको

संग्रहको सदस्यहरु प्रतिक्रियामा पहिले नै सूचीबद्ध गरिएका छन्।

WebDAV: २०७ Multi-Status प्रतिक्रियाहरु भित्र प्रयोग गरिन्छ एकै संग्रह को सदस्यहरु बारम्बार सूचीबद्ध गर्न बाझ गर्न जब बाइन्डिङहरु लूप बनाउँछन्।

RFC 5842 ↗
226

IM प्रयोग गरिएको

प्रतिक्रिया संसाधनमा लागू गरिएको इन्स्ट्यान्स हेरफेरहरुको परिणाम हो।

डेल्टा इन्कोडिङ: सर्भरले पूर्ण संसाधनको सट्टा अघिल्लो संस्करण विरुद्ध भेद फर्काउँछ, ब्याण्डविथ बचाउँछ। अत्यन्त विरलै कार्यान्वयन गरिन्छ।

RFC 3229 ↗
300

बहु विकल्पहरु

संसाधनका बहु प्रतिनिधित्व उपलब्ध छन्।

सर्भरले बहु विकल्पहरु प्रस्ताव गर्छ (उदा. विभिन्न ढाँचा वा भाषाहरु) र क्लायन्टले एक छनौट गर्नु पर्छ। विरलै प्रयोग गरिन्छ, किनभने स्वचालित सामग्री वार्ता सामान्यतः यो संभाल्छ।

RFC 9110 ↗
301

स्थायी रूपमा सार्नुहोस्

संसाधन स्थायी रूपमा नयाँ URL मा सरेको छ।

स्थायी URL परिवर्तनहरुको लागि प्रयोग गर्नुहोस् — खोज इञ्जिनहरु तिनको सूचकांक अपडेट गरिनेछ। SEO अनुमति नयाँ URL मा स्थानान्तरण।

RFC 9110 ↗
302

फेला पारिएको (अस्थायी पुनर्निर्देशन)

संसाधन अस्थायी रूपमा फरक URL मा छ।

पुनर्निर्देशन स्थायी छैन भनी सूचित गर्छ। क्यासिङ ३०१ को तुलनामा कम आक्रामक छ। चीजहरुको लागि प्रयोग गर्नुहोस् जस्तै 'लगइन आवश्यक, /login मा पुनर्निर्देशित'।

RFC 9110 ↗
303

अन्य हेर्नुहोस्

GET प्रयोग गरेर फरक URL मा पुनर्निर्देशित गर्नुहोस्।

POST जमाहरु पछि प्रयोग गरिन्छ — प्रतिक्रिया भन्छ 'तपाईको POST काम गर्यो, यस GET URL हेर्नुहोस् परिणामको लागि'। ब्राउजरहरु सधैं नयाँ URL GET गर्छन्।

RFC 9110 ↗
304

परिवर्तन गरिएको छैन

क्यास गरिएको संस्करण अझै वैध छ; यो प्रयोग गर्नुहोस्।

सशर्त अनुरोधमा प्रतिक्रिया (If-None-Match वा If-Modified-Since हेडरहरु सहित)। ब्याण्डविथ बचाउँछ — कुनै शरीर फर्काइएको छैन।

RFC 9110 ↗
307

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

३०२ जस्तै तर मूल HTTP विधि संरक्षण गर्छ।

यदि मूल POST थियो, पुनर्निर्देशन पनि POST प्रयोग गर्छ। आधुनिक विकल्प ३०२ को लागि जब विधि संरक्षण महत्त्वपूर्ण हो।

RFC 9110 ↗
308

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

३०१ जस्तै तर मूल HTTP विधि संरक्षण गर्छ।

३०१ को आधुनिक प्रतिस्थापन जब तपाई चाहनु हुन्छ POST अनुरोधहरु पुनर्निर्देशन पछि POST रहन।

RFC 9110 ↗
400

खराब अनुरोध

सर्भरले खराब वाक्यविन्यासको कारणले अनुरोध बुझ्न सकेन।

सामान्य कारणहरु: शरीरमा खराब ढाँचा गरिएको JSON, अमान्य क्वेरी प्यारामिटरहरु, वा गुमेको आवश्यक क्षेत्रहरु। अनुरोध शरीर र हेडरहरु जाँच गर्नुहोस्।

RFC 9110 ↗
401

असधिकृत

प्रमाणीकरण आवश्यक छ र प्रदान गरिएको छैन।

क्लायन्टले प्रमाणीकरण प्रमाणपत्र समावेश गर्नु पर्छ (Authorization हेडर, कुकी, टोकन)। 'असधिकृत' एक गलत नाम हो — यो साँच्चै 'अप्रमाणित' अर्थ राखे।

RFC 9110 ↗
402

भुक्तानी आवश्यक

भविष्यको प्रयोगको लागि आरक्षित — कहिले कहिले भुक्तान गरिएको API तरहरुको लागि प्रयोग गरिन्छ।

मूल रूपमा डिजिटल भुक्तानीहरुको लागि अभिप्रेत। आधुनिक प्रयोग: APIs कहिले कहिले ४०२ फर्काउँछन् जब प्रयोगकर्ता आफ्नो भुक्तान कोटा अतिक्रम गरेको हो।

RFC 9110 ↗
403

निषेध गरिएको

क्लायन्ट प्रमाणित छ तर अनुमति छैन।

४०१ बाट फरक — प्रयोगकर्ता IS लग इन, तर तिनको खाता यो संसाधनको लागि अनुमति छैन। भूमिका/अनुमति तर्क जाँच गर्नुहोस्।

RFC 9110 ↗
404

फेला पारिएन

अनुरोध गरिएको संसाधन अस्तित्वमा छैन।

या त URL गलत छ, संसाधन हटाइएको छ, वा यो कहिले अस्तित्व थिएन। सर्भरहरु कहिले कहिले ४०४ फर्काउँछन् कि ४०३ अझै सही हुन्छ भनी लुकाउन।

RFC 9110 ↗
405

विधि अनुमति छैन

यस संसाधनको लागि प्रयोग गरिएको HTTP विधि अनुमति छैन।

उदाहरणको लागि, एक GET अनुरोध endpoint लाई जो केवल POST स्वीकार गर्छ। प्रतिक्रियाले मान्य विधिहरु सूचीबद्ध गर्दै Allow हेडर समावेश गर्नु पर्छ।

RFC 9110 ↗
406

स्वीकार्य छैन

कुनै प्रतिनिधित्व क्लायन्टको Accept हेडरहरुसँग मेल खाँदैन।

क्लायन्टले सामग्री प्रकार, भाषा, वा इन्कोडिङ माग गरेको छ (Accept, Accept-Language, Accept-Encoding द्वारा) सर्भरले सन्तुष्ट गर्न सकेन। धेरै सर्भरहरु कठोर वार्ता छोड्छन् र यसको सट्टा डिफल्ट फर्काउँछन्।

RFC 9110 ↗
407

प्रॉक्सी प्रमाणीकरण आवश्यक

क्लाइन्टले पहिले प्रॉक्सीसँग प्रमाणीकरण गर्नुपर्छ।

४०१ जस्तै, तर प्रॉक्सी द्वारा जारी गरिएको: क्लायन्टले Proxy-Authorization प्रमाणपत्र पठाउनु पर्छ। कर्पोरेट नेटवर्कहरमा प्रमाणीकृत प्रॉक्सीहरु सहित देखिन्छ।

RFC 9110 ↗
408

अनुरोध समयसीमा

सर्भरले अनुरोधको लागि प्रतीक्षा गर्दै समय सीमा समाप्त गर्यो।

क्लाइन्टले अनुरोध निकाय पठाउन बहुत लामो समय लिए वा जडान निष्क्रिय राखे। अनुरोध फेरी प्रयास गर्नुहोस्।

RFC 9110 ↗
409

द्वन्द्व

अनुरोध संसाधनको वर्तमान स्थितिसँग द्वन्द्वमा छ।

सामान्यतः समवर्ती सम्पादन द्वन्द्व वा डुप्लिकेट संसाधन निर्माणको लागि फिरेको हुन्छ (उदाहरण, त्यो इमेल अनुहारसँग प्रयोगकर्ता बनाउँदै जो पहिले अवस्थित छ)।

RFC 9110 ↗
410

हराएको

संसाधन हटाइएको थियो र फर्केर आउँदैन।

४०४ भन्दा बलिया — सर्भरले स्पष्ट रूपमा जानदछ कि संसाधन पहिले अवस्थित थियो तर स्थायी रूपमा हटाइएको छ। खोज इञ्जिनहरूले अनुक्रमणिका हटाइनेछन्।

RFC 9110 ↗
411

लम्बाइ आवश्यक

सर्भरलाई Content-Length हेडर चाहिन्छ।

अनुरोध अस्वीकार गरिएको थियो किनभने यसमा Content-Length हेडर छैन र सर्भरले अज्ञात आकारको निकाय मनाही गर्छ। हेडर जोडी र फेरी प्रयास गर्नुहोस्।

RFC 9110 ↗
412

पूर्वनिबन्धन असफल

अनुरोध हेडरमा एक शर्त पूरी भएन।

शर्तीय हेडरहरू जस्तै If-Match वा If-Unmodified-Since असफल हुँदा फिरेको हुन्छ — सामान्यतः आशावादी लकिङ: कोही अरूले तपाईंको संस्करणदेखि संसाधन परिवर्तन गरेको छ। पुनः प्राप्त गरी पुनः प्रयास गर्नुहोस्।

RFC 9110 ↗
413

पेलोड बहुत ठूलो

अनुरोध निकाय सर्भरको आकार सीमा अधिक गर्छ।

ठूला फाइलहरू अपलोड गर्दा साधारण। सर्भर कन्फिगरेसन (nginx, apache) अधिकतम निकाय आकार सेट गर्छ। सर्भरको कन्फिगरेसन जाँच गर्नुहोस्।

RFC 9110 ↗
414

URI बहुत लामो

अनुरोध URL सर्भरको लम्बाइ सीमा अधिक गर्छ।

साधारणतः बहुत लामो क्वेरी स्ट्रिङहरूद्वारा कारण (उदाहरण GET मा डेटा कोडिङ)। POST निकायमा जानुहोस्, वा यदि तपाई नियन्त्रण गर्छौ भने सर्भर सीमा बढाउनुहोस्।

RFC 9110 ↗
415

समर्थन नगरिएको मिडिया प्रकार

सर्भर पठाइएको Content-Type सम्हाल्न सक्दैन।

उदाहरण, application/xml पठाइँदै एक सर्भरमा जो केवल application/json स्वीकार गर्छ। Content-Type हेडर सही सेट गर्नुहोस्।

RFC 9110 ↗
416

दायरा सन्तोषजनक नहुँदै

अनुरोध गरिएको बाइट दायरा संसाधनको आकारको बाहिर छ।

Range हेडरले फाइलको अंश माग गर्छ जो अवस्थित छैन — उदाहरण अपलोड पुनरारम्भ गरी फाइलको अन्तमा जाना। प्रतिक्रियाले वास्तविक आकारसँग Content-Range समावेश गर्नुपर्छ।

RFC 9110 ↗
417

अपेक्षा असफल

सर्भर Expect हेडरको आवश्यकता पूरी गर्न सक्दैन।

पठाइँदै जब सर्भर Expect: 100-continue समर्थन गर्दैन। केही क्लाइन्टहरूले यो हेडर डिफल्ट गरी ठूला POSTs मा पठाउँछन्; यसलाई अक्षम गर्दै साधारणतः त्रुटि समाधान गर्छ।

RFC 9110 ↗
418

मेरो टिपट हुँ

सर्भर कफी बनाउन अस्वीकार गर्छ किनभने यो टिपट हो।

१९९८ को अप्रिल फूल जोक (RFC २३२४)। केही वास्तविक API हरूले यसलाई जोकहरू वा खराब गरिएका अन्त्य बिन्दुहरू चिह्नमा प्रयोग गर्छन्। उत्पादन प्रयोगको लागि नहोइ।

RFC 2324 ↗
421

गलत निर्दिष्ट अनुरोध

अनुरोध सर्भरमा पठाइएको थियो जो यसको लागि प्रतिक्रिया उत्पन्न गर्न असक्षम छ।

HTTP/2 जडान पुनः प्रयोगसँग साधारण: अनुरोध लक्ष्य होस्टनेमको लागि कन्फिगर नगरिएको सर्भरमा पहुँचे। क्लाइन्टले नयाँ जडानमा पुनः प्रयास गर्नुपर्छ।

RFC 9110 ↗
422

प्रक्रिया गर्न सकिने सामग्री नहोइ

अनुरोध वाक्य रचना वैध थियो तर अर्थ गलत थियो।

उदाहरण, JSON सही तरीकामा पार्स गरिएको तर आवश्यक क्षेत्र हराएको, वा क्षेत्र मान दायराको बाहिर। REST API सत्यापन प्रतिक्रियाहरूमा साधारण।

RFC 9110 ↗
423

लक गरिएको

संसाधन लक गरिएको छ।

WebDAV: स्रोत वा गन्तव्य संसाधन अरू क्लाइन्टद्वारा लक गरिएको छ, यसैले अपरेशन गर्न सक्दैन। लक रिलिज हुनको प्रतीक्षा गर्नुहोस् वा उचित टोकनसँग तोड्नुहोस्।

RFC 4918 ↗
424

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

अनुरोध असफल भयो किनभने अगिलो निर्भर अनुरोध असफल भयो।

WebDAV: निर्भर अपरेशनको श्रृङ्खलामा, अगिलो कार्य असफल भयो, यसैले यो अपरेसन गरिएन। मूल कारणको लागि अगिलो असफलता हेर्नुहोस्।

RFC 4918 ↗
425

बहुत प्रारम्भिक

सर्भर अनुरोध प्रक्रिया गर्न अस्वीकार गर्छ जो रिप्ले हुन सक्छ।

TLS १.३ ०-RTT (प्रारम्भिक डेटा) सम्बन्धित: सर्भर सम्भावित रूपमा रिप्ले गरिएको अनुरोध प्रक्रिया गर्ने जोखिम लिँदैन। क्लाइन्टले ह्यान्डशेक पूरा भएपछी पुनः प्रयास गर्नुपर्छ।

RFC 8470 ↗
426

अपग्रेड आवश्यक

क्लाइन्टले अलग प्रोटोकलमा स्विच गर्नुपर्छ।

सर्भर वर्तमान प्रोटोकल अनुरोध सेवा गर्न अस्वीकार गर्छ तर अपग्रेड पश्चात् सेवा गर्नेछ — प्रतिक्रियामा Upgrade हेडर आवश्यक प्रोटोकल नाम गर्छ।

RFC 9110 ↗
428

पूर्वनिबन्धन आवश्यक

सर्भर अनुरोध शर्तीय हुन आवश्यक छ।

सर्भर शर्तीय हेडर माग गर्छ (जस्तै If-Match) हराएको अपडेट द्वन्द्व रोक्न। संसाधन प्राप्त गर, यसको ETag क्याप्चर गर, र If-Match सँग पुनः पठाउनुहोस्।

RFC 6585 ↗
429

बहुत धेरै अनुरोध

क्लाइन्ट दर सीमित हुँदै छ।

ढिलो गर्नुहोस्। प्रतिक्रियामा Retry-After हेडर समावेश हुनुपर्छ जो कहिले पुनः प्रयास गर्ने संकेत गर्छ। अनुरोध कोटा भएको API सँग साधारण।

RFC 6585 ↗
431

अनुरोध हेडर क्षेत्रहरू बहुत ठूला

हेडरहरू सर्भरमा प्रक्रिया गर्न बहुत ठूला छन्।

एक हेडर वा कुल हेडर आकार सीमा अधिक गर्छ — सबैभन्दा साधारणतः ठूला कुकीहरू। कुकीहरू खाली गर वा तपाइको ऐप मा संग्रह गर्ने कुरा घटाउनुहोस्।

RFC 6585 ↗
451

कानूनी कारण को लागि उपलब्ध नहोइ

कानूनी माग को कारणले पहुँच अस्वीकार।

संसाधन कानूनी कारणले अवरुद्ध छ — सेन्सरशिप, अदालत आदेश, वा क्षेत्रीय नियमन। संख्या उपन्यास Fahrenheit ४५१ को नोड हो।

RFC 7725 ↗
500

आन्तरिक सर्भर त्रुटि

सर्भरले अप्रत्याशित स्थिति सामना गरेको छ।

सर्भर-पक्ष त्रुटिहरूको लागि सामान्य क्याच-सबै। वास्तविक कारणको लागि सर्भर लगहरू जाँच गर्नुहोस्: अनिपटिएको अपवाद, डाटाबेस त्रुटि, आदि।

RFC 9110 ↗
501

लागू गर नगरिएको

सर्भर अनुरोध गरिएको कार्यक्षमता समर्थन गर्दैन।

उदाहरण, सर्भरले HTTP विधि स्वीकृति दिएन। अभ्यास मा दुर्लभ — सामान्यतः तपाई ४०५ देख्नुहुन्छ।

RFC 9110 ↗
502

खराब गेटवे

सर्भर, गेटवे रूपमा कार्य गर्दै, अपस्ट्रीम सर्भरबाट खराब प्रतिक्रिया पायो।

माइक्रोसेवा आर्किटेक्चरमा साधारण। आपका लोड ब्यालेन्सर वा रिभर्स प्रॉक्सीले ब्याकएन्ड सेवा बाट गलत प्रतिक्रिया पायो।

RFC 9110 ↗
503

सेवा उपलब्ध नहोइ

सर्भर अनुरोध सम्हाल्न अस्थायी रूपमा असक्षम छ।

या तो अनुरक्षणको लागि तल वा अधिभारित। प्रतिक्रियामा Retry-After हेडर समावेश हुनुपर्छ। साधारणतः साजसज्जाहरूको समयमा फिरेको।

RFC 9110 ↗
504

गेटवे समयसीमा

गेटवे सर्भरले अपस्ट्रीम प्रतिक्रियाको लागि प्रतीक्षा गर्दै समय सीमा समाप्त गर्यो।

ब्याकएन्ड सेवा समयमा प्रतिक्रिया दिएन। अपस्ट्रीम सेवा स्वास्थ्य र समयसीमा कन्फिगरेसन जाँच गर्नुहोस्।

RFC 9110 ↗
505

HTTP संस्करण समर्थित नहोइ

सर्भर अनुरोधमा प्रयोग गरिएको HTTP संस्करण समर्थन गर्दैन।

अनुरोधको प्रमुख HTTP संस्करण सर्भरद्वारा समर्थित छैन। आधुनिक क्लाइन्टहरू सँग लगभग कहिले देखिएन।

RFC 9110 ↗
506

वेरिएन्ट पनि वार्ता गर्छ

सर्भर सामग्री वार्ता त्रुटि कन्फिगरेसन गर्छ।

पारदर्शी सामग्री वार्ता लुपमा समाप्त: छनोट गरिएको वेरिएन्ट आफै वार्ता गर्न कन्फिगर गरिएको छ। सर्भर कन्फिगरेसन त्रुटि संकेत गर्छ।

RFC 2295 ↗
507

अपर्याप्त भण्डारण

सर्भर डिस्क स्पेस बाहिर छ।

WebDAV-विशिष्ट मूलमा तर कहिले साधारण सर्भरहरूद्वारा प्रयोग। अनुरोध सहेक्षमता अभावको कारणे अनुरोध सहेक्षमा सक्दैन भन्ने अर्थ।

RFC 4918 ↗
508

लुप पत्ता लगाइएको

सर्भरले अनुरोध प्रक्रिया गर्दै अनन्त लुप पत्ता लगायो।

WebDAV: Depth: infinity अनुरोध प्रक्रिया गर्दै लुप प्रवेश गरेको (उदाहरण गोलाकार बन्धन)। अपरेशन समाप्त गरिएको।

RFC 5842 ↗
510

विस्तारित नहोइ

अनुरोधमा अरू विस्तारहरू आवश्यक छन्।

अप्रचलित HTTP एक्सटेन्सन फ्रेमवर्कबाट: सर्भरलाई अनुरोध पूर्ण गर्न अगाडि अधिक जानकारी चाहिन्छ। आधुनिक वेबमा प्रभावकारी रूपमा अप्रयोग।

RFC 2774 ↗
511

नेटवर्क प्रमाणीकरण आवश्यक

क्लाइन्टले नेटवर्क पहुँच पाउन प्रमाणीकरण गर्नुपर्छ।

बन्दी पोर्टलहरू (होटेल/एयरपोर्ट WiFi) द्वारा प्रयोग गरिएको बाह्य साइटमा पहुँच गर्न अगाडि नेटवर्कमा लग इन गर्नुपर्छ भन्ने संकेत गर्न।

RFC 6585 ↗

सामान्य प्रयोगहरू

  • API डिजाइनको लागी संदर्भREST API डिजाइन गर्दा, प्रत्येक प्रतिक्रियाको लागी सही स्थिति कोड चयन गर्नुहोस्।
  • त्रुटि कोड द्रुत हेर्नुहोस्जब आपको अनुप्रयोग भ्रमित HTTP त्रुटि फिर्ता गर्दछ, यो वास्तवमा के मतलब छ भनी हेर्नुहोस्।
  • HTTP स्थिति कोड सिक्नुहोस्HTTP र REST सिक्न विद्यार्थी र विकासकारहरुको लागी व्यापक संदर्भ।
  • घटना को दौरान द्रुत संदर्भउत्पादन घटनाको दौरान, प्रत्येक स्थिति कोड के मतलब गर्छ भनी द्रुत हेर्नुहोस्।
  • API कागजातको लागि सन्दर्भAPI कागजात लेख्दा, तपाईले फिर्ता गर्ने स्थिति कोडहरूको अधिकार विवरणमा लिंक गर्नुहोस्।

यो कसरी काम गर्छ

यो उपकरण सबै पाँच वर्ग (1xx–5xx) फैलिएका 63 HTTP स्टेटस कोडहरूको हार्डकोड गरिएको लुकअप तालिकाको वरिपरि बनेको क्लाइन्ट-साइड सन्दर्भ हो, हरेक यसलाई परिभाषित गर्ने RFC नम्बरसहित एनोटेट गरिएको। कुनै सर्भर कल छैन, कुनै बाह्य API छैन, र कुनै नेटवर्क अनुरोध छैन — सबै फिल्टरिङ र डिस्प्ले JavaScript को बिल्ट-इन एरे र स्ट्रिङ विधिहरू प्रयोग गरी ब्राउजरमा हुन्छ।

  1. 1
    लुकअप तालिका लोड गरिएको
    63 IANA-दर्ता स्टेटस कोडहरूको पूरा सेट यो उपकरणमा JavaScript एरेको रूपमा सीधै इम्बेड गरिएको छ, हरेक प्रविष्टिमा संख्यात्मक कोड, क्यानोनिकल अंग्रेजी नाम, वर्ग श्रेणी, र यसलाई परिभाषित गर्ने विशेष RFC (जस्तै, धेरैजसो HTTP/1.1 कोडका लागि RFC 9110, 429 Too Many Requests का लागि RFC 6585, 418 I'm a Teapot का लागि RFC 2324)।
  2. 2
    फिल्टर मेमोरीमा चल्छ
    तपाईंले टाइप गर्दा वा वर्ग फिल्टर छान्दा, JavaScript को Array.filter ले मेमोरीमा भएको सूचीमा चल्छ, String.includes प्रयोग गरी तपाईंको प्रश्नलाई स्टेटस कोड नम्बर, क्यानोनिकल नाम, र छोटो र लामो विवरण स्ट्रिङ दुवैसँग मिलाउँदै — कुनै डिबाउन्स ढिलाइ छैन, कुनै सर्भर राउन्ड-ट्रिप छैन।
  3. 3
    विवरण RFC लिंकसहित विस्तार हुन्छ
    हरेक नतिजा एउटा HTML details/summary एलिमेन्टको रूपमा रेन्डर हुन्छ। एउटा प्रविष्टि विस्तार गर्दा लामो-रूपको व्याख्या र rfc-editor.org मा आधिकारिक RFC को प्रत्यक्ष लिंक देखिन्छ, त्यसैले तपाईं कुनै पनि कोडका लागि ठ्याक्कै स्पेसिफिकेसन पाठ पढ्न सक्नुहुन्छ।
  4. 4
    डीप लिंक र क्लिपबोर्ड प्रतिलिपि
    एउटा प्रविष्टि खोल्दा URL ह्यास कोड नम्बरमा अद्यावधिक हुन्छ (जस्तै #404), पृष्ठलाई सेयर र बुकमार्क-मैत्री बनाउँदै। प्रतिलिपि बटनले क्यानोनिकल स्ट्रिङ (जस्तै '404 Not Found') लाई ब्राउजरको navigator.clipboard API मार्फत क्लिपबोर्डमा लेख्छ।

सम्बन्धित उपकरणहरू

📚

उद्धरण जेनेरेटर

वेबसाइट, पुस्तक, जर्नल र YouTube का लागि APA 7, MLA 9, Chicago र Harvard उद्धरण तथा पाठभित्रका सन्दर्भ बनाउनुहोस् — र कपी वा निर्यात गर्न सन्दर्भ सूची तयार गर्नुहोस्। निःशुल्क र निजी।

प्रयास गर्नुहोस्
⏱️

इन्टरभल टाइमर

HIIT र Tabata व्यायामका लागि वार्म-अप, राउन्ड, सेट, ठुलो उल्टो गणना, रङ-सङ्केतित चरण, बिप र ऐच्छिक आवाज निर्देशनसहितको काम र आराम टाइमर।

प्रयास गर्नुहोस्
🔪

भिडियो स्प्लिटर

लामो भिडियोलाई भागहरूमा बाँड्नुहोस्: WhatsApp स्ट्याटस वा स्टोरीजका लागि 60 सेकेन्डका टुक्राहरू, बराबर भागहरूको संख्या, वा इमेलका लागि 25 MB जस्तो साइजभन्दा सानो भागहरू। प्रत्येक भाग वा सबै ZIP का रूपमा सुरक्षित गर्नुहोस्। तपाईंको ब्राउजरमा चल्छ; भिडियो अपलोड हुँदैन।

प्रयास गर्नुहोस्फाइलहरू स्थानीय रहन्छन्

बारम्बार सोधिने प्रश्नहरू