Чаму 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:// да адраса проксі змяняе пратакол рэпазіторыя або ператварае кожны запыт у тунель.