Composer ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗਾਂ: REQUEST_FULLURI ਫਲੈਗ ਛੱਡੋ

Composer ਦੇ ਪੁਰਾਣੇ HTTP_PROXY_REQUEST_FULLURI ਅਤੇ ਸੰਬੰਧਿਤ FULLURI ਹੱਲ ਦਸਤਾਵੇਜ਼ੀ ਲਾਗੂਆਂ ਵਿੱਚ ਹੁਣ ਲੋੜੀਂਦੇ ਨਹੀਂ ਹਨ ਅਤੇ ਨਹੀਂ ਵਰਤੇ ਜਾਂਦੇ। ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਫਲੈਗ ਚੱਲ ਰਹੇ ਕਲਾਇੰਟ ਦਾ ਰਾਹ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ।

POSIX shell ਵਿੱਚ ਕਮਾਂਡ-ਲਾਈਨ Composer ਲਈ, ਉਸ shell ਤੋਂ Composer ਸੱਦਣ ਤੋਂ ਪਹਿਲਾਂ ਸਮਰਥਿਤ ਪ੍ਰੌਕਸੀ ਵੇਰੀਏਬਲ export ਕਰੋ:

export http_proxy=http://proxy.example:8080
export https_proxy=http://proxy.example:8080

ਛੋਟੇ ਅੱਖਰਾਂ ਵਾਲੇ ਨਾਮ ਪਸੰਦ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਪ੍ਰੌਕਸੀ ਆਪ ਸਾਧਾਰਨ HTTP ਵਰਤਦਾ ਹੈ ਤਾਂ ਦੋਵੇਂ ਮੁੱਲ http:// ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਸਕਦੇ ਹਨ; HTTPS ਮੰਜ਼ਿਲ ਲਈ ਪ੍ਰੌਕਸੀ ਨਾਲ HTTPS ਕਨੈਕਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਦਾਹਰਨ endpoint ਨੂੰ ਮਨਜ਼ੂਰ ਸੇਵਾ ਨਾਲ ਬਦਲੋ। ਜਨਤਕ ਪੈਕੇਜ ਡਾਊਨਲੋਡ ਲਈ ਜਿੱਥੇ ਜਨਤਕ ਵਿਚੋਲੇ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, HTTP ਪ੍ਰੌਕਸੀ ਸੂਚੀ ਤੋਂ HTTP ਉਮੀਦਵਾਰ ਚੁਣੋ।

IDE ਜਾਂ build ਏਜੰਟ ਨੂੰ ਮੁੱਲ ਆਪਣੇ ਹੀ ਪ੍ਰੋਸੈਸ ਵਾਤਾਵਰਨ ਵਿੱਚ ਚਾਹੀਦੇ ਹਨ। ਬਾਅਦ ਵਿੱਚ ਪੱਕੀ ਸੈਟਿੰਗ ਬਦਲਣ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਿਹਾ ਪ੍ਰੋਸੈਸ ਅੱਪਡੇਟ ਨਹੀਂ ਹੁੰਦਾ।

ਜਦੋਂ Composer CLI ਤੋਂ ਬਾਹਰ ਚੱਲਦਾ ਹੈ

CLI ਤੋਂ ਬਿਨਾਂ ਸੰਦਰਭ ਵਿੱਚ HTTP ਬੇਨਤੀਆਂ ਲਈ Composer http_proxy ਜਾਂ HTTP_PROXY ਨਹੀਂ ਵਰਤਦਾ। ਇਸਦੀ ਥਾਂ ਇਹ CGI_HTTP_PROXY ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਬੇਨਤੀ ਹੈਡਰਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਪ੍ਰੌਕਸੀ ਸੰਰਚਨਾ ਸਮਝੇ ਜਾਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। shell ਹੱਲ ਨੂੰ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਨਕਲ ਨਾ ਕਰੋ ਅਤੇ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲੀ ਬੇਨਤੀ ਤੋਂ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗ ਨਾ ਲਵੋ।

ਅਸਫਲ ਕਾਰਵਾਈ ਪੜ੍ਹੋ

ਨਾ-ਸੁਲਝਿਆ ਪ੍ਰੌਕਸੀ ਨਾਮ, ਰੱਦ ਕੀਤਾ ਕਨੈਕਸ਼ਨ, 407 ਚੁਣੌਤੀ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਅਸਫਲਤਾ ਵੱਖ-ਵੱਖ ਪੜਾਵਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ। ਪੁਰਾਣੇ IPv6 ਜਾਂ ਸਰਟੀਫਿਕੇਟ-ਤਸਦੀਕ ਹੱਲ ਲਾਗੂ ਕਰਨ ਦੀ ਥਾਂ ਪਹਿਲੀ ਅਰਥਪੂਰਨ ਗਲਤੀ ਵਰਤੋ।

ਜੇ Composer ਦਾ HTTP ਡਾਊਨਲੋਡ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ Git-ਆਧਾਰਿਤ ਨਿਰਭਰਤਾ ਅਸਫਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਵੱਖਰੀ Git ਪ੍ਰੋਸੈਸ, ਉਸਦਾ ਰਾਹ ਅਤੇ ਉਸਦਾ ਖਾਤਾ ਜਾਂਚੋ। ਉਹ ਸਫਲ Composer ਡਾਊਨਲੋਡ ਤੋਂ ਵੱਖਰਾ ਉਪਭੋਗਤਾ ਹੈ।