Por qué APT no usa CONNECT para cada descarga
El reenvío HTTP ordinario y la tunelización HTTPS utilizan conversaciones de proxy distintas. Un servicio solo con CONNECT puede no admitir las solicitudes que genera un repositorio HTTP.
«El proxy acepta CONNECT» no significa que acepte todas las solicitudes que enviará APT.
Para un repositorio HTTP ordinario, APT puede usar el reenvío normal de proxy HTTP: el proxy recibe una solicitud HTTP que identifica el recurso de destino. Para HTTPS a través de un proxy HTTP, el cliente normalmente establece un túnel CONNECT y luego negocia la sesión TLS del destino a través de él.
| Destino | Conversación típica con un proxy HTTP |
|---|---|
| Repositorio HTTP | Reenviar una solicitud HTTP |
| Repositorio HTTPS | CONNECT y luego TLS del destino |
Un servicio que solo acepta túneles puede rechazar una solicitud reenviada ordinaria. Un HTTP 405 merece una mirada al método real, al emisor de la respuesta y a la política del proxy; no demuestra que APT carezca de compatibilidad con SOCKS ni que su contraseña sea incorrecta.
Compare el comportamiento admitido del servicio con la documentación de transporte de APT y la semántica de CONNECT. Utilice un servicio aprobado compatible o una URL de repositorio admitida. Para repositorios públicos donde se permiten intermediarios públicos, la lista de proxies HTTP ofrece candidatos para comprobarlos frente a esos requisitos. No suponga que añadir https:// a la dirección del proxy cambia el protocolo del repositorio ni convierte cada solicitud en un túnel.