არის თუ არა გაზიარებული .NET IWebProxy უსაფრთხო ერთდროულ მოთხოვნებში?

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

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

შეინახეთ კონფიგურაციის ცვლილებები მოთხოვნების დამუშავების გარეთ

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

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

ხანგრძლივი პაუზა GetProxy-ში შეიძლება პირიქით, აღმოჩენას ან PAC-ის შეფასებას უკავშირდებოდეს. Microsoft აღწერს ბლოკირებად აღმოჩენას WinHTTP-ისთვის; ეს განმარტება ძალაშია, როცა კლიენტი იყენებს ამ ბექენდს. გაზომეთ მარშრუტის ძებნა ცალკე კავშირისა და პასუხის დროისგან. ნელი ძებნის სერიალიზაცია მხოლოდ რიგს შექმნის.

ფიქსირებულ ბოლო წერტილს შეუძლია აღმოჩენა მოხსნას, როცა ფიქსირებული მარშრუტია განზრახული. ცვალებადი სისტემური პოლიტიკიდან ერთი URI-ის დაჭერა ასევე აუქმებს მის მომავალ გადაწყვეტილებებს. შეინარჩუნეთ ეს განსხვავება ძველი კოდის მოვლისას; ახალი HTTP სამუშაოსთვის გამოიყენეთ HttpClient და მისი მხარდაჭერილი handler-კონფიგურაცია.