इस स्थिति के लिए HTTP सही कोड प्रतिक्रिया 403 निषिद्ध होगी :
सर्वर अनुरोध को समझ गया, लेकिन इसे पूरा करने से इनकार कर रहा है। प्राधिकरण मदद नहीं करेगा और अनुरोध को दोहराया नहीं जाना चाहिए। यदि अनुरोध विधि HEAD नहीं थी और सर्वर यह सार्वजनिक करना चाहता है कि अनुरोध क्यों पूरा नहीं हुआ है, तो यह इकाई में इनकार के कारण का वर्णन करेगा। यदि सर्वर क्लाइंट को यह जानकारी उपलब्ध नहीं कराना चाहता है, तो इसके बजाय स्थिति कोड 404 (नहीं मिला) का उपयोग किया जा सकता है।
(हालांकि 403 प्रतिक्रिया की परिभाषा में कहा गया है कि "प्राधिकरण मदद नहीं करेगा", IMO को विशेष रूप से HTTP बेसिक / डाइजेस्ट प्रमाणीकरण के संदर्भ में समझा जाना चाहिए , जिसके लिए स्थिति कोड 401 अनधिकृत का उपयोग किया जाना चाहिए। क्योंकि आप उपयोग नहीं कर रहे हैं। उन प्रमाणीकरण विधियों में से कोई भी, 403 आपके मामले में उपयुक्त स्थिति कोड है।)
हालांकि, एक 403 स्थिति कोड का उपयोग कर (या कम से कम दृढ़ता से तात्पर्य है) तथ्य यह है कि वहाँ से पता चलता है है , उस URL वाला पेज भले ही सर्वर इसे वितरित करने के लिए मना कर रहा है। यह कुछ ऐसा है कि आप संभावित घुसपैठियों से छुपाने के लिए चाहते हो सकता है है के रूप में, HTTP / 1.1 मानक स्पष्ट रूप से अनुमति देता है 404 नहीं मिला स्थिति कोड के बजाय वापस करने ( जोर मेरा):
सर्वर को अनुरोध-यूआरआई से मेल खाते हुए कुछ भी नहीं मिला है। कोई संकेत नहीं दिया जाता है कि क्या स्थिति अस्थायी या स्थायी है। 410 (गया) स्थिति कोड SHOULD का उपयोग किया जाना चाहिए यदि सर्वर को पता है, कुछ आंतरिक रूप से कॉन्फ़िगर करने योग्य तंत्र के माध्यम से, कि एक पुराना संसाधन स्थायी रूप से अनुपलब्ध है और इसका कोई अग्रेषण पता नहीं है।
यह स्थिति कोड आमतौर पर तब उपयोग किया जाता है जब सर्वर यह बताना नहीं चाहता कि अनुरोध को अस्वीकार क्यों किया गया है, या जब कोई अन्य प्रतिक्रिया लागू नहीं होती है।
बेशक, इस तरह के छिपाव को प्रभावी बनाने के लिए, आपके द्वारा लौटाए जाने वाले 404 त्रुटि पृष्ठ को वास्तविक गैर-मौजूद पृष्ठों के लिए वापस आने के समान दिखाई देने की आवश्यकता है । अन्यथा, यह केवल सबसे बेवकूफ और सबसे आकस्मिक हमलावरों को बेवकूफ बना देगा। (यदि आपका लक्ष्य केवल Google के सूचकांक से पृष्ठों को बाहर रखना है, तो 403 प्रतिक्रिया ऐसा ही करेगी।)
आपके प्रश्न में सुझाई गई अन्य संभावित प्रतिक्रियाओं और अन्य उत्तरों के बारे में क्या?
जैसा कि मैंने पहले उल्लेख किया है, मुझे विश्वास नहीं है कि यहां 401 प्रतिक्रिया उपयुक्त है। यह व्यवहार में काम कर सकता है , अधिकांश ब्राउज़रों और खोज इंजनों के रूप में इनफ़ॉगर किसी भी विकृत या गैर-मान्यता प्राप्त 4 xx श्रृंखला प्रतिक्रिया कोड का इलाज करेगा जैसे कि यह 404 था, लेकिन यह अभी भी HTTP कल्पना के अनुसार मान्य नहीं है, और इसे पसंद करने का कोई व्यावहारिक कारण नहीं है। 403 या 404 से अधिक।
301 (या 302) का उपयोग करके एक अलग "404 त्रुटि" पृष्ठ पर पुनर्निर्देशित करें, यह एक भयानक अभ्यास है जो मैला मोड_ब्राइट ट्यूटोरियल्स द्वारा फैलाया गया है, और सीधे 404 प्रतिक्रिया वापस करने की तुलना में बिल्कुल कोई रिड्यूसिंग सुविधाएँ नहीं हैं:
यह आगंतुकों के लिए भ्रामक है, क्योंकि वे जिस URL पर जाने का प्रयास कर रहे थे , वह त्रुटि पृष्ठ के URL से बदल जाता है। इस प्रकार, वे एक संदेश को यह कहते हुए देखते हैं कि वे एक गैर-मौजूद पृष्ठ पर पहुंच गए हैं, लेकिन कोई भी आसानी से दिखाई देने वाला संकेत नहीं है कि वे जिस पृष्ठ पर जाने का प्रयास कर रहे थे, और वह आसानी से URL में किसी भी स्पष्ट टाइपो को ठीक करने जैसी किसी भी पुनर्प्राप्ति रणनीति का प्रयास नहीं कर सकता है, या इसे Google या Wayback मशीन में कॉपी-पेस्ट करना।
यह खोज इंजनों को भ्रमित कर सकता है, खासकर यदि आपका 404 पृष्ठ robots.txt में अस्वीकृत है , या यदि यह गलत तरीके से वास्तविक 404 स्थिति कोड ( "सॉफ्ट 404" ) के बजाय 200 ओके प्रतिक्रिया देता है , तो संभवतः आपका 404 पृष्ठ खोज में दिखाई देगा। यादृच्छिक खोज शब्दों के लिए परिणाम।
यह आपके सर्वर पर अतिरिक्त लोड (कम मात्रा) का कारण बनता है, आगंतुकों के लिए प्रतिक्रिया समय बढ़ाता है और संभावित रूप से आपकी साइट को क्रॉल करने वाले खोज इंजन को धीमा कर देता है, क्योंकि अब एक गैर-मौजूद (या छुपा हुआ) पृष्ठ के लिए हर अनुरोध में एक अतिरिक्त HTTP दौर शामिल है- ट्रिप।
इसका कोई एसईओ लाभ नहीं है, क्योंकि 404 पृष्ठ पर पुनर्निर्देशित पृष्ठों के किसी भी "लिंक जूस" को वैसे भी खो दिया जाता है।
(निश्चित रूप से, एक स्थिति जहां आप 404 प्रतिक्रिया के बजाय 301 रीडायरेक्ट का उपयोग करना चाहते हैं, जब पृष्ठ वास्तव में स्थानांतरित हो गया है, और आप आगंतुक को उसके सही स्थान पर पुनर्निर्देशित कर सकते हैं। लेकिन यह मामला यहां चर्चा नहीं है।)
अंत में, मैं यहां कई टिप्पणियों में व्यक्त की गई भावना को प्रतिध्वनित करना चाहूंगा, कि आपके व्यवस्थापक पृष्ठों को इस तरह "छिपाना" उचित पासवर्ड-आधारित प्रमाणीकरण के लिए पर्याप्त विकल्प नहीं है । कहा कि, यदि आपके पास पहले से ही एक सुरक्षित प्रमाणीकरण प्रणाली स्थापित है, तो पन्नों को छिपाना एक अतिरिक्त परत के रूप में उपयोगी हो सकता है, भले ही गहराई दृष्टिकोण में एक रक्षा में काफी कमजोर हो ।