Приоритет прокси и bypass променљивих у gRPC C-Core
Пратите приоритет проксија и заобилажења у gRPC Core без претпоставке да друга gRPC имплементација користи исти мапер.
Промена http_proxy може не учинити ништа ако већ постоји gRPC поставка вишег приоритета. Почните идентификацијом имплементације: следеће понашање припада подразумеваном HTTP прокси маперу gRPC C-Core и његовим зависностима.
Мапер проверава аргумент проксија канала, затим grpc_proxy, затим https_proxy, затим http_proxy и зауставља се на првој постављеној вредности.
Откривање заобилажења има сопствени редослед: no_grpc_proxy има предност над no_proxy. Стара вредност тамо може објаснити зашто неки циљ избегава иначе постављени прокси.
Овај мапер користи HTTP CONNECT. Његов документовани прокси URI очекује HTTP шему; gRPC услуга заштићена TLS-ом сама по себи не захтева TLS-ом заштићену прокси крајњу тачку. Проверите подржану аутентификацију одвојено уместо да претпоставите да је доступна било каква шема пријаве у прегледачу. За јавни gRPC циљ где су јавни посредници дозвољени, листе HTTP проксија нуди кандидате крајњих тачака за изабрани HTTP прокси URI; потврдите приступ стварном CONNECT циљу и порту.
Имплементација gRPC-а у Java, Go, JavaScript или другом језику може имати другачији транспортни код и конфигурацију. Не примењујте листу C-Core променљивих као универзално правило на све што се зове gRPC.
За неуспешан канал задржите изабрани прокси, одлуку о заобилажењу, циљ и фазу грешке. Доступан HTTP API кроз други клијент не доказује да је овај мапер користио исте поставке или да прокси дозвољава тражено CONNECT одредиште.