Composer પ્રોક્સી સેટિંગ્સ: REQUEST_FULLURI ફ્લેગ્સ છોડી દો
વર્તમાન Composer પ્રોક્સી પર્યાવરણ ચલોનું દસ્તાવેજીકરણ કરે છે અને ઘણા જવાબોમાં મળતા જૂના REQUEST_FULLURI ઉપાયો હવે વાપરતું નથી.
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 ડાઉનલોડ કરતાં જુદો વપરાશકર્તા છે.