Prednost spremenljivk proxy in obhoda v gRPC C-Core
Sledite prednosti proxy in obhoda v gRPC Core, ne da bi domnevali, da druga implementacija gRPC uporablja isti preslikovalnik.
Spreminjanje http_proxy morda ne stori ničesar, če že obstaja nastavitev gRPC z višjo prednostjo. Začnite z identifikacijo implementacije: naslednje vedenje pripada privzetemu preslikovalniku HTTP proxy v gRPC C-Core in od njega odvisnim delom.
Preslikovalnik preveri argument proxy kanala, nato grpc_proxy, nato https_proxy, nato http_proxy in se ustavi pri prvi nastavljeni vrednosti.
Odkrivanje obhoda ima svoj vrstni red: no_grpc_proxy ima prednost pred no_proxy. Stara vrednost tam lahko pojasni, zakaj se nek cilj izogne sicer nastavljenemu proxyju.
Ta preslikovalnik uporablja HTTP CONNECT. Njegov dokumentirani proxy URI pričakuje shemo HTTP; storitev gRPC, zaščitena s TLS, sama po sebi ne zahteva s TLS zaščitene končne točke proxyja. Podprto preverjanje pristnosti preverite ločeno, namesto da bi domnevali, da je na voljo katera koli shema prijave v brskalniku. Za javni cilj gRPC, kjer so dovoljeni javni posredniki, seznama proxyjev HTTP ponuja kandidate končnih točk za izbrani URI proxyja HTTP; potrdite dostop do dejanskega cilja CONNECT in vrat.
Implementacija gRPC v Javi, Go, JavaScriptu ali drugem jeziku ima lahko drugačno transportno kodo in konfiguracijo. Seznama spremenljivk C-Core ne uporabljajte kot univerzalnega pravila za vse, kar se imenuje gRPC.
Pri neuspešnem kanalu ohranite izbrani proxy, odločitev o obhodu, cilj in stopnjo napake. HTTP API, dosegljiv prek drugega odjemalca, ne dokazuje, da je ta preslikovalnik uporabil enake nastavitve ali da proxy dovoljuje zahtevani cilj CONNECT.