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:// जोड़ने से रिपॉज़िटरी का प्रोटोकॉल बदल जाता है या हर अनुरोध टनल बन जाता है।