Apache HttpClient 4.2: zachowaj AuthCache proxy w kontekście żądania

W starszej aplikacji HttpClient 4.2.2 dostawca poświadczeń i pamięć podręczna uwierzytelniania robią różne rzeczy. Dostawca dostarcza konto; pamięć podręczna pozwala świadomie wstępnie skonfigurowanemu schematowi uwierzytelniania uczestniczyć, zanim nadejdzie kolejne wyzwanie.

Dla starego konstruktora BasicScheme właściwego dla proxy przekazanie wygląda tak:

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

Ten fragment zakłada, że client ma już pasującą trasę proxy i dostawcę poświadczeń. proxy to jego HttpHost, a request to rzeczywista operacja. Klucz pamięci podręcznej musi opisywać tego pośrednika, a nie witrynę docelową.

Przekaż wypełniony kontekst do execute. Zbudowanie go i użycie przeciążenia, które tworzy inny kontekst, pozostawia pamięć podręczną poza wymianą. W przypadku późniejszych operacji, które mają współdzielić ten stan uwierzytelniania, zachowaj odpowiedni kontekst, zamiast za każdym razem budować pusty.

Jawny stan PROXY należy do tego starszego API. TARGET dotyczy uwierzytelniania celu. Nowsze generacje HttpClient zmieniły pakiety i API uwierzytelniania, więc traktuj to jako wskazówkę konserwacyjną dla istniejącego kodu 4.2, a nie przepis na nowego klienta.

Zwykła wymiana sterowana wyzwaniem może nadal być poprawna. Zasianuj uwierzytelnianie Basic tylko dla znanego i zamierzonego proxy, a każde odpowiedź zużyj lub zwolnij, zanim następna operacja będzie potrzebować jej połączenia. Użyteczny wynik to konto i buforowany schemat powiązane z wykonaniem, które faktycznie wysyła żądanie.