Hi,
Suddenly my Fiddler installation is no longer able to forward traffic to my upstream system proxy, if I use the Fiddler Gateway setting "Use System Proxy (recommended)". The proxy is manually set up in my Windows 10 Proxy settings to "http://devproxy.mycompany.net" port 8080 and works fine for e.g. requests from Chrome (without Fiddler).
In Wireshark I can see that if I use the the Fiddler Gateway setting "Manual Proxy Configuration", with "http=devproxy.mycompany.net:8080;https=devproxy.mycompany.net:8080" I can see that Fiddler forwards SSL "CONNECT devserver.mycompany.net:443" calls correctly to the proxy.
But if I use the Fiddler Gateway setting "Use System Proxy (recommended)", Wireshark shows that something, presumably Fiddler, instead tries to look up devserver.mycompany.net locally in DNS, where it cannot be found, and the CONNECT request results in a "502 Fiddler - DNS Lookup Failed" response.
Do you have any idea why Fiddler doesn't just forward the requests "raw" to the proxy in this case???
For study purposes I tried to make a simple app to learn capturing web traffic. but it didn't capture any traffic. Can you help me to figure out what is wrong here:
void Start()
{
FiddlerApplication.Prefs.SetBoolPref("fiddler.certmaker.CleanupServerCertsOnExit", true);
FiddlerCoreStartupSettings startupSettings =
new FiddlerCoreStartupSettingsBuilder()
.ListenOnPort(8888)
.DecryptSSL()
.OptimizeThreadPool()
.Build();
CertMaker.createRootCert();
FiddlerApplication.Startup(startupSettings);
FiddlerApplication.AfterSessionComplete += FiddlerApplication_AfterSessionComplete;
}
private void FiddlerApplication_AfterSessionComplete(Session oSession)
{
string reqHeaders = oSession.oRequest.headers.ToString();
var reqBody = Encoding.UTF8.GetString(oSession.RequestBody);
string respHeaders = oSession.oResponse.headers.ToString();
var respBody = Encoding.UTF8.GetString(oSession.ResponseBody);
string output = reqHeaders + "\r\n" +
(!string.IsNullOrEmpty(reqBody) ? reqBody + "\r\n" : string.Empty) +
"==========================================================" + "\r\n\r\n" +
respHeaders + "\r\n" +
(!string.IsNullOrEmpty(respBody) ? respBody + "\r\n" : string.Empty) +
"==========================================================" + "\r\n\r\n";
BeginInvoke(new Action<string>((text) =>
{
textBoxTraffic.AppendText(text);
}), output);
}
Hi good morning, please I need your support for use Telerik in Centos 7.
Will I Install Telerik in Centos 7?
Regards
I've encountered an interesting problem when trying to debug digest authentication in my company's application using Internet Explorer 11 (11.0.9600.19377 on Windows 7 64-bit) with Fiddler (v5.0.20192.25091). It seems that with Fiddler running and capturing traffic, the behaviour of IE11 is actually different, suggesting that Fiddler is modifying the outgoing traffic before it hits the server.
To give a bit of context, using Chrome and Firefox (with or without Fiddler running) I'm finding that the digest auth. process works entirely as expected:
When using IE11 without Fiddler, the process is incorrect – I've been able to analyse this by using Wireshark:
However, when using IE11 with Fiddler running and capturing traffic, the browser behaves differently (following the same process as Chrome and Firefox) and actually works correctly. My understanding was that Fiddler is completely transparent (capturing all WinINET traffic without modification) so that leaves me with a few questions:
I've added the following line to static `function Main()` :
CertMaker.StoreCert("api.some.service.com", "C:\\Bla.pfx", "Secret");
But when I try to do a get I still get a cert with the following info:
Server certificate:
* subject: OU=Created by http://www.fiddler2.com; O=DO_NOT_TRUST; CN=*.some.service.com
* start date: Aug 8 14:29:55 2018 GMT
* expire date: Nov 6 14:29:55 2021 GMT
* subjectAltName: host "api.some.service.com" matched cert's "*.some.service.com"
* issuer: OU=Created by http://www.fiddler2.com; O=DO_NOT_TRUST; CN=DO_NOT_TRUST_FiddlerRoot
The way I tested it was by performing the following call :
sudo curl -x "my.fqdn:9999" --http1.1 --cacert ./FiddlerRoot.pem -v -sSi https://api.some.service.com/SomeFunc
Hi,
I've similar need as mentioned in another post: https://www.telerik.com/forums/automatic-saving-of-responses-into-autoresponder, but don't want to pile up the AutoResponder. The AutoResponder UI is a simple list view and when I pull SAZ sessions, I'm finding it difficult with other existing rules. I wonder if something can be done programmatically to locate the session in a SAZ file and serve the response accordingly bypassing the UI. I'm using below code snippet to locate a session in the SAZ, but not finding a way to serve the response body stored in SAZ file.
for
(var i1:
int
= 0; i1<sSessions.Length; ++i1)
{
FiddlerObject.log(
"sSessions: "
+ i1 +
": "
+ sSessions[i1].url);
if
(sSessions[i1].url ===
'example.com/default.css'
) {
//FiddlerObject.log("sSessions: " + i1 + ": " + sSessions[i1].GetResponseBodyAsString());
//TODO logic to map oSession.response = response stored in SAZ file
}
}
Can anyone help? The above sample code snippet may not be the best one, and appreciate for improved version.
Cheers,
Please forgive me if this has been addressed elsewhere but I cannot find anything to help....
I have been pointed in the direction of Fiddler after running into problems using the IIS SEO Toolkit, which does not work if a site does not have TLS 1.0 enabled. The original thread can be seen at https://forums.iis.net/t/1236833.aspx?IIS+SEO+Toolkit+Not+Crawling+Sites+w+TLS+1+0+Disabled+.
Fiddler is suggested as a cure for this problem but I am not having any luck getting it to allow the crawler to run. I have used the following code in the custom rules:
if (oSession.HTTPMethodIs("CONNECT") && oSession.HostnameIs("www.yourdomain.com")) {
oSession["x-OverrideSslProtocols"] = " ssl3;tls1.0;tls1.1;tls1.2";
}
The aim is to allow Fiddler to act as a proxy so that the IIS software can use TLS 1.0 to speak to Fiddler, which can then use TLS 1.1+ to access the website.
Is there a Fiddler genius who can help make this work? I know that you will be doing a lot of people a huge service.
Many thanks,
Joe