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 ಗಮ್ಯಸ್ಥಾನವನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.