I'm experiencing some really odd timeout issues when running a ASP.NET 2.0 project on Cassini on localhost, and I don't have enough data to get a clue of what's going on.
Is there a way to monitor localhost traffic to Cassini, either using some specific development tool or a general-purpose monitoring app such as fiddler?
Just to pre-empt some answers I'm already aware of:
Normally I can use the well-known dot-hack for using fiddler to monitor localhost traffic, but with Cassini I get the following error message in the browser:
[Fiddler] Connection to localhost. failed. Exception Text: No connection could be made because the target machine actively refused it ::1:3213
Fiddler also listens to localhost on http://ipv4.fiddler:port, and I can intercept the traffic. But when I do this the timeout issues don't occur!
Any other tools or fiddler workarounds welcome! Thanks!
Edit: Oops. This question had already been asked... Twice.. Didn't come up on search or suggestions. The solution found in the second thread is to use the dot-hack with ip-address (http://127.0.0.1.:port/ instead of "localhost". This question may be closed.
While fiddler ignores requests to localhost, it listens to 127.0.0.1. (note the trailing dot):
So this won't work:
http://localhost:1234/
But this will:
http://127.0.0.1.:1234/
You're generally better off using http://ipv4.fiddler as it makes it more explicit what you're trying to do.
CassiniDev is an open source project that was developed to fill in all the blanks left by WebDev.WebServer/Cassini.
You will find this issue handled as well as many others.
It works well as a stand-alone server, as an in-process server suitable for testing and embedding and, most notably, as a direct replacement for the Visual Studio 2008/2010 dev servers.
alt text http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=cassinidev&DownloadId=123367
alt text http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=cassinidev&DownloadId=123366
Related
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.
On my desktop I run Visual studio web server cassini and fiddler as a proxy, then I connect to a web site running in Cassini using an iPad connected via wireless.
This has always worked since I installed and unistalled the MVC pack for visual studio.
Now I get this message from fiddler (it is sent to the iPad):
[Fiddler] DNS Lookup for "http://175.33.22.116" failed. The requested name is valid, but no data of the requested type was found
There are similar posts with this message, but none of them with my setup.
Can you suggest what to check?
Thank you
This indicates that the traffic from your IPAD client is malformed. Are you using anything in Fiddler (e.g. Tools > HOSTS) to change the traffic? If not, the bug is on the client; e.g. something is trying to connect to http://http://175.33.22.116 which isn't legal (due to the double http:// within the string).
This may be a general topic, but I came across the issue while working on some code using the Rook package.
The recent R versions include an http server. You may have seen this while checking for help topics using RGui. It opens a new browser with the IP/Port, etc.
For eg., if I enter ?paste, this brings up,
http://127.0.0.1:31234/library/.../paste.html
But if I use my IP, say 192.168.1.2 in place of 127.0.0.1, the page fails to load, I get an error
While trying to retrieve the URL:http://192....
The following error was encountered:
We can not connect to the server you have requested
I have other apps that have httpd interfaces, and I can go to those app's http interfaces using both 127.0.0.1 and 192.168.1.2 ... etc. So, as far as system/network permissions are concerned - I do not think that is the issue here.
Rather, there is something specific to the R httpd process that disallows it to be accessed using the domain name, etc ?
The above was tested in a corporate network. When I tried the same process from my home network it worked fine. However, since I already access http interfaces of many other locally installed apps from the corporate PC, I think there might be something specific to R's http process that needs to be checked ?
Workstation is running - Windows XP
Please let me know if you have any thoughts on the above,
Regards,
Raj.
Fixed it. The trick is to specify,
s <- Rhttpd$new()
s$start(listen="0.0.0.0",port="20000")
when starting the Rook process. Specifying 0.0.0.0 makes it listen to all the interfaces and now I can access it using my external IP. Thanks a lot for your help nonetheless !
When opening a TCP port, the local IP address may be chosen. For incoming connections, typically INADDR_ANY (-1) is supplied to bind(), which means to open the port on every available interface.
However, it is quite possible to open a port on just one interface on your machine (in this case, 127.0.0.1), simply by supplying the IP address of the interface. Seems that R does just this.
My guess is that you may have a proxy in place on your corporate network. Your browser is probably configured to use that proxy to access the Internet. Most browsers will exclude an address which they know to be local (127.0.0.1 or localhost) from using the proxy, but might not exclude any other IP.
Try disabling the proxy in your browser (even "Auto-Detect", completely turn the proxy off) and see if you're able to connect.
I had the same problem.
If you are using RStudio, this might be a bug in the RStudio. Check out this link:
https://support.rstudio.com/hc/communities/public/questions/202656007-Cryptic-error-on-starting-RStudio-daily-with-R-devel
Updating to the latest version of RStudio with the latest version of R fixes the problem.
We have a windows service running that listens on e.g. port 9999. Now we want to be able to send a TCP packet through an ASPX page to that service. Both the service and ASP.NET WebApp run on the same server.
The problem is that this works fine on my dev machine (without IIS though, through Visual Studio Web Server) and on our older Win 2003 Server machine. But it doesn't work on our new Win2008 R2 Server. The packet just won't arrive.
I'm absolutely clueless as to what the problem may be. A search in Google didn't help me as it seems I'm the only one wanting to send TCP packets through an aspx site.
What I have tried so far:
1) Changing the identity of the corresponding Application Pool
2) Disabled the Firewall
3) In web.config set the trust level to "Full" (which seems to be default anyways)
I'd appreciate any more hints!
And if you use software like TCPView and/or Wireshark do you see the connection being created and the packet being sent? The first step into solving this problem is finding out on 'which side' the cause lies.
It might also be useful to see the code you're using to build the connection and actually send the packet. Might give some clues as to what is going wrong :)
And last but not least, you say it works on your development machine with ASP.net WebDev server. Install IIS locally and try it again. Try to mimic the actual problem situation as best as you can (apart from OS-choice etc.).
This is an old and almost forgotten question to which I have found a solution weeks later. It was a IPv4/IPv6 "problem". localhost always resolved to the IPv6 adress, but the listening application was only listening on IPv4 adresses. So replacing "localhost" with 127.0.0.1 solved my problem.
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?