Apache HttpClient 4.2: შეინახეთ proxy AuthCache მოთხოვნის კონტექსტში

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

ძველი proxy-სპეციფიკური BasicScheme კონსტრუქტორისთვის გადაცემა ასე გამოიყურება:

AuthCache cache = new BasicAuthCache();
cache.put(proxy, new BasicScheme(ChallengeState.PROXY));

HttpContext context = new BasicHttpContext();
context.setAttribute(ClientContext.AUTH_CACHE, cache);
HttpResponse response = client.execute(request, context);

ეს ფრაგმენტი ვარაუდობს, რომ client-ს უკვე აქვს შესაბამისი proxy მარშრუტი და სერთიფიკატების მომწოდებელი. proxy არის მისი HttpHost, ხოლო request — რეალური ოპერაცია. ქეშის გასაღები უნდა აღწერდეს ამ შუამავალს და არა დანიშნულების საიტს.

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

აშკარა PROXY მდგომარეობა ამ ძველ API-ს ეკუთვნის. TARGET დანიშნულების ავთენტიფიკაციას ეხება. HttpClient-ის ახალმა თაობებმა პაკეტები და ავთენტიფიკაციის API შეცვალეს, ამიტომ ეს გამოიყენეთ როგორც არსებული 4.2 კოდის მომსახურების სახელმძღვანელო და არა როგორც ახალი client-ის რეცეპტი.

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