Composer ನ ಹಳೆಯ HTTP_PROXY_REQUEST_FULLURI ಮತ್ತು ಸಂಬಂಧಿತ FULLURI ಪರಿಹಾರಗಳು ದಾಖಲಿತ ಅನುಷ್ಠಾನದಲ್ಲಿ ಇನ್ನು ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಬಳಕೆಯಲ್ಲಿಲ್ಲ. ನಿರ್ಲಕ್ಷಿಸಿದ ಫ್ಲ್ಯಾಗ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಕ್ಲೈಂಟ್‌ನ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಲಾರದು.

POSIX ಶೆಲ್‌ನಲ್ಲಿ ಕಮಾಂಡ್-ಲೈನ್ Composer ಗಾಗಿ, ಆ ಶೆಲ್‌ನಿಂದ 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 ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಇದು ವಿನಂತಿ ಹೆಡರ್‌ಗಳನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಾಕ್ಸಿ ಸಂರಚನೆ ಎಂದು ತಪ್ಪಾಗಿ ಗ್ರಹಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಶೆಲ್ ಪರಿಹಾರವನ್ನು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನಕಲಿಸಬೇಡಿ ಮತ್ತು ಅವಿಶ್ವಾಸಾರ್ಹ ವಿನಂತಿಯಿಂದ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಡಿ.

ವಿಫಲವಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಓದಿ

ಬಗೆಹರಿಯದ ಪ್ರಾಕ್ಸಿ ಹೆಸರು, ನಿರಾಕರಿಸಿದ ಸಂಪರ್ಕ, 407 ಸವಾಲು ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ವೈಫಲ್ಯ ವಿವಿಧ ಹಂತಗಳನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಹಳೆಯ IPv6 ಅಥವಾ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಪರಿಹಾರಗಳನ್ನು ಅನ್ವಯಿಸುವ ಬದಲು ಮೊದಲ ಅರ್ಥಪೂರ್ಣ ದೋಷವನ್ನು ಬಳಸಿ.

Composer ನ HTTP ಡೌನ್‌ಲೋಡ್ ಕೆಲಸ ಮಾಡಿದರೂ Git ಆಧಾರಿತ ಅವಲಂಬನೆ ವಿಫಲವಾದರೆ, ಪ್ರತ್ಯೇಕ Git ಪ್ರಕ್ರಿಯೆ, ಅದರ ಮಾರ್ಗ ಮತ್ತು ಅದರ ಖಾತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಅದು ಯಶಸ್ವಿ Composer ಡೌನ್‌ಲೋಡ್‌ಗಿಂತ ಬೇರೆ ಬಳಕೆದಾರ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು