在遗留的 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 认证,并且在下一次操作需要其连接之前消费或释放每个响应。有用的结果是:账号与缓存方案附着在真正发送该请求的那次执行上。

相关文章