gRPC C-Core ରେ ପ୍ରକ୍ସି ଏବଂ ବାଇପାସ୍ ଭେରିଏବଲ୍‌ର ପ୍ରାଥମିକତା

ଅଧିକ ପ୍ରାଥମିକତାର gRPC ସେଟିଂ ପୂର୍ବରୁ ଥିଲେ http_proxy ବଦଳାଇବାରେ କିଛି ନହେବ। ପ୍ରଥମେ କାର୍ଯ୍ୟକାରୀକୁ ଚିହ୍ନଟ କରନ୍ତୁ: ନିମ୍ନ ଆଚରଣ gRPC C-Core ର ଡିଫଲ୍ଟ HTTP ପ୍ରକ୍ସି ମ୍ୟାପର ଏବଂ ଏହା ଉପରେ ନିର୍ଭର କରୁଥିବା ଅଂଶର।

ମ୍ୟାପର ପ୍ରଥମେ ଚ୍ୟାନେଲ ପ୍ରକ୍ସି ଆର୍ଗୁମେଣ୍ଟ, ତାପରେ grpc_proxy, ତାପରେ https_proxy, ତାପରେ http_proxy ଯାଞ୍ଚ କରେ ଏବଂ ପ୍ରଥମ କନଫିଗର ହୋଇଥିବା ମୂଲ୍ୟରେ ଅଟକେ।

ବାଇପାସ୍ ଚିହ୍ନଟର ନିଜସ୍ୱ କ୍ରମ ଅଛି: no_grpc_proxy ର no_proxy ଉପରେ ପ୍ରାଥମିକତା ଅଛି। ସେଠାରେ ଥିବା ପୁରୁଣା ମୂଲ୍ୟ ଏକ ଲକ୍ଷ୍ୟ ଅନ୍ୟଥା କନଫିଗର ପ୍ରକ୍ସିକୁ କାହିଁକି ଏଡ଼ାଏ ତାହା ବ୍ୟାଖ୍ୟା କରିପାରେ।

ଏହି ମ୍ୟାପର HTTP CONNECT ବ୍ୟବହାର କରେ। ଏହାର ଡକ୍ୟୁମେଣ୍ଟେଡ୍ ପ୍ରକ୍ସି URI HTTP ସ୍କିମ୍ ଆଶା କରେ; TLS-ସୁରକ୍ଷିତ gRPC ସେବା ନିଜେ TLS-ସୁରକ୍ଷିତ ପ୍ରକ୍ସି ଏଣ୍ଡପଏଣ୍ଟ ଆବଶ୍ୟକ କରେ ନାହିଁ। କୌଣସି ବ୍ରାଉଜର ଲଗଇନ୍ ସ୍କିମ୍ ଉପଲବ୍ଧ ବୋଲି ନଧରି ସମର୍ଥିତ ପ୍ରମାଣୀକରଣ ଅଲଗା ଯାଞ୍ଚ କରନ୍ତୁ। ସାର୍ବଜନୀନ ମଧ୍ୟସ୍ଥ ଅନୁମତିପ୍ରାପ୍ତ ସାର୍ବଜନୀନ gRPC ଲକ୍ଷ୍ୟ ପାଇଁ, HTTP ପ୍ରକ୍ସି ତାଲିକାରୁ ମନୋନୀତ HTTP ପ୍ରକ୍ସି URI ପାଇଁ ଏଣ୍ଡପଏଣ୍ଟ ପ୍ରାର୍ଥୀ ଦିଏ; ପ୍ରକୃତ CONNECT ଲକ୍ଷ୍ୟ ଏବଂ ପୋର୍ଟକୁ ପ୍ରବେଶ ନିଶ୍ଚିତ କରନ୍ତୁ।

Java, Go, JavaScript କିମ୍ବା ଅନ୍ୟ ଭାଷାର gRPC କାର୍ଯ୍ୟକାରୀର ପରିବହନ କୋଡ୍ ଏବଂ କନଫିଗରେସନ୍ ଭିନ୍ନ ହୋଇପାରେ। gRPC କୁହାଯାଉଥିବା ସବୁକିଛି ଉପରେ C-Core ଭେରିଏବଲ୍ ତାଲିକାକୁ ସର୍ବଭୌମ ନିୟମ ଭାବରେ ଲାଗୁ କରନ୍ତୁ ନାହିଁ।

ବିଫଳ ଚ୍ୟାନେଲ ପାଇଁ ମନୋନୀତ ପ୍ରକ୍ସି, ବାଇପାସ୍ ନିଷ୍ପତ୍ତି, ଲକ୍ଷ୍ୟ ଏବଂ ତ୍ରୁଟିର ପର୍ଯ୍ୟାୟ ସଂରକ୍ଷିତ ରଖନ୍ତୁ। ଅନ୍ୟ କ୍ଲାଏଣ୍ଟ ମାଧ୍ୟମରେ ପହଞ୍ଚିବାଯୋଗ୍ୟ HTTP API ଏହା ପ୍ରମାଣ କରେ ନାହିଁ ଯେ ଏହି ମ୍ୟାପର ସେହି ସେଟିଂ ବ୍ୟବହାର କରିଛି କିମ୍ବା ପ୍ରକ୍ସି ଆବଶ୍ୟକ CONNECT ଗନ୍ତବ୍ୟସ୍ଥାନକୁ ଅନୁମତି ଦିଏ।