This will probably be an environmental issue but I'm stumped as where to start.
I'm attempting to call a a webservice on an external server in an asp.net web app while debugging in VS2008. The exact same code/project works on one machine calling the server but on another machine (my new one) it fails with the 400 Bad request (data is invalid) error.
Both machines are running Windows 7. What should I be looking for as differences in the two machines that could be contributing to this problem?
Edit Deleting the webreference in the project and re-creating the webreference had no effect
Update
I went to use Fidler2 to inpect the request and response which resulted in the error going away. Things are beginning to point to an internet proxy issue.
It's an Internet Proxy issue. The suspect machine had be configured to manually use a proxy server. Turning this off: Control Panel -> Internet Options -> Connections Tab -> Lan Settings Button, and enabling "Automatically detect settings" has fixed the problem.
Related
I have some websites that should be able to get data from each other by a webservice.
Every website is using the "same" code so in every website(s) web.config, you have both the service and client config.
When doing a request, url is set in runtime like:
foreach(var sibling in mySiblings)
{
var client = new MySoapClient("MySoapClient", sibling.Host + "/webservice/MySoapClient.asmx");
var info = client.GetInfo();
allInfo.Add(info);
}
(only pseudo code)
All sites are hosted on the same server.
When code is executed, you get an error after a while:
"There was no endpoint listening at 'http://host_address/webservice/MySoapClient.asmx' that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details."
InnerException: "Unable to connect to the remote server"
Adding log to the code above, checking the "client.EndPoint.ListenUri.AbsoluteUri" gives you a correct path, that can be reached when entered in a browser.
Now, the real annoying problem:
There are some servers/sites that CAN connect - and some that can't.
There is another server, with "same" sites - only this is the test-sites.
(Copy of the code, copy of the databases - other dns-names)
The test-sites can connect to the other test-sites webservices and get data.
The test-sites can NOT connect to Prod-sites
The prod-sites can connect to sites on the test-server.
The prod-sites can NOT connect to Prod-sites. (Not even to it self)
So, it seems like there is a problem with the prod-sites/server.
Only problem with that...if you set it up on you local machine - you can get data from both test - and prod.
I also built a simple test-client, (aspx-page) containing a dropdownlist with hostnames, For prod and for test. And a button.
Click the button: Make a call to a simple method in the webservice of selected host.
I then set this up in the IIS as "http://public-ip-number/wsTest" on four locations.
Running this on my own computer: Can connect to both test and prod.
Running this on the test-server: Can connect to test.
Running this on the prod-server: Can connect to test.
Running this on a third server I have access to: Can connect to both test and prod.
Test and Prod are hosted by a hosting company. Both servers has been setup the exact same way, since test should reflect prod. (Windows 2016 server) Or at least they should.
My system: Windows 10
The third server: Windows Server 2012.
Since the code is identical on the two servers, I don't think that's the problem. Specially since everything works when calls are done "from the outside".
I have access to the servers through VPN/RDS, and have full administrator roles. But there is no visual difference on how the servers are set up, as far as I can see.
Could there be some firewall blocking on the hosting-part?
I really don't know where to look!
Anyone with any ideas...I'm all ears!
Update:
This wasn't actually a coding-problem.
The hosting-company had indeed added a rule to the firewall, "The problem is NAT Loopback. This means that the server shall access itself on public IP addresses."
After they fixed it, everything worked as it should.
I am having very strange network problems. I am on a domain where a few servers are located on a different subnet. I can ping these servers, dns look them up and remote desktop to them by IP-address. I however cannot find them when using:
net view \server
or
Try to access them via windows explorer.
The person next to me who has an identical machine and is on the same subnet has no problems, as a matter of fact, I am the only one in a 50 person company having this problem!
This wouldn't be so much of a problem except for the fact that my machine cannot use web services located on these servers, neither via HTTP or NET.TCP.
After trying everything I can find on the internet and some more (added a new network card, reset policies, etc.) I finally got WireShark to see what is going on. When doing net view \server I notice that the server never responds to "Session Setup Request" but it did respond to "Negotiate Protocol Request". So what could possibly cause the server never to responde to the Session Setup Request?
Here is the server side capture (Not same session)
OK I found out what this was by comparing my tcpip registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters) with a machine that worked. What I noticed is that I had the following 2 entries
EnablePMTUBHDetect 0
EnablePMTUDiscovery 1
but the other machine didn't. By deleting these entries, everything started working!
This however is very strange because these happen to be the default values for there registry keys so I do not understand why having these entries cause such a problem.
We have a lamp word press intranet site running, however, the first time I load the site it doesn't load and says the page cannot be displayed. When I refresh the site it loads. Is this a problem with our server or dns or what?! We have no proxy and sometimes get this error message as well ERR_CONNECTION_RESET. Any ideas?
I suppose the best way forward is to first figure out which part of the process is failing, browser, computer or web server.
Determine the most likely point of failure
If the fault occurs on more than one computer, and with different browsers then it not likely to be browser or computer issue. Therefore the next step is to look at the webserver.
if it looks like a computer or browser issue
If its only failing on one computer or browser the try flushing your browser cache, if that fails then it could be a network setup issue. You could try setting you computers DNS network settings to point to your internet router and to your web servers IPs.
if it seems like a web server issue
1) Check settings of your network, try setting DNS to router and webserver.
2)If you have a spare computer install fresh webserver and try using new test webserver to see if you get the same problems
and if all else fails get windows PC install WAMP;) or the ultimate solution switch it off and go the pub.
We have recently implemented a new ASP.NET site to our webservers to replace our old Classic ASP site(Both severs are Windows 2008 R2 Using IIS 7.5). They are hosted on a Load Balancer.
This one .NET webform application is used for approximately 30 clients (each with their own URL. client1.mysite.biz, client2.mysite.biz etc...)
Our original plan was deploy our new application into 3 "WebSites" each with their own app pools and BIND the clients to the relevant Website.
When binding we bound to both Http and Https for the URL (we have certificates for each of the sites)
INITIAL PROBLEM:
We noticed that after we bound more than half the sites and tested, we were suddenly being greeted with "Service Unavailable. Service is Temporarily Unavailable" (NO NUMBER just the words) every time. We unbound everything and tried again (meticulously testing each time we bound a site). Each time after binding a certain number of sites the same thing happened.
We ran out of down time and went to Plan B. We put the whole thing in the "Default Website" as a virtual directory (No bindings) (This is how the Classic ASP site was setup)
OUR PROBLEM NOW:
Occasionally we get the same dreaded white screen with "Service Unavailable. Service is Temporarily Unavailable" (NO NUMBER just the words).
It seems to happen randomly (not load or time dependent as far as we can tell). If using AJAX it simply is caught in the "Error" portion of the AJAX code but I believe it is the same problem. The error occurs INSTANTLY when it does happen. If the user attempts to repeat the action that caused the problem everything is fine (they are not logged out and they proceed on their way).
However this is happening MULTIPLE times a day and it's across ALL of our sites (not just this new one).
One more item of great importance. This appears to be happening to ALL of our sites (Virtual Directories and custom WebSites on BOTH of our web servers). That seems to rule out a "bad" server (both are in the cloud did I mention?) and it also "seems" to rule out App Pool settings but what do I know?
About our IIS servers: We have multiple application pools running multiple different instances of websites (different code). Some are testing sites. Some are using classic ASP and others and using ASP.NET.
What we've tried: We scoured the web looking for answers and have edited our machine.config file to increase all manner of things such as "Threads, Max-Connections etc...". We've edited our App Pool settings by increasing our Queue Length and turning on ALL the logs.
Anyone seen anything like this before? My theory is it has something to do with the bindings and the frequency of the error is increased for each binding I initiate but that is difficult to test when it happens on my production servers only.
We have finally solved this problem. As mentioned previously, we noticed that the IIS logs contained a sc-win32-status 64 error when we experienced the Service Unavailable problem in the browser when (and only when) our site was using the Load Balancer.
To help look into this further, we did a network capture of the traffic on the Load Balancer while testing. We reproduced the random Service Unavailable problem, saw the associated win32-status 64 error in the IIS logs, and identified the specific packet of traffic on the network capture for this event.
Using Wireshark, we followed the TCP stream and noticed that the TCP connection was reset by the Load Balancer immediately after this packet. We reproduced the problem three times and every time there was a TCP reset immediately afterwards.
Walking backwards through the TCP stream, we noticed in all three instances a packet for HTTP/1.1 200 (accplication/octet-stream) and prior to that a request to download a document (ie. .pdf or .xlsx or .docx) from one of our sites. The server that contains all our documents is not a web server and does not have the IIS role active. The document server does not have a way to define the content/media type for the document that is being downloaded. Hence the generic (application/octet-stream) packet in the network capture. The Load Balancer treated the request for a document as potentially malicious and decided to reset the TCP connection if another request is made. To fix the problem, we added a content type library function to our application using this post as a guide. Sorted!
In Summary:
A document was requested from our document server via our web
application
The document was sent back to the user with a generic content type =
application/octet-stream
The Load Balancer flagged this activity to be potentially malicious
Another request within this TCP connection was made
The Load Balancer reset the TCP connection
This results in a Service Unavailable
Lesson Learned:
Always define your content/media types if you are serving content from a non web server or a web server running an IIS version less than 7 (Heaven forbid).
A UC Certificate was originally meant for Microsoft Exchange, but it can also be used to cover multiple domains. We use one and it covers about 60+ domains (actually 4 or 5 domains with lots of subdomains). We also apply the certificate to a load balancer and two web servers and we have multiple sites. So far as I can tell the certificates operate as expected. you can view it from any of the 60+ domains. One odd thing about our setup is that in the IIS UI, you can't bind the same certificate to more than one site so we had to use the appcmd command line interface to bind multiple sites to the same certificate.
After looking more closely at our IIS logs it appears that there is indeed something that coincides with this behavior. We get an error of 200 0 64 which is the sc-win32-status 64: "the specified network name is no longer available".
Now our 2 IIS servers are hosted in the cloud on Sungard, and we are using a load balancer that they setup for us. It was our theory that the load balancer was "losing" the proper session id of the user when this 64 error occurs and has no idea where it was supposed to be.
We ran some controlled tests. One group we took OFF the load balancer and sent them directly to one of the servers and another group used the load balancer but made sure to connect to the same server. Both teams conducted the tests of trying to reproduce the error (which is to say we clicked a popup on the site over and over).
The results were interesting. The group that was NOT on the load balancer NEVER received the "Service Unavailable" error! BUT the logs indicated they were getting 64 errors 45 times. The group that WAS on the load balancer was able to produce the "Service Unavailable" message twice and the logs confirmed that there were exactly 2 instances of the 64 error that coincided to the exact moment that the errors were observed.
So what does this mean?
1.) Load balancer has some settings "Sticky Sessions?" that aren't keeping the sessions in right (but we can't find the right settings. It's not even our load balancer it's SunGard's). Anyone have any advice on these settings for ASP.NET?
2.) 64 errors are a part of web life? We gave more cpu power to one of our Virtual IIS servers and received less 64 errors. This is all I can come up with. We've sunk too much time and money trying to solve this, but it appears that I have an option at least of taking people off the load balancer and just routing them to one or the other server and in addition I can at least beef up the server to handle more traffic and reduce the 64 errors.
In a testing environment, I self-signed a cert and installed it on a web site in IIS 6. This is using .NET 2.0. Cert seems fine (minus the fact that client services don't fully trust it as one would expect). I can do whatever I want to by hitting the site locally from the server on HTTPS or HTTP.
The problem is coming in when accessing this site remotely. If the page has an exception on it, the connection drops. Not return an error, but just flat-out drops, where the browser says it couldn't find the site (this is after it churns for a few seconds, where I can see TCP traffic from the client IP coming in).
The interesting part is that I can create a blank ASPX page, with nothing on it, and it's fine over HTTPS. But the minute I put throw new Exception(); on the page, it goes back to dropping. By the way, it seems to act completely normal if I hit the same page using HTTP instead.
So I'm a bit stuck. Anyone seen something like this?
My first inclination is to go after the proxy/firewall rules between my remote client machine and the server, but I want to make sure it's not something I could fix before I bug other teams.
EDIT ...looks to be a firewall whitelisting problem. Others on my subnet have the same problem, but people in other locations can hit it just fine.
This is not a proxy or firewall issue, because the Yellow Screen Of Death is just text which transmits through any firewall just fine. Here are a couple things that I would try first.
Make sure that the fact that you are using HTTPS isn't the root cause of the problem, such as the problem isn't caused in your program, by handling HTTPS. Such as some special handling of Error code.
Create a new cert and see if the same issues occures.
Try to reproduce this issue on another machine, it could just be a configuration issue.
Try getting a real cert from GoDaddy, they are only 29.99.
That is all that I can come up with right now. One thing that you didn't mention was which version of IIS you were using, which will be helpful.
Have your thrown the exception and then tested the page using regular HTTP? Is the same thing happening, or does it only happen if you throw an exception and access it using HTTPS?