Amikor egy proxy elutasítja az APT User-Agent fejlécét
Ismerje fel az ügyfél-identitás szabályzatának kifejezett elutasítását, amikor a curl sikeres, de az APT ugyanazon a proxyn keresztül blokkolva van.
A curl letölt egy URL-t. Az APT ugyanazt a proxyt használva olyan oldalt kap, amely szerint a User-Agentje nincs jóváhagyva. Ez a válasz már szűkíti a vizsgálatot: a közvetítő ügyfélszabályzatot alkalmaz.
A tároló tükreinek, a jelszavaknak és a DNS-nek az egyidejű módosítása elveti ezt a hasznos bizonyítékot. Az útvonal megváltoztatása előtt őrizze meg a visszakapott állapotot és a vonatkozó elutasítási szöveget.
Az APT dokumentálja a Acquire::http::User-Agent beállítást a HTTP-s beszerzési módszerhez. Ha a hálózat üzemeltetője jóváhagyott azonosítót követel, állítsa be szándékosan a megbeszélt értéket. Egy böngésző teljes identitásláncának átmásolása egy régi válaszból elrejtheti a tényleges frissítőt, és mégis elbukhat egy másik szabályzatfeltételen.
Ellenőrizze a sikertelen kérés hatókörét. Egy HTTP-tároló kérés és egy HTTPS-alagút eltérő információt tár fel egy közönséges, nem elfogó proxy számára. Ne következtessen arra, hogy az egyik útvonalon látható fejlécszabályzat a titkosított forgalmon belül automatikusan ugyanúgy érvényesül.
Az elutasítási oldal, amelyet ott adnak vissza, ahol tároló-metaadatokat vártak, később elemzési hibát vagy aláírás-hibára emlékeztető hibát is okozhat. A tárolóba vetett bizalom megváltoztatása előtt olvassa el a válasz eredetét. A sikeres proxy-útválasztás nem tesz egy HTML-szabályzatoldalt érvényes csomagindexszé. Egy Hash Sum mismatch esetén tartsa együtt a várt ellenőrzőösszeget és a tényleges bájtokat.