I would like to write a C# app to handle my HTTP (including AJAX requests) rather than go the PHP, PERL or ASP route as I just need to return some standard HTML, albeit obviously, as I want CGI, dynamically generated.
UPDATE: I am not proposing to write my own web server but have the exe hosted by a webserver such as IIS or Apache. Also I dont want to learn and use ASP (I know I can do it much faster, development time, myself in C#) and I just want W3C valid html sent back to the client.
Are there any good reasons for not doing this?
I realise each time a HTTP request is made the exe has to be loaded and run - but surely so does Perl, ASP and PHP? Is there a way to have an exe remain running dealing with all HTTP requests for specific page? (though it feels like I am just writing a mini HTTP server then!)
Are there any good tutorials? I have read this one, but it is bit dated (2005): http://www.codeproject.com/KB/cs/cgi_csharp.aspx
UPDATE2: I dont think speed is going to be a issue anyway (running a small exe without a GUI is almost instantaneous) but if I wanted to be really efficant I could write C# server then the non-static page requests can have a tiny exe written in C which sends the request to the C# server and returns the reply. Couldn't I? :)
There are solutions such as FastCGI, that eliminate the overhead of launching an executable every time you want to process a request. Very few people still use traditional CGI. I don't know if there is a solution compatible with .net.
There is a much better option for .NET, the System.Web.IHttpHandler class.
All you have to do is subclass IHttpHandler, and overload 1 method to process a request. In my opinion it is simpler CGI.
There is a good example on the MSDN Site.
I'd suggest leveraging the HttpListener API for this kind of thing if IIS really doesn't cut it for you.
Related
I would like to make a command line exe application that serves dynamic content via http. However, at least for now, I don't want it to undergo any setup that requires the user to have IIS.
It will not have to serve any heavy loads, just take one request at a time from the local user.
Reasons for wanting this:
I want it to look nice, and I have more experience in html/css than in thick client display frameworks, and I don't have a lot of time to devote to this project
I want people to be able to run it without knowing how to configure IIS
If enough people find it useful, I want to be able to easily convert it to a full-fledged web application later
Are there established methods for making this happen aside from setting up a System.Net.WebRequest listenier and writing parsing code?
I am a fairly experienced (mid-level) developer that has spent quite a bit of time working on the backend of many web-based projects. Rarely getting into the ui/display aspects. However, I am now a lead on a project that is in the process of taking an api to a service architecture using an asp.net mvc rest architecture. I have not problem doing this and have written many of these services already. however, I find myself wondering about the parts "hidden" by IIS/WAS and MVC.
What I am hoping to find is a good tutorial that explains what happens from the point a web page (or webservice) is requested to the point it is received by the web page or application takes over. I want to know how IIS (or any other webserver) knows what to do with a request. (One thought was a tutorial for developing your own webserver.)
I realize this is probably a large subject that I don't necessarily need to know all of to be an "expert" web developer. However, it certainly can't hurt and I also am experienced enough to separate the wheat from the chaff.
Thanks in advance!
I would recommend you to download and install Fiddler. Then run it and look at all the traffic that's being exchanged over the wire. It will allow you to see the actual HTTP requests and responses and their exact contents. This will allow you to gather deeper understanding at what happens at the lower network levels which is extremely useful to know when developing a web application.
I have already made an HTTP web server using Java only, able to run Java application at server side. I used the HTTP 1.1 specification. But you may find easier to start with a tutorial about HTTP before reading the specification.
If you are developing a RESTful web service and want to learn more about HTTP I strongly suggest reading RESTful Web Services Cookbook: Solutions for Improving Scalability and Simplicity.
I am looking for a basic method of retrieving the URLs (HTTP) being requested by any other application on the local computer. Basically I only want a textbox in this app that lists the URLs as they are being requested. I am only interested in the url, nothing more. What would be the simplest way of accomplishing this? I would rather not require the app to run in admin-mode and I don't want to use external libraries such as Fiddler or similar.
Update:
I noticed Fiddler was developed with .NET so its obviously possible to do what I want using only .NET. Im sifting through the code of Fiddler using Reflector but its not giving me much. I dont know where to start. But as I said, Im only interesting in outgoing traffic on HTTP and only the specific url of the request. This cant be so hard so fix with .NET only?
Update:
The key seem to be to use a Socket from the System.Net.Sockets namespace. Im not exactly sure how to use it correctly yet but Im following some other examples and it seem to be pretty easy.
I know you said don't want to use external libraries, but there is no simple way of intercepting the URLs requested by other processes without using other libraries.
In case you are interested, I used PCap .NET some time ago. It was really easy to use, and in few hours I had an application listening for HTTP communications between third party applications, and automating one of them depending on the captured info.
Maybe a strange and green question, but
Is there anything C# can't do what javascript can...
And considering JQuery?
except for the fact that one is clientside, and the other serverside?
Or am I asking a very stupid question now?
EDIT:
to be more specific: I mean web programming, and indeed maybe a more useful question is:
> What can I do client side that I can't do server side, and vice versa?
> Are there more reasons to use both languages if you keep "server/clientside" out of scope?
> some developers avoid javascript. why?
What can I do client side that I can't
do server side, and vice versa?
Client-side: Javascript runs in most browsers without a plugin. C# requires a browser plugin like Silverlight. Even though it's running on a client machine, Javascript can't read and write files there. C# in Silverlight may be able to read and write files depending on the Silverlight version and what the client allows. Both Javascript and C#/Silverlight can talk to remote servers.
Server-side: since you control this machine, you can do whatever you want - read files, write files, talk directly to databases, etc. Keep in mind there's nothing stopping you from running Javascript server-side. Check out node.js.
Are there more reasons to use both
languages if you keep
"server/clientside" out of scope?
I wouldn't leave the execution environment out of your analysis. If you absolutely need client-side interaction and can't guarantee C# will execute on the client, C# isn't practical. Likewise, if your company runs Windows servers and doesn't want to install Javascript runtimes/compilers, you won't be able to use Javascript on the server.
some developers avoid javascript. why?
Problems with Javascript in a browser are absolutely awful to debug. You're running on a machine that's out of your control - the user may be running an obscure or ancient browser, they may be using anti-virus software that mucks with your Javascript, their browser plugins might muck with your Javascript. It's hard.
This is the cost of doing business on someone else's machine, however. If it was easy, a beautiful client-side experience would mean less. Solving hard problems isn't for everyone but it sure is appreciated when it's done well.
I take it your real question is, if c# can do everything, why should you use javascript at all? The answer here is performance, both perceived and real. The trick here is that to use c# to do the DOM manipulation normally associated with javascript, a browser has to post back an extra http request to the server and tell the c# code what to do. Lets talk about those extra requests. Spread around a lot of users, they add up very quickly and play havoc on your server infrastructure. The "real" performance issue is that now a lot of work has to happen on your server(s), instead of in your users' browsers. The "perceived" performance issues is that, even if you have the server resources to easily handle all the additional http requests, you user now has to spend extra time waiting for latency incurred by those http round trips.
Both languages rely heavily on API's that were designed for different domains.
JavaScript was originally intended to run inside of a browser, so it makes heavy use of DOM API's as well as other in-browser operations such as AJAX. C# probably does not have good support for such API's as it was never intended to be executed directly inside a browser - although Silverlight may provide such operations since it is (in a way) a "C# Sandbox" inside of a browser.
On the other hand, C# is a general-purpose language that was designed to build basically any application, from server-side engines to client applications to services - you get the idea...
I have seen a C# project where javascript is embedded and can execute javascript within a C# code. Have a look here on CodeProject to see how that is achieved.
Technically, no.
You could even use Javascript server-side if you wanted (or client-side C# via different mechanisms).
They're really just two ways of getting the same job done.
Is there any way to have apache "pass" the request it takes to a c# "application" to handle, allowing it to return specific content. I want to handle an intense amount of asynchronous calls to apache via javascript and have these calls routed through c# (much the way asp.net does). Has anyone successfully done this before? Any idea where to start looking?
Update:
Some more information. I want to be able to handle thousands of concurrent asynchronous requests as fast as can possibly occur writing the interpreting agent in some kind of threaded c# application. I could be wrong, but I dont think that iis with asp.net is tailored for this sort of thing (a proof of concept would be great).
I feel that going with something like apache would be better suited. If that means going from something else to c# first is fine I guess, but I would like to be more direct.
Apache actually supports running C# libraries using mod mono. Also, you could use CURL to send a web request to C# running on IIS. Another way would be to open a server socket directly in C#, and have apache (via php, python, or some other scripting language) connect to you C# application to handle the request. I think you need to be more specific about what exactly you are trying to accomplish.
with apache2, you could run mod_aspdotnet
or if it suits you, run some urls in proxy mode (pass them to another asp.net server), using mod_proxy
or Kibbee's excellent solution