How a Web Server Works:

Web server serves static and dynamic content to a Web browser (such as Internet Explorer, Firefox, Netscape Navigator etc.) at a basic level. This means that the Web server receives a request for a Web page such as:

and maps that Uniform Resource Locator (URL) to a local file on the host server. In this case, the file:


is somewhere on the host file system. The server then loads this file from disk and serves it out across the network to the user’s Web browser. This entire exchange is mediated by the browser and server talking to each other using Hypertext Transfer Protocol (HTTP). The simplified workflow is shown in the following Figure.


Simplified flow of the browser and web server.


Because this simple arrangement, which allows the serving of static content such as HyperText Markup Language (HTML) and image files to a Web browser was the initial concept behind what we now call the World Wide Web.

The most important expansion on this was the concept of dynamic content (i.e., Web pages created in response to a user’s input, whether directly or indirectly). The oldest and mostly used standard for doing this is Common Gateway Interface (CGI). Other newer CGI based are Microsoft ASP (Active Server Page), JSP (Java Server Page), Perl and php.  This is a pretty meaningless name, but it basically defines how a Web server should run programs locally and transmit their output through the Web server to the user’s Web browser that is requesting the dynamic content.

For all intents and purposes the user’s Web browser never really has to know that the content is dynamic because CGI is basically a Web server extension protocol. The figure below shows what happens when a browser requests a page dynamically generated from a CGI program.

Web server, browser and CGI program.


The second important advance, and the one that makes e-commerce possible, was the introduction of Secure Hypertext Transfer Protocol (S-HTTP), Secure Socket Layer (SSL) and HTTP/TLS (HTTP over TLS). This protocol allows secure communication to go on between the browser and Web server. This means that it is safe for user and server to transmit sensitive data to each another across what might be considered an insecure network. What happens when the data arrives at either end is another matter, however, and should not be ignored.

The simplicity of the above arrangements is deceptive, and underestimating its complexities often leads to bad decisions being made about the design of a Web-hosting infrastructure. It is too easy to focus on the design of the Web pages themselves and the technologies used to create dynamic content, such as Java, Javascript, Perl, PHP and ASP, and to subsequently miss the fact that each of these technologies can be aided, or hindered, by the platform on which they are to be run, the Web server itself.

HTTP Protocol

HTTP is the protocol that allows Web browsers and servers to communicate. It forms the basis of what a Web server must do to perform its most basic operations. HTTP started out as a very simple protocol, and even though it has had numerous enhancements, it is still relatively simple. As with other standard Internet protocols, control information is passed as plain text via a TCP (Transmission Control Protocol) connection.

IIS Architecture

IIS has two main layers – Kernel Mode and User Mode. The Kernel Mode contains the HTTP.SYS and User Mode contains WAS and W3 service.


The above diagrams shows the flow of an HTTP request in process. The request-processing flow is described as:

  1. An HTTP request first goes to HTTP.sys and now, HTTP.SYS is responsible for passing the request to a particular application pool.
  2. HTTP.sys contacts to WAS and WAS requests configuration information from the xml file.
  3. The configuration information is sent to WWW service receives.
  4. The WWW service uses the configuration information to configure HTTP.sys.
  5. Configured HTTP.sys contacts to WAS and now, WAS starts a worker process for the application pool to which the request was made.
  6. The worker process processes the request and returns a response to HTTP.sys. The request is passed through an ordered series of module in the processing pipeline.

Role of HTTP.sys in IIS

HTTP.SYS is the part of kernel mode of IIS. Every client request is passes through the kernel mode, Http.sys then makes a queue for each and individual application pool based on the request. Whenever we create any application pool IIS automatically registers the pool with HTTP.sys to identify the particular during request processing. It provides the following services in IIS:

  1. Routing HTTP requests to the correct request queue.
  2. Caching of responses in kernel mode.
  3. Performing all text-based logging for the WWW service.
  4. Implementing quality of service functionality, which includes connection limits, connection timeouts, queue-length limits, and bandwidth throttling.

ISAPI Filter

ISAPI filters are DLL files that can be used to modify and enhance the functionality provided by IIS. ISAPI filters always run on an IIS server, filtering every request until they find one they need to process.

ISAPI filters can be registered with IIS to modify the behavior of a server. It can perform the following tasks:

  1. Change request data (URLs or headers) sent by the client
  2. Control which physical file gets mapped to the URL
  3. Control the user name and password used with anonymous or basic authentication
  4. Modify or analyze a request after authentication is complete
  5. Modify a response going back to the client
  6. Run processing when a request is complete
  7. Run processing when a connection with the client is closed
  8. Perform special logging or traffic analysis.
  9. Handle encryption and compression.

Different Security Settings Available in IIS

IIS provides a variety of authentication schemes:

  1. Anonymous (enabled by default)
  2. Basic
  3. Digest
  4. Integrated Windows authentication (enabled by default)
  5. Client Certificate Mapping