gRPC C-Core-ի պրոքսիի և շրջանցման փոփոխականների առաջնահերթությունը

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 թիրախին և պորտին։

Java-ով, Go-ով, JavaScript-ով կամ այլ լեզվով gRPC իրականացումը կարող է ունենալ տարբեր տրանսպորտային կոդ և կարգավորում։ Մի կիրառեք C-Core փոփոխականների ցանկը որպես համընդհանուր կանոն այն ամենի նկատմամբ, ինչը կոչվում է gRPC։

Ձախողված ալիքի համար պահեք ընտրված պրոքսին, շրջանցման որոշումը, թիրախը և սխալի փուլը։ Այլ հաճախորդի միջոցով հասանելի HTTP API-ն չի ապացուցում, որ այս մապերն օգտագործել է նույն կարգավորումները կամ որ պրոքսին թույլատրում է պահանջվող CONNECT նպատակակետը։