It is not a specific problem because I have more than one experience that fiddler save my app.
A recent example:
I had an excel addin app write in C#. In the app I had a httpclient to connect to my server through ssl. And I ignored the certification in my code explicitly.
The app always worked well(I mean the connection part), but one day in a QA environment, it failed in no causes. The connection seemed to be blocked for long long time.
Coincidentally, we opened the Fiddler and tried to grab some http. Then everything worked fine.
(Fiddler may do something in the middle)
Then after closing Fiddler, we cannot recreate the problem because all things went back to fine again.
(Fiddler change something permanently!)
Here are some clues:
We use the normal C# http clients System.Net.Http .
Our server is ssl (https, but we must ignore the cert)
The app was good in the same environment at frist.
The lastest change is about the localization, and the test enviroment changed the windows local and language.
We are under a company network, using a proxy in the example above.
The failure is not the whole connection module, but a specific request.(In our case, a request that post two small xml files including excel itself)
Please give us some hint and guess, so we can feel better on this mystical problem.
How long is a "long long time" exactly?
Fiddler does not make any persistent changes to the system; if you start and stop it, the system is returned to the prior configuration. I suppose it's remotely possible that if some configuration setting were corrupt before Fiddler ran, that corruption wouldn't be replicated after Fiddler attempted to reapply it, but we don't know of any such "corrections."
This article describes some of the things folks find unexpected in terms of Fiddler "magically" fixing things while it runs.
Related
This is my first Stack Overflow question so apologies if this isn't great...
I'm sure this is something either super simple I am missing or something very complex that I've gotten myself into, but I am using ClickOnce for the first time to create an automated updater for a company application I developed.
The application itself was originally written in VB but I have translated it into C#. We use this to automate a database of assets, which changes very frequently. I have been tasked to allow it to complete automated updates to keep from confusing some of the techs with uninstall/reinstalling the application weekly.
I volunteered to make an FTP server using a personal server machine I use at home. Normally this machine would be used for local networking but I've wanted to create an FTP server for some time (this is my first FTP server too).
So I went on my way, set the publish location for the build to ftp://[IP.ADDRESS]:21/Folder/Subfolder and the Installation folder URL to http://[IP.ADDRESS]:21/Folder/Subfolder
Long story short, when I try to test an update (changing only the assembly version), I am an error:
System.Deployment.Application.DeploymentDownloadException: Downloading http://[IP.ADDRESS]:21/Folder/Subfolder/applciation.application did not succeed ---> System.Net.WebException: The server committed a protocol violation.
I did some research and tried adding an SSL certificate and changed the update path to https://[IP.ADDRESS]:21/Folder/Subfolder/ then tested that. This time around, I get this error:
System.Deployment.Application.DeploymentDownloadException: Downloading http://[IP.ADDRESS]:21/Folder/Subfolder/applciation.application did not succeed ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. --> System.IO.IOException: The handshake failed due to an unexpected format.
I cannot tell if this is progress or if I moved backwards here LOL. I've been jumping back and forth and going to many threads to try to figure out where this is going wrong. I'm also having a pretty tricky time finding out if this is an error with how I've set up ClickOnce or if this is an error in how I have set up FTP with IIS.
Apologies if this is not enough information, I can provide more if necessary. Also apologies if this is too much information! Any help or guidance is appreciated!
I'm guessing you're working for a small company and infrastructure/resources are at a premium. With that in mind I'll offer some suggestions:
Does your company have a network shared drive? I don't like ClickOnce, but I have deployed it to network shares in the past with success. This has the benefit of you not needing to deal with security.
Have you considered migrating this to a web application? Web development seemed really daunting when I was a native app developer, but with Blazor and ASP.NET Core it's become a lot more accessible. This would completely get rid of the need for updating the application.
Consider an alternative deployment route. ClickOnce is not incredibly well supported.
I'd be remiss if I didn't throw a red flag on security. FTP is a very old protocol and is basically insecure by design. Hosting it on your home server means that you're transmitting the app over the public internet... What would happen if someone outside your company installed the application?
I have a c# app that exports data from the database to the user's Exchange Calendar, using Microsoft.Exchange.WebServices (15.0.0.0). My app is DotNet 4.5.2 and I use Visual Studio 2013.
The app has been working fine for a year, and even now works 95% of the time. The app runs constantly on machine that I am logged into and monitor. This is a low volume process, perhaps 50 items get exported per day at most.
Every couple of days, the program will give this error:
"The request failed. Unable to connect to the remote server"
when the app is attempting to create an EWS connection to the server.
It will do this for maybe 10-20 items. So I shut it down, run it again, and it works perfectly fine on all the records that failed before.
This is my first EWS app, but I've been programming 30+ years and do have somewhat little knowledge of internet based apps.
Any helpful information or suggestions would be greatly appreciated!
Thank you kind people!
The internet often works, but should never be considered reliable. Anything using it should handle errors, and retry if desired. The classic approach is Exponential backoff. Its possible something nasty is going on, like your ISP swapped your IP address, or just intermittent failure. I don't know anything EWS specific, but there may also be sources of flaky issues there as well.
I am using the System.Web.Helpers.WebGrid extensively throughout our application, and for the most part it is fine and in fact running locally it is always fine or with a self SSL on the server it is also fine. So I don't know if the problem could actually be with IIS or a firewall, or the actual grid, or what I need to do to fix it.
On all browsers, although the result is slightly different, successive ajax sorting and paging on the WebGrid will eventially cause it to hang, and when I inspect the response in Fiddler I get
[Fiddler] ReadResponse() failed: The server did not return a response for this request.
If I copy and paste the url directly into a browser it will load but if I continually hit F5 I will eventually get a message stating "This webpage is not available" in chrome (with Error 103 ERR_CONNECTION_ABORTED) or "Internet Explorer cannot display the webpage" in IE.
The url is quite long and convoluted, something like http://app.myapp.com/mygrid/9e3b2ae5-cbe1-4a4a-a355-a14f00d26e24?mylayout=true&myid=634982439599769687&readonly=False&search=-&__=634982439708207187&sort=Name&dir=ASC
and this problem seems to go away if an SSL certificate is installed on the server, and doesn't happen at all locally.
Any ideas?
Your last paragraph of your question
and this problem seems to go away if an SSL certificate is installed
on the server, and doesn't happen at all locally.
immediately made me think of possible issues with DEFLATE and GZIP problems, knowing they would be disabled on encrypted connection, and quite possibly also for local connections, as you can't really move the same certificate from the server environment to your local development environment (that would beat their purpose), and would have to create a new self-signed certificate for testing purposes, if that was a requirement.
I also happen to have stumbled across infinite loop may occur in GZipStream or DeflateStream issues before with one of previous .NET 4.0, version 4.0.30319.236 to be precise. These problems have been solved in later .NET 4.0 builds and can be avoided by installing .NET 4.5 on top of you 4.0 installation as well. If that's what was causing your problems, it's still rather difficult to say and some other server-side settings might have caused it, such as now discontinued IIS Lockdown Tool, or even URLScan not accepting lengthy URL requests when the compression for them is enabled.
TL;DR - Either case, the obvious conclusion was to try disabling IIS server's urlCompression for these requests (and/or httpCompression) in your Web.config file, and see if the issues still persist:
<configuration>
<system.webServer>
<urlCompression doStaticCompression="false" doDynamicCompression="false" />
</system.webServer>
</configuration>
This is obviously a hack solution that should be looked into further, by comparing differences between server's and your local environments, if that is at all possible. It is also quite possible that the server wasn't updated with all the latest libraries, and doing so could resolve it as well.
DISCLAIMER: I realize this isn't really a 100% bullet-proof answer, however OP suggested in the comments that it did the trick. I have also posted this question and a possible answer to it on DMZ yesterday, asking if anyone else would know of a better answer and knowing these issues would be immediately recognized by our IT Security wizards, but the St. Patrick's day seems to have taken its toll :)
Cheers!
I have a bug where special characters (danish 'ø' in this case) are shown correctly when running locally, but wrong when the code runs on a server (I get a pipe '|'). I was trying to solve this today, but I did not have access to the server, other than updating the code files. I will limited access monday, so I can at least write intermediate results to a log file, but to be prepared I thought I'd ask for suggestions here.
Program flow:
A C# test calls my own web service via a WebRequest.
This web service calls an external web service via another web request.
When running my own web service locally I get correct results returned from the external web service.
When deploying the code to the server the external web service returns an error; it didn't find the word I was searching for. Except that I entered 'Bøssemagergade', but the word it complains about is returned as 'B|ssemagergade'. What can cause this difference? AFAIK the server runs with the exact same regional settings as my local machine.
I'm sure this is common stuff, but I haven't been doing web services before (I do feel at home with C#/.NET though, and know about encodings etc.).
Thanks!
You need to check your data at every stage in the process. Make sure you understand which encoding you're using (try to avoid using Encoding.Default) and verify the binary data going across the wire with something like WireShark.
See my debugging unicode problems article for further information.
I'm quoting myself on a previous question I asked to further explain:
"I'm trying to run a freshly created ASP.NET Website using C#, however when I do so it launches FireFox and attempts to connect to http://localhost:1295/WebSite1/Default.aspx (for example), but after about 10-15 seconds it displays a "Connection Interrupted - The connection to the server was reset while the page was loading." Error.
This issue is also present with older ASP.NET C# pages/Web Services I've built in the past, nothing is actually running off the ASP.NET Development server."
This is the problem that was occuring, that is before I noticed every time I ran the website, the notification for the ASP.NET Server-startup showed one port (1130 for example), and when the website failed to load; it turns out it was attempting to load the site on another port (In this case, 1128). It was suggested that an anti-virus program could have caused this kind of redirection; low and behold uninstalling Nod32 fixed the problem!
So my question is: Has anyone found a way to create an exception or remove this functionality from Nod32?
Within Nod32 enter the Advanced Setup options, and turn off protocol filtering.
It's a known problem with NOD32. Looks like it's IMON module (protocol filter) accidentally does some modifications of TCP packets that go through it.
The solution is to either turn it off, or use a different software.