Чому APT не використовує CONNECT для кожного завантаження
Звичайне пересилання HTTP і тунелювання HTTPS використовують різні розмови з проксі. Служба лише з CONNECT може не підтримувати запити, які створює HTTP-репозиторій.
«Проксі приймає CONNECT» не означає, що він приймає кожен запит, який надішле APT.
Для звичайного HTTP-репозиторію APT може використовувати звичайне пересилання через HTTP-проксі: проксі отримує HTTP-запит, що ідентифікує цільовий ресурс. Для HTTPS через HTTP-проксі клієнт зазвичай встановлює тунель CONNECT, а потім узгоджує TLS-сеанс призначення через нього.
| Призначення | Типова розмова з HTTP-проксі |
|---|---|
| HTTP-репозиторій | Переслати HTTP-запит |
| HTTPS-репозиторій | CONNECT, потім TLS призначення |
Служба, що приймає лише тунелі, може відхилити звичайний пересланий запит. HTTP 405 вартий уваги до фактичного методу, джерела відповіді та політики проксі; він не доводить, що APT не підтримує SOCKS або що його пароль неправильний.
Порівняйте підтримувану поведінку служби з документацією транспорту APT і семантикою CONNECT. Використовуйте сумісну схвалену службу або підтримуваний URL репозиторію. Для публічних репозиторіїв, де дозволені публічні посередники, список HTTP-проксі пропонує кандидатів для перевірки на відповідність цим вимогам. Не припускайте, що додавання https:// до адреси проксі змінює протокол репозиторію або перетворює кожен запит на тунель.