HTTP मेथड टेस्टर — देखें URL कौन-से HTTP मेथड लेता है

सर्वर कैसे बताता है कि कोई URL कौन-से HTTP मेथड सपोर्ट करता है?

हर मेथड का जवाब देकर: RFC 9110 कहता है कि 405 Method Not Allowed जवाब में सपोर्ट वाले मेथड की सूची वाला Allow हेडर हो, 501 का मतलब है कि सर्वर मेथड लागू ही नहीं करता, और OPTIONS रिक्वेस्ट का जवाब भी Allow के साथ दिया जा सकता है। हर general-purpose सर्वर को GET और HEAD सपोर्ट करना ज़रूरी है; जहाँ PUT, PATCH और DELETE इस्तेमाल के लिए नहीं हैं, वहाँ उन्हें ठुकराना या प्रमाणीकरण माँगना चाहिए।

सुरक्षा नोट: Write मेथड सिर्फ़ उन्हीं सिस्टम पर जाँचें जिनकी जाँच की आपको अनुमति है: गुमनाम DELETE स्वीकार करने वाला एंडपॉइंट सच में कुछ मिटा सकता है।

HTTP मेथड टेस्टर कैसे इस्तेमाल करें

रिसोर्स का URL डालें, जैसे https://api.example.com/v1/items।
जाँचने वाले मेथड चुनें। GET, HEAD और OPTIONS डिफ़ॉल्ट रूप से चालू हैं; POST, PUT, PATCH या DELETE सिर्फ़ उस URL के लिए चुनें जो आपका है या जिसे जाँचने की अनुमति है।
"मेथड भेजें" दबाएँ और "मेथड के हिसाब से जवाब" पढ़ें: हर मेथड का स्टेटस और उसका मतलब।
RFC 9110 से टकराने वाली बातों के लिए "निष्कर्ष" और सर्वर क्या घोषित करता है इसके लिए "Allow और CORS हेडर" पढ़ें।

HTTP मेथड टेस्टर की खूबियाँ

एक URL पर GET, HEAD, OPTIONS, POST, PUT, PATCH और DELETE में से कोई भी, हर एक एक बार, भेजता है और सारे स्टेटस कोड साथ-साथ दिखाता है
हर जवाब सीधे शब्दों में समझाता है: सफल जवाब, रीडायरेक्ट (फ़ॉलो नहीं किया), प्रमाणीकरण चाहिए, मना है, मेथड की अनुमति नहीं, सर्वर में लागू नहीं, सर्वर एरर, कोई जवाब नहीं
जवाबों में आया Allow हेडर और Access-Control-Allow-Origin, -Methods व -Headers के मान दिखाता है
RFC 9110 से टकराने वाली बातें पकड़ता है: बिना Allow हेडर का 405, GET चलते हुए HEAD का इनकार, जवाबों के उलट Allow हेडर
उन write मेथड को उजागर करता है जो गुमनाम, ख़ाली रिक्वेस्ट पर 2xx देते हैं, ताकि आप जाँच सकें कि उन्हें प्रमाणीकरण माँगना चाहिए था या नहीं
Write मेथड डिफ़ॉल्ट रूप से बंद हैं, और आपकी ओर से मेथड व URL के सिवा कभी कुछ नहीं भेजा जाता

इनपुट और आउटपुट

इनपुट

जाँचने का URL — सार्वजनिक होस्ट नाम वाला http:// या https:// URL; "example.com/path" में https:// जोड़ दिया जाता है। URL में यूज़र-नेम और पासवर्ड स्वीकार नहीं।
मेथड — GET, HEAD और OPTIONS डिफ़ॉल्ट रूप से चालू; POST, PUT, PATCH और DELETE तब तक बंद जब तक आप न चुनें। इनके सिवा कुछ नहीं चुना जा सकता।

आउटपुट

सारांश — कितने मेथड भेजे गए, कितनों पर 2xx आया, कितने अस्वीकार हुए या अनुमति नहीं थी, और कितनों का जवाब नहीं आया।
मेथड के हिसाब से जवाब — हर मेथड का स्टेटस कोड और कारण, उसका मतलब, Allow हेडर, Content-Type और जवाब का समय।
निष्कर्ष और Allow व CORS हेडर — RFC 9110 से टकराने वाली बातें, 2xx देने वाले write मेथड, और घोषित Allow व CORS मान।
इस टेस्ट के बारे में — ठीक-ठीक क्या भेजा गया, ताकि नतीजा उसी रूप में पढ़ा जाए।

HTTP मेथड टेस्टर का उदाहरण

JSON API एंडपॉइंट जो HEAD मना करता है

इनपुट:

https://api.example.com/v1/items, जिसमें GET, HEAD, OPTIONS, POST और DELETE चुने गए

आउटपुट:

सारांश: भेजे गए मेथड 5 · 2xx जवाब 2 · अस्वीकार या अनुमति नहीं 3 · कोई जवाब नहीं 0
मेथड के हिसाब से जवाब: GET 200 OK — सफल जवाब · HEAD 405 Method Not Allowed — मेथड की अनुमति नहीं (Allow: GET, POST, OPTIONS) · OPTIONS 204 No Content — सफल जवाब · POST 401 Unauthorized — प्रमाणीकरण चाहिए · DELETE 405 Method Not Allowed — मेथड की अनुमति नहीं
निष्कर्ष: GET चलता है पर HEAD मना है; RFC 9110 हर general-purpose सर्वर से GET के साथ HEAD का समर्थन चाहता है। · कोई CORS हेडर नहीं आया। रिक्वेस्ट में Origin हेडर नहीं होता…
Allow और CORS हेडर: Allow हेडर GET, POST, OPTIONS · Access-Control-Allow-Origin नहीं भेजा गया

HTTP मेथड टेस्टर के नतीजे कैसे पढ़ें

2xx का मतलब है कि सर्वर ने इस URL के लिए मेथड का जवाब दिया। POST, PUT, PATCH या DELETE में इसका मतलब यह नहीं कि कुछ बना या मिटा — रिक्वेस्ट में बॉडी और क्रेडेंशियल नहीं थे — बस इतना कि सर्वर ने उसे ठुकराया नहीं।

405 या 501 का मतलब है कि मेथड इस URL पर उपलब्ध नहीं; 401 या 403 का मतलब है कि वह शायद है पर प्रमाणीकरण या अनुमति चाहिए। API से अपेक्षा यही है कि वह जो मेथड लागू नहीं करता उन्हें 405 और Allow हेडर के साथ ठुकराए।

3xx दिखाया जाता है, फ़ॉलो नहीं होता: redirect वाले URL पर मेथड अलग बर्ताव कर सकता है, इसलिए उस URL को भी जाँचें।

"कोई जवाब नहीं" का मतलब है कि 8 सेकंड में जवाब नहीं आया, कनेक्शन फ़ेल हुआ या नाम resolve नहीं हुआ; कुछ मेथड चुपचाप गिराने वाला फ़ायरवॉल भी ऐसा ही दिखता है।

HTTP मेथड टेस्टर कब इस्तेमाल करें

यह जाँचना कि API जो मेथड लागू नहीं करता उन्हें 405 और सही Allow हेडर से ठुकराता है।
सिक्योरिटी टेस्ट: पक्का करना कि किसी रिसोर्स पर DELETE, PUT या PATCH बिना प्रमाणीकरण स्वीकार नहीं होते।
किसी क्लाइंट को मिले "405 Method Not Allowed" की जाँच, यह देखकर कि उस URL पर सर्वर असल में क्या स्वीकार करता है।
मॉनिटरिंग और कैशिंग टूल्स के लिए पक्का करना कि जहाँ GET चलता है वहाँ HEAD भी चलता है।

समस्या निवारण

हर मेथड "समय पर जवाब नहीं मिला" दिखाता है: होस्ट धीमा है या क्लाउड नेटवर्क से आने वाले कनेक्शन गिरा देता है। फिर कोशिश करें, या अपने कंप्यूटर से curl से जाँचें।
पेज URL को सार्वजनिक न होने की वजह से ठुकराता है: निजी, लोकल और आरक्षित पतों और इस साइट के अपने पतों से कभी संपर्क नहीं किया जाता।
"आप अनुरोध सीमा तक पहुँच गए हैं": हर मेथड प्रति-मिनट कोटे में एक बाहर जाने वाली रिक्वेस्ट गिना जाता है। कम मेथड जाँचें, एक मिनट रुकें, या बड़े कोटे के लिए साइन-इन करें।
हर मेथड 403 या एक ही पेज लौटाता है: साइट के आगे का फ़ायरवॉल या बॉट-सुरक्षा ऐप्लिकेशन की जगह जवाब देती है; तब नतीजे उस परत के हैं, API के नहीं।

HTTP मेथड टेस्टर के बारे में अक्सर पूछे जाने वाले सवाल

क्या मैं रिक्वेस्ट बॉडी या अपने हेडर भेज सकता हूँ?

नहीं। टेस्टर रिक्वेस्ट प्रॉक्सी नहीं है: रिक्वेस्ट में आपकी बॉडी, कुकी या हेडर नहीं जा सकते, सिर्फ़ मेथड, URL, तय User-Agent और relay का X-Mutqan-Relay: 1 हेडर। फिर भी आपका डाला URL, पाथ और query string समेत, वैसा ही भेजा जाता है, और POST, PUT, PATCH और DELETE किसी असली रिसोर्स पर असर डाल सकते हैं, इसलिए सिर्फ़ अपने या अनुमति वाले URL जाँचें। अपने कंप्यूटर से पूरी रिक्वेस्ट भेजनी हो तो HTTP रिक्वेस्ट से cURL कन्वर्टर आपके लिए कमांड लिख देता है।

क्या मेरे API पर DELETE या PUT भेजना सुरक्षित है?

रिक्वेस्ट में न बॉडी होती है न क्रेडेंशियल, इसलिए सुरक्षित एंडपॉइंट को इन्हें 401, 403 या 405 से ठुकराना चाहिए। गुमनाम DELETE पर 2xx देने वाले एंडपॉइंट ने शायद सच में उस पर अमल कर दिया हो। सिर्फ़ अपने या अनुमति वाले URL जाँचें, और write मेथड असली डेटा की जगह टेस्ट रिसोर्स पर चलाएँ।

किसी मेथड पर सिर्फ़ 3xx क्यों दिखता है?

Redirect दिखाए जाते हैं, फ़ॉलो नहीं होते: रिक्वेस्ट स्टेटस दर्ज करके रुक जाती है, क्योंकि फ़ॉलो करने का मतलब होता मेथड को किसी दूसरे URL पर भेजना। अगर redirect वाला URL ही आपके काम का है तो उसे जाँचें।

मेरा API CORS सपोर्ट करता है, फिर CORS हेडर क्यों नहीं दिखते?

रिक्वेस्ट में Origin हेडर नहीं होता, और कई सर्वर Access-Control-Allow-* हेडर सिर्फ़ उन्हीं cross-origin रिक्वेस्ट को देते हैं जिनमें यह हो। CORS टेस्टर आपके चुने origin के साथ असली preflight भेजता है।

मैं इसे कितनी बार चला सकता हूँ?

हर मेथड एक बाहर जाने वाली रिक्वेस्ट है, जो उन बाक़ी टूल्स के साथ साझा प्रति-मिनट कोटे में गिनी जाती है जो आपकी ओर से साइटों से जुड़ते हैं। सातों मेथड जाँचने में साइन-इन न किए विज़िटर का ज़्यादातर कोटा लग जाता है; साइन-इन करने से कोटा बढ़ता है। कोटा ख़त्म होने पर पेज बताता है कि कितना रुकना है।

तकनीकी नोट्स

RFC 9110 का §9 मेथड परिभाषित करता है: GET और HEAD safe हैं, PUT और DELETE idempotent, POST दोनों में से कुछ नहीं, और हर general-purpose सर्वर को GET और HEAD सपोर्ट करना ज़रूरी है। 405 Method Not Allowed जवाब में रिसोर्स के सपोर्ट वाले मेथड की सूची वाला Allow हेडर होना ज़रूरी है (§15.5.6, §10.2.1), और 501 Not Implemented का मतलब है कि सर्वर मेथड को पहचानता ही नहीं। PATCH को RFC 5789 परिभाषित करता है।

हर जाँच Mutqan सर्वर की अपने डायग्नॉस्टिक relay से की गई एक रिक्वेस्ट है: होस्ट DNS-over-HTTPS से resolve होता है और तब तक ठुकराया जाता है जब तक उसके सारे पते सार्वजनिक न हों, रिक्वेस्ट में सिर्फ़ मेथड, URL, तय User-Agent और relay का X-Mutqan-Relay: 1 हेडर होता है, और जवाब की बॉडी पढ़ी नहीं जाती। TRACE (जो रिक्वेस्ट को वैसा ही लौटाता है) और CONNECT (जो टनल खोलता है) इस सेट में नहीं हैं और कभी नहीं भेजे जाते।

CORS हेडर (Access-Control-Allow-Origin, -Methods, -Headers) जैसे जवाबों में आए वैसे दिखाए जाते हैं। रिक्वेस्ट में Origin हेडर नहीं होता, इसलिए origin के हिसाब से CORS जवाब बदलने वाला सर्वर यहाँ शायद कुछ न भेजे; ब्राउज़र का असली preflight Origin और Access-Control-Request-Method वाला OPTIONS होता है, जिसे CORS टेस्टर भेजता है।

सीमाएँ और कार्यप्रणाली

यह रिक्वेस्ट प्रॉक्सी नहीं है: बॉडी, कुकी, टोकन या कस्टम हेडर नहीं भेजे जा सकते, इसलिए इन्हें माँगने वाला एंडपॉइंट सिर्फ़ इनकार से जवाब देता है।

URL वैसा ही भेजा जाता है जैसा आप डालते हैं, पाथ और query string समेत, और POST, PUT, PATCH व DELETE बिना बॉडी के भी किसी असली रिसोर्स पर असर डाल सकते हैं: सिर्फ़ अपने या अनुमति वाले URL जाँचें।

यहाँ सिर्फ़ बताए गए सात मेथड हैं; TRACE, CONNECT और कस्टम मेथड (PROPFIND, PURGE) कभी नहीं भेजे जाते।

रिक्वेस्ट आपके कंप्यूटर से नहीं, Mutqan सर्वर के नेटवर्क से जाती हैं; क्लाउड ट्रैफ़िक, क्षेत्र या बॉट के साथ अलग बर्ताव करने वाले सर्वर आपको अलग जवाब दे सकते हैं।

हर मेथड की एक रिक्वेस्ट बस एक झलक है: रेट लिमिट, अलग बैकएंड वाले लोड बैलेंसर और कैश अगली रिक्वेस्ट पर जवाब बदल सकते हैं।

सुरक्षा और गोपनीयता

URL Mutqan सर्वर को भेजा जाता है, जो चुने गए मेथड अपने नेटवर्क से उस होस्ट को भेजता है; आपके लिखे में से सिर्फ़ URL होस्ट तक पहुँचता है, और कुछ भी सहेजा नहीं जाता।

संदर्भ

RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
Allow header — MDNMDN Web Docs (Mozilla)Allow रिस्पॉन्स हेडर: रिसोर्स किन मेथड को सपोर्ट करता है, और 405 जवाब में इसे भेजना क्यों ज़रूरी है।
OPTIONS request method — MDNMDN Web Docs (Mozilla)OPTIONS: सर्वर से पूछना कि URL किन मेथड की अनुमति देता है, और CORS preflight के रूप में इसकी भूमिका।