Apache HttpClient 4.2: захоўвайце Proxy AuthCache у кантэксце запыту

У старым праграме на HttpClient 4.2.2 пастаўшчык уліковых даных і кэш аўтэнтыфікацыі выконваюць розныя задачы. Пастаўшчык дае ўліковы запіс; кэш дазваляе наўмысна загадзя настроенай схеме аўтэнтыфікацыі ўдзельнічаць раней, чым прыйдзе чарговы выклік.

Для старога канструктара 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 — гэта яго HttpHost, а request — фактычная аперацыя. Ключ кэша павінен апісваць гэтага пасярэдніка, а не сайт прызначэння.

Перадайце запоўнены кантэкст у execute. Калі пабудаваць яго, а потым выкарыстаць перагрузку, якая стварае іншы кантэкст, кэш застанецца па-за абменам. Для наступных аперацый, якія павінны падзяляць гэты стан аўтэнтыфікацыі, захоўвайце адпаведны кантэкст, а не перабудоўвайце пусты кожны раз.

Яўны стан PROXY належыць гэтаму старому API. TARGET датычыцца аўтэнтыфікацыі прызначэння. Новыя пакаленні HttpClient змянілі пакеты і API аўтэнтыфікацыі, таму ўспрымайце гэта як кіраўніцтва па суправаджэнні існуючага кода 4.2, а не як рэцэпт для новага кліента.

Звычайны абмен, кіраваны выклікам, можа заставацца правільным. Засявайце базавую аўтэнтыфікацыю толькі для вядомага мэтавага проксі, і спажывайце або вызваляйце кожны адказ, перш чым наступнай аперацыі спатрэбіцца яго злучэнне. Карысны вынік — уліковы запіс і кэшаваная схема, прывязаныя да выканання, якое фактычна адпраўляе запыт.