Proxy i precedència de variables d'omissió a gRPC C-Core
Seguiu la precedència de proxy i d'omissió de gRPC Core sense suposar que una altra implementació de gRPC fa servir el mateix mapador.
Canviar http_proxy pot no fer res si ja hi ha un paràmetre de gRPC amb més prioritat. Comenceu identificant la implementació: el comportament següent pertany al mapador HTTP de proxy per defecte de gRPC C-Core i als seus dependents.
El mapador comprova un argument de proxy del canal, després grpc_proxy, després https_proxy, després http_proxy, i s'atura al primer valor configurat.
El descobriment d'omissions té el seu propi ordre: no_grpc_proxy té precedència sobre no_proxy. Un valor antic allà pot explicar per què un objectiu evita un proxy configurat d'altra manera.
Aquest mapador fa servir HTTP CONNECT. El seu URI de proxy documentat espera un esquema HTTP; un servei gRPC protegit amb TLS no requereix per si mateix un punt final de proxy protegit amb TLS. Comproveu l'autenticació compatible per separat en lloc de suposar que hi ha disponible qualsevol esquema d'inici de sessió del navegador. Per a un objectiu gRPC públic on es permeten intermediaris públics, la llista de proxys HTTP ofereix candidats de punt final per a l'URI de proxy HTTP seleccionat; confirmeu l'accés a l'objectiu i el port reals de CONNECT.
Una implementació de gRPC en Java, Go, JavaScript o una altra pot tenir codi de transport i configuració diferents. No apliqueu la llista de variables de C-Core com a regla universal per a tot el que es diu gRPC.
Per a un canal fallit, conserveu el proxy seleccionat, la decisió d'omissió, l'objectiu i l'etapa de l'error. Una API HTTP accessible des d'un altre client no demostra que aquest mapador fes servir els mateixos paràmetres ni que el proxy permeti la destinació CONNECT necessària.