Kvifor APT ikkje brukar CONNECT for kvar nedlasting
Vanleg HTTP-vidaresending og HTTPS-tunnelering brukar ulike proxy-samtalar. Ei teneste med berre CONNECT støttar kanskje ikkje førespurnadene eit HTTP-lager lagar.
«Proxyen godtek CONNECT» tyder ikkje at han godtek kvar førespurnad APT sender.
For eit vanleg HTTP-lager kan APT bruke vanleg HTTP-proxyvidaresending: proxyen mottek ein HTTP-førespurnad som identifiserer målressursen. For HTTPS gjennom ein HTTP-proxy set klienten vanlegvis opp ein CONNECT-tunnel og forhandlar deretter TLS-økta til målet gjennom han.
| Mål | Typisk samtale med ein HTTP-proxy |
|---|---|
| HTTP-lager | Send ein HTTP-førespurnad vidare |
| HTTPS-lager | CONNECT, deretter TLS til målet |
Ei teneste som berre godtek tunnelar, kan avvise ein vanleg vidaresend førespurnad. Ein HTTP 405 fortener eit blikk på den faktiske metoden, avsendar av svaret og proxy-politikken; det beviser ikkje at APT manglar SOCKS-støtte eller at passordet er feil.
Samanlikn den støtta åtferda til tenesta med APT-transportdokumentasjonen og CONNECT-semantikken. Bruk ei kompatibel godkjend teneste eller ein støtta lager-URL. For offentlege lager der offentlege mellomledd er tillatne, tilbyr HTTP-proxylista kandidatar å kontrollere mot desse krava. Ikkje gå ut frå at det å leggje til https:// i proxyadressa endrar protokollen til lageret eller gjer kvar førespurnad til ein tunnel.