gRPC C-Core প্রক্সি ও বাইপাস ভেরিয়েবলের অগ্রাধিকার

উচ্চতর অগ্রাধিকারের gRPC সেটিং আগে থেকেই থাকলে http_proxy বদলে কিছুই হতে পারে না। প্রথমে বাস্তবায়নটি চিহ্নিত করুন: নিচের আচরণ gRPC C-Core-এর ডিফল্ট HTTP প্রক্সি ম্যাপার ও তার নির্ভরশীলদের।

ম্যাপারটি প্রথমে চ্যানেল প্রক্সি আর্গুমেন্ট, তারপর grpc_proxy, তারপর https_proxy, তারপর http_proxy দেখে এবং প্রথম কনফিগার করা মানে থেমে যায়।

বাইপাস শনাক্তকরণের নিজস্ব ক্রম আছে: no_grpc_proxy-এর অগ্রাধিকার no_proxy-এর চেয়ে বেশি। সেখানে পুরোনো মান থাকলে কোনো লক্ষ্য কেন অন্যথায় কনফিগার করা প্রক্সি এড়ায় তা ব্যাখ্যা করতে পারে।

এই ম্যাপার HTTP CONNECT ব্যবহার করে। এর নথিভুক্ত প্রক্সি URI একটি HTTP স্কিম আশা করে; TLS-সুরক্ষিত gRPC সেবা নিজে থেকেই TLS-সুরক্ষিত প্রক্সি এন্ডপয়েন্ট দাবি করে না। ব্রাউজার লগইন স্কিম আছে ধরে না নিয়ে সমর্থিত প্রমাণীকরণ আলাদাভাবে যাচাই করুন। এমন পাবলিক gRPC লক্ষ্যের জন্য যেখানে পাবলিক মধ্যস্থতাকারী অনুমোদিত, HTTP প্রক্সির তালিকা নির্বাচিত HTTP প্রক্সি URI-এর জন্য এন্ডপয়েন্ট প্রার্থী দেয়; প্রকৃত CONNECT লক্ষ্য ও পোর্টে প্রবেশ নিশ্চিত করুন।

Java, Go, JavaScript বা অন্য gRPC বাস্তবায়নের পরিবহন কোড ও কনফিগারেশন ভিন্ন হতে পারে। gRPC নামে সব কিছুর জন্য C-Core ভেরিয়েবল তালিকাকে সর্বজনীন নিয়ম হিসেবে প্রয়োগ করবেন না।

ব্যর্থ চ্যানেলের ক্ষেত্রে নির্বাচিত প্রক্সি, বাইপাস সিদ্ধান্ত, লক্ষ্য ও ত্রুটির ধাপ সংরক্ষণ করুন। অন্য ক্লায়েন্ট দিয়ে HTTP API পৌঁছানো প্রমাণ করে না যে এই ম্যাপার একই সেটিং ব্যবহার করেছে বা প্রক্সি প্রয়োজনীয় CONNECT গন্তব্য অনুমোদন করে।