વાપરી શકાય તેવા 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 બગડી શકે છે. શ્રેણીબદ્ધ સ્ટ્રિંગ બદલાવને બદલે ક્લાયન્ટનું સમર્થિત પ્રમાણીકરણ અમલીકરણ વાપરો.

પડકાર વાપરી શકાય તેવો થયા પછી જ ઓળખપત્ર પ્રદાતાએ કેમ ખાતું પરત ન આપ્યું તેની તપાસ કરવી અર્થપૂર્ણ છે.