Apache HttpClient 4.2: Proxy-AuthCache im Request-Kontext behalten

In einer älteren HttpClient-4.2.2-Anwendung erfüllen ein Credentials-Provider und ein Authentifizierungs-Cache unterschiedliche Aufgaben. Der Provider liefert das Konto; der Cache erlaubt es einem bewusst vorkonfigurierten Authentifizierungsschema, teilzunehmen, bevor die nächste Challenge eintrifft.

Für den alten proxy-spezifischen BasicScheme-Konstruktor sieht die Übergabe so aus:

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

Dieses Fragment setzt voraus, dass client bereits die passende Proxy-Route und den Credentials-Provider besitzt. proxy ist sein HttpHost, und request ist die eigentliche Operation. Der Cache-Schlüssel muss diesen Vermittler beschreiben, nicht die Zielwebsite.

Übergeben Sie den befüllten Kontext an execute. Wer ihn aufbaut und dann eine Überladung nutzt, die einen anderen Kontext erzeugt, lässt den Cache außerhalb des Austauschs. Für spätere Operationen, die diesen Authentifizierungszustand teilen sollen, behalten Sie den passenden Kontext, statt jedes Mal einen leeren neu aufzubauen.

Der explizite PROXY-Zustand gehört zu dieser älteren API. TARGET betrifft die Authentifizierung am Ziel. Neuere HttpClient-Generationen haben Pakete und Authentifizierungs-APIs geändert, daher dient dies als Wartungshinweis für bestehenden 4.2-Code und nicht als Rezept für einen neuen Client.

Ein normaler, challenge-gesteuerter Austausch kann weiterhin korrekt sein. Basic-Authentifizierung nur für einen bekannten, beabsichtigten Proxy vorab setzen, und jede Antwort verbrauchen oder freigeben, bevor die nächste Operation ihre Verbindung braucht. Das nützliche Ergebnis ist ein Konto und ein gecachtes Schema, die an der Ausführung hängen, die die Anfrage tatsächlich sendet.