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 ਮੰਜ਼ਿਲ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ।