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).
Related
I have on-prem TFS within a small domain that we RDP into. Development machines are in this domain/enclave as well. Prior to the most recent TFS upgrade, we were able to connect Visual Studio to TFS and browse the TFS web UI using HTTP only within the enclave. We could also use HTTPS from outside the enclave (no http) to access the web UI. With the latest upgrade, I have mirrored the IIS authentication, SSL and binding configurations but now pointing a browser or Visual Studio at the HTTP only address always redirects to the HTTPS address and forces the SSL login. This is a problem for us because we use a large enterprise PKI infrastructure (access cards, non-local services, etc) that is very flaky: constantly dropping the Visual Studio connection to TFS and asking for PIN re-entry every 2 - 3 minutes. How can I stop the http address from re-directing to https all the time in our enclave? Is TFS doing this now? or IIS?
Since TFS2017 server changed the Authentication from NTLM to KERBEROS by default. You could use the following command to use NTLM back:
TFSConfig Authentication /provider:NTLM
And please try to create a new DNS, then check the result again.
If you want to remove Https, you should change the "Public URL" to http in TFS administration console, removed the HTTPS bindings from IIS.
If above is not work, try to uninstall and re-install the Application Tire and choose the http only option.
For more details take a look at this similar question: TFS 2018 - remove HTTPS
Got it. Found this article describing the redirect behavior from the URL. Long story short-> In IIS, select the TFS under Sites, then Application Settings, setting name sslOnly was set to true. Changed to false. Now I can access the TFS portal from inside the enclave using http OR https and from outside using https only. This means that VS can also connect to TFS via http only.
I need to connect to a third party webservice. When I hit the link directly in the chrome browser, I am able to connect to it and I get a response. But when I tried the same using Advanced REST Client app of chrome, I get a message as 'The service's server DNS address could not be found.'
Also, when I tried to connect it via my JAVA code, using spring's rest template, am getting an Unknown host exception. What could be the reason that am able to connect via browser but not otherwise?
Thanks in advance.
Maybe it's a problem with your system's DNS settings? I'm not sure how Chrome handles queries to DNS when primary DNS did not found the record. If it uses Google DNS' then Chrome may connect to the service but other applications can't.
To test it set your DNS to 8.8.8.8 and check if apps start working.
From browser it's working properly but not from rest client or application, then i guess the problem with the proxy.
if you are using your office network, then this issue will come.
Try hitting the webservice by connecting to personal network.
i have faced similar issue last week, from browser and postman i'm able to hit the web service but not from the application.
Ones i connected with my personal then it started working.
Hope it helps.
I have some iOS 5 code that I am using to interface to an ASP.NET web service. The code can (seemingly) connect OK to my service but a blank reply is sent every time. I have stepped through the code and saw how iOS takes the service domain address and turns it into an IP address and tests for connection. Does it also use the IP address for a connection when running? The problem is that I have my service running on a shared ASP.NET box so mysite.com/mywebservice.asmx will resolve while an ip address like xxx.xxx.xxx.xxx/mywebservice.asmx will not resolve at all. Could this be the root cause of why my web request is blank every time?
I'm guessing your web site has a registered domain name which is auto-mapped to an IP . Therefore, according to a similar issue that we faced earlier, you need to analyze the full request that is being sent . Tools like - firebug http://getFirebug.com , poster https://addons.mozilla.org/en-US/firefox/addon/poster/ can be really handy for the same.
The issue I faced was solved by changing the "user-agent" header in the request from the IOS device.
So you can replace the value of the header you send with the one that is sent from the browser. Also, there can be some cookies being sent by the browser as a default behaviour.
I think those would be good directions to look, considering the web service you hit gives a reply to the browser.
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
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.