Când un proxy respinge User-Agent-ul APT
Recunoașteți un refuz explicit al politicii de identitate a clientului când curl reușește, dar APT este blocat prin același proxy.
curl preia un URL. APT, folosind același proxy, primește o pagină care spune că User-Agent-ul său nu este aprobat. Acel răspuns restrânge deja investigația: intermediarul aplică o politică de client.
Schimbarea simultană a oglinzilor depozitului, a parolelor și a DNS aruncă acea dovadă utilă. Păstrați starea returnată și textul de refuz relevant înainte de a schimba ruta.
APT documentează Acquire::http::User-Agent pentru metoda de achiziție HTTP. Dacă operatorul de rețea cere un identificator aprobat, setați deliberat valoarea convenită. Copierea întregului șir de identitate al unui browser dintr-un răspuns vechi poate ascunde actualizatorul real și tot poate eșua la o altă condiție de politică.
Verificați domeniul cererii eșuate. O cerere către un depozit HTTP și un tunel HTTPS expun informații diferite unui proxy obișnuit care nu interceptează. Nu presupuneți că o politică de antet vizibilă pe o cale se aplică automat identic în interiorul traficului criptat.
O pagină de refuz returnată acolo unde se așteptau metadatele depozitului poate provoca mai târziu și o eroare de analiză sau o eroare care pare a fi de semnătură. Citiți originea răspunsului înainte de a schimba încrederea în depozit. Rutarea reușită prin proxy nu transformă o pagină de politică HTML într-un index valid de pachete. Pentru un Hash Sum mismatch, păstrați împreună suma de control așteptată și octeții reali.