ASP.NET Core প্রক্সি সেটিংস: launchSettings.json বনাম উৎপাদন
ডেভেলপমেন্ট লঞ্চ-প্রোফাইলের প্রক্সি মানকে স্থাপন করা ASP.NET Core প্রক্রিয়ার পরিবেশ ও HTTP হ্যান্ডলার থেকে আলাদা করুন।
launchSettings.json-এ থাকা প্রক্সি মান একটি ডেভেলপমেন্ট লঞ্চ প্রোফাইলের। অ্যাপ্লিকেশন প্রকাশ করলে সেই প্রোফাইল IIS ওয়ার্কার, পরিষেবা বা কনটেইনারের পরিবেশ হয়ে ওঠে না।
স্থাপন করা পরিবেশে ব্যর্থতার ক্ষেত্রে, যে প্রক্রিয়াটি সত্যিই অ্যাপ্লিকেশন শুরু করে তা পরীক্ষা করুন। তার পরিবেশ, অ্যাকাউন্ট ও HTTP হ্যান্ডলার নির্ধারণ করে কোন প্রক্সি ইনপুট পাওয়া যায়।
| কোথায় কাজ করে | স্থাপনের পরে কী তুলনা করবেন |
|---|---|
| IDE লঞ্চ প্রোফাইল | হোস্ট প্রক্রিয়ার পরিবেশ |
| ইন্টারঅ্যাকটিভ ব্যবহারকারী সেশন | পরিষেবা অ্যাকাউন্ট ও তার প্রক্সি সেটিংস |
| হাতে তৈরি HTTP ক্লায়েন্ট | অ্যাপ্লিকেশনের ইনজেক্ট করা ক্লায়েন্ট যে হ্যান্ডলার ব্যবহার করে |
আধুনিক HttpClient-এর ডিফল্ট প্রক্সি আরম্ভের প্ল্যাটফর্ম-নির্দিষ্ট পরিবেশ ও সিস্টেম-কনফিগারেশন নিয়ম আছে। স্পষ্টভাবে কনফিগার করা হ্যান্ডলার সেই ডিফল্টগুলি অগ্রাহ্য করতে পারে। IHttpClientFactory-এর সঙ্গে, নামকৃত ক্লায়েন্টের প্রাথমিক হ্যান্ডলার নিবন্ধন এবং কল স্থলে পাওয়া নাম পরীক্ষা করুন। কনফিগারেশন ফাইল উপেক্ষা করা হয়েছে বলে সিদ্ধান্তে আসার আগে উভয় ইনপুট পরীক্ষা করুন।
পুরোনো .NET Framework system.net/defaultProxy উদাহরণ অন্য একটি কনফিগারেশন মডেল বর্ণনা করে। সেই অংশটি আধুনিক স্থাপন ফাইলে পেস্ট করবেন না এবং ধরে নেবেন না যে প্রতিটি .NET HTTP বাস্তবায়ন এটি ব্যবহার করে। IIS স্থাপনে, ASP.NET Core মডিউলেরও প্রক্রিয়া-পরিবেশ কনফিগারেশনের সমর্থিত ব্যবস্থা আছে; মান যোগ করার সময় বাকি হোস্টিং কনফিগারেশন সংরক্ষণ করুন।
প্রত্যাশিত ভেরিয়েবলটি আছে কি না তা লিপিবদ্ধ করুন, কিন্তু তার সম্পূর্ণ শংসাপত্র-বহনকারী মান প্রকাশ করবেন না। তারপর নিশ্চিত করুন যে ব্যর্থ অনুরোধ করা ক্লায়েন্টটি সেই উৎস ব্যবহার করে। সঠিকভাবে কনফিগার করা লঞ্চার ইচ্ছাকৃতভাবে অন্য পথ ব্যবহার করা ক্লায়েন্টকে ঠিক করতে পারে না।