Vanhassa HttpClient 4.2.2 -sovelluksessa tunnistetietojen tarjoaja ja todennuksen välimuisti tekevät eri tehtäviä. Tarjoaja toimittaa tilin; välimuisti antaa tarkoituksella etukäteen määritetyn todennusmenetelmän osallistua ennen kuin seuraava haaste saapuu.

Vanhan välityspalvelinkohtaisen BasicScheme-konstruktorin kohdalla luovutus näyttää tältä:

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

Tämä katkelma olettaa, että clientillä on jo vastaava välityspalvelinreitti ja tunnistetietojen tarjoaja. proxy on sen HttpHost ja request on varsinainen toiminto. Välimuistin avaimen on kuvattava tätä välittäjää, ei kohdesivustoa.

Välitä täytetty konteksti executelle. Jos rakennat sen ja käytät sitten ylikuormitusta, joka luo toisen kontekstin, välimuisti jää vaihdon ulkopuolelle. Myöhemmille toiminnoille, joiden on jaettava tämä todennustila, säilytä sopiva konteksti sen sijaan että rakentaisit joka kerta tyhjän.

Selkeä PROXY-tila kuuluu tähän vanhempaan APIin. TARGET koskee kohteen todennusta. Uudemmat HttpClient-sukupolvet ovat muuttaneet paketteja ja todennus-APIja, joten käytä tätä olemassa olevan 4.2-koodin ylläpito-ohjeena, älä uuden clientin reseptinä.

Tavallinen haasteohjattu vaihto voi yhä olla oikein. Kylvä Basic-todennus vain tunnetulle ja aiotulle välityspalvelimelle, ja kuluta tai vapauta jokainen vastaus ennen kuin seuraava toiminto tarvitsee sen yhteyden. Hyödyllinen tulos on tili ja välimuistiin tallennettu menetelmä, jotka on liitetty siihen suoritukseen, joka pyynnön todella lähettää.

Aiheeseen liittyvät artikkelit