HTTP 407 utan ei brukbar Proxy-Authenticate-utfordring

Ein klient kan ikkje velje ein autentiseringsmekanisme ut frå eit statusnummer åleine. Svaret frå proxyen må skildre kva det godtek.

HTTP krev at ein proxy som genererer 407, sender ei Proxy-Authenticate-utfordring. For ein Basic-teneste er eit enkelt døme:

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

Den numeriske statusen, hovudnamnet og syntaksen som er særskild for skjemaet, er alle viktige. Ei merkevarelagd feilside med ordet authentication i brødteksten er ikkje eit høveleg erstatning for hovudet. Eigne implementasjonar må òg sende eit fullstendig HTTP 407-svar, inkludert avsluttinga av hovudet og innramminga av brødteksten.

Undersøk svaret som nådde denne klienten

Registrer status- og utfordringsfelta etter at hemmelege verdiar er fjerna. Eit mellomledd kan ha endra svaret, eller ein eigen proxy kan ha bygd ei ugyldig utfordring. Samanlikn desse prova med den eigne transaksjonsloggen til proxyen.

Viss tenesta i staden sender 405 eller ein annan feil, må du ikkje merke kvart slikt svar som 407 i ein eigen klient. Du ville skjule reelle feil i metodepolitikken og framleis ikkje ha noka påliteleg forhandling om skjemaet. Reparer åtferda til tenesta eller bruk den dokumenterte og støtta autentiseringsvegen.

Fleire utfordringar krev òg ein ekte HTTP-parsar. Eit komma kan skilje parametrar eller utfordringar; å dele heile hovudet blindt på komma kan øydeleggje eit realm i gåseauge. Bruk den støtta autentiseringsimplementasjonen til klienten i staden for ei rad med strengbyte.

Fyrst når utfordringa er brukbar, gjev det meining å undersøkje kvifor leverandøren av legitimasjon ikkje returnerte ein konto.