I have written a simple HTTP Proxy server in C# that I would like to integration/functional test. Is there a product already created that I could use to do this? If not, what is the best way to write my own tests for this (I already have unit tests)?
To test the integration by delivering a webpage you could try one of the following:
Selenium
WaTiN
Watir
You can run Watin tests directly from xUnit in C# too - we do this for our applications. I also believe it is possible to dynamically set the proxy settings in the browser for Watin (and probably the others too).
Alternatively to make HTTP requests to a given address try JMeter.
Slightly offtopic: Having seen a share of custom HTTP proxies, the usual feature their authors forget (and later discover that they need) is the support for the CONNECT method. Without CONNECT your proxy can't be used for TLS/SSL connections. Also, software that tunnels their non-HTTP traffic via the proxy won't work either.
There are two more products to use:
Web Polygraph
Funkload
Both are easy to find via Google. Both perform functional and load testing of web servers/proxies.
When you're using the above, I'd also suggest running one of the latency/packet loss injection tools discussed in Best way to simulate a WAN network. It's regrettably easy to decide that your proxy is stable when you test it in a non-messy environment.
Related
According to my research whilst trying to solve this problem, it turns out that the .Net WebProxy class does not support Socks proxies - a tad annoying. I also can't seem to find any code or information which explains how to implement Socks 4/5 support via a class which can easily be used with HttpWebRequest (the Proxy property, to be exact).
I've found limited information via google on how I could do this. One suggestion involves changing internet explorer proxy settings - something I'd rather not do.
Does anyone know of anything which could do the job or have any suggestions? Any help would be much appreciated.
I tried numerous .Net libraries which claimed to support Socks4/5 but found many of them just did not work or would error trying to connect to proxies I knew were functioning.
I've ended up using Chilkat Software's Sock/SSL component which seems to work well for me even if I do have to manually construct the HTTP requests instead of using HttpWebRequest as I would have liked.
Update note: Chilkat.Http (similar to the HttpWebRequest class) does inherently have support for SOCKS proxies. So don't spend time trying to code your own HTTP requests as I did; just use the Chilkat.Http.SocksHostname, Chilkat.Http.SocksPort and Chilkat.Http.SocksVersion properties.
Changing IE's proxy settings won't help you at all-- the other poster was just observing that it works for IE. Because the .NET Framework doesn't support SOCKS, you'd have to write your own CERN-Proxy to SOCKS-Proxy converter, such that .NET talks to the CERN proxy (the type it supports) and your code converts that to a SOCKS proxy call.
FWIW, this is something I'm presently looking to add to FiddlerCore (www.fiddler2.com/core) because I already have almost all of the code. The only thing I really need is a SOCKSv4a proxy to test against.
Since .NET 6, socks proxies can be used natively with HttpClient. See this issue on GitHub.
Use Privoxy or same to create http proxy gateway to your socks.
Add this to main config to chain Privoxy and socks:
forward-socks5 / proxy_host:port .
And something like that to enable direct access to your local network:
forward 192.168.*.*/ .
forward 10.*.*.*/ .
forward 127.*.*.*/ .
I am working on an media application for which I would like to provide an external API library that would allow another application to communicate with mine an query status information. My application is written in C# and the API DLL will be the same. Initially my thought was to simply use WCF and Named Pipes since it would provide an extremely easy way to code up the whole interface.
However, I realized that doing this would pretty much preclude any other languages or platforms from communicating with the application if I ever wanted to make, for example, an android or Web remote for it.
So, what protocol could I use that would allow a fast and simple interface from within my C# code, but also allow APIs to be written in other platforms.
Basic requirements are:
Local and Remote communication
Low overhead
Procedure Calls
File transfer (to send media)
Pre-Existing C#, open source library would be nice.
I've looked at a lot of the options, used XML-RPC and JSON-RPC before, but would like to know what the community thinks is the best option.
I think using WCF it's the best way to do what you want. It will be simple in maintenance, cover all your requirements and easy to extend. Just don't restrict the access to your API only by net.pipe. I think you should use net.pipe, net.tcp and maybe basic http as primary bindings. I mean several endpoints for each service. So, a client app, no matter what language it is written, will be able to choose what binding to use to access your API server.
For example:
C# client app on the same machine - use net.pipe
PHP client app in web - use basic http
Java client app on another machine - use net.tcp
As an example:
http://www.kevingao.net/wcf-java-interop/java-client-and-wcf-server.html
I have a server client application.
The clients sends the server http posts with info every second or so.
The server is implemented using C#, there server doesn't need to respond in any way to the client.
Whats the easiest and most practical way to get this done? Is there some kind of library that is easy to use that I can import into my project.
Why not just use a regular old web service? It sounds like you have simple functionality that doesn't need to maintain a connection state. With a web service, you can simply expose the methods to your client, accessible via HTTP/S. If you're already using .NET for your client, you can simply add a web reference to your project and have .NET do the heavy lifting for you. There wouldn't be any need to reinvent the wheel.
You can use http.sys to create your own http listener without IIS or additional overhead. Aaron Skonnard has a good article here.
Because of certain limitations of uhttpsharp (specifically no support for POST forms and file uploads and it using threads to process requests), I've made NHttp available at github which supports full request parsing like ASP.net and processes requests using the asynchronous TCP model.
I need to expose our repository which resides in our server machine to clients. The clients should be authenticated, and read write permissions are enabled. We are having doubts regarding which way to go with the implementation:
We already have client based COM layer so we can wrap it with some C# UI.
Server rest services, and then writing rest services based UI in C#/GWT/etc.
Implement WebDav protocol and get free client (windows, total commander, others)
What do you think is the best approach?
I don't know what kind of repository you are talking about, and what your clients need to do with it. But if it's plain reading and writing of files, I'd say WebDAV is the best way to go: It's supported widely across all platforms, has loads of free clients, can be set up on a Windows machine within minutes, supports SSL (I think) and is very easy to use.
If you need to do more fine-grained things like protocol changes, have you considered using source control software like Subversion, Git or Mercurial? They would give great possibilities, but the learning curve for your clients would be very steep. I wouldn't recommend this for a non-techie audience.
WebDAV or SFTP (SSH File Transfer Protocol) server would work. They offer similar functionality, with SFTP being more widespread.
I'm not sure what you have in the way of infrastructure, but I'd suggest putting the server in a DMZ so if anyone breaks in they can't do too much fdamage to the rest of your network.
How are you going to authenticate users? ASP.NET 2.0+ has some useful libraries that provide some excellent out-of-the-box capability fo managing users which integrates with FormsAuthentication; this will gove you options for identity and access management - assuming you write a asp.net front end.
What ever approach you take, I'd suggest PEN testing it - either yourselves or by a third party security specialist.
I want to watch all the HTTP requests going out of a certain application and cancel them if needed.
Is there a way to do this in C#?
If you can touch the system's proxy configuration (which is used by many applications) or, if the app doesn't heed that setting, touch the application's configuration to use a proxy of your choice, you can create a HTTP proxy that would do the job for you.
If you just want to profile, there is a ready made tool that behaves like this and is very nice, Fiddler.
Else you'd have to go deeper into the network stack and implement something like a sniffer/firewall, for instance using WinPcap. That's a lot harder to do.
If you're working with Windows, it is possible to hook the WinInet API calls and do whatever you want with them.
FreeCap (or its commercial version, WideCap) does that: allows you to send TCP traffic through a proxy server. That proxy might then do the filtering (e.g. Fiddler).
I know this brings more stand-alone applications into the system, but it works.