I have an ASP.NET app that I'm running on Mac OS X. This app has a web service. I call the web service, it then calls a third-party web service. I can successfully see in Charles that my web service is getting called. However, I cannot see the call to the third-party web service. Why would this happen? Does Charles ignore nested calls like this? I really need to debug the service call. However, I cannot see the Request that is being sent to the service in Charles.
How can I view the details of the call to the third-party service in Charles?
You need to configure your ASP.NET app to use Charles as its proxy.
When you call your web service, your client (a browser?) uses Charles as its proxy, so you see the request. Your ASP.NET app then makes a new network request, but is not using Charles as its proxy so you don't see it.
On Mac OS X, usually all applications use the system proxy settings, set in System Preferences > Network. Charles automatically sets those to use Charles if Mac OS X Proxy is ticked in the Proxy menu in Charles. I presume that is ticked for you, given that your client used Charles.
So perhaps ASP.NET apps don't use the system proxy settings. In which case you need to check how you can set a proxy in your ASP.NET app. I'm sorry I'm not sure how to do that!
Related
I am in a stage of using SignalR in my project and i don't understand when to use Self hosted option and when we should not use. As a example if I am willing to host my web application in server farm,
There will be separate hosting servers
Separate SignalR hubs in each IIS server
If we want to broadcast message into each client, how this is working in SignalR
The idea with SignalR running in multiple instances is that clients connected on instance A cannot get messages from clients connected to instance B.
(SignalR scaleout documentation)
However, when you scale out, clients can get routed to different
servers. A client that is connected to one server will not receive
messages sent from another server.
The solution to this is using a backplane - everytime a server recieves a message, it forwards it to all other servers. You can do this using Azure Service Bus, Redis or SQL.
The way I see, you use the self host option when you either don't want the full IIS running (because you have some lightweight operations that don't require all IIS heaviness) or you don't want a web server at all (for example you want to add real-time functionality to an already existing let's say forms application, or in any other process).
Be sure to read the documentation for self-hosting SignalR and decide whether you actually need to self host SignalR.
If you are developing a web application under IIS, I don't see any reason why you would want to self-host SignalR.
Hope this helps. Best of luck!
I'm sure that was a confusing enough title.
I have a long running Windows service dealing with things happening in the world. This service is my canonical source of truth for the rest of my system. Now I want to slap a web interface onto this so the clients can see what is actually going on. At first this would simply be a MVC5 application with some Web API stuff. Then I plan to use SignalR 2.0 and Ember.js to make this application more interactive and "realtime".
The client communicates with the Windows Service over named pipes using WCF. A client (such as a web app) could request an instance of for example IEventService, would be given a WCF proxy client, and could read about events through this interface. Simple enough.
However, a web application basically just exists in the sense that it responds to requests from the user. The way I understand it, this is not the optimal environment for a long lived WCF client proxy to raise events in, and thus I wonder how to host my SignalR stuff. Keep in mind that a user would log in to the MVC5 site, but through the magic of SignalR, they will keep interacting with the service without necessarily making further requests to the website.
The way I see it, there are two options:
1) Host SignalR stuff as part of the web app. Find a way to keep it "long-running" while it has active clients, so that it can react to events on the WCF client proxy by passing information out to the connected web users.
2) Host SignalR stuff as part of my Windows service. This is already long-running, but I know nada about OWIN and what this would mean for my project. Also the SignalR client will have to connect to a different port than where the web app was served from, I assume.
Any advice on which is the right direction to go in? Keep in mind that in extreme cases, a web user would log in when they get to work in the morning, and only have signalr traffic going back and forth (i.e. no web requests) for a full work day, before logging out. I need them to keep up with realtime events all that time.
Any takers? :)
The benefit of self-hosting as part of your Windows service is that you can integrate the calls to clients directly with your existing code and events. If you host the SignalR server separately, you'd have another layer of communication between your service and the SignalR server.
If you've already decided on using WCF named pipes for that, then it probably won't make a difference whether you self-host or host in IIS (as long as it's on the same machine). The SignalR server itself is always "long-running" in the sense that as long as a client is connected, it will receive updates. It doesn't require manual requests from the user.
In any case, you'll probably need a web server to serve the HTML, scripts and images.
Having clients connected for a day shouldn't be a problem either way, as far as I can see.
I have an ASP.NET MVC 4 application that needs to query another application to process requests. The MVC application makes it's request via REST. I can see the incoming HTTP request from the browser to the MVC application, but I can't see the outbound REST call from the MVC application to the REST application.
Both applications are running in IIS Express. I access the MVC application localhost:42001 and the REST application is using ASP.NET MVC WebAPI, listening at localhost:42002
How do I get the REST requests that are going to localhost:42002?
The request are making it to the REST application, I can also set and hit breakpoints in that code. I just can't see the traffic in Fiddler.
This is because Fiddler is a proxy. Your browser filters all the requests through Fiddler. Your web server is not proxy'ed through Fidder so web server to web server traffic won't go through Fiddler.
To get that to work, you'd need to tell your web application to use Fiddler's proxy. It seems like you can follow http://fiddler2.com/documentation/Configure-Fiddler/Tasks/ConfigureDotNETApp which has some information on how to configrue your web application to send all requests through the proxy.
Another idea, if you're willing to do some packet sniffing, you could use something like Wireshark and that would capture all traffic coming and going on your computer and then you could filter down to the information you need. This is overkill for what you're looking for, but could help at some point.
By default, Fiddler proxies requests sent from the current user-account. ASP.NET runs in a different user's account. See http://fiddler2.com/blog/blog/2013/01/08/capturing-traffic-from-.net-services-with-fiddler for details on how to capture web traffic from service accounts like the one that IIS/ASP.NET are using.
I have created a sweet ASP.NET 4.0 UDP listener via WCF that starts on Application_Start. As usual, everything is hunky dory on my local machine. On my local machine using the VS Dev Environment and setting it to not open any page upon debug, the listener starts without browsing to anything yet. However, whenever I deploy to my shared host, I must access the site via a web browser before the listener will start. I do not have access to the IIS control panel but I do have some limited setting changes I can make to IIS via "Website Panel" software. I believe the shared host uses IIS 7.5.
Is there a better way to solve this rather than creating a polling service from my home PC to send an HTTP request to the shared host every so often to kick off the listener?
Requirements
The client sends UDP packets over a configurable port. I cannot change anything other than the IP and port that the client uses to connect
The solution must work with my shared host since I cannot afford a VPS at this time - otherwise I would've created a Windows Service. I got around creating a window service before by creating a polling service via WCF Application_Start but that only works because the info the users would see have to be on a webpage therefore application_start would always be called. In this case, the users/clients are not necessarily accessing the webpage.
Ideas:
Somehow pull this into a .svc. That way when the .svc is accessed by the client, it kicks off the listener for everyone else. But how can a .svc running on port 80 accept UDP calls? I'm also not sure if the client will be able to connect to more than an IP:PORT (I don't think it'd accept a .svc path like URL.com/awesomeListener.svc).
Any suggestions? Thank you so much.
If you are running ASP.NET 4.0 you can set it to auto-start for you which will fire Application_Start:
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
So far I've been successfully using fiddler to sniff web service traffic from both test fixtures, console apps and web projects.
Today I noticed I am not able anymore to sniff that kind of traffic if I am running my web application (it's a ASP.NET website, hosted locally on IIS). I see all the local traffic but the web service traffic is just gone (the service is being hit as I do see the response debugging into the code).
I am still able to successfully sniff soap requests and responses from test fixtures or console apps in the same solution (exact same environment).
If it was a windows (I am on Win7) security update or the likes it would never work I guess (unless it affects only traffic routed through IIS).
What should I be looking for that could cause the emergence this behavior?
Any pointers appreciated!
NOTE: I can see local traffic, but not the SOAP request/responses to the web service which is not hosted locally anyway (it's a sandbox another team is providing)
EDIT: This bit of configuration did the trick (found on Rick Strahl's blog)
<system.net>
<defaultProxy>
<proxy
usesystemdefault="False"
bypassonlocal="True"
proxyaddress="http://127.0.0.1:8888"/>
</defaultProxy>
</system.net>
What's the client of the web service? ASP.NET?
ASP.NET traffic isn't proxied unless you configure ASP.NET to use a proxy. It's possible/likely that the app.config or machine.config changed such that traffic is no longer getting proxied?
You should have a look at this section: http://www.fiddlerbook.com/fiddler/help/hookup.asp#Q-DOTNET
If you want to view the http traffic between your web site and your web service on your development machine, and don't want to change your machine.config.
One easy solution is to change the Application Pool Identity of your web site to use your own credentials of the current logged on user. This means that your web site will adopt your proxy settings and will now redirect to Fiddler.
Make sure the web service you are calling (from IE) is not http://localhost/yourwebservice
Fiddler will not intercept localhost traffic from IE, use http://machinename/yourwebservice instead.
I ran into this issue a week or so ago. Try this page: http://docs.telerik.com/fiddler/Observe-Traffic/Troubleshooting/NoTrafficToLocalhosthttp://www.fiddler2.com/fiddler/help/hookup.asp#Q-LocalTraffic
The ipv4.fiddler was the part that worked for me. Hope this helps.
You're probably using a port other than 80 for these http requests. I remember setting up a reverse proxy to look at WCF requests I was making on my local machine during dev. Here's the documentation:
http://www.fiddlertool.com/fiddler/help/reverseproxy.asp
Can you try the following -
Try stopping the windows firewall and see what happens
try using firefox and redirecting traffic to fiddler and see what happens