I need to see the actual requests being made from a asp page to the webservice(which calls another webservice). All these requests happen on the same local box. I ran the "proxycfg -p http=127.0.0.1:8888;https=127.0.0.1:8888" on the command prompt based on
http://www.fiddler2.com/fiddler/help/hookup.asp#Q-WinHTTP: How can I configure a WinHTTP application to use Fiddler?
I now see the webservice wsdl requests in Fiddler but not the actual requests. Would someone know why??
If your WS calls are going to your local machine, make sure the URLs they are using are "localhost." instead of "localhost" - notice the dot in the first instance. Otherwise fiddler never gets a chance to pick up the request.
Related
I need to access a website we have from a machine that isn't able to see the external IP of the webserver. All http requests are of the form http://a.b.c.d/sitelauncher/sitelauncher.aspx and fail to see the site since that IP is inaccessible, yet the webserver happens to be on the local network. How can I somehow intercept and replace so all requests are of the form http://192.168.x.y/sitelauncher/sitellauncher.aspx
Silverlight is required on the client side in case this helps although have no access to source.
Is there some tool available that would permit some kind of string replacement on each occasion an http request is made?
Have tried a thing called rinetd which complains because it can't bind to the original IP target:port (no surprise since it'll be invisible).
Any ideas folks?
Cheers
Iain
I am trying to intercept HTTP requests sent via an application I have installed on my Windows 7 machine. I'm not sure what platform the application is built on, I just know that Fiddler isn't correctly intercepting anything that this program is sending/receiving. Requests through Chrome are intercepted fine.
Can Fiddler be set up as a proxy for ALL applications, and if so, how would I go about doing this? I have no control over the application code, it's just something I installed. It is a live bidding auction program which seems to mainly display HTML pages inside the application window.
Fiddler isn't correctly intercepting anything that this program is sending/receiving
That means the program is either firing requests to localhost (very unlikely), or ignoring the proxy settings for the current user (most likely). The latter also means this application won't function on a machine where a proxy connection is required in order to make HTTP calls to the outside.
The alternative would be to use a packet inspector like Wireshark, or to let the application be fixed to respect proxy settings, or to capture all HTTP requests originating from that machine on another level, for example the next router in your network.
How do I get around this error
**The Requested FTP command is not supported when using HTTP Proxy**
occur on the following code
ftpWebRequest.Method = WebRequestMethods.Ftp.DeleteFile.
It is urgent. Can anyone give suggestions for this problem
Your proxy might be blocking FTP delete keywords when filtering requests.
Can you check if you are able to do this activity when not in the proxy (try from a different network where you connect directly).
if yes, i dont think it is straighforward for you to do this activity from behind proxy.
Another solution is to try open source ftps libraries http://ftps.codeplex.com/
or
1. Create a WCF service on the FTP server which allows you to do all that you want.
2. From client side make call to the WCF service passing the command.
I have a public web server with the following software installed:
IIS7 on port 80
Subversion over apache on port 81
TeamCity over apache on port 82
Unfortunately, both Subversion and TeamCity comes with their own web server installations, and they work flawlessly, so I don't really want to try to move them all to run under IIS, if that is even possible.
However, I was looking at IIS and I noticed the HTTP redirect part, and I was wondering...
Would it be possible for me to create a HTTP handler, and install it on a sub-domain under IIS7, so that all requests to, say, http://svn.vkarlsen.no/anything/here is passed to my HTTP handler, which then subsequently creates a request to http://localhost:81/anything/here, retrieves the data, and passes it on to the original requestee?
In other words, I would like IIS to handle transparent forwards to port 81 and 82, without using the redirection features. For instance, Subversion doesn't like HTTP redirect and just says that the repository has been moved, and I need to relocate my working copy. That's not what I want.
If anyone thinks this can be done, does anyone have any links to topics I need to read up on? I think I can manage the actual request parts, even with authentication, but I have no idea how to create a HTTP handler.
Also bear in mind that I need to handle sub-paths and documents beneath the top-level domain, so http://svn.vkarlsen.no/whatever/here needs to be handled by a single handler, I cannot create copies of the handler for all sub-directories since paths are created from time to time.
Try the Application Request Routing addon for IIS to configure IIS as a reverse proxy.
I'm looking for details on the DEBUG HTTP verb.
It's clear to me that this is used for remote debugging - though I'm not even sure if it's for IIS or ASP.NET...
If I want to access this interface directly - i.e. not through Visual Studio, but sending these commands manually - what do I need to know? What are the commands for it?
I'm also interested in misuse cases, if you have any information on that...
Just for completeness, consolidating here the answers from what-is-the-non-standard-http-verb-debug-used-for-in-asp-net-iis: (thanks #Mark, #Jørn).
http://support.microsoft.com/kb/937523
When the client tries to automatically
attach the debugger in an ASP.NET 2.0
application, the client sends a HTTP
request that contains the DEBUG verb.
This HTTP request is used to verify
that the process of the application is
running and to select the correct
process to attach.
The DEBUG verb is used to start/stop remote debugging sessions. More specifically, a DEBUG request can contain a Command header with value start-debug and stop-debug, but the actual debugging is done via an RPC protocol.
It uses Windows authentication, and DCOM to actually do the debugging though (obviously, if you're allowing RPC traffic, then you've got bigger problems) or of any exploits. UrlScan does block it by default, though.
However, poking an ASP.NET website with the DEBUG requests can be used to reveal if the web.config has <compilation debug="true">. The test can be performed with telnet, WFetch or similar, by sending a request like this:
DEBUG /foo.aspx HTTP/1.0
Accept: */ *
Host: www.example.com
Command: stop-debug
Depending on whether debugging is enabled or not, you will get either 200 OK or 403 Forbidden.
It is generally accepted that you should never have <compilation debug="true"/> in a production environment, as it has serious implications on the performance of the website. I am not sure if having debugging enabled opens any new attack vectors, unless RPC traffic is enabled as well, in which case you have more serious problems anyway.
If you want to do remote debugging, I would suggest utilizing debug.writeline and the tool from sysinternals DebugView. This allows you to 'listen' for debug statements either on your location machine or on a remote machine, provided you have the necessary access.
I cannot directly answer the part about DEBUG http as I am unfamiliar with it.