उपयोग करने योग्य Proxy-Authenticate चुनौती के बिना HTTP 407

क्लाइंट केवल स्थिति संख्या से प्रमाणीकरण तंत्र नहीं चुन सकता। प्रॉक्सी की प्रतिक्रिया में यह वर्णित होना चाहिए कि वह क्या स्वीकार करती है।

HTTP के अनुसार 407 उत्पन्न करने वाली प्रॉक्सी को Proxy-Authenticate चुनौती भेजनी होती है। Basic सेवा के लिए एक सरल उदाहरण है:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

संख्यात्मक स्थिति, हेडर का नाम और स्कीम-विशिष्ट वाक्य-रचना, सभी महत्वपूर्ण हैं। जिसके मुख्य भाग में authentication शब्द हो ऐसा ब्रांडेड त्रुटि पृष्ठ हेडर का विकल्प नहीं है। कस्टम कार्यान्वयनों को भी हेडर समाप्ति और मुख्य भाग की फ्रेमिंग सहित पूर्ण HTTP 407 प्रतिक्रिया भेजनी चाहिए।

इस क्लाइंट तक पहुँची प्रतिक्रिया की जाँच करें

गोपनीय मान हटाने के बाद स्थिति और चुनौती फ़ील्ड दर्ज करें। कोई मध्यस्थ प्रतिक्रिया बदल सकता है, या कस्टम प्रॉक्सी ने अमान्य चुनौती बनाई हो सकती है। उस साक्ष्य की तुलना प्रॉक्सी के अपने लेन-देन लॉग से करें।

यदि सेवा इसके बजाय 405 या कोई अन्य त्रुटि भेजती है, तो कस्टम क्लाइंट के भीतर ऐसी हर प्रतिक्रिया को 407 के रूप में पुनः लेबल न करें। आप विधि-नीति की वास्तविक विफलताओं को छिपा देंगे और फिर भी विश्वसनीय स्कीम बातचीत नहीं होगी। सेवा का व्यवहार ठीक करें या उसका प्रलेखित समर्थित प्रमाणीकरण मार्ग उपयोग करें।

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

चुनौती उपयोग योग्य होने के बाद ही यह जाँचना अर्थपूर्ण है कि क्रेडेंशियल प्रदाता ने खाता क्यों नहीं लौटाया।