APT દરેક ડાઉનલોડ માટે CONNECT કેમ વાપરતું નથી
સામાન્ય HTTP ફોરવર્ડિંગ અને HTTPS ટનલિંગ જુદી જુદી પ્રોક્સી વાતચીતો વાપરે છે. ફક્ત CONNECT આધારિત સેવા HTTP રિપોઝિટરી જે વિનંતીઓ બનાવે છે તેને સપોર્ટ ન કરી શકે.
“પ્રોક્સી CONNECT સ્વીકારે છે” એનો અર્થ એ નથી કે તે APT મોકલશે તેવી દરેક વિનંતી સ્વીકારે છે.
સામાન્ય HTTP રિપોઝિટરી માટે, APT સામાન્ય HTTP પ્રોક્સી ફોરવર્ડિંગ વાપરી શકે છે: પ્રોક્સી લક્ષ્ય સંસાધન ઓળખતી HTTP વિનંતી મેળવે છે. HTTP પ્રોક્સી દ્વારા HTTPS માટે, ક્લાયન્ટ સામાન્ય રીતે CONNECT ટનલ સ્થાપે છે, પછી તેના દ્વારા લક્ષ્યનું TLS સત્ર વાટાઘાટ કરે છે.
| લક્ષ્ય | HTTP પ્રોક્સી સાથેની સામાન્ય વાતચીત |
|---|---|
| HTTP રિપોઝિટરી | HTTP વિનંતી ફોરવર્ડ કરો |
| HTTPS રિપોઝિટરી | CONNECT, પછી લક્ષ્ય TLS |
ફક્ત ટનલ સ્વીકારતી સેવા સામાન્ય ફોરવર્ડ કરેલી વિનંતી નકારી શકે છે. HTTP 405 વાસ્તવિક પદ્ધતિ, પ્રતિસાદ આપનાર અને પ્રોક્સી નીતિ પર નજર કરવા લાયક છે; તે સાબિત કરતું નથી કે APT માં SOCKS સપોર્ટ નથી અથવા તેનો પાસવર્ડ ખોટો છે.
સેવાના સપોર્ટેડ વર્તનની APT ટ્રાન્સપોર્ટ દસ્તાવેજીકરણ અને CONNECT અર્થ સાથે તુલના કરો. સુસંગત મંજૂર સેવા અથવા સપોર્ટેડ રિપોઝિટરી URL વાપરો. જાહેર રિપોઝિટરી માટે જ્યાં જાહેર મધ્યસ્થીઓને મંજૂરી છે, HTTP પ્રોક્સી સૂચિ તે જરૂરિયાતો સામે ચકાસવા ઉમેદવારો આપે છે. એવું ન ધારો કે પ્રોક્સી સરનામાંમાં https:// ઉમેરવાથી રિપોઝિટરીનો પ્રોટોકોલ બદલાય છે અથવા દરેક વિનંતી ટનલ બની જાય છે.