HTTP 407 sen uzebla Proxy-Authenticate-defio

Kliento ne povas elekti aŭtentikigan mekanismon nur el statusnumero. La respondo de la prokuro devas priskribi, kion ĝi akceptas.

HTTP postulas, ke prokuro generanta 407 sendu Proxy-Authenticate-defion. Por Basic-servo simpla ekzemplo estas:

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

La cifereca statuso, la kaplinlinoma nomo kaj la skemo-specifa sintakso ĉiuj gravas. Marka erarpaĝo kun la vorto authentication en sia korpo ne anstataŭas la kaplinion. Propraj efektivigoj ankaŭ devas sendi kompletan HTTP 407-respondon, inkluzive de la kaplinifinaĵo kaj la kadrigo de la korpo.

Ekzamenu la respondon, kiu atingis ĉi tiun klienton

Kaptu la statusajn kaj defiajn kampojn post forigo de sekretaj valoroj. Peranto eble transformis la respondon, aŭ propra prokuro eble konstruis nevalidan defion. Komparu tiun pruvon kun la propra transakcia protokolo de la prokuro.

Se la servo anstataŭe sendas 405 aŭ alian eraron, ne reetikedi ĉiun tian respondon kiel 407 ene de propra kliento. Vi kaŝus verajn malsukcesojn de la metoda politiko kaj ankoraŭ havus neniun fidindan skemo-negocadon. Riparu la konduton de la servo aŭ uzu ĝian dokumentitan subtenatan aŭtentikigan vojon.

Pluraj defioj ankaŭ postulas veran HTTP-analizilon. Komo povas apartigi parametrojn aŭ defiojn; blinda divido de la tuta kaplinio ĉe komoj povas difekti realm en citiloj. Uzu la subtenatan aŭtentikigan efektivigon de la kliento anstataŭ sinsekvo de signoĉenaj anstataŭigoj.

Nur post kiam la defio estas uzebla, havas sencon esplori, kial la identigila provizanto ne redonis konton.