Когато прокси отхвърли User-Agent на APT
Разпознавайте явен отказ по политика за идентичност на клиента, когато curl успява, а APT е блокиран през същото прокси.
curl извлича URL. APT, използвайки същото прокси, получава страница, която казва, че неговият User-Agent не е одобрен. Този отговор вече стеснява разследването: посредникът прилага клиентска политика.
Промяната на огледала на хранилището, пароли и DNS наведнъж изхвърля това полезно доказателство. Запазете върнатия статус и съответния текст на отказа, преди да смените маршрута.
APT документира Acquire::http::User-Agent за метода за извличане по HTTP. Ако мрежовият оператор изисква одобрен идентификатор, задайте договорената стойност съзнателно. Копирането на целия идентификационен низ на браузър от стар отговор може да скрие действителния обновяващ процес и пак да се провали при друго условие на политиката.
Проверете обхвата на неуспешната заявка. Заявка към HTTP хранилище и HTTPS тунел разкриват различна информация пред обикновено прокси без прихващане. Не заключавайте, че политика за заглавка, видима на един път, автоматично се прилага по същия начин в шифрования трафик.
Страница за отказ, върната там, където се очакват метаданни на хранилището, може по-късно да причини грешка при анализ или грешка, подобна на подпис. Прочетете произхода на отговора, преди да промените доверието към хранилището. Успешното маршрутизиране през прокси не прави HTML страница с политика валиден индекс на пакети. За Hash Sum mismatch пазете очакваната контролна сума и действителните байтове заедно.