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 særegen for skjemaet, er alle viktige. En merkevarelagt feilside med ordet authentication i brødteksten er ikke en erstatning for headeren. Egne implementasjoner må også sende et fullstendig HTTP 407-svar, inkludert avslutningen av headeren og innrammingen av brødteksten.

Inspiser svaret som nådde denne klienten

Registrer status- og utfordringsfeltene etter at hemmelige verdier er fjernet. En mellomliggende part 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 dens dokumenterte støttede autentiseringsvei.

Flere utfordringer krever også en ekte HTTP-parser. Et komma kan skille parametere eller utfordringer; å dele hele headeren 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, er det meningsfullt å undersøke hvorfor legitimasjonsleverandøren ikke returnerte en konto.