პროქსისა და გვერდის ავლის ცვლადების უპირატესობა gRPC C-Core-ში
თვალყური ადევნეთ gRPC Core-ის პროქსისა და გვერდის ავლის უპირატესობას, იმის დაშვების გარეშე, რომ gRPC-ის სხვა იმპლემენტაცია იმავე მაპერს იყენებს.
http_proxy-ის შეცვლამ შეიძლება არაფერი გააკეთოს, თუ უფრო მაღალი უპირატესობის gRPC პარამეტრი უკვე არსებობს. დაიწყეთ იმპლემენტაციის იდენტიფიცირებით: შემდეგი ქცევა ეკუთვნის 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 სამიზნესა და პორტზე.
gRPC-ის იმპლემენტაციას Java-ში, Go-ში, JavaScript-ში ან სხვა ენაზე შეიძლება ჰქონდეს განსხვავებული ტრანსპორტის კოდი და კონფიგურაცია. ნუ გამოიყენებთ C-Core ცვლადების სიას როგორც საყოველთაო წესს ყველაფერზე, რასაც gRPC ჰქვია.
წარუმატებელი არხისთვის შეინარჩუნეთ არჩეული პროქსი, გვერდის ავლის გადაწყვეტილება, სამიზნე და შეცდომის ეტაპი. სხვა კლიენტის მეშვეობით ხელმისაწვდომი HTTP API არ ამტკიცებს, რომ ამ მაპერმა იგივე პარამეტრები გამოიყენა ან რომ პროქსი საჭირო CONNECT დანიშნულებას უშვებს.