Prioritatea variabilelor de proxy și bypass în gRPC C-Core
Urmăriți prioritatea proxy și bypass din gRPC Core fără a presupune că altă implementare gRPC folosește același mapper.
Modificarea http_proxy poate să nu facă nimic dacă există deja o setare gRPC cu prioritate mai mare. Începeți prin identificarea implementării: comportamentul următor aparține mapperului HTTP de proxy implicit din gRPC C-Core și celor care depind de el.
Mapperul verifică un argument de proxy al canalului, apoi grpc_proxy, apoi https_proxy, apoi http_proxy, și se oprește la prima valoare configurată.
Descoperirea bypass-ului are propria ordine: no_grpc_proxy are prioritate față de no_proxy. O valoare veche acolo poate explica de ce o țintă evită un proxy configurat altfel.
Acest mapper folosește HTTP CONNECT. URI-ul său documentat de proxy așteaptă o schemă HTTP; un serviciu gRPC protejat cu TLS nu necesită prin el însuși un endpoint de proxy protejat cu TLS. Verificați separat autentificarea acceptată în loc să presupuneți că orice schemă de autentificare din browser este disponibilă. Pentru o țintă gRPC publică unde sunt permise intermediare publice, lista de proxy-uri HTTP oferă candidați de endpoint pentru URI-ul de proxy HTTP ales; confirmați accesul la ținta și portul reale de CONNECT.
O implementare gRPC în Java, Go, JavaScript sau alt limbaj poate avea cod de transport și configurație diferite. Nu aplicați lista de variabile C-Core ca regulă universală pentru tot ce se numește gRPC.
Pentru un canal eșuat, păstrați proxy-ul ales, decizia de bypass, ținta și etapa erorii. Un API HTTP accesibil prin alt client nu dovedește că acest mapper a folosit aceleași setări sau că proxy-ul permite destinația CONNECT necesară.