Develop Reference

WCF service is working when Fiddler is running .Net 4.5

If I'm not running fiddler then my WCF throws exception : "Add service reference gives Exception": Unable to connect to remote server.
However, everything works fine while running fiddler. How to know what fiddler is doing and what change I should do accordingly in my WCF code to make it work without fiddler? Please suggest?
I'm trying to analyse this using WireShark.But, I'm new to this tool and finding difficulty.
Note: I found, there is a another server sitting between my client and the server from where I'm trying to get data.

if you run fiddler, it will change your proxy settings in the browser. That also can cause this issue.
check the proxy settings in IE.

Barclaycard ePDQ not hitting postback after migration

We recently migrated a site to a new server. This site integrates with Barclaycard ePDQ, and was working fine on the old server.
Since migrating, however, ePDQ is unable to hit our Postback Url (which is an ashx handler). They are seeing a response http code = -1, which we're told means it's either exceeding the maximum timeout (20 seconds) or the url simply can't be accessed.
We checked the firewall on the new server, and it is allowing incoming traffic over ports 80 and 443.
I am also able to mimic the POST with the same request data to the Postback Url using Fiddler, and this works fine. So no timeouts, and it is accepting POST requests over port 80.
The site was migrated several days ago, and running a DNS propagation tool against the domain shows it universally resolving to it's new IP.
We're running Windows server 2012 on the new server. The old server was running Windows 2008 R2.
Does anybody have any ideas why ePDQ is unable to hit our postback url?
Thanks in advance

In HTTPS request , Request.IsSecureConnection return false

I have an asp.net application working in https (SSL). This is working well in my local computer and Amazon AWS(production environment).
But when I host this application in office (for testing) some strange things happens.
I can see the https in browser and the lock sign.
Fiddler also showing that the output is encrypted and shows port 443.
But HttpContext.Current.Request.IsSecureConnection returns false
And HttpContext.Current.Request.Url.Scheme returns http.
In the office we are using Juniper SSG firewall and TMG 2010 (Forefront Threat Management Gateway 2010). So server receive request through Juniper and TMG 2010. Thanks in advance.

To reduce costs I suspect that the SSL certificate is installed on the TMG Gateway and that this gateway is simply rewriting the request to standard HTTP when passing it to the actual web server. So by the time the request hits IIS and your web application it is a standard plain HTTP request.

This tripped my up after deploying to Amazon's Elastic Beanstalk environment. I couldn't see any way to get the load-balancer to allow the SSL request straight through to the server. Instead it was always terminating the SSL at the load-balancer and passing plain http back to the server.
I found this documentation: Elastic Load Balancing Concepts - X-Forwarded Headers.
Essentially the load-balancer injects a number of additional HTTP Headers into each request before forwarding it to the back-end server. The most relevant one is X-Forwarded-Proto which tracks the protocol used to connect from the client's browser to the load-balancer. This can be checked like so:
var loadbalancerReceivedSSLRequest = string.Equals(Request.Headers["X-Forwarded-Proto"], "https");
var serverReceivedSSLRequest = Request.IsSecureConnection;
if (loadbalancerReceivedSSLRequest || serverReceivedSSLRequest)
{
// SSL in use.
}
else
{
// SSL not in use.
}

Well another way to check is to check the port
if(context.Request.Url.Port == 443)
Note: check which port is used for secure connections, usually it is 443

Cannot connect to WebSocket Server. No idea why

I'm using the code from this article just to try and get something up and running. However, I cannot seem to connect to the web sockets server once it's running.
I have tried forwarding both ports 8080 and 8181, ensuring that they are forwarded using canyouseeme, allowing the ports under my firewall, completely disabling my firewall, trying and forwarding different ports, etc.
Nothing has worked so far. Both the HTML browser page and console server application run just fine with no errors but I keep getting this error message when I try to connect through the HTML page in my browser:
Connecting to ws://localhost:8181/chat ...
Socket closed!
I have never used WebSockets before so I'm not sure if I'm missing something like if I need to install some framework, run some daemon, or what. I'm running Windows 7 64 Bit and using Visual Studio to run the solution. Not sure how to get this to work. Anyone have any ideas?

The server mentioned in that article is likely using the older Hixie protocol. If you are running a recent version of Chrome or Firefox then you are using the newer HyBi/IETF protocol. The article was written in Jun 2010 before the newer protocol was standardized and adopted.
Update:
Fleck looks like a descendant of the code in that article (via Nugget) that supports the old and new protocol variants.

Is it possible to use Fiddler to debug Http traffic issue?

I am using ASP.Net + .Net 3.5 + VS 2008 + IIS 7.0 + C# to develop a web application. I want to use Fiddler to debug (i.e. monitor request and response Http traffic) local traffic -- i.e. when I test web application inside VSTS 2008's built-in test ASP.Net web server. Is that feasible? If yes, how to monitor such traffic? For example, in VSTS 2008's built-in ASP.Net test web application server, the Url I want to monitor request traffic sent to http://localhost:1870/Default.aspx and its response (i.e. when F5 is pressed in VSTS 2008).
BTW: I previously think Fiddler could only be used to monitor port 80 Http traffic, not sure whether port 1870 could be monitored?

Have you tried adding a dot after the localhost? Quick test on my machine seems to indicate this is needed in IE but might not be in Firefox actually.

If you change your URL to 'http://ipv4.fiddler:1870/..' instead of 'http://localhost:1870/...' then fiddler will intercept your traffic and display the requests. Localhost doesn't go through wininet (I believe) which fiddler will then ignore. Fiddler registers ipv4.fiddler as localhost so you can monitor local traffic.
You can also add an entry to your hosts file and direct some URL (e.g. mysite.com 127.0.0.1) and use it as your URL (e.g. http://mysite.com:1870/...) and fiddler will pick that up, too.

Doesn't fiddler ignore 'Localhost' try changing the url's to your machines hostname.