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