Përparësia e variablave të proxy dhe anashkalimit në gRPC C-Core
Ndiqni përparësinë e proxy dhe anashkalimit të gRPC Core pa supozuar se një implementim tjetër i gRPC përdor të njëjtin mapper.
Ndryshimi i http_proxy mund të mos bëjë asgjë kur ekziston tashmë një cilësim gRPC me përparësi më të lartë. Filloni duke identifikuar implementimin: sjellja në vijim i përket mapper-it standard të proxy HTTP të gRPC C-Core dhe atyre që varen prej tij.
Mapper-i kontrollon një argument proxy të kanalit, pastaj grpc_proxy, pastaj https_proxy, pastaj http_proxy, dhe ndalon në vlerën e parë të konfiguruar.
Zbulimi i anashkalimit ka rendin e vet: no_grpc_proxy ka përparësi ndaj no_proxy. Një vlerë e vjetër atje mund të shpjegojë pse një objektiv shmang një proxy të konfiguruar ndryshe.
Ky mapper përdor HTTP CONNECT. URI-ja e dokumentuar e proxy-t pret një skemë HTTP; një shërbim gRPC i mbrojtur me TLS nuk kërkon në vetvete një pikë fundore proxy të mbrojtur me TLS. Kontrolloni veçmas vërtetimin e mbështetur në vend që të supozoni se çdo skemë hyrjeje e shfletuesit është e disponueshme. Për një objektiv publik gRPC ku lejohen ndërmjetës publikë, lista e proxy-ve HTTP ofron kandidatë pikash fundore për URI-në e zgjedhur të proxy HTTP; konfirmoni aksesin në objektivin dhe portin realë të CONNECT.
Një implementim gRPC në Java, Go, JavaScript ose një gjuhë tjetër mund të ketë kod transporti dhe konfigurim të ndryshëm. Mos e zbato listën e variablave të C-Core si rregull universal për gjithçka që quhet gRPC.
Për një kanal të dështuar, mbani proxy-n e zgjedhur, vendimin e anashkalimit, objektivin dhe fazën e gabimit. Një API HTTP e arritshme përmes një klienti tjetër nuk vërteton se ky mapper përdori të njëjtat cilësime ose se proxy lejon destinacionin e kërkuar CONNECT.