Quand un proxy rejette l'User-Agent d'APT
Reconnaître un refus explicite de politique d'identité client lorsque curl réussit mais qu'APT est bloqué via le même proxy.
curl récupère une URL. APT, avec le même proxy, reçoit une page indiquant que son User-Agent n'est pas autorisé. Cette réponse restreint déjà l'enquête : l'intermédiaire applique une politique client.
Changer à la fois les miroirs du dépôt, les mots de passe et le DNS écarte cette preuve utile. Conservez le statut renvoyé et le texte de refus pertinent avant de modifier la route.
APT documente Acquire::http::User-Agent pour la méthode d'acquisition HTTP. Si l'exploitant du réseau exige un identifiant approuvé, configurez délibérément la valeur convenue. Copier la chaîne d'identité complète d'un navigateur depuis une ancienne réponse peut masquer le véritable outil de mise à jour et échouer malgré tout à une autre condition de politique.
Vérifiez la portée de la requête échouée. Une requête vers un dépôt HTTP et un tunnel HTTPS exposent des informations différentes à un proxy ordinaire non interceptant. Ne déduisez pas qu'une politique d'en-tête visible sur un chemin s'applique automatiquement à l'identique dans un trafic chiffré.
Une page de refus renvoyée là où des métadonnées de dépôt étaient attendues peut aussi provoquer plus tard une erreur d'analyse ou une erreur d'apparence de signature. Lisez l'origine de la réponse avant de modifier la confiance accordée au dépôt. Un routage réussi via le proxy ne fait pas d'une page de politique HTML un index de paquets valide. Pour un Hash Sum mismatch, gardez ensemble la somme de contrôle attendue et les octets réels.