How the ASP.NET Web Server Works

The easiest job a web server has is to provide ordinary HTML pages. When you request such a file, the web server simply reads it off the hard drive (or retrieves it from an in-memory cache) and sends the complete document to the browser, which displays it. In this case, the web server is just a glorified file server that waits for network requests and dishes out the corresponding documents.

When you use a web server in conjunction with dynamic content such as an ASP.NET page, something more interesting takes place. On its own, the web server has no idea how to process ASP.NET tags or run C# code. However, it’s able to enlist the help of the ASP.NET engine to perform all the heavy lifting. Figure diagrams how this process works for ASP and ASP.NET pages. For example, when you request the page Default.aspx, the web server sends the request over to the ASP.NET engine (which starts automatically if needed). The ASP.NET engine loads the requested page, runs the code it contains, and then creates the final HTML document, which it passes back to IIS. IIS then sends the HTML document to the client.

At this point, you might be wondering how the web server knows when it needs to get the ASP or ASP.NET engine involved. Essentially, the web server looks at the file extension of the requested page (such as .asp or .aspx) to determine the type of content. The web server compares this extension against a list to determine what program owns this file type. For example, the web server’s list indicates that the .aspx extension is owned by the aspnet_isapi.dll component in the c:\Windows\Microsoft.NET\Framework\v2.0.50727 directory. The aspnet_isapi.dll component is known as an ISAPI extension, because it uses the ISAPI (Internet Server API) model to plug into the web server.

All web servers perform the same task as that shown in Figure. However, when you run an ASP.NET application in Visual Studio, you don’t need to worry about deployment and file type registration. That’s because Visual Studio includes a built-in web server. It receives the requests for the pages in your web application and then runs the corresponding code. This test web server has a significant limitation—it only accepts requests from the local computer. In other words, there’s no way for other people on other computers to access your website.

To run your web application outside the development environment, you need a more powerful web server. The web server software runs continuously on your computer (or, more likely, a dedicated web server computer). This means it’s ready to handle HTTP requests at any time and provide your pages to clients who connect from the same network or over the Internet. 

On Microsoft Windows operating systems, the web server you’ll use is IIS. In most cases, you won’t be developing on the same computer you use to host your website. If you do, you will hamper the performance of your web server by tying it up with development work. You will also frustrate clients if a buggy test application crashes the computer and leaves the website unavailable, or if you accidentally overwrite the deployed web application with a work in progress. Generally, you’ll perfect your web application on another computer and then copy all the files to the web server.