Hvorfor APT ikke bruger CONNECT til hver download
Almindelig HTTP-videresendelse og HTTPS-tunnelering bruger forskellige proxy-samtaler. En tjeneste med kun CONNECT understøtter måske ikke de anmodninger, et HTTP-lager producerer.
„Proxyen accepterer CONNECT“ betyder ikke, at den accepterer enhver anmodning, APT sender.
For et almindeligt HTTP-lager kan APT bruge normal HTTP-proxyvideresendelse: proxyen modtager en HTTP-anmodning, der identificerer destinationsressourcen. For HTTPS gennem en HTTP-proxy opretter klienten normalt en CONNECT-tunnel og forhandler derefter destinationens TLS-session gennem den.
| Destination | Typisk samtale med en HTTP-proxy |
|---|---|
| HTTP-lager | Videresend en HTTP-anmodning |
| HTTPS-lager | CONNECT, derefter destinationens TLS |
En tjeneste, der kun accepterer tunneler, kan afvise en almindelig videresendt anmodning. En HTTP 405 fortjener et kig på den faktiske metode, svarets udsteder og proxy-politikken; det beviser ikke, at APT mangler SOCKS-understøttelse, eller at dens adgangskode er forkert.
Sammenlign tjenestens understøttede adfærd med APT-transportdokumentationen og CONNECT-semantikken. Brug en kompatibel godkendt tjeneste eller en understøttet lager-URL. For offentlige lagre, hvor offentlige mellemled er tilladt, tilbyder HTTP-proxylisten kandidater til at kontrollere mod disse krav. Antag ikke, at tilføjelse af https:// til proxyadressen ændrer lagerets protokol eller gør enhver anmodning til en tunnel.