Клиент нь зөвхөн төлөвийн дугаараас баталгаажуулалтын механизм сонгож чадахгүй. Проксигийн хариу нь юуг хүлээн авдагаа тодорхойлсон байх ёстой.

HTTP нь 407 үүсгэдэг проксигоос Proxy-Authenticate сорилт илгээхийг шаарддаг. Basic үйлчилгээний энгийн жишээ:

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

Тоон төлөв, толгойн нэр, схемд хамаарах синтакс бүгд чухал. Биедээ authentication гэх үг агуулсан брэнд алдааны хуудас нь толгойг орлохгүй. Захиалгат хэрэгжүүлэлтүүд мөн толгойн төгсгөгч ба биеийн хүрээг оруулан бүрэн HTTP 407 хариу илгээх ёстой.

Энэ клиентэд хүрсэн хариуг шалгана уу

Нууц утгуудыг хассаны дараа төлөв ба сорилтын талбаруудыг бүртгэнэ. Завсрын холбоос хариуг өөрчилсөн байж болно, эсвэл захиалгат прокси хүчингүй сорилт бүтээсэн байж болно. Тэр нотолгоог проксигийн өөрийн гүйлгээний бүртгэлтэй харьцуулна уу.

Хэрэв үйлчилгээ оронд нь 405 эсвэл өөр алдаа илгээвэл захиалгат клиентийн дотор ийм хариу бүрийг 407 гэж дахин шошголох хэрэггүй. Та аргын бодлогын бодит алдааг нууж, найдвартай схем хэлэлцээргүй хэвээр үлдэнэ. Үйлчилгээний зан төлөвийг засаж, эсвэл түүний баримтжуулсан дэмжигдсэн баталгаажуулалтын замыг ашиглана уу.

Олон сорилтод мөн жинхэнэ HTTP задлагч хэрэгтэй. Таслал параметр эсвэл сорилтыг тусгаарлаж болно; бүх толгойг таслалаар сохроор хуваах нь хашилтын доторх realm-ыг гэмтээж болно. Дараалсан мөр солилтын оронд клиентийн дэмжигдсэн баталгаажуулалтын хэрэгжүүлэлтийг ашиглана уу.

Сорилт ашиглах боломжтой болсны дараа л итгэмжлэл нийлүүлэгч яагаад бүртгэл буцааж өгөөгүйг шалгах нь утга учиртай.

Холбоотой нийтлэлүүд