Comment utiliser Fiddler pour modifier le code d'état d'une réponse HTTP ?

Question

J'ai besoin de tester le code d'une application client que j'ai écrite pour tester sa gestion des différents codes d'état renvoyés dans une réponse HTTP par un serveur Web.

J'ai installé Fiddler 2 (Web Debugging Proxy) et je crois qu'il y a un moyen de modifier les réponses à l'aide de cette application, mais j'ai du mal à trouver comment. Ce serait le moyen le plus pratique, car il me permettrait de laisser le code du client et du serveur non modifié.

Quelqu'un peut-il m'aider ? J'aimerais intercepter la réponse HTTP envoyée du serveur au client et modifier le code d'état avant qu'elle n'atteigne le client.

Tout conseil serait très apprécié.

Answer 1

Ok, je suppose que vous êtes déjà en mesure de surveiller votre trafic client/serveur. Ce que vous voulez faire, c'est mettre un point d'arrêt sur la réponse et la modifier avant de l'envoyer au client.

Voici quelques façons différentes de le faire :

1. Règles > Points d'arrêt automatiques > Après les réponses
2. Dans la boîte quickexec (la boîte noire en bas) tapez "bpafter yourpage.svc". Maintenant, Fiddler s'arrêtera à un point d'arrêt avant toutes les requêtes vers toute URL contenant "yourpage.svc". Tapez "bpafter" sans paramètres pour effacer le point d'arrêt.
3. Modifiez la réponse de manière programmée à l'aide de FiddlerScript. La meilleure documentation pour FiddlerScript se trouve sur le site officiel : http://www.fiddler2.com/Fiddler/dev/

Une fois que la réponse est arrêtée au point d'arrêt, il suffit de double-cliquer dessus pour l'ouvrir dans les inspecteurs. Vous avez maintenant plusieurs options :

1. Juste à côté du bouton vert "Run to Completion" (sur lequel vous cliquez pour envoyer la réponse) se trouve une liste déroulante qui vous permet de choisir certains types de réponses par défaut.
2. Ou, dans l'inspecteur des en-têtes, modifiez le code de réponse et le message dans la zone de texte située en haut.
3. Vous pouvez également cliquer sur l'inspecteur "Raw" et manipuler la réponse brute pour lui faire subir des modifications arbitraires. C'est aussi un bon moyen de voir ce que fait votre client lorsqu'il reçoit une réponse malformée, ce que vous testerez probablement accidentellement :)

Answer 2

Une autre alternative consiste à utiliser l'outil de Fiddler AutoResponder (dans le panneau de droite). Cela vous permet d'attraper une requête vers n'importe quel URI qui correspond à une chaîne de caractères et de servir une réponse "fixe" à partir d'un fichier. Le fichier peut contenir à la fois des en-têtes et des données utiles. L'avantage de cette approche est que vous n'avez pas à écrire FiddlerScript et que vous n'avez pas à traiter chaque requête manuellement via un point d'arrêt.

Vous devez configurer la règle dans Fiddler comme indiqué ci-dessous (assurez-vous d'activer la fonction les demandes non jumelées passent à travers sinon toutes les autres requêtes http échoueront).

Dans cet exemple, toute demande dont l'URI comprend "fooBar" recevra la réponse type. Le format du fichier variera en fonction de vos API (vous pouvez utiliser votre navigateur pour intercepter une "vraie" réponse et vous baser sur celle-ci) mais le mien ressemblait à ce qui suit :

HTTP/1.1 409 Conflict
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, DELETE, PUT, PATCH, OPTIONS
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
Access-Control-Max-Age: 86400
Content-Type: application/vnd.api+json
Content-Length: 149
Date: Tue, 28 Mar 2017 10:03:29 GMT

{"errors":[{"code":"OutOfStock","detail":"Item not in stock","source":{"lineId":{"type":"Order line Number","id":"1"}},"meta":{"availableStock":0}}]}

J'ai découvert qu'il fallait un retour chariot à la fin de la dernière ligne (c'est-à-dire après le json), et que l'en-tête Content-Length devait correspondre au nombre de caractères du json, sinon la webapp se bloquait. Votre expérience peut varier.

Answer 3

Créer une règle FiddlerScript. Voici ce que j'ai utilisé afin de générer une copie locale d'un site web qui utilisait intentionnellement 403 sur chaque page pour déjouer HTTrack/WGET. https://gist.github.com/JamoCA/22db8d68a9a2fb20cb04a85360185333

/* 20180615 Fiddler rule to ignore all 403 HTTP Status errors so WGET or HTTrack can generate local copy of remote website */
   SCENARIO: Changing the user agent or setting a delay isn't enough and the entire remote server is configured to respond w/403.
   CONFIGURE: Add below rule to FiddlerScript OnBeforeReponse() section.  Configure HTTrack/WGET/CRON to use proxy 127.0.0.01:8888 */

static function OnBeforeResponse(oSession: Session) {
  if (oSession.HostnameIs("TARGETHOSTNAME_FILTER.com") && oSession.responseCode == 403) {
    oSession.responseCode = 200;
    oSession.oResponse.headers.HTTPResponseCode = 200;
    oSession.oResponse.headers.HTTPResponseStatus = "200 OK";
  }
}