Kipaumbele cha proksi na vigezo vya kupita katika gRPC C-Core

Kubadilisha http_proxy kunaweza kusifanye chochote ikiwa mpangilio wa gRPC wenye kipaumbele cha juu tayari upo. Anza kwa kutambua utekelezaji: tabia ifuatayo ni ya mapper chaguo-msingi wa proksi HTTP ya gRPC C-Core na wale wanaotegemea hiyo.

Mapper hukagua hoja ya proksi ya kituo, kisha grpc_proxy, kisha https_proxy, kisha http_proxy, na husimama kwenye thamani ya kwanza iliyowekwa.

Ugunduzi wa kupita una mpangilio wake: no_grpc_proxy ina kipaumbele juu ya no_proxy. Thamani ya zamani hapo inaweza kueleza kwa nini lengo moja huepuka proksi iliyowekwa kwa njia nyingine.

Mapper hii inatumia HTTP CONNECT. URI ya proksi iliyoandikwa inatarajia mpango wa HTTP; huduma ya gRPC inayolindwa na TLS yenyewe haihitaji kituo cha mwisho cha proksi kinacholindwa na TLS. Kagua uthibitishaji unaotumika kando badala ya kudhani kuwa mpango wowote wa kuingia kwenye kivinjari unapatikana. Kwa lengo la umma la gRPC ambapo wapatanishi wa umma wanaruhusiwa, orodha ya proksi za HTTP inatoa wagombea wa vituo vya mwisho kwa URI ya proksi HTTP iliyochaguliwa; thibitisha ufikiaji wa lengo na bandari halisi za CONNECT.

Utekelezaji wa gRPC katika Java, Go, JavaScript au lugha nyingine unaweza kuwa na msimbo na usanidi tofauti wa usafirishaji. Usitumie orodha ya vigezo vya C-Core kama kanuni ya jumla kwa kila kitu kinachoitwa gRPC.

Kwa kituo kilichoshindikana, hifadhi proksi iliyochaguliwa, uamuzi wa kupita, lengo na hatua ya hitilafu. API ya HTTP inayofikiwa kupitia mteja mwingine haithibitishi kuwa mapper hii ilitumia mipangilio ile ile au kwamba proksi inaruhusu lengo la CONNECT linalohitajika.