Web applications are very different from traditional desktop applications.

The first obvious difference is that a production-level web application will always involve at least two networked machines. Given the nature of web applications, the networked machines must agree upon a particular wire protocol to determine how to send and receive data. The wire protocol that connects the computers is the Hypertext Transfer Protocol (HTTP). Another aspect of web development that is markedly different from traditional desktop programming is the fact that HTTP is essentially a stateless protocol. As soon as the web server emits a response to the client, everything about the previous interaction is forgotten. This is certainly not the case for a traditional desktop application, where the state of the executable is most often alive until the user shuts down the application. As a web developer, it is up to you take specific steps to remember information (such as items in a shopping cart, credit card numbers, home and work addresses, etc.) about the users who are currently logged on to your site. There are many ways to handle state such as session variables, cookies, and application variables.

A web server is a software product in charge of hosting your web applications, and it typically provides a number of related services such as integrated security, File Transfer Protocol (FTP) support, mail exchange services etc. Internet Information Services (IIS) is Microsofts enterprise level web server product. The role of Web Server are : Receive and process request coming from web browser via HTTP. Sends a response back to the web browser. Closes all connection with the browser. Releases all resources that were involved with the Request.
The Web Browser provides a platform independent means of displaying web pages which are written in HTML. HTML is designed to able render information in any operating system. It can also render Images, Music, Video etc. and also responds to hyperlink to other pages. The role of Web Browser are : Presents Information and collects input from user. Executes client-side scripting.

A html file may contain blocks of script code that will be processed by the requesting browser. There are two major reasons why client-side scripting is used : To validate user input in the browser before posting back to the web server You should always be mindful of ways to minimize travel across the wire (Round trip). One technique that saves round-trips is to use client-side scripting to validate user input before submitting the form data to the web server. If an error is found (such as not supplying data within a required field), you can alert the user to the error without incurring the cost of posting back to the web server. To interact with the Document Object Model (DOM) of the target browser In addition to validating user input, client-side scripts can also be used to interact with the underlying object model (the DOM) of the web browser itself. Most commercial browsers expose a set of objects that can be used to control how the browser should behave. One major problem is the fact that different browsers tend to expose similar, but not identical, object models. Thus, if you emit a block of client-side script code that interacts with the DOM, it may not work identically on all browsers.

A single IIS installation is able to host numerous web applications, each of which resides in a virtual directory. Each virtual directory is mapped to a physical directory on the hard drive. Therefore, if you create a new virtual directory named CarsRUs, the outside world can navigate to this site using a URL such as http://www.CarsRUs.com (assuming your sites IP address has been registered with the world at large). Under the hood, this virtual directory maps to a physical root directory on the web server, such as C:\inetpub\wwwroot\AspNetCarsSite, which contains the content of the CarsRUs web application. If you create ASP.NET web applications using Visual Studio 2008 or latter, you have the option of having the IDE generate a new virtual directory for the current website automatically.

Now that you have configured a directory to host your web application, and you have chosen a web server to serve as the host, you need to create the web application. Web application is simply the set of files that constitute the functionality of the site. To be sure, a vast number of these files will contain codes defined by Hypertext Markup Language (HTML). HTML is a standard markup language used to describe how literal text, images, external links are to be rendered within the client-side browser.
Hyper Text Transfer Protocol (HTTP) is a text based communication protocol that is used to request web pages from web server and send response back to the web browser. HTTP messages are typically sent between the web browser and web server using port 80 (Port 443 when using secure HTTP(HTTPS)).

When a client machine launches a web browser (such as Microsoft Internet Explorer), an HTTP request is made to access a particular resource (typically a web page) on the remote server machine. HTTP is a text-based protocol that is built upon a standard request / response paradigm. For example, if you navigate to http://www.google.co.in, the browser use a web technology termed Domain Name Service (DNS) that converts the registered URL into a four-part, 32-bit numerical value, termed an IP address. At this point, the browser opens a socket connection and sends the HTTP request for processing to the target site. The web server receives the incoming HTTP request in order to format a proper HTTP response. Web programmers may use any number of technologies (CGI, ASP, ASP .NET, JSP, etc.) to dynamically generate the content to be emitted into the HTTP response. At this point, the client-side browser renders the HTML sent from the web server. Following figure shows the basic HTTP request/response cycle.

Client-Side Browser
Display Html Obtained from HTTP Response

Incoming HTTP Request

Web Server
Web Applications Server-Side Resources Such as .aspx, .php,

Outgoing HTTP Response

The HTTP Request/Response Cycle

The server side processing is involved, a typical interactive user session with the web form consists with following steps : 1. The user request a web form from the user. 2. The web server responds back with the requested web form. 3. The user enters the data and submits the form to the Web server. 4. The Web server processes the form and sends back the result to the user. NOTE : In the above step 3 is also referred as Postback Step 3 and step 4 are collectively referred as Round trip.

Now that you have a simple HTML page, you need to examine how to transmit the form data back to the web server for processing. When you build an HTML form, you typically supply an action attribute on the opening <form> tag to specify the recipient of the incoming form data. Possible receivers include mail servers, other HTML files, an Active Server Pages (ASP) file, and so forth.

For this example, youll use a classic ASP file named ClassicAspPage.asp. Update your default.htm file by specifying the following attribute in the opening <form> tag: <form name = "defaultPage" id = "defaultPage" action= "http://localhost/Cars/ClassicAspPage.asp" method= "GET > ... </form> These extra attributes ensure that when the Submit button for this form is clicked, the form data is sent to the ClassicAspPage.asp at the specified URL. When you specify method="GET" as the mode of transmission, the form data is appended to the query string as a set of name/value pairs separated by ampersands: http://localhost/Cars/ClassicAspPage.asp?txtUserName=Andrew&txtPassword=Foo$& btnSubmit= Submit The other method of transmitting form data to the web server is to specify method="POST": In this case, the form data is not appended to the query string, but instead is written to a separate line within the HTTP header. Using POST, the form data is not directly visible to the outside world. More important, POST data does not have a character-length limitation (many browsers have a limit for GET queries). For the time being, make use of HTTP GET to send the form data to the receiving *.asp page. 10