একটি WinHTTP অনুরোধ প্রক্সিতে প্রমাণীকরণ করে, ওয়েবসাইটের 401 পায়, তারপর পরের পাঠে আরেকটি 407 পায়। প্রক্সি ও ওয়েবসাইটের প্রমাণীকরণ অবস্থা আলাদা, এবং পুনঃপাঠের পথকে দুটোই ধরে রাখতে হয়।

মাইক্রোসফটের মূল WinHTTP প্রমাণীকরণ নমুনা নির্বাচিত প্রক্সি স্কিমটি একটি ভেরিয়েবলে রাখে এবং সেই স্কিম নির্বাচিত হওয়ার পর প্রতিটি WinHttpSendRequest-এর আগে প্রক্সি অ্যাকাউন্ট আবার প্রয়োগ করে।

  1. অনুরোধ পাঠান এবং প্রতিক্রিয়া পরীক্ষা করুন।
  2. 407-এর জন্য প্রস্তাবিত স্কিমগুলি জিজ্ঞাসা করুন এবং নির্বাচিত প্রক্সি স্কিম মনে রাখুন।
  3. পুনরায় পাঠানোর আগে সেই স্কিম ও অ্যাকাউন্ট দিয়ে WINHTTP_AUTH_TARGET_PROXY-এর জন্য WinHttpSetCredentials কল করুন।
  4. গন্তব্যের 401-এর জন্য তার স্কিম নিন এবং পরের পাঠের জন্য মনে রাখা প্রক্সি অবস্থা ধরে রেখে সার্ভার শংসাপত্র নির্ধারণ করুন।

নমুনাটি বিশেষভাবে সার্ভার চ্যালেঞ্জ বা রিডাইরেক্টের পরে পুনঃপ্রমাণীকরণকে প্রক্সি শংসাপত্র আবার প্রয়োগের কারণ হিসেবে উল্লেখ করে। কেবল প্রথম 407 শাখায় কলটি রাখলে অন্য একটি পুনরায় চেষ্টার পথ প্রত্যাশিত সেটআপ ছাড়া থেকে যেতে পারে।

প্রতিটি API ফলাফল যাচাই করুন এবং পুনরাবৃত্ত ব্যর্থতা সীমিত রাখুন। মাইক্রোসফটের সংক্ষিপ্ত নমুনা পূর্ববর্তী স্ট্যাটাস ট্র্যাক করে, আর উৎপাদন পুনরায় চেষ্টার নীতির পুনরাবৃত্ত পালাবদল ক্রমও চেনা উচিত।

ব্যর্থতার পরে ব্যবহারকারী প্রতিস্থাপন অ্যাকাউন্ট দিলে, সেই পুনঃপাঠ পথে ব্যবহৃত মানগুলি হালনাগাদ করুন। WinHttpSetCredentials অনুরোধ-পরিসরীয়; এটি প্রক্রিয়া-ব্যাপী পাসওয়ার্ড ভাণ্ডার নয় যার বিষয়বস্তু ভবিষ্যতের সব অনুরোধের জন্য বদলে দেওয়া হয়।

সম্পর্কিত নিবন্ধ