Apache HttpClient 4.2: зберігайте Proxy AuthCache у контексті запиту
Зберігайте кеш Basic-автентифікації проксі HttpClient 4.2 у тому самому контексті виконання, який використовують наступні запити.
У застарілому застосунку на 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-автентифікацію лише для відомого й передбаченого проксі, і використовуйте або звільняйте кожну відповідь до того, як наступній операції знадобиться її з'єднання. Корисний результат — обліковий запис і кешована схема, прив'язані до виконання, яке справді надсилає запит.