लिंक की जाँच में 405: HEAD और GET की तुलना करें

सिर्फ संख्या देखकर लिंक को टूटा न मानें

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

Stack Overflow के एक प्रश्न में जाँच को GET से HEAD करने पर 405 आने लगा। Reddit के दूसरे प्रश्न में प्रोग्राम से लिंक जाँचने पर गलत चेतावनियों का उल्लेख है। ये लोगों की बताई समस्याएँ हैं, आपके मामले के कारण का प्रमाण नहीं। इस प्रक्रिया में पहले अनुरोध और सामग्री की तुलना की जाती है, फिर तय होता है कि लिंक, जाँच उपकरण या साइट की सेटिंग में सुधार चाहिए।

HEAD और GET में क्या अंतर है

GET संसाधन का एक रूप माँगता है; HEAD, GET से संबंधित मेटाडेटा माँगता है लेकिन उत्तर का मुख्य भाग नहीं। MDN यह अंतर समझाता है। केवल हेडर माँगने से डेटा स्थानांतरण कम हो सकता है, लेकिन इससे पेज पढ़ा नहीं जाता और अपेक्षित दस्तावेज़ होने की पुष्टि नहीं होती। यह भी सुनिश्चित नहीं कि ऐप या बीच का सर्वर दोनों विधियाँ सही ढंग से संभाले। अस्वीकृति पर इस्तेमाल हुई विधि दर्ज करें।

RFC 9110 के अनुसार 405 उत्तर में Allow हेडर होना चाहिए, जिसमें संसाधन की वर्तमान समर्थित विधियाँ हों। उपकरण दिखाता है तो उसे देखें। गायब हो तो अनुपस्थिति लिखें; उसका मूल्य न गढ़ें और हर विधि खोल देने को समाधान न मानें। उदाहरण का उत्तर केवल समझाने के लिए है, किसी वास्तविक साइट का कैप्चर नहीं। Allow भी आवश्यक विधि की जाँच का विकल्प नहीं है।

HTTP/1.1 405 Method Not Allowed
Allow: GET

समझ आने वाले अनुरोधों की तुलना करें

यदि आप साइट के प्रशासक हैं और टर्मिनल जानते हैं, तो एक ही सार्वजनिक, केवल पढ़ने वाले पते पर HEAD और GET की तुलना करें। कमांड हेडर दिखाते हैं; दूसरा मुख्य भाग प्राप्त करने के बाद हटाता है, इसलिए डेटा डाउनलोड हो सकता है। example.invalid को अपनी अधिकृत साइट के पेज से बदलें। यह काल्पनिक डोमेन है, उपलब्ध सेवा नहीं। खरीद, मिटाने या लॉगआउट जैसी कार्रवाइयों को परीक्षण न बनाएँ।

URL और अपने नियंत्रण वाली परिस्थितियाँ समान रखें। समय, विधि, स्थिति और रीडायरेक्ट लिखें। कमांड रीडायरेक्ट का पीछा नहीं करते: पहले उसका गंतव्य देखें, फिर तय करें कि वहाँ दोहराना है या नहीं। क्रेडेंशियल न जोड़ें और निजी कुकी सार्वजनिक उपकरण में न डालें। लॉगइन ब्राउज़र तथा दूसरी मशीन का अनाम अनुरोध समान तुलना नहीं हैं। विधि को कारण बताने से पहले यह अंतर दर्ज करें।

curl --head --max-time 20 "https://example.invalid/guide"
curl --silent --show-error --max-time 20 --dump-header - --output /dev/null "https://example.invalid/guide"

जल्द निष्कर्ष निकाले बिना परिणाम समझें

तुलनीय परिस्थितियों में HEAD को 405 और GET को 200 मिले तो कह सकते हैं कि दोनों अनुरोधों को अलग उत्तर मिला। फिर भी पेज खोलकर सामग्री देखनी बाकी है। GET को भी 405 मिले तो केवल HEAD की समस्या सिद्ध नहीं हुई। GET को 404 मिले तो पहले HEAD परीक्षण ने पेज के अस्तित्व की पुष्टि नहीं की थी। अवलोकन और अनुमान अलग रखें।

त्रुटि हटाने के लिए फ़ॉर्म को POST से GET न करें। इससे व्यवहार बदल सकता है और डेटा पते में दिख सकता है। सुविधा के लिए सुरक्षा नियंत्रण बंद न करें और लिखने वाली विधियाँ सक्षम न करें। अपनी साइट पर परिणाम उस व्यक्ति को दें जो रूट तथा सर्वर नियम जाँचता है। दूसरी साइट पर उचित सार्वजनिक लिंक माँगें या संवेदनशील जानकारी के बिना समस्या बताएँ।

WikiURL से एक अतिरिक्त जाँच करें

WikiURL के URL जाँच उपकरण में पूरा सार्वजनिक पता चिपकाएँ और HTTP स्थिति तथा मिले अंतिम पते को सुरक्षित रखें। यह सेवा के सर्वर से किया गया अतिरिक्त अवलोकन है। इसे अपने ब्राउज़र, लॉगइन सत्र या पिछले कमांड के समान न मानें। इंटरफ़ेस में HEAD और GET चुनने का मैनुअल विकल्प नहीं है; जो तुलना वह दिखाता नहीं, उसका दावा न करें।

फिर वास्तविक गंतव्य ब्राउज़र में खोलें और देखें कि लक्षित लोगों को सही पेज मिलता है। दोनों परिणाम अलग हों तो उनकी परिस्थितियाँ भी सुरक्षित रखें। 200 सामग्री या सुरक्षा का प्रमाणपत्र नहीं; एक 405 अकेले लिंक हटाने का निर्णय नहीं करता। उद्देश्य विशिष्ट हिस्से को सुधारने के लिए प्रमाण जुटाना है, किसी लेबल को पूरा निदान मान लेना नहीं।

साझा करने से पहले जाँच योग्य निर्णय लिखें

छोटा रिकॉर्ड बनाएँ: URL, तारीख, उपकरण, ज्ञात विधि या विधि देखी नहीं गई, स्थिति, अंतिम गंतव्य और जाँची गई सामग्री। बाकी परीक्षण लंबित लिखें। आवश्यक हेडर रखते समय टोकन, कुकी और व्यक्तिगत जानकारी हटाएँ। दूसरे समीक्षक को यह सार तथा अपेक्षित व्यवहार दें, ऐसा निष्कर्ष नहीं जिसे अवलोकन अभी समर्थन नहीं देते।

ठोस सुधार के बाद उचित सीमा में दोबारा जाँचें और सामग्री की पुष्टि करें, फिर WikiURL से पता छोटा करें या QR बनाएँ। ये स्वरूप साझा करना आसान करते हैं, लेकिन सर्वर की समर्थित विधि नहीं बदलते और संसाधन नहीं सुधारते। प्रकाशित फ़ाइल के साथ मूल संदर्भ लिंक रखें। इससे क्लाइंट का अंतर, अस्वीकृत विधि और गलत गंतव्य अलग समझेंगे तथा एक उत्तर पर वैध पता नहीं मिटाएँगे।