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, а не как рецепт для нового клиента.

Обычный обмен, управляемый испытанием, всё ещё может быть правильным. Задавайте Basic-аутентификацию заранее только для известного и предполагаемого прокси, и используйте или освобождайте каждый ответ до того, как следующей операции понадобится его соединение. Полезный результат — учётная запись и кешированная схема, привязанные к выполнению, которое действительно отправляет запрос.