Apache HttpClient 4.2: hald på proxy-AuthCache på førespurnadskonteksten

I ein eldre HttpClient 4.2.2-applikasjon gjer ein credential-provider og ein autentiseringscache ulike jobbar. Provideren leverer kontoen; cachen lèt eit medvite førehandskonfigurert autentiseringsskjema delta før ein ny utfordring kjem.

For den gamle proxy-spesifikke BasicScheme-konstruktøren ser overleveringa slik ut:

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

Dette utdraget føreset at client alt har den samsvarande proxy-ruta og credential-provideren. proxy er HttpHost-en hans, og request er den faktiske operasjonen. Cache-nøkkelen må skildre den mellomleiaren, ikkje nettstaden ein skal til.

Send den fylte konteksten til execute. Å byggje han og så bruke ei overbelasting som lagar ein annan kontekst, lèt cachen stå utanfor utvekslinga. For seinare operasjonar som skal dele denne autentiseringstilstanden, hald på den aktuelle konteksten i staden for å byggje ein tom på nytt kvar gong.

Den eksplisitte PROXY-tilstanden høyrer til denne eldre API-en. TARGET gjeld autentisering av målet. Nyare HttpClient-generasjonar har endra pakkar og autentiserings-API-ar, så bruk dette som vedlikelelsrettleiing for eksisterande 4.2-kode og ikkje som oppskrift for ein ny klient.

Ei vanleg utfordringsstyrt utveksling kan framleis vere korrekt. Så Basic-autentisering berre for ein kjend og tiltenkt proxy, og bruk opp eller slepp kvar respons før neste operasjon treng sambandet hans. Det nyttige resultatet er ein konto og eit bufra skjema knytt til utføringa som faktisk sender førespurnaden.