वापरण्यायोग्य Proxy-Authenticate आव्हानाशिवाय HTTP 407

क्लायंट केवळ स्थिती क्रमांकावरून प्रमाणीकरण पद्धत निवडू शकत नाही. प्रॉक्सीच्या प्रतिसादात ते काय स्वीकारते याचे वर्णन असणे आवश्यक आहे.

407 निर्माण करणाऱ्या प्रॉक्सीने Proxy-Authenticate आव्हान पाठवणे HTTP आवश्यक करते. Basic सेवेसाठी एक सोपे उदाहरण:

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

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

या क्लायंटपर्यंत पोहोचलेल्या प्रतिसादाची तपासणी करा

गोपनीय मूल्ये काढून टाकल्यानंतर स्थिती आणि आव्हान फील्ड्स नोंदवा. मध्यस्थाने प्रतिसाद बदलला असू शकतो, किंवा सानुकूल प्रॉक्सीने अवैध आव्हान तयार केले असू शकते. त्या पुराव्याची प्रॉक्सीच्या स्वतःच्या व्यवहार लॉगशी तुलना करा.

सेवा त्याऐवजी 405 किंवा अन्य त्रुटी पाठवत असल्यास, सानुकूल क्लायंटमध्ये अशा प्रत्येक प्रतिसादाला 407 असे पुन्हा लेबल करू नका. आपण पद्धत-धोरणातील खऱ्या अपयशांना लपवाल आणि तरीही विश्वासार्ह योजना वाटाघाटी नसेल. सेवेचे वर्तन दुरुस्त करा किंवा तिचा दस्तऐवजीकृत समर्थित प्रमाणीकरण मार्ग वापरा.

एकापेक्षा जास्त आव्हानांसाठी खरा HTTP पार्सरही आवश्यक आहे. स्वल्पविराम मापदंड किंवा आव्हाने वेगळी करू शकतो; संपूर्ण हेडर स्वल्पविरामांवर आंधळेपणाने विभाजित केल्यास अवतरण चिन्हांतील realm बिघडू शकते. क्रमिक स्ट्रिंग बदलांऐवजी क्लायंटची समर्थित प्रमाणीकरण अंमलबजावणी वापरा.

आव्हान वापरण्यायोग्य झाल्यानंतरच क्रेडेन्शियल पुरवठादाराने खाते का परत केले नाही याची तपासणी करणे अर्थपूर्ण आहे.