Requests and Responses in Web Browsers and Web Servers

The growth of the concept, "Internet Of Things" has made a significant difference in our everyday life. Most of our daily activities today involve a connection to the web. We make calls, text our friends and so on using the internet. Hence we can roar here on the point that the World Wide Web (we will call this the web throughout this article) is growing. The RSS feeds that were working a couple of months ago in Chrome stopped working now since Google Chrome developers discarded it. With new products and new items engulfing the web every day, the existing products should be concerned about its survival. As a website developer, here, let me write something based on my understanding of how our web browsers and web servers request and respond to our web pages.

Here we need to understand three major terms as pre-requisites:

  1. Client: The one that sends the request (a Web Browser).
  2. Server: The one that sends a response.
  3. Protocol: is nothing but a set of rules that allow you to communicate between a client and a server. We use a protocol called English to communicate between two people. In the same way the internet uses protocols to transfer information between a client and server. The most commonly used protocol is the HyperText Transfer Protocol (HTTP) for websites. HTTP allows you to transfer files in the form of text between client and server.

Some software or a person types in the URL of a website into a browser (the client) and that requests a page from the server. The browser here acts as the client and sends a request to the remote server. The server processes the request and sends a response using a protocol (normally HTTP). The request is sent from the browser to the web server. The term "server" technically means nothing but a special piece of software running in a remote computer to access resources (pages, images, and so on). In terms of Microsoft technologies we have IIS to process our requests. To send and receive requests and responses from the client and server we need to establish a connection. This is done using protocols. The most commonly used protocol is HTTP. Digging in deeper into HTTP gives you the conclusion that it is connectionless. The word connectionless means that the server does not know whether the client is ready to receive the response or the client does not know whether the server is ready to accept a request. That is why HTTP is built on top of TCP/IP. TCP/IP helps us to establish the connection and the transfer happens as text between the client and server. So, here starts the topic!

You are sitting in front of your desktop/laptop/tablet/smartphone and so on. The moment you type in the URL for the page, the browser recognises it as a request. The request is sent to the web server using HTTP. The request is broken into the three different parts 1) the protocol, 2) the server name and 3) the file extension. Let me say: http://www.csharpcorner.com/index.aspx will be split into the HTTP protocol, the server name, www.csharpcorner.com and the file extension, index.aspx. The server name is mapped into an equivalent IP address by means of a domain naming server (DNS). This IP address is used to connect to the web server. The connection will be established at port 80 by default.

The request reaches the web server. In our case it is IIS. So far, the site name is converted into an IP address and has reached the proper server. When we install ASP.NET in our servers the script map is automatically updated to the corresponding ISAPI extensions to process the request. The .aspx extension will be updated to aspnet_isapi.dll and can be requested using aspnet_regiis. When a request comes to IIS, it creates/runs a worker process (w3wp.exe) if not running. Aspnet_regiis.dll is hosted in the w3wp.exe processes. If the file extension matches the extensions supported by IIS, the request is passed to the .Net runtime. Here the application manager class creates an Application Domain. Inside the Application Domain's hosting environment an object is instantiated to created objects such as httpcontext, httpresponse and httprequest. Once all the core objects are created, the HttpApplication class is instantiated. Here starts the life cycle. If the global.asax file is present, it will be executed first and the page life cycles will be executed.

The following are the page life cycle events (please look at the MSDN for the proper events).

  1. PreInit: During this event, if not a PostBack, creation or re-creation of dynamic controls, master pages, themes will be set dynamically. The profile property values will also be set.

  2. Init: During this phase, the controls will be initialized and page properties will be set.

  3. InitComplete: This indicates that all the initialization is complete.

  4. PreLoad: Loads viewstate for the page.

  5. Load: During this phase the load events are raised and the onLoad() methods will be called.

  6. Control events: All the control events like button click are handled here.

  7. PreRender: Occurs for each control on the page.

  8. SaveStateComplete: Changes to the viewstate are complete.

  9. Render: During this phase, the page is rendered.

  10. Unload: Closing of the db connection occurs here.

After all these processes, the contents are parsed in the form of HTML and rendered by the user agent, say the browser.

There is no single official documentation in MSDN to cover both the page and application life cycles and this articles combines it a bit well. Refer to the MSDN (msdn.microsoft.com) for more information.