If you are new to web development and choose ASP.NET Web Forms as your starting point, you may be forgiven for not understanding how ASP.NET works, and what its role is. This article covers the basics which should help you discover your limits.
ASP.NET Web Forms is a great paradigm in my view, but it has a lot to answer for. One of the main things it encourages is Windows Forms developers to come to the dark side of web application development. Web application development is totally unlike Windows Forms, but with a drag and drop RAD environment, and an event-driven model, Web Forms hides a lot of basic HTTP plumbing from the uninformed. And what happens is that things don't work as they expect. This question is typical of a large number of similar ones I have seen, and in fact finally prompted this write-up.
To start with, here's an overview of how web applications work. Consider a restaurant. You walk in, are greeted by the maitre d' and get seated. You give the waiter your order and he disappears. A while later, he returns with your meal. You don't know where your meal came from or how it was prepared. You don't care, so long as it is edible.
While he was gone, and completely out of your sight, the waiter passed your food order to the chef in the kitchen. The chef sprang into action and prepared the order. A part of the order may have been fulfilled without any real work, such as a plain bread roll. Or the order may have needed special processing, such as frying or grilling. These tasks would have been passed to specialists within the kitchen to manage. Once complete, the order is passed it to the waiter for delivery. The chef doesn't know what happened to the food that was prepared or where it went. He doesn't care (so long as he receives no complaints).
Web applications are like this. For the diner, read client. The chef is the web server, and the waiter is the transport mechanism for the Request (the meal order) and the Response (the cooked meal). The client makes a request which TCP conveys to the correct web server, given the URL of the request. The server examines the request and decides if it can be fulfilled without further ado, or whether some processing is required. The part of the request which is examined primarily is the file extension. These may have been registered with the server and mapped to special processors, such as ASP.NET or PHP. Or, in the case of an image or html file, there is no need for processing. The raw content of the file is served as a response.
A palatable meal in the case of a web response is generally html. If the processors are called into play, instead of grilling or frying the ingredients in preparation for the response, they execute any related or embedded code logic, which is responsible for generating html dynamically. However, once the response has been sent, the web server doesn't know what happened to it or care. Like the waiter, it sits back on its chair, and waits for the next request. It has no persistent connection with the client.
What you can't do as a web developer
- Force a page to print without invoking the Print dialogue box
- Select a printer
- Bookmark a site
- Remove an item from the browser's History
- Remove an item from the brower cache
- Read cookies set by other sites
- Access the client's file system
- Force a user to upload a file
- Get the size of a file prior to upload
- Get the dimensions of an image prior to upload
- Determine the file type prior to upload
- Access a database on the client machine or the web server
- Invoke Word, Excel, Outlook etc
- Force the user to download a file or plugin without a prompt
- Get the filepath of an upload
- Adjust their page margins for printing
- Change their default printer
- Disable the back/forward buttons
- Read a key from their registry
- Change their security settings
- Automatically run an EXE on the client
- Force them to enable cookies
- Access a page on another site
So how can you perform these actions if the business requirements demand them? There are a number of options. Traditionally, developers created ActiveX controls that the user must agree to download and install. More information can be found here, but they are limited in that they can only work with Internet Explorer. This is usually all that's needed for corporate Intranet sites, although if IT security teams forbid the installation of plugins or ActiveX, you have a problem.
A second option is to use Flash or SilverLight. Like ActiveX controls, these technologies can be granted specific permissions to access the local file system as well as network locations. However, unlike ActiveX controls, they are not restricted to the Internet Explorer browser as a host. There are plugins for a number of different browsers for both types of application. A final option is to simply create an exe that the user chooses to download and install like any other application.