Ko posredovalni strežnik zavrne User-Agent APT
Prepoznajte izrecno zavrnitev politike identitete odjemalca, ko curl uspe, a je APT blokiran skozi isti posredovalni strežnik.
curl pridobi URL. APT prek istega posredovalnega strežnika prejme stran, ki pravi, da njegov User-Agent ni odobren. Ta odgovor že zožuje preiskavo: posrednik uporablja politiko odjemalca.
Hkratna sprememba zrcal repozitorija, gesel in DNS zavrže ta koristni dokaz. Preden spremenite pot, shranite vrnjeno stanje in ustrezno besedilo zavrnitve.
APT dokumentira Acquire::http::User-Agent za metodo pridobivanja HTTP. Če omrežni operater zahteva odobren identifikator, namerno nastavite dogovorjeno vrednost. Kopiranje celotnega identitetnega niza brskalnika iz starega odgovora lahko skrije dejanski posodabljalnik in vseeno spodleti pri drugem pogoju politike.
Preverite obseg neuspešne zahteve. Zahteva do repozitorija HTTP in tunel HTTPS razkrijeta običnemu posredovalnemu strežniku, ki ne prestreza, različne informacije. Ne sklepajte, da se politika glave, vidna na eni poti, samodejno uporablja enako znotraj šifriranega prometa.
Stran zavrnitve, vrnjena tam, kjer so bili pričakovani metapodatki repozitorija, lahko pozneje povzroči tudi napako pri razčlenjevanju ali napako, ki je videti kot napaka podpisa. Preden spremenite zaupanje v repozitorij, preberite izvor odgovora. Uspešno usmerjanje prek posredovalnega strežnika ne naredi strani s politiko HTML veljavnega indeksa paketov. Pri Hash Sum mismatch hranite pričakovano kontrolno vsoto in dejanske bajte skupaj.