gRPC C-Core tarpinio serverio ir apėjimo kintamųjų prioritetas
Sekite gRPC Core tarpinio serverio ir apėjimo prioritetą, nelaikydami, kad kita gRPC realizacija naudoja tą patį atvaizduotoją.
http_proxy keitimas gali nieko neduoti, jei jau yra aukštesnio prioriteto gRPC nustatymas. Pradėkite nuo realizacijos nustatymo: toliau aprašytas elgesys priklauso gRPC C-Core numatytajam HTTP tarpinio serverio atvaizduotojui ir nuo jo priklausantiems komponentams.
Atvaizduotojas tikrina kanalo tarpinio serverio argumentą, tada grpc_proxy, tada https_proxy, tada http_proxy ir sustoja ties pirmąja sukonfigūruota reikšme.
Apėjimo nustatymas turi savo tvarką: no_grpc_proxy turi pirmenybę prieš no_proxy. Sena reikšmė ten gali paaiškinti, kodėl vienas tikslas apeina kitaip sukonfigūruotą tarpinį serverį.
Šis atvaizduotojas naudoja HTTP CONNECT. Jo dokumentuotas tarpinio serverio URI tikisi HTTP schemos; TLS apsaugota gRPC paslauga pati savaime nereikalauja TLS apsaugoto tarpinio serverio galinio taško. Tikrinkite palaikomą autentifikavimą atskirai, o ne manykite, kad prieinama bet kokia naršyklės prisijungimo schema. Viešam gRPC tikslui, kuriame leidžiami vieši tarpininkai, HTTP tarpinių serverių sąrašo siūlo galinio taško kandidatus pasirinktam HTTP tarpinio serverio URI; patvirtinkite prieigą prie faktinio CONNECT tikslo ir prievado.
Java, Go, JavaScript ar kitos kalbos gRPC realizacija gali turėti kitokį transporto kodą ir konfigūraciją. Netaikykite C-Core kintamųjų sąrašo kaip universalios taisyklės viskam, kas vadinama gRPC.
Nepavykusio kanalo atveju išsaugokite pasirinktą tarpinį serverį, apėjimo sprendimą, tikslą ir klaidos etapą. HTTP API, pasiekiama per kitą klientą, neįrodo, kad šis atvaizduotojas naudojo tuos pačius nustatymus arba kad tarpinis serveris leidžia reikiamą CONNECT paskirties vietą.