Varför APT inte använder CONNECT för varje nedladdning
Vanlig HTTP-vidarebefordran och HTTPS-tunnel använder olika proxy-samtal. En tjänst med bara CONNECT stöder kanske inte de förfrågningar som ett HTTP-förråd producerar.
”Proxy:n accepterar CONNECT” betyder inte att den accepterar varje förfrågan APT skickar.
För ett vanligt HTTP-förråd kan APT använda vanlig HTTP-proxyvidarebefordran: proxy:n tar emot en HTTP-förfrågan som identifierar målresursen. För HTTPS genom en HTTP-proxy upprättar klienten vanligtvis en CONNECT-tunnel och förhandlar sedan målresursens TLS-session genom den.
| Mål | Typiskt samtal med en HTTP-proxy |
|---|---|
| HTTP-förråd | Vidarebefordra en HTTP-förfrågan |
| HTTPS-förråd | CONNECT, sedan målets TLS |
En tjänst som bara accepterar tunnlar kan avvisa en vanlig vidarebefordrad förfrågan. En HTTP 405 förtjänar en titt på den faktiska metoden, avsändaren av svaret och proxy-policyn; det bevisar inte att APT saknar SOCKS-stöd eller att lösenordet är fel.
Jämför tjänstens stödda beteende med APT:s transportdokumentation och CONNECT-semantiken. Använd en kompatibel godkänd tjänst eller en stödd förråds-URL. För offentliga förråd där offentliga mellanhänder är tillåtna erbjuder HTTP-proxylistan kandidater att kontrollera mot dessa krav. Anta inte att det att lägga till https:// i proxyadressen ändrar förrådets protokoll eller gör varje förfrågan till en tunnel.