HTTP 407 uten en brukbar Proxy-Authenticate-utfordring

En klient kan ikke velge en autentiseringsmekanisme ut fra et statusnummer alene. Proxyens svar må beskrive hva den godtar.

HTTP krever at en proxy som genererer 407, sender en Proxy-Authenticate-utfordring. For en Basic-tjeneste er et enkelt eksempel:

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

Den numeriske statusen, headernavnet og syntaksen som er spesifikk for skjemaet, er alle viktige. En merkevarelagt feilside med ordet authentication i brødteksten er ikke en erstatning for hodet. Egne implementasjoner må også sende et fullstendig HTTP 407-svar, inkludert avslutningen av hodet og innrammingen av brødteksten.

Undersøk svaret som nådde denne klienten

Registrer status- og utfordringsfeltene etter at hemmelige verdier er fjernet. En mellomledd kan ha endret svaret, eller en egen proxy kan ha bygget en ugyldig utfordring. Sammenlign disse bevisene med proxyens egen transaksjonslogg.

Hvis tjenesten i stedet sender 405 eller en annen feil, må du ikke merke hvert slikt svar som 407 i en egen klient. Du ville skjule reelle feil i metodepolicyen og fortsatt ikke ha noen pålitelig forhandling om skjemaet. Reparer tjenestens oppførsel eller bruk den dokumenterte og støttede autentiseringsveien.

Flere utfordringer krever også en ekte HTTP-parser. Et komma kan skille parametere eller utfordringer; å dele hele hodet blindt på kommaer kan ødelegge et realm i anførselstegn. Bruk klientens støttede autentiseringsimplementasjon i stedet for en rekke strengerstatninger.

Først når utfordringen er brukbar, gir det mening å undersøke hvorfor legitimasjonsleverandøren ikke returnerte en konto.