Pada aplikasi lama HttpClient 4.2.2, penyedia kredensial dan cache autentikasi melakukan tugas yang berbeda. Penyedia memasok akun; cache memungkinkan skema autentikasi yang sengaja dikonfigurasi sebelumnya ikut serta sebelum tantangan berikutnya datang.

Untuk konstruktor BasicScheme lama yang khusus proksi, penyerahannya tampak seperti ini:

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

Fragmen ini mengasumsikan client sudah memiliki rute proksi yang cocok dan penyedia kredensial. proxy adalah HttpHost-nya, dan request adalah operasi sebenarnya. Kunci cache harus menjelaskan perantara itu, bukan situs web tujuan.

Teruskan konteks yang sudah terisi ke execute. Membangunnya lalu memakai overload yang membuat konteks lain membuat cache berada di luar pertukaran. Untuk operasi berikutnya yang hendak berbagi status autentikasi itu, pertahankan konteks yang sesuai alih-alih membangun ulang konteks kosong setiap kali.

Status PROXY eksplisit milik API yang lebih lama ini. TARGET berkaitan dengan autentikasi tujuan. Generasi HttpClient yang lebih baru mengubah paket dan API autentikasi, jadi gunakan ini sebagai panduan pemeliharaan untuk kode 4.2 yang ada, bukan sebagai resep untuk client baru.

Pertukaran normal yang digerakkan tantangan masih bisa benar. Taburkan autentikasi Basic hanya untuk proksi yang dikenal dan dimaksudkan, dan konsumsi atau lepaskan setiap respons sebelum operasi berikutnya membutuhkan koneksinya. Hasil yang berguna adalah akun dan skema tersimpan yang melekat pada eksekusi yang benar-benar mengirim permintaan.

Artikel terkait