Precedence ng proxy at bypass variables sa gRPC C-Core
Sundin ang precedence ng proxy at bypass ng gRPC Core nang hindi ipinapalagay na gumagamit ng parehong mapper ang ibang implementasyon ng gRPC.
Ang pagbabago ng http_proxy ay maaaring walang epekto kapag may umiiral nang setting ng gRPC na may mas mataas na priyoridad. Simulan sa pagkilala sa implementasyon: ang sumusunod na pag-uugali ay kabilang sa default na HTTP proxy mapper ng gRPC C-Core at sa mga nakadepende rito.
Sinusuri ng mapper ang argumento ng proxy ng channel, pagkatapos ang grpc_proxy, pagkatapos ang https_proxy, pagkatapos ang http_proxy, at humihinto sa unang naka-configure na halaga.
May sariling pagkakasunod-sunod ang pagtuklas ng bypass: nangingibabaw ang no_grpc_proxy sa no_proxy. Ang lumang halaga doon ay maaaring magpaliwanag kung bakit iniiwasan ng isang target ang isang proxy na naka-configure sa ibang paraan.
Gumagamit ang mapper na ito ng HTTP CONNECT. Inaasahan ng dokumentadong proxy URI nito ang isang HTTP scheme; ang serbisyong gRPC na protektado ng TLS ay hindi mismo nangangailangan ng proxy endpoint na protektado ng TLS. Suriin nang hiwalay ang sinusuportahang authentication sa halip na ipalagay na may available na anumang scheme ng pag-login ng browser. Para sa pampublikong target ng gRPC kung saan pinapayagan ang pampublikong intermediary, ang listahan ng mga HTTP proxy ay nag-aalok ng mga kandidatong endpoint para sa napiling HTTP proxy URI; tiyakin ang pag-access sa aktwal na target at port ng CONNECT.
Ang implementasyon ng gRPC sa Java, Go, JavaScript o ibang wika ay maaaring may ibang transport code at configuration. Huwag ilapat ang listahan ng variable ng C-Core bilang pangkalahatang tuntunin sa lahat ng tinatawag na gRPC.
Para sa nabigong channel, itago ang napiling proxy, desisyon sa bypass, target at yugto ng error. Ang HTTP API na maaabot sa pamamagitan ng ibang client ay hindi nagpapatunay na ginamit ng mapper na ito ang parehong mga setting o pinapayagan ng proxy ang kinakailangang destinasyon ng CONNECT.