Apache HttpClient 4.2 : conserver l'AuthCache du proxy sur le contexte de la requête

Dans une application héritée sous HttpClient 4.2.2, un fournisseur d'identifiants et un cache d'authentification n'ont pas le même rôle. Le fournisseur fournit le compte ; le cache permet à un schéma d'authentification délibérément préconfiguré de participer avant qu'un autre défi n'arrive.

Pour l'ancien constructeur BasicScheme propre au proxy, la transmission ressemble à ceci :

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);

Ce fragment suppose que client possède déjà la route de proxy correspondante et le fournisseur d'identifiants. proxy est son HttpHost, et request est l'opération réelle. La clé du cache doit décrire cet intermédiaire, pas le site de destination.

Passez le contexte rempli à execute. Le construire puis utiliser une surcharge qui crée un autre contexte laisse le cache en dehors de l'échange. Pour les opérations ultérieures censées partager cet état d'authentification, conservez le contexte approprié plutôt que d'en reconstruire un vide à chaque fois.

L'état PROXY explicite appartient à cette API plus ancienne. TARGET concerne l'authentification de la destination. Les générations plus récentes d'HttpClient ont changé les paquets et les API d'authentification ; utilisez donc ceci comme conseil de maintenance pour du code 4.2 existant, et non comme recette pour un nouveau client.

Un échange normal piloté par un défi peut rester correct. N'amorcez l'authentification Basic que pour un proxy connu et voulu, et consommez ou libérez chaque réponse avant que l'opération suivante n'ait besoin de sa connexion. Le résultat utile est un compte et un schéma mis en cache attachés à l'exécution qui envoie réellement la requête.