curl, .NET ਅਤੇ ਕੰਟੇਨਰਾਂ ਵਿੱਚ NO_PROXY ਅਨੁਕੂਲਤਾ
ਸਾਂਝੀ ਸਿੱਧੀ-ਰੂਟਿੰਗ ਨੀਤੀ ਨੂੰ ਥੋੜ੍ਹੇ ਜਿਹੇ ਪ੍ਰਤੀਨਿਧ ਮੰਜ਼ਿਲਾਂ ਦੀ ਵਰਤੋਂ ਨਾਲ ਕਲਾਇੰਟ-ਖਾਸ ਸੰਰਚਨਾ ਵਿੱਚ ਬਦਲੋ।
ਇੱਕ ਟੀਮ ਸਾਂਝੀ environment ਫਾਈਲ ਵਿੱਚ ਇੱਕ ਬਾਈਪਾਸ ਸਟਰਿੰਗ ਪਾਉਂਦੀ ਹੈ। curl ਸਿੱਧਾ ਜਾਂਦਾ ਹੈ, ਦੂਜੀ ਐਪਲੀਕੇਸ਼ਨ proxy ਵਰਤਦੀ ਹੈ, ਅਤੇ ਕੰਟੇਨਰ ਫਿਰ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ। ਸਾਂਝੀ ਫਾਈਲ ਨੇ ਉਹੀ ਅੱਖਰ ਵੰਡੇ। ਇਸਨੇ ਇੱਕ ਸਾਂਝਾ parser ਨਹੀਂ ਵੰਡਿਆ।
ਟਿਕਾਊ ਚੀਜ਼ ਨੀਤੀ ਹੈ: ਕਿਹੜੀਆਂ ਮੰਜ਼ਿਲਾਂ ਸਿੱਧੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਕਿਹੜੀਆਂ ਸ਼ਰਤਾਂ ਹੇਠ? ਇਸਨੂੰ ਹਰ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਲੋੜੀਂਦੀ ਸਟਰਿੰਗ ਤੋਂ ਵੱਖ ਰੱਖੋ।
ਪਹਿਲਾਂ ਉਮੀਦ ਕੀਤੇ ਰੂਟ ਲਿਖੋ
ਸਿਰਫ਼ ਆਸਾਨ ਸਫਲਤਾਵਾਂ ਨਹੀਂ, ਸਗੋਂ ਸੀਮਾ-ਕੇਸ ਵੀ ਸਮੇਤ ਪ੍ਰਤੀਨਿਧ ਪਤੇ ਵਰਤੋ:
| ਮੰਜ਼ਿਲ ਦਾ ਰੂਪ | ਨੀਤੀ ਮਾਲਕ ਲਈ ਸਵਾਲ |
|---|---|
| ਮੁੱਢਲਾ ਡੋਮੇਨ | ਕੀ ਇਸਨੂੰ ਬਾਈਪਾਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਸਿਰਫ਼ ਇਸਦੇ ਬੱਚਿਆਂ ਨੂੰ? |
| ਇੱਕ ਸਬਡੋਮੇਨ | ਕੀ ਇਹ ਉਹੀ ਰੂਟ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ? |
| ਸ਼ਬਦੀ ਨਿੱਜੀ IP | ਕੀ ਉਹ ਪਤਾ ਇਸ ਕਲਾਇੰਟ ਤੋਂ ਸਿੱਧਾ ਪਹੁੰਚਯੋਗ ਹੈ? |
| hostname ਹੇਠ ਉਹੀ ਸੇਵਾ | ਕੀ ਨਾਮ-ਅਧਾਰਿਤ ਅਤੇ ਪਤਾ-ਅਧਾਰਿਤ ਬੇਨਤੀਆਂ ਮੇਲ ਖਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ? |
| ਹੋਰ ਸੇਵਾ ਪੋਰਟ | ਕੀ ਛੋਟ host ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ ਜਾਂ ਇੱਕ ਸੁਣਨ ਵਾਲੇ ਨੂੰ? |
ਫਿਰ ਖਪਤਕਾਰਾਂ ਦੀ ਪਛਾਣ ਕਰੋ: image ਖਿੱਚਣ ਵਾਲਾ daemon, ਕੰਟੇਨਰ ਅੰਦਰਲਾ ਪ੍ਰੋਗਰਾਮ, ਕਿਸੇ ਭਾਸ਼ਾ ਦੀ HTTP ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਇੱਕ ਇੰਟਰਐਕਟਿਵ ਬ੍ਰਾਊਜ਼ਰ ਸਾਰੇ ਵੱਖਰੀਆਂ ਐਂਟਰੀਆਂ ਹੋ ਸਕਦੇ ਹਨ। Docker ਕਲਾਇੰਟ proxy ਸੰਰਚਨਾ ਕੰਟੇਨਰ ਦੇ environment ਮੁੱਲ ਭਰ ਸਕਦੀ ਹੈ, ਬਿਨਾਂ ਇਹ ਕਹੇ ਕਿ ਅੰਦਰਲੇ ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਉਹੀ ਮੇਲ ਨਿਯਮ ਲਾਗੂ ਕਰਨੇ ਪੈਣ।
ਅੰਨ੍ਹੇਵਾਹ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ ਅਨੁਵਾਦ ਕਰੋ
ਸੱਚੇ ਫ਼ਰਕ ਦੀ ਇੱਕ ਦਰਜ ਉਦਾਹਰਨ ਮੁੱਢਲੇ-ਡੋਮੇਨ ਦੀ ਸੀਮਾ ਹੈ। curl ਦੀ ਡੋਮੇਨ ਛੋਟ ਨਾਮਿਤ ਡੋਮੇਨ ਅਤੇ ਮੇਲ ਖਾਣ ਵਾਲੇ ਬੱਚਿਆਂ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ। .NET ਦੀ environment ਨੀਤੀ ਖਾਲੀ ਨਾਮ ਨੂੰ ਅੱਗੇ ਬਿੰਦੀ ਵਾਲੇ ਸਬਡੋਮੇਨ ਰੂਪ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ। „ਹਮੇਸ਼ਾ ਅੱਗੇ ਬਿੰਦੀ ਜੋੜੋ“ ਵਾਲਾ ਸਰਵਵਿਆਪੀ ਨਿਯਮ ਦੋਵੇਂ ਨੀਤੀਆਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰ ਸਕਦਾ।
IP-ਰੇਂਜ ਸਹਾਇਤਾ ਵੀ ਖਪਤਕਾਰ ਅਤੇ ਉਸਦੇ ਸੰਸਕਰਣ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਨਵੇਂ ਸੁਤੰਤਰ curl ਵਾਲੀ ਮਸ਼ੀਨ ਫਿਰ ਵੀ ਪੁਰਾਣੇ libcurl ਨਾਲ ਜੁੜੀ ਐਪਲੀਕੇਸ਼ਨ, ਜਾਂ ਬਿਲਕੁਲ ਹੋਰ ਲਾਇਬ੍ਰੇਰੀ ਵਰਤਣ ਵਾਲਾ ਕਲਾਇੰਟ ਚਲਾ ਸਕਦੀ ਹੈ। ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੀ ਰਿਲੀਜ਼ ਪੂਰੀ ਕਲਾਇੰਟ ਸੂਚੀ ਨਹੀਂ ਹੈ।
ਹਰ ਖਪਤਕਾਰ ਲਈ, ਉਸਦਾ ਸਮਰਥਿਤ ਸੰਰਚਨਾ ਇੰਟਰਫੇਸ ਅਤੇ ਇੱਛਤ ਰੂਟਾਂ ਦਾ ਸਭ ਤੋਂ ਛੋਟਾ ਪ੍ਰਗਟਾਵਾ ਦਰਜ ਕਰੋ। ਜਿਸਦਾ ਅਰਥ ਕੋਈ ਵੀ ਨਹੀਂ ਸਮਝਾ ਸਕਦਾ, ਅਜਿਹੇ ਚਤੁਰ ਪੈਟਰਨ ਨਾਲੋਂ ਛੋਟੀ ਸਪਸ਼ਟ host ਸੂਚੀ ਬਿਹਤਰ ਹੋ ਸਕਦੀ ਹੈ।
ਸੰਰਚਨਾ ਸਬੂਤ ਨੂੰ ਕਨੈਕਸ਼ਨ ਸਬੂਤ ਤੋਂ ਵੱਖ ਰੱਖੋ
ਪਾਰਸ ਕੀਤੀ ਸੈਟਿੰਗ ਜਾਂ ਰੂਟਿੰਗ-ਫੈਸਲਾ API ਦਿਖਾ ਸਕਦੀ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮ ਨੇ ਕੀ ਚੁਣਿਆ। ਬੇਨਤੀ ਦਾ ਨਤੀਜਾ ਫਿਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਰੂਟ ਵਰਤੋਂਯੋਗ ਸੀ ਜਾਂ ਨਹੀਂ। .NET ਵਿੱਚ, HttpClient.DefaultProxy.IsBypassed ਉਹ ਸੰਰਚਨਾ-ਪਾਸੇ ਦੀ ਜਾਂਚ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਡਿਫਾਲਟ proxy ਵਰਤੀ ਜਾ ਰਹੀ ਨੀਤੀ ਹੁੰਦੀ ਹੈ। ਸਿਰਫ਼ ਬੇਨਤੀ ਦਾ ਸਮਾਂ ਖ਼ਤਮ ਹੋਣ ਕਾਰਨ ਨਾ-ਪਹੁੰਚਯੋਗ ਸਿੱਧੀ ਸੇਵਾ ਨੂੰ ਬਾਈਪਾਸ-ਪਾਰਸਰ ਦੀ ਅਸਫਲਤਾ ਵਜੋਂ ਨਾ ਪਛਾਣੋ।
ਕਲਾਇੰਟ ਜਾਂ ਆਧਾਰ image ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਿਆਂ ਸੀਮਾ ਮੰਜ਼ਿਲਾਂ ਰੱਖੋ। ਉਹ ਭਵਿੱਖ ਦੇ ਅਨੁਕੂਲਤਾ ਬਦਲਾਅ ਦਿਖਾਉਂਦੀਆਂ ਹਨ, ਬਿਨਾਂ ਇਸ ਦੀ ਲੋੜ ਕਿ ਪੂਰੀ ਟੀਮ ਦੁਬਾਰਾ ਖੋਜੇ ਕਿ ਫਾਈਲ ਵਿੱਚ ਦੋ ਮਿਲਦੇ-ਜੁਲਦੇ ਡੋਮੇਨ ਐਂਟਰੀਆਂ ਕਿਉਂ ਹਨ।