23

This is probably the weirdest problem I have run into. I have a piece of code to submit POST to a url. The code doesn't work neither throws any exceptions when fiddler isn't running, However, when fiddler is running, the code posts the data successfuly. I have access to the post page so I know if the data has been POSTED or not. This is probably very non-sense, But it's a situation I am running into and I am very confused.

byte[] postBytes = new ASCIIEncoding().GetBytes(postData);
HttpWebRequest req = (HttpWebRequest)WebRequest.Create("http://myURL);
req.UserAgent = "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10";
req.Accept = "application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5";
req.Headers.Add("Accept-Charset", "ISO-8859-1,utf-8;q=0.7,*;q=0.3");
req.Headers.Add("Accept-Language", "en-US,en;q=0.8");
req.Method = "POST";
req.ContentType = "application/x-www-form-urlencoded";
req.ContentLength = postBytes.Length;
req.CookieContainer = cc;
Stream s = req.GetRequestStream();
s.Write(postBytes, 0, postBytes.Length);
s.Close();
dlock
  • 9,447
  • 9
  • 47
  • 67
  • 1
    is the request getting redirected by chance and fiddler is handling this? – BrokenGlass Jan 26 '11 at 03:38
  • if there is any redirection I would see it in fiddler's log right? – dlock Jan 26 '11 at 03:42
  • Is it possible that the `postBytes` contains characters that should have been url encoded? Perhaps fiddler is silently filtering that for you? – Jim Mischel Jan 26 '11 at 03:52
  • Thats true. It contains a field that may have spaces, it also contains a field that holds an email (with @). Do you think that this might be causing the problem? – dlock Jan 26 '11 at 03:55
  • Are you POSTing to [`localhost.`](http://weblogs.asp.net/lorenh/archive/2008/01/10/tip-for-using-fiddler-on-localhost.aspx)? – Jordão Jan 26 '11 at 04:07
  • Where did you actually send the request? e.g the GetResponseStream call? Did you remember to call close on that? – EricLaw Jan 26 '11 at 04:29
  • I don't care about the response so I didn't initialize a HttpWebResponse Object. In addition to that, I am sending the request to facebook (what does it have to do with our problem?). – dlock Jan 26 '11 at 04:34
  • Ok so its for facebook (from your comments) then the problem i see its that you are using http instead of https... as far s i know sending a post to facebok with accesstoken needs you to use https.. And i dont think you need to initialize all thse HTTp headers ..i never set then just the content type and content length and the content (including access token) – Shekhar_Pro Jan 26 '11 at 04:40
  • Why is it working with fiddler then? – dlock Jan 26 '11 at 04:42
  • well i am not sure.. but first just try what i said in the comment above and see that if it helps.. – Shekhar_Pro Jan 26 '11 at 04:44
  • @Shekhar, How to make it https? by the way am sending to facebook mobile. I guess it's http. – dlock Jan 27 '11 at 06:52
  • use `https://myurl` instead of `http://myurl`... and you are posting to graph api not to mobile right ? – Shekhar_Pro Jan 27 '11 at 07:50
  • http://www.telerik.com/automated-testing-tools/blog/13-02-28/help-running-fiddler-fixes-my-app.aspx – Zasz Aug 22 '13 at 21:22
  • @deadlock Did you ever find a solution. We are experiencing behavior very similar to your original question. – Aaron Corcoran Oct 22 '13 at 16:22
  • @AaronCorcoran I think I had problems in my proxy config – dlock Nov 08 '13 at 17:03

9 Answers9

14

If you don't call GetResponseStream() then you can't close the response. If you don't close the response, then you end up with a socket in a bad state in .NET. You MUST close the response to prevent interference with your later request.

Sergio
  • 6,900
  • 5
  • 31
  • 55
EricLaw
  • 56,563
  • 7
  • 151
  • 196
  • 2
    This isn't really correct. You can close the response just fine if you use a `using` block, which is what you should be doing anyway. No need to call `GetResponseStream()` if you don't need the stream. `using (var response = request.GetResponse()) { /* ... use response */ }` – JLRishe Aug 28 '18 at 13:49
8

Close the HttpWebResponse after getting it.

I had the same problem, then I started closing the responses after each request, and Boom, no need to have fiddler running.

This is a pseudo of a synchronous code:

request.create(url);

///codes

httpwebresponse response = (httpwebresponse)request.getresponse();

/// codes again like reading it to a stream

response.close();
Daniel Fischer
  • 181,706
  • 17
  • 308
  • 431
bardya
  • 81
  • 1
  • 1
  • In my case, I'm using a custom WebClient that overloads `GetWebResponse` to keep track of redirects. After reading this I realized that I wasn't closing the existing response before starting a new request. – Andy Edinborough Sep 13 '12 at 22:00
  • Thanks a ton for this!!! Worked for me after a couple of hours of head scratching. – josey wales Jun 04 '14 at 18:41
5

I had a similar problem recently. Wireshark would show the HTTPWebRequest not leave the client machine unless Fiddler was running. I tried removing proxy settings, but that didn't fix the problem for me. I tried everything from setting the request to HttpVersion.Version10, enabling/disabling SendChuck, KeepAlive, and a host of other settings. None of which worked.

Ultimately, I just checked if .Net detected a proxy and had the request attempt to ignore it. That fixed my issue with request.GetResponse() throwing an immediate exception.

IWebProxy proxy = request.Proxy;

if (request.Proxy != null)
{
    Console.WriteLine("Removing proxy: {0}", proxy.GetProxy(request.RequestUri));
    request.Proxy = null;
}
Kamil K
  • 51
  • 1
  • 1
4

In my case when I had the same situation (POST only works when Fiddler is running) the code was sending the POST from an application running on IISExpress in a development environment behind a proxy to an external server. Apparently even if you have proxy settings configured in Internet Options the environment IIS is running in may not have access to them. In my work environment I simply had to update web.config with the path to our proxy's configuration script. You may need to tweak other proxy settings. In that case your friend is this MSDN page that explains what they are: http://msdn.microsoft.com/en-us/library/sa91de1e.aspx.

Ultimately I included the following in the application's web.config and then the POST went through.

<configuration>
  <system.net>
    <defaultProxy>
      <proxy scriptLocation="http://example.com:81/proxy.script" />
    </defaultProxy>
  </system.net>
</configuration>
2

I ran into the same problem with Python - requests to a local server were failing with a 404, but then when I ran them with Fiddler running they were working correctly.

The real clue to the problem here is that Fiddler works by acting as a proxy for HTTP traffic so that all requests from the local machine go through Fiddler rather than straight out into the network.

In the exact situation I was in, I was making requests to a local server, regular traffic passes through a proxy and in Local Area Network (LAN) Settings for the network connection the Proxy server pane the Bypass proxy server for local addresses option was checked.

My suspicion is that the "Bypass proxy server for local addresses" is not necessarily picked up by the programming language, but the proxy server details are. Fiddler is aware of that policy, so requests through Fiddler work but requests direct from the programming language don't.

By setting the proxy for the request for the local server to nothing, it worked correctly from code. Obviously, that could be a gotcha if you find yourself moving from an internal to external server during deployment.

glenatron
  • 11,018
  • 13
  • 64
  • 112
2

I faced the same scenario : I was POSTing to an endpoint behind Windows Authentication.

Fiddler keeps a pool of open connections, but your C# test or powershell script does not when it runs without fiddler.

So you can make the test/script to also maintain a pool of open authenticated connections, by setting the property UnsafeAuthenticatedConnectionSharing to true on your HttpWebRequest. Read more about it here, microsoft KB. In both cases in that article, you can see that they are making two requests. The first one is a simple GET or HEAD to get the authentication header (to complete the handshake), and the second one is the POST, that will use the header obtained before.

Apparently you cannot (sadness) directly do the handshake with POST http requests.

Zasz
  • 12,330
  • 9
  • 43
  • 63
  • This is what solved my problem. I was getting a timeout when trying to manually log in (screen scraping) via code. Thanks! – Kirk Liemohn Mar 03 '21 at 18:27
2

Always use using construct. it make sure all resource release after call

   using (HttpWebResponse responseClaimLines = (HttpWebResponse)requestClaimLines.GetResponse())
                {
                    using (StreamReader reader = new StreamReader(responseClaimLines.GetResponseStream()))
                    {
                        responseEnvelop = reader.ReadToEnd();
                    }
                }

add following entries to webconfig file

<system.net>
<connectionManagement>
<add address="*" maxconnection="30"/>

Mahesh
  • 2,731
  • 2
  • 32
  • 31
2

Well i have faced similar problem few weeks back and the reason was that when fiddler is running it changes the proxy settings to pass the request through Fiddler but when its closed the proxy somehow still remains and thus doesn't allow your request to go ahead on internet.

I tried by setting the IE's and Firefox's network settings to not to take any proxy and it worked.

Try this, may it be the same problem...

Shekhar_Pro
  • 18,056
  • 9
  • 55
  • 79
  • I had proxy settings in IE and Firefox as you mentioned. I have set them up not to use any proxies, Yet that didn't solve the problem. – dlock Jan 26 '11 at 04:15
  • Ok tell me two things. Are you able to send a GET request from your code to the URL. Second Have you tried with any other URL. Try graph.facebook.com/me (obviously the facebook will return an error but you will know if data is getting through) – Shekhar_Pro Jan 26 '11 at 04:22
  • Yes I am very sure I can send a GET request normally and receive it's response perfectly. I will try with another URL but I think it will yield to the same problem. – dlock Jan 26 '11 at 04:32
0

I found the solution in increasing the default number of connections

ServicePointManager.DefaultConnectionLimit = 10000;
Sam
  • 2,950
  • 1
  • 18
  • 26