Apache HttpClient 4.2: behåll proxy-AuthCache på förfrågningskontexten
Behåll en HttpClient 4.2 proxy-Basic-auth-cache på samma exekveringskontext som efterföljande förfrågningar använder.
I en äldre HttpClient 4.2.2-applikation gör en credential-provider och en autentiseringscache olika saker. Providern levererar kontot; cachen låter ett medvetet förkonfigurerat autentiseringsschema delta innan nästa utmaning anländer.
För den gamla proxyspecifika BasicScheme-konstruktorn ser överlämningen ut så här:
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);Det här utdraget förutsätter att client redan har den matchande proxyvägen och credential-providern. proxy är dess HttpHost, och request är den faktiska operationen. Cache-nyckeln måste beskriva den mellanhanden, inte målwebbplatsen.
Skicka den ifyllda kontexten till execute. Att bygga den och sedan använda en överlagring som skapar en annan kontext lämnar cachen utanför utbytet. För senare operationer som ska dela det autentiseringstillståndet, behåll den lämpliga kontexten i stället för att bygga en tom på nytt varje gång.
Det explicita PROXY-tillståndet hör till detta äldre API. TARGET gäller autentisering mot målet. Nyare HttpClient-generationer har ändrat paket och autentiserings-API:er, så använd detta som underhållsvägledning för befintlig 4.2-kod och inte som recept för en ny klient.
Ett normalt utmaningsstyrt utbyte kan fortfarande vara korrekt. Så Basic-autentisering endast för en känd avsedd proxy, och förbruka eller frigör varje svar innan nästa operation behöver dess anslutning. Det användbara resultatet är ett konto och ett cachat schema knutet till den exekvering som faktiskt skickar förfrågan.