Une requête WinHTTP s'authentifie auprès du proxy, reçoit le 401 d'un site web, puis obtient un autre 407 lors de l'envoi suivant. Le proxy et le site web ont des états d'authentification distincts, et le chemin de renvoi doit conserver les deux.

L'exemple d'authentification WinHTTP natif de Microsoft conserve le schéma de proxy choisi dans une variable et réapplique le compte proxy avant chaque WinHttpSendRequest une fois ce schéma sélectionné.

  1. Envoyez la requête et inspectez la réponse.
  2. Pour un 407, interrogez les schémas proposés et mémorisez le schéma de proxy choisi.
  3. Avant de renvoyer, appelez WinHttpSetCredentials pour WINHTTP_AUTH_TARGET_PROXY avec ce schéma et ce compte.
  4. Pour un 401 de la destination, obtenez son schéma et définissez ses informations d'identification serveur tout en conservant l'état de proxy mémorisé pour l'envoi suivant.

L'exemple mentionne spécifiquement la réauthentification après un défi du serveur ou une redirection comme raison de réappliquer les informations d'identification du proxy. Placer l'appel uniquement dans la première branche 407 peut laisser un autre chemin de nouvelle tentative sans la configuration attendue.

Vérifiez chaque résultat d'API et gardez les échecs répétés bornés. L'exemple compact de Microsoft suit l'état précédent, tandis qu'une politique de nouvelle tentative en production devrait aussi reconnaître une séquence alternée répétée.

Si l'utilisateur fournit un compte de remplacement après un échec, mettez à jour les valeurs utilisées par ce chemin de renvoi. WinHttpSetCredentials s'applique à la requête ; ce n'est pas un magasin de mots de passe à l'échelle du processus dont le contenu serait remplacé pour toutes les requêtes futures.

Articles similaires