How Web Applications Work

The same core functionality of the browser that fed the Web's phenomenal growth across platform and operating systems also proved to be an inherent weakness. After downloading the code for an HTML page and all of its parts, browsers render the page on the client side. Client-side rendering gave a universality to Web browsing at the cost of sacrificing server-side power and connectivity to data sources and other server-related functions, such as email. The rise of application server technology combined the universal access of the client-side browser with the far-ranging power of server-side programming.

All application server technology whether it's Active Server Pages (ASP), ASP.NET, ColdFusion, PHP: Hypertext Preprocessor (often just called PHP), or JavaServer Pages (JSP) works essentially the same way [c1-1]:

Figure c1-1.

1. Someone browsing the Web selects a link. This action sends a request for that particular URL from the server that is hosting the site.

2. When the host server receives the request, if the page has an .htm or .html extension (or other recognized HTML extensions), the page is sent directly to the client.

3. If the page has another file extension such as .asp or .cfm the host server forwards the requested page (which is a mix of server-side and HTML code) to the corresponding application server.

4. The application server accepts the page and executes the server-side code, outputting the results as HTML and integrating them into the other code of the page.

5. The page is returned to the host server completely stripped of server-side code and consisting only of HTML.

6. The host server sends the HTML-only page back to the requesting browser.

This process explains why you can never see the server-side source code for an ASP or ColdFusion page you're browsing by simply viewing the source code of the page.