Kiam prokurilo rifuzas la User-Agent de APT
Rekonu eksplicitan rifuzon de klienta identeca politiko kiam curl sukcesas sed APT estas blokata tra la sama prokurilo.
curl elprenas URL-on. APT, uzante la saman prokurilon, ricevas paĝon kiu diras ke ĝia User-Agent ne estas aprobita. Tiu respondo jam mallarĝigas la esploron: la peranto aplikas klientan politikon.
Ŝanĝi spegulojn de la deponejo, pasvortojn kaj DNS-on samtempe forĵetas tiun utilan pruvon. Konservu la redonitan staton kaj la koncernan rifuzan tekston antaŭ ol ŝanĝi la itineron.
APT dokumentas Acquire::http::User-Agent por la HTTP-akira metodo. Se la reta operatoro postulas aprobitan identigilon, agordu la interkonsentitan valoron konscie. Kopii la tutan identecan ĉenon de retumilo el malnova respondo povas kaŝi la faktan ĝisdatigilon kaj ankoraŭ malsukcesi alian politikokondiĉon.
Kontrolu la amplekson de la malsukcesa peto. Peto al HTTP-deponejo kaj HTTPS-tunelo malkaŝas malsamajn informojn al ordinara prokurilo kiu ne interceptas. Ne konkludu ke kaplitera politiko videbla sur unu vojo aŭtomate aplikiĝas same ene de ĉifrita trafiko.
Rifuza paĝo redonita tie kie oni atendis deponejan metadatumon ankaŭ povas kaŭzi postan analizan eraron aŭ eraron aspektantan kiel subskriba eraro. Legu la originon de la respondo antaŭ ol ŝanĝi la fidon al la deponejo. Sukcesa prokurila enkursigo ne faras HTML-politikan paĝon valida pakaĵindekso. Por Hash Sum mismatch, tenu la atendatan kontrolsumon kaj la faktajn bajtojn kune.