HTTP 407 გამოსაყენებელი Proxy-Authenticate გამოწვევის გარეშე

კლიენტი ვერ შეარჩევს ავტორიზაციის მექანიზმს მხოლოდ სტატუსის ნომრის მიხედვით. პროქსის პასუხმა უნდა აღწეროს, რას იღებს იგი.

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. გამოიყენეთ კლიენტის მხარდაჭერილი ავტორიზაციის იმპლემენტაცია და არა სტრიქონების თანმიმდევრული ჩანაცვლებები.

მხოლოდ მას შემდეგ, რაც გამოწვევა გამოსადეგი გახდება, აქვს აზრი იმის გამოკვლევას, თუ რატომ არ დააბრუნა სერტიფიკატების მომწოდებელმა ანგარიში.