First ,I want to say that fiddler is a reallllllly useful tool !

However, I have been disturbed for a long time about this problem. So here is the problem.

 
Step 1.

I received a response from server like this   (some useless headers have been omitted) :
 

HTTP/1.1 200 OK
Server: GewaServer3
Content-Type: text/html;charset=UTF-8
Content-Length: 48

var data = {"retval":"145918761","success":true}

 

Step 2.

After receiving the previous response, I hope fiddler could automatically send the request like this:
 

POST http://www.gewa.com/ajax/trade/save.xhtml HTTP/1.1
Host: www.gewa.com
Connection: keep-alive
Cookie: bdshare_firstime=1385011581672;
 
code=1321&Id=145918761&type=1556
 


But  I hope this part in request body 

(Id=145918761)

will be automatically changed according to the response body I received before 

("retval":"145918761")

 
I try to find a way to solve the problem for many days but I couldn’t.

If anyone could help I would be soooooo grateful!

Thanks again!
 

 

 

 

when I open the fiddler does not appear any link, even if I open a page in my browser, help me what do I do?

Hi,

I have been searching everywhere on the net and have found this link for an inspector for WCF RIA calls. http://blog.functionalfun.net/2009/11/fiddler-plug-in-for-inspecting-wcf.html

But it is no longer available for download at the MSDN Code Gallery URL linked in the article.

Does anyone know where I can download this plugin or is there a different way to decode WCF RIA services using Fiddler?

-Tim

I have noticed this for a while now. It would slowly grow and grow and grow, even if I have 100 sessions max to keep. I may have noticed a few times when it's grown past a gigabyte in memory, to start growing more exponentially, as much as two megabytes per "refresh" in browser window. However, the real problem is that it also does it when there's filters turned on. To my understanding, filters should prevent traffic that doesn't pass them from being stored anywhere. The main reason why I have noticed it, is because I work with an external API to monitor all the calls towards them (ie if the request url doesn't contain "wsapi", it doesn't get through) and I have fiddler running on the background at all times regardless of whether the API is used or not, and occasionally my system would slow down, so I would open task manager... and see fiddler hogging about 7 gigs of ram. Yes, seven gigs, almost half of my RAM, with the fiddler window being completely empty. Yes, empty. No records, none. Yet Fiddler is growing exponentially, should I forget it on for a few days without checking on its memory footprint.

It's something that has been there for ages, and not something I think about, as I normally just restart the program (or close and start it when I need it), but since I discovered it while I had some spare time, I thought I'd make a post about it, as the internet has been rather fruitless about it, although I can see a few posts which normally relate to garbage collection... but considering I have had the slowdown with 1,5 gigs of Fiddler memory with rest of the applications pushing it far over 16 gigs (swap file to the rescue), if it really is that, the garbage collector is doing an incredibly rotten job, as the resources are definitely needed by other applications.

I am very new to Fiddler and am needing some help monitoring some JSON messages. I normally use a test client from my pc to send json messages to a rest api endpoint on azure. There are various other applications sending messages to that endpoint too. How do i capture all the messages that reach the endpoint?

I want to autoinspect session if it allow by filter. If I try to put oSession.oFlags["X-Builder-Inspect"] = "1"; in a OnBeforeRequest() - autoinspect works, but it trying to inspect sessions that didn't allow by filter. So i tried to put oSession.oFlags["X-Builder-Inspect"] = "1"; in OnBeforeResponse() but then autoispect doesnt work. What's the reason? May be there is other ways to autoinspect allowed sessions?

I am trying to use 100% stack area chart and on this scenario it gives me overflow chart. Here for 2004 and 2011 all data are 0 (zero).
http://trykendoui.telerik.com/EjIw/2

 

In the company I work for, there is a .NET application developed using WCF. There are 2 parts - 1. Application  server and 2. A thick client - Both installed on the same machine. The application server is IIS.

I would like to capture all SOAP calls make by the client to the application server. I tried Fiddler, but it is not capturing traffic to localhost at the moment. Any way to capture the WCF calls made to the localhost by the windows thick client?

I tried to remove "loopback" from Tools - Fiddler Options - Connections : "ByPass Fiddler for URL's that with", but unable to do this. 

If fiddler doesn't do this any other software that does this? 

I've been using the hosts filter option extensively, to hide traffic from various sites (used for regular surfing).
It seems that the filter has a maximum length of 4096 characters - is that correct?

Shouldn't we be allowed to specify more than that?

I'm working with the owner of the firm where I work to track down the source of "DO_NOT_TRUST_FiddlerRoot" certificates that keep accumulating in his Personal cert store. We've also identified the "DO_NOT_TRUST_FiddlerRoot" dummy CA cert in his "Trusted Root Certification Authorities" store. We've been able to confirm that he does not have the Fiddler application installed on this computer. We've also been unable to find any of the FiddlerCore DLLs on his hard drives. Which leads me to believe that the FiddlerCore DLL has been merged into a stand-alone executable by using something like ILMerge.

We have a general idea of when the dummy CA cert was created, so we're starting to look at applications (particularly applications in the system's Startup folders) which were installed right about that time. But the question for the forum: is there any quick or easy way to identify which applications may have the FiddlerCore engine embedded in them?

Thanks in advance for any advice, suggestions!