Waarom APT niet voor elke download CONNECT gebruikt
Gewone HTTP-doorsturing en HTTPS-tunneling gebruiken verschillende proxygesprekken. Een dienst met alleen CONNECT ondersteunt mogelijk niet de verzoeken die een HTTP-repository produceert.
„De proxy accepteert CONNECT” betekent niet dat hij elk verzoek accepteert dat APT verstuurt.
Voor een gewone HTTP-repository kan APT normale HTTP-proxydoorsturing gebruiken: de proxy ontvangt een HTTP-verzoek dat de bestemmingsbron identificeert. Voor HTTPS via een HTTP-proxy stelt de client gewoonlijk een CONNECT-tunnel in en onderhandelt daarna de TLS-sessie van de bestemming erdoor.
| Bestemming | Typisch gesprek met een HTTP-proxy |
|---|---|
| HTTP-repository | Een HTTP-verzoek doorsturen |
| HTTPS-repository | CONNECT, dan TLS van de bestemming |
Een dienst die alleen tunnels accepteert, kan een gewoon doorgestuurd verzoek weigeren. Een HTTP 405 verdient een blik op de werkelijke methode, de afzender van de reactie en het proxybeleid; het bewijst niet dat APT geen SOCKS-ondersteuning heeft of dat het wachtwoord onjuist is.
Vergelijk het ondersteunde gedrag van de dienst met de APT-transportdocumentatie en de CONNECT-semantiek. Gebruik een compatibele goedgekeurde dienst of een ondersteunde repository-URL. Voor openbare repositories waar openbare tussenpersonen zijn toegestaan, biedt de HTTP-proxylijst kandidaten om tegen die eisen te controleren. Ga er niet van uit dat het toevoegen van https:// aan het proxyadres het protocol van de repository verandert of elk verzoek in een tunnel verandert.