Prioritato de prokuraj kaj preterpasa variabloj en gRPC C-Core
Spuru la prioritaton de prokuro kaj preterpaso en gRPC Core sen supozi, ke alia gRPC-implementaĵo uzas la saman mapilon.
Ŝanĝi http_proxy povas fari nenion, se jam ekzistas gRPC-agordo kun pli alta prioritato. Komencu per identigo de la implementaĵo: la sekva konduto apartenas al la implicita HTTP-prokura mapilo de gRPC C-Core kaj al ĝiaj dependaĵoj.
La mapilo kontrolas kanalan prokuran argumenton, poste grpc_proxy, poste https_proxy, poste http_proxy, kaj haltas ĉe la unua agordita valoro.
La malkovro de preterpaso havas propran ordon: no_grpc_proxy havas prioritaton super no_proxy. Malnova valoro tie povas klarigi, kial unu celo evitas alie agorditan prokuron.
Ĉi tiu mapilo uzas HTTP CONNECT. Ĝia dokumentita prokura URI atendas HTTP-skemon; TLS-protektita gRPC-servo ne postulas per si mem TLS-protektitan prokuran finpunkton. Kontrolu subtenatan aŭtentikigon aparte anstataŭ supozi, ke iu ajn retumila ensalutsistemo disponeblas. Por publika gRPC-celo, kie publikaj perantoj estas permesataj, la listo de HTTP-prokuriloj proponas finpunktajn kandidatojn por la elektita HTTP-prokura URI; konfirmu aliron al la efektiva CONNECT-celo kaj haveno.
gRPC-implementaĵo en Java, Go, JavaScript aŭ alia lingvo povas havi malsaman transportan kodon kaj agordon. Ne apliku liston de C-Core-variabloj kiel universalan regulon al ĉio nomata gRPC.
Por malsukcesa kanalo, konservu la elektitan prokuron, la preterpasan decidon, la celon kaj la eraran stadion. HTTP-API atingebla per alia kliento ne pruvas, ke ĉi tiu mapilo uzis la samajn agordojn aŭ ke la prokuro permesas la postulatan CONNECT-celon.