Proxy eta bypass aldagaien lehentasuna gRPC C-Core-n
Jarraitu gRPC Core-ren proxy eta bypass lehentasunari, gRPC inplementazio batek mapper bera erabiltzen duela suposatu gabe.
http_proxy aldatzeak ez du ezer egiten lehentasun handiagoko gRPC ezarpen bat badago. Hasi inplementazioa identifikatzen: ondorengo portaera gRPC C-Core-ren HTTP proxy mapper lehenetsiari eta haren mendekoei dagokie.
Mapper-ak kanal-proxy argumentua egiaztatzen du, gero grpc_proxy, gero https_proxy, gero http_proxy, eta konfiguratutako lehen balioan gelditzen da.
Bypass detekzioak bere ordena du: no_grpc_proxy-k no_proxy-ren gainetik du lehentasuna. Hango balio zahar batek azal dezake zergatik helburu batek bestela konfiguratutako proxy bat saihesten duen.
Mapper honek HTTP CONNECT erabiltzen du. Bere proxy URI dokumentatuak HTTP eskema espero du; TLS-rekin babestutako gRPC zerbitzu batek ez du berez TLS-rekin babestutako proxy mutur-puntu bat behar. Egiaztatu onartutako autentifikazioa bereizita, nabigatzaileko saio-hasiera eskema edozein dagoela suposatu beharrean. Bitartekari publikoak onartzen diren gRPC helburu publiko baterako, HTTP proxyen zerrendatik hautatutako HTTP proxy URI-rako mutur-puntu hautagaiak eskaintzen ditu; berretsi benetako CONNECT helburura eta portura iristea.
Java, Go, JavaScript edo beste hizkuntza bateko gRPC inplementazio batek garraio-kode eta konfigurazio desberdinak izan ditzake. Ez aplikatu C-Core aldagai-zerrenda gRPC deitzen den guztiarentzako arau unibertsal gisa.
Huts egin duen kanal baterako, gorde hautatutako proxy-a, bypass erabakia, helburua eta errore-fasea. Beste bezero batekiko HTTP API irisgarri batek ez du frogatzen mapper honek ezarpen berak erabili zituenik edo proxy-ak behar den CONNECT helmuga baimentzen duenik.