Apache HttpClient 4.2: অনুরোধ প্রসঙ্গে প্রক্সি AuthCache রাখুন

পুরোনো HttpClient 4.2.2 অ্যাপ্লিকেশনে ক্রেডেনশিয়াল প্রোভাইডার ও অথেনটিকেশন ক্যাশ আলাদা কাজ করে। প্রোভাইডার অ্যাকাউন্ট জোগায়; ক্যাশ আগে থেকেই ইচ্ছাকৃতভাবে সাজানো একটি অথেনটিকেশন স্কিমকে পরবর্তী চ্যালেঞ্জ আসার আগে অংশ নিতে দেয়।

পুরোনো প্রক্সি-নির্দিষ্ট BasicScheme কনস্ট্রাক্টরের ক্ষেত্রে হস্তান্তরটি এমন দেখায়:

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

এই অংশটি ধরে নেয় যে client-এর কাছে ইতিমধ্যেই মিলে যাওয়া প্রক্সি রুট ও ক্রেডেনশিয়াল প্রোভাইডার আছে। proxy হলো তার HttpHost, আর request হলো প্রকৃত কাজ। ক্যাশ কী-কে সেই মধ্যবর্তীকে বর্ণনা করতে হবে, গন্তব্য ওয়েবসাইটকে নয়।

ভরা context-টি execute-এ দিন। এটি তৈরি করে তারপর অন্য context বানায় এমন overload ব্যবহার করলে ক্যাশটি বিনিময়ের বাইরে থেকে যায়। যে পরবর্তী কাজগুলি ওই অথেনটিকেশন অবস্থা ভাগ করতে চায়, তাদের জন্য প্রতিবার খালি context নতুন করে না বানিয়ে উপযুক্ত context-টি ধরে রাখুন।

স্পষ্ট PROXY অবস্থাটি এই পুরোনো API-র। TARGET গন্তব্যের অথেনটিকেশন নিয়ে। নতুন HttpClient প্রজন্ম প্যাকেজ ও অথেনটিকেশন API বদলেছে, তাই এটি বিদ্যমান 4.2 কোডের রক্ষণাবেক্ষণ নির্দেশনা হিসেবে ব্যবহার করুন, নতুন client-এর রেসিপি হিসেবে নয়।

স্বাভাবিক চ্যালেঞ্জ-চালিত বিনিময় এখনও সঠিক হতে পারে। শুধু জানা ও ইচ্ছাকৃত প্রক্সির জন্যই Basic অথেনটিকেশন বপন করুন, এবং পরবর্তী কাজের সংযোগ দরকার হওয়ার আগেই প্রতিটি response খরচ করুন বা ছেড়ে দিন। উপকারী ফল হলো এমন অ্যাকাউন্ট ও ক্যাশ করা স্কিম যা সত্যিই অনুরোধ পাঠায় এমন এক্সিকিউশনের সঙ্গে যুক্ত।