Apache HttpClient 4.2: hou die proxy-AuthCache op die versoekkonteks

In 'n ou HttpClient 4.2.2-toepassing doen 'n geloofsbrieweverskaffer en 'n verifikasiekas verskillende take. Die verskaffer lewer die rekening; die kas laat 'n doelbewus vooraf opgestelde verifikasiemeganisme meedoen voordat die volgende uitdaging opdaag.

Vir die ou proxy-spesifieke BasicScheme-konstruktor lyk die oorhandiging so:

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

Hierdie fragment aanvaar dat client reeds die regte proxy-roete en geloofsbrieweverskaffer het. proxy is sy HttpHost en request is die werklike bewerking. Die kassleutel moet daardie tussenganger beskryf, nie die bestemmingswebwerf nie.

Gee die gevulde konteks aan execute. Om dit te bou en dan 'n oorlaai te gebruik wat 'n ander konteks skep, laat die kas buite die transaksie. Vir latere bewerkings wat dieselfde verifikasietoestand moet deel, hou die toepaslike konteks eerder as om elke keer 'n leë een te herbou.

Die eksplisiete PROXY-toestand hoort by hierdie ouer API. TARGET handel oor verifikasie by die bestemming. Nuwer HttpClient-geslagte het pakkette en verifikasie-API's verander; gebruik dit dus as instandhoudingsriglyn vir bestaande 4.2-kode, nie as resep vir 'n nuwe kliënt nie.

'n Normale uitdagingsgedrewe transaksie kan steeds korrek wees. Saai basiese verifikasie slegs vir 'n bekende beoogde proxy, en verbruik of gee elke respons vry voordat die volgende bewerking sy verbinding nodig het. Die nuttige resultaat is 'n rekening en gekaste meganisme wat aan die uitvoering geheg is wat die versoek werklik stuur.