août
2010
Un article de benji_dv
Fiddler, pour ceux qui ne connaissent pas, est un proxy web (dispo ici http://www.fiddler2.com/).
Ce petit outil (bien pratique) permet de visualiser le trafic http provenant d’une session utilisateur ou d’une application.
La problématique :
Actuellement, je travaille sur un ensemble d’applications qui interagissent entre elles par le biais de services WCF.
Un de ces services sert de proxy métier.
Son rôle consiste donc, à interroger plusieurs sources de données (services web qui existent sur un système d’information, mais dont nous n’avons pas la maitrise) pour nous retourner des objets métiers utilisables dans nos applications.
Nous avons été confronté à un problème sur cette application WCF, dont le principal rôle est de servir de proxy entre nos représentations métier, et celles provenant de tiers (éditeurs logiciels, sharepoints,…).
Le problème est simple : dans certains cas de requêtage, les résultats étaient… étranges.
Or, nous ne pouvons pas réellement savoir ce qui se trame ( 
) sur le serveur de test… car il n’est pas en debug…
Donc, en installant fiddler, en redirigeant le trafic de l’application WCF vers ce dernier, et en activant les traces dans l’application WCF : nous avons constaté et rapidement traité le problème (problème provenant d’un service tiers).
Lorsque fiddler est utilisé sur un poste de dev, aucun problème ne se pose : il affiche le trafic sortant de la session utilisateur courante.
Sur un serveur web, la situation est tout autre, car il est indispensable de préciser dans le fichier de config de l’application le proxy utilisé pour le trafic sortant.
Voici donc les lignes à ajouter dans le fichier web.config pour rediriger le trafic vers fiddler…
<system.net>
<defaultProxy>
<proxy proxyaddress="http://localhost:8888/"/>
</defaultProxy>
</system.net>
l’adresse http://localhost:8888 est l’adresse par défaut utilisée par fiddler pour écouter le trafic à sniffer et à rediriger.
@+ 