Keutamaan Pemboleh Ubah Proksi dan Pintasan gRPC C-Core
Jejaki keutamaan proksi dan pintasan gRPC Core tanpa menganggap pelaksanaan gRPC lain menggunakan pemeta yang sama.
Menukar http_proxy mungkin tidak berkesan jika tetapan gRPC berkeutamaan lebih tinggi sudah ada. Mulakan dengan mengenal pasti pelaksanaannya: tingkah laku berikut milik pemeta proksi HTTP lalai gRPC C-Core dan bahagian yang bergantung padanya.
Pemeta menyemak argumen proksi saluran, kemudian grpc_proxy, kemudian https_proxy, kemudian http_proxy, dan berhenti pada nilai pertama yang dikonfigurasikan.
Penemuan pintasan mempunyai urutannya sendiri: no_grpc_proxy mengatasi no_proxy. Nilai lama di situ boleh menjelaskan mengapa sesuatu sasaran mengelak proksi yang dikonfigurasikan sebaliknya.
Pemeta ini menggunakan HTTP CONNECT. URI proksi yang didokumenkan menjangka skema HTTP; perkhidmatan gRPC yang dilindungi TLS tidak dengan sendirinya memerlukan titik akhir proksi yang dilindungi TLS. Semak pengesahan yang disokong secara berasingan dan jangan anggap mana-mana skema log masuk pelayar tersedia. Bagi sasaran gRPC awam yang membenarkan perantara awam, senarai proksi HTTP menawarkan calon titik akhir untuk URI proksi HTTP yang dipilih; sahkan akses kepada sasaran dan port CONNECT sebenar.
Pelaksanaan gRPC dalam Java, Go, JavaScript atau bahasa lain mungkin mempunyai kod pengangkutan dan konfigurasi yang berbeza. Jangan gunakan senarai pemboleh ubah C-Core sebagai peraturan sejagat untuk semua yang dipanggil gRPC.
Bagi saluran yang gagal, simpan proksi yang dipilih, keputusan pintasan, sasaran dan peringkat ralat. API HTTP yang boleh dicapai melalui klien lain tidak membuktikan pemeta ini menggunakan tetapan yang sama atau proksi membenarkan destinasi CONNECT yang diperlukan.