libproxy choisit une route ; votre client établit la connexion
Utilisez les résultats de libproxy comme candidats de routage par URL au lieu d'attendre que la découverte redirige les sockets de l'application.
Si libproxy renvoie un URI de proxy alors que la socket suivante se connecte directement, vérifiez la transmission. libproxy découvre la politique ; il n'intercepte pas chaque socket ouverte par l'application.
- Interrogez la ressource. Dans l'API C documentée de libproxy 0.5, créez une fabrique de proxy et demandez l'URL de destination réelle.
- Interprétez les candidats ordonnés. Les résultats HTTP, SOCKS et direct exigent un traitement différent. Conservez leur ordre de préférence et la politique d'échec prévue.
- Configurez le consommateur. Transmettez le type de proxy choisi, le point de terminaison et le dispositif d'authentification à un transport qui les prend en charge. Une socket TCP brute n'obtient pas de négociation CONNECT ni SOCKS à partir d'un URI renvoyé.
N'enregistrez pas une seule réponse comme route pour toutes les destinations et ne rendez pas le routage direct permanent parce que le premier proxy a échoué une fois.
Si le client HTTP intègre déjà le proxy système ou la découverte PAC, choisissez un seul propriétaire de la sélection. Deux sélecteurs indépendants plus un autre habillage peuvent produire une route qu'aucune des deux politiques ne prévoyait.
En code natif, respectez le cycle de vie de la fabrique et de la mémoire de résultats de l'API installée. Réutiliser une fabrique peut conserver un état de découverte utile, mais elle exige encore une requête pour chaque destination. Journalisez la sélection séparément du résultat de la connexion : un URI renvoyé ne prouve pas une authentification, une résolution ou un accès ultérieur réussis.