Apache HttpClient connaît le mot de passe mais reçoit toujours 407

Un mot de passe correct chez le fournisseur n’établit pas d’identifiant correspondant pour le proxy réellement sélectionné. Commencez par le schéma, l’hôte et le port de ce point de terminaison ; un champ hôte n’accepte généralement qu’un nom d’hôte ou une IP, pas une URL complète.

1. Lisez tout l’échange d’authentification. Un 407 suivi d’une nouvelle tentative acceptée peut être normal. Vérifiez que le résultat final est toujours 407 avant de considérer la connexion comme refusée.
2. Comparez la route et la portée des identifiants. Faites correspondre l’hôte/port réel et les autres champs définis par l’HttpClient 5 AuthScope déployé. Un port erroné peut laisser BasicCredentialsProvider sans entrée appropriée.
3. Vérifiez la méthode et l’identité. Le proxy a-t-il proposé la méthode prise en charge ? La nouvelle tentative a-t-elle utilisé la connexion attendue ? L’opérateur exige-t-il un compte qualifié par domaine ou un autre format documenté ?

Utilisez l’API de la version majeure installée. Une recette de cache d’authentification d’HttpClient 4 ne se transpose pas telle quelle en version 5. Appliquez les exigences de compte de l’opérateur au lieu d’essayer des variantes de nom d’utilisateur arbitraires.

L’authentification préemptive est un autre choix délibéré. Pour un schéma compatible, elle peut supprimer un aller-retour, mais elle change le moment où les identifiants sortent et exige une portée prise en charge. Elle ne peut pas être la première correction pour un point de terminaison incohérent ou une méthode non prise en charge.

Conservez l’identité du proxy mise en cause, la méthode, la correspondance de portée et l’état final dans des diagnostics expurgés. Le mot de passe et les traces brutes porteuses d’identifiants sont inutiles pour cette comparaison.