HTTP 407 uden en brugbar Proxy-Authenticate-udfordring

En klient kan ikke vælge en godkendelsesmekanisme ud fra et statusnummer alene. Proxyens svar skal beskrive, hvad den accepterer.

HTTP kræver, at en proxy, der genererer 407, sender en Proxy-Authenticate-udfordring. For en Basic-tjeneste er et enkelt eksempel:

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

Den numeriske status, headernavnet og den skemaspecifikke syntaks betyder alle noget. En brandet fejlside med ordet authentication i brødteksten er ikke en erstatning for headeren. Tilpassede implementeringer skal også sende et komplet HTTP 407-svar, inklusive headerens afslutning og brødtekstens indramning.

Undersøg det svar, der nåede denne klient

Registrér status- og udfordringsfelterne, efter at hemmelige værdier er fjernet. En mellemled kan have ændret svaret, eller en tilpasset proxy kan have konstrueret en ugyldig udfordring. Sammenlign disse beviser med proxyens egen transaktionslog.

Hvis tjenesten i stedet sender 405 eller en anden fejl, må du ikke omdøbe hvert sådant svar til 407 i en tilpasset klient. Du ville skjule egentlige fejl i metodepolitikken og stadig ikke have nogen pålidelig forhandling om skemaet. Ret tjenestens adfærd, eller brug dens dokumenterede understøttede godkendelsesvej.

Flere udfordringer kræver også en rigtig HTTP-parser. Et komma kan adskille parametre eller udfordringer; blind opdeling af hele headeren på kommaer kan ødelægge et realm i anførselstegn. Brug klientens understøttede godkendelsesimplementering i stedet for en række strengudskiftninger.

Først når udfordringen er brugbar, giver det mening at undersøge, hvorfor legitimationsudbyderen ikke returnerede en konto.