Hvorfor APT ikke bruker CONNECT for hver nedlasting
Vanlig HTTP-videresending og HTTPS-tunnelering bruker forskjellige proxy-samtaler. En tjeneste med bare CONNECT støtter kanskje ikke forespørslene et HTTP-lager produserer.
«Proxyen godtar CONNECT» betyr ikke at den godtar hver forespørsel APT sender.
For et vanlig HTTP-lager kan APT bruke vanlig HTTP-proxyvideresending: proxyen mottar en HTTP-forespørsel som identifiserer målressursen. For HTTPS gjennom en HTTP-proxy oppretter klienten vanligvis en CONNECT-tunnel og forhandler deretter målets TLS-økt gjennom den.
| Mål | Typisk samtale med en HTTP-proxy |
|---|---|
| HTTP-lager | Videresend en HTTP-forespørsel |
| HTTPS-lager | CONNECT, deretter målets TLS |
En tjeneste som bare godtar tunneler, kan avvise en vanlig videresendt forespørsel. En HTTP 405 fortjener en titt på den faktiske metoden, avsenderen av svaret og proxy-policyen; det beviser ikke at APT mangler SOCKS-støtte eller at passordet er feil.
Sammenlign tjenestens støttede atferd med APT-transportdokumentasjonen og CONNECT-semantikken. Bruk en kompatibel godkjent tjeneste eller en støttet lager-URL. For offentlige lagre der offentlige mellommenn er tillatt, tilbyr HTTP-proxylisten kandidater å kontrollere mot disse kravene. Ikke anta at det å legge til https:// i proxyadressen endrer lagerets protokoll eller gjør hver forespørsel til en tunnel.