HTTP 407 sonder 'n bruikbare Proxy-Authenticate-uitdaging

'n Kliënt kan nie 'n verifikasiemeganisme bloot uit 'n statusnommer kies nie. Die proxy se antwoord moet beskryf wat dit aanvaar.

HTTP vereis dat 'n proxy wat 407 genereer, 'n Proxy-Authenticate-uitdaging stuur. Vir 'n Basic-diens is 'n eenvoudige voorbeeld:

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

Die numeriese status, die kopnaam en die skemaspesifieke sintaksis is almal belangrik. 'n Handelsmerk-foutblad met die woord authentication in sy liggaam is nie 'n plaasvervanger vir die kop nie. Pasgemaakte implementerings moet ook 'n volledige HTTP 407-antwoord stuur, insluitend die kopafsluiter en die raamwerk van die liggaam.

Ondersoek die antwoord wat hierdie kliënt bereik het

Vang die status- en uitdagingsvelde op met geheime waardes verwyder. 'n Tussenganger het die antwoord dalk verander, of 'n pasgemaakte proxy het dalk 'n ongeldige uitdaging opgestel. Vergelyk daardie bewyse met die proxy se eie transaksielog.

As die diens eerder 405 of 'n ander fout stuur, moenie elke sulke antwoord as 407 in 'n pasgemaakte kliënt herbenoem nie. Jy sou egte metodebeleidfoute verberg en steeds geen betroubare skema-onderhandeling hê nie. Herstel die diens se gedrag of gebruik sy gedokumenteerde ondersteunde verifikasiepad.

Veelvuldige uitdagings vereis ook 'n regte HTTP-ontleder. 'n Komma kan parameters of uitdagings skei; om die hele kop blindelings op kommas te verdeel, kan 'n aangehaalde realm beskadig. Gebruik die kliënt se ondersteunde verifikasie-implementering eerder as 'n reeks stringvervangings.

Slegs nadat die uitdaging bruikbaar is, maak dit sin om te ondersoek waarom die geloofwaardigheidsverskaffer nie 'n rekening teruggegee het nie.