17. Web Servers (Apache and IIS)
Stop abusing my verses, or publish some of your own.
—Martial
There are three difficulties in authorship: to write anything worth the publishing, to find honest men to publish it, and to get sensible men to read it.
—Charles Caleb Colton
When your Daemon is in charge, do not try to think consciously. Drift, wait and obey.
—Rudyard Kipling
Objectives
In this chapter you’ll:
• Learn about a web server’s functionality.
• Install Apache HTTP Server and Microsoft IIS Express.
• Test the book’s examples using Apache and IIS Express.
17.3 Multitier Application Architecture
17.4 Client-Side Scripting versus Server-Side Scripting
17.6 Apache, MySQL and PHP Installation
17.6.4 Running the Examples Using Apache HTTP Server
17.7 Microsoft IIS Express and WebMatrix
17.7.1 Installing and Running IIS Express
17.7.2 Installing and Running WebMatrix
17.7.3 Running the Client-Side Examples Using IIS Express
17.7.4 Running the PHP Examples Using IIS Express
17.1. Introduction
In this chapter, we discuss the specialized software—called a web server—that responds to client requests (typically from a web browser) by providing resources such as XHTML documents. For example, when users enter a Uniform Resource Locator (URL) address, such as www.deitel.com, into a web browser, they’re requesting a specific document from a web server. The web server maps the URL to a resource on the server (or to a file on the server’s network) and returns the requested resource to the client. During this interaction, the web server and the client communicate using the platform-independent Hypertext Transfer Protocol (HTTP), a protocol for transferring requests and files over the Internet or a local intranet.
We also discuss two web servers—the open source Apache HTTP Server and Microsoft’s Internet Information Services Express (IIS Express)—that you can install on your own computer for testing your web pages and web applications.
Because this chapter is essentially a concise series of installation instructions to prepare you for the server-side chapters of the book, it does not include a summary or exercises.
17.2. HTTP Transactions
In this section, we discuss the fundamentals of web-based interactions between a client web browser and a web server. In its simplest form, a web page is nothing more than an HTML (HyperText Markup Language) document (with the extension .html or .htm) that describes to a web browser the document’s content and structure.
HTML documents normally contain hyperlinks that link to different pages or to other parts of the same page. When the user clicks a hyperlink, the requested web page loads into the user’s web browser. Similarly, the user can type the address of a page into the browser’s address field.
URIs and URLs
URIs (Uniform Resource Identifiers) identify resources on the Internet. URIs that start with http:// are called URLs (Uniform Resource Locators). Common URLs refer to files, directories or server-side code that performs tasks such as database lookups, Internet searches and business-application processing. If you know the URL of a publicly available resource anywhere on the web, you can enter that URL into a web browser’s address field and the browser can access that resource.
Parts of a URL
A URL contains information that directs a browser to the resource that the user wishes to access. Web servers make such resources available to web clients.
Let’s examine the components of the URL
http://www.deitel.com/books/downloads.html
The text http:// indicates that the HyperText Transfer Protocol (HTTP) should be used to obtain the resource. Next in the URL is the server’s fully qualified hostname (for example, www.deitel.com)—the name of the web-server computer on which the resource resides. This computer is referred to as the host, because it houses and maintains resources. The hostname www.deitel.com is translated into an IP (Internet Protocol) address—a numerical value that uniquely identifies the server on the Internet. An Internet Domain Name System (DNS) server maintains a database of hostnames and their corresponding IP addresses and performs the translations automatically.
The remainder of the URL (/books/downloads.html) specifies the resource’s location (/books) and name (downloads.html) on the web server. The location could represent an actual directory on the web server’s file system. For security reasons, however, the location is typically a virtual directory. The web server translates the virtual directory into a real location on the server, thus hiding the resource’s true location.
Making a Request and Receiving a Response
When given a web page URL, a web browser uses HTTP to request the web page found at that address. Figure 17.1 shows a web browser sending a request to a web server.
Fig. 17.1. Client interacting with web server. Step 1: The GET request.
In Fig. 17.1, the web browser sends an HTTP request to the server. The request (in its simplest form) is
GET /books/downloads.html HTTP/1.1
The word GET is an HTTP method indicating that the client wishes to obtain a resource from the server. The remainder of the request provides the path name of the resource (e.g., an HTML5 document) and the protocol’s name and version number (HTTP/1.1). The client’s request also contains some required and optional headers.
Any server that understands HTTP (version 1.1) can translate this request and respond appropriately. Figure 17.2 shows the web server responding to a request.
Fig. 17.2. Client interacting with web server. Step 2: The HTTP response.
The server first sends a line of text that indicates the HTTP version, followed by a numeric code and a phrase describing the status of the transaction. For example,
HTTP/1.1 200 OK
indicates success, whereas
HTTP/1.1 404 Not found
informs the client that the web server could not locate the requested resource. A complete list of numeric codes indicating the status of an HTTP transaction can be found at www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.
HTTP Headers
Next, the server sends one or more HTTP headers, which provide additional information about the data that will be sent. In this case, the server is sending an HTML5 text document, so one HTTP header for this example would read:
Content-type: text/html
The information provided in this header specifies the Multipurpose Internet Mail Extensions (MIME) type of the content that the server is transmitting to the browser. The MIME standard specifies data formats, which programs can use to interpret data correctly. For example, the MIME type text/plain indicates that the sent information is text that can be displayed directly. Similarly, the MIME type image/jpeg indicates that the content is a JPEG image. When the browser receives this MIME type, it attempts to display the image.
The header or set of headers is followed by a blank line, which indicates to the client browser that the server is finished sending HTTP headers. Finally, the server sends the contents of the requested document (downloads.html). The client-side browser then renders (or displays) the document, which may involve additional HTTP requests to obtain associated CSS and images.
HTTP get and post Requests
The two most common HTTP request types (also known as request methods) are get and post. A get request typically gets (or retrieves) information from a server, such as an HTML document, an image or search results based on a user-submitted search term. A post request typically posts (or sends) data to a server. Common uses of post requests are to send form data or documents to a server.
An HTTP request often posts data to a server-side form handler that processes the data. For example, when a user performs a search or participates in a web-based survey, the web server receives the information specified in the HTML form as part of the request. Get requests and post requests can both be used to send data to a web server, but each request type sends the information differently.
A get request appends data to the URL, e.g., www.google.com/search?q=deitel. In this case search is the name of Google’s server-side form handler, q is the name of a variable in Google’s search form and deitel is the search term. The ? in the preceding URL separates the query string from the rest of the URL in a request. A name/value pair is passed to the server with the name and the value separated by an equals sign (=). If more than one name/value pair is submitted, each pair is separated by an ampersand (&). The server uses data passed in a query string to retrieve an appropriate resource from the server. The server then sends a response to the client. A get request may be initiated by submitting an HTML form whose method attribute is set to "get", or by typing the URL (possibly containing a query string) directly into the browser’s address bar. We discuss HTML forms in Chapters 2–3.
A post request sends form data as part of the HTTP message, not as part of the URL. A get request typically limits the query string (i.e., everything to the right of the ?) to a specific number of characters, so it’s often necessary to send large amounts of information using the post method. The post method is also sometimes preferred because it hides the submitted data from the user by embedding it in an HTTP message. If a form submits several hidden input values along with user-submitted data, the post method might generate a URL like www.searchengine.com/search. The form data still reaches the server and is processed in a similar fashion to a get request, but the user does not see the exact information sent.
Software Engineering Observation 17.1
The data sent in a post request is not part of the URL, and the user can’t see the data by default. However, tools are available that expose this data, so you should not assume that the data is secure just because a post request is used.
Client-Side Caching
Browsers often cache (save on disk) recently viewed web pages for quick reloading. If there are no changes between the version stored in the cache and the current version on the web, this speeds up your browsing experience. An HTTP response can indicate the length of time for which the content remains “fresh.” If this amount of time has not been reached, the browser can avoid another request to the server. If not, the browser loads the document from the cache. Similarly, there’s also the “not modified” HTTP response, indicating that the file content has not changed since it was last requested (which is information that’s send in the request). Browsers typically do not cache the server’s response to a post request, because the next post might not return the same result. For example, in a survey, many users could visit the same web page and answer a question. The survey results could then be displayed for the user. Each new answer would change the survey results.
17.3. Multitier Application Architecture
Web-based applications are often multitier applications (sometimes referred to as n-tier applications) that divide functionality into separate tiers (i.e., logical groupings of functionality). Although tiers can be located on the same computer, the tiers of web-based applications often reside on separate computers. Figure 17.3 presents the basic structure of a three-tier web-based application.
Fig. 17.3. Three-tier architecture.
The bottom tier (also called the data tier or the information tier) maintains the application’s data. This tier typically stores data in a relational database management system (RDBMS). We discuss RDBMSs in Chapter 18. For example, Amazon might have an inventory information database containing product descriptions, prices and quantities in stock. Another database might contain customer information, such as user names, billing addresses and credit card numbers. These may reside on one or more computers, which together comprise the application’s data.
The middle tier implements business logic, controller logic and presentation logic to control interactions between the application’s clients and its data. The middle tier acts as an intermediary between data in the information tier and the application’s clients. The middle-tier controller logic processes client requests (such as requests to view a product catalog) and retrieves data from the database. The middle-tier presentation logic then processes data from the information tier and presents the content to the client. Web applications typically present data to clients as HTML documents.
Business logic in the middle tier enforces business rules and ensures that data is reliable before the application updates a database or presents data to users. Business rules dictate how clients access data and how applications process data. For example, a business rule in the middle tier of a retail store’s web-based application might ensure that all product quantities remain positive. A client request to set a negative quantity in the bottom tier’s product information database would be rejected by the middle tier’s business logic.
The top tier, or client tier, is the application’s user interface, which gathers input and displays output. Users interact directly with the application through the user interface, which is typically a web browser or a mobile device. In response to user actions (e.g., clicking a hyperlink), the client tier interacts with the middle tier to make requests and to retrieve data from the information tier. The client tier then displays the data retrieved for the user.
17.4. Client-Side Scripting versus Server-Side Scripting
Client-side scripting with JavaScript can be used to validate user input, to interact with the browser, to enhance web pages, and to add client/server communication between a browser and a web server.
Client-side scripting does have limitations, such as browser dependency; the browser or scripting host must support the scripting language and capabilities. Scripts are restricted from arbitrarily accessing the local hardware and file system for security reasons. Another issue is that client-side scripts can be viewed by the client using the browser’s source-viewing capability. Sensitive information, such as passwords or other personally identifiable data, should not be on the client. All client-side data validation should be mirrored on the server. Also, placing certain operations in JavaScript on the client can open web applications to security issues.
Programmers have more flexibility with server-side scripts, which often generate custom responses for clients. For example, a client might connect to an airline’s web server and request a list of flights from Boston to San Francisco between April 19 and May 5. The server queries the database, dynamically generates an HTML document containing the flight list and sends the document to the client. This technology allows clients to obtain the most current flight information from the database by connecting to an airline’s web server.
Server-side scripting languages have a wider range of programmatic capabilities than their client-side equivalents. Server-side scripts also have access to server-side software that extends server functionality—Microsoft web servers use ISAPI (Internet Server Application Program Interface) extensions and Apache HTTP Servers use modules. Components and modules range from programming-language support to counting the number of web-page hits. We discuss some of these components and modules in subsequent chapters.
17.5. Accessing Web Servers
To request documents from web servers, users must know the hostnames on which the web server software resides. Users can request documents from local web servers (i.e., ones residing on users’ machines) or remote web servers (i.e., ones residing on different machines).
Local web servers can be accessed through your computer’s name or through the name localhost—a hostname that references the local machine and normally translates to the IP address 127.0.0.1 (known as the loopback address). We sometimes use localhost in this book for demonstration purposes. To display the machine name in Windows, Mac OS X or Linux, run the hostname command in a command prompt or terminal window.
A remote web server referenced by a fully qualified hostname or an IP address can also serve documents. In the URL http://www.deitel.com/books/downloads.html, the middle portion, www.deitel.com, is the server’s fully qualified hostname.
17.6. Apache, MySQL and PHP Installation
This section shows how to install the software you need for running web apps using PHP. The Apache HTTP Server, maintained by the Apache Software Foundation, is the most popular web server in use today because of its stability, efficiency, portability, security and small size. It’s open source software that runs on Linux, Mac OS X, Windows and numerous other platforms. MySQL (discussed in more detail in Section 18.5) is the most popular open-source database management system. It, too, runs on Linux, Mac OS X and Windows. PHP (Chapter 19) is the most popular server-side scripting language for creating dynamic, data-driven web applications.
The Apache HTTP Server, MySQL database server and PHP can each be downloaded and installed separately, but this also requires additional configuration on your part. There are many integrated installers that install and configure the Apache HTTP Server, MySQL database server and PHP for you on various operating-system platforms. For simplicity, we’ll use the XAMPP integrated installer provided by the Apache Friends website (www.apachefriends.org).
17.6.1. XAMPP Installation
The XAMPP integrated installer for Apache, MySQL and PHP is available for Windows, Mac OS X and Linux. Chapters 18 and 19 assume that you’ve used the XAMPP installer to set up the software. Go to
http://www.apachefriends.org/en/xampp.html
then choose the installer for your platform. Carefully follow the provided installation instructions and be sure to read the entire installation page for your platform! We assume in Chapters 18 and 19 that you used the default installation options here.
Microsoft Web Platform Installer
If you’d prefer to use PHP with Microsoft’s IIS Express and SQL Server Express, you can use their Web Platform Installer to set up and configure PHP:
http://www.microsoft.com/web/platform/phponwindows.aspx
Please note, however, that Chapter 19 assumes you’re using PHP with MySQL and the Apache HTTP Server.
17.6.2. Running XAMPP
Once you’ve installed XAMPP, you can start the Apache and MySQL servers for each platform as described below.
Windows
Go to your c:xampp folder (or the folder in which you installed XAMPP) and double click xampp_start.exe. If you need to stop the servers (e.g., so you can shut down your computer), use xampp_stop.exe in the same folder.
Mac OS X
Go to your Applications folder (or the folder in which you installed XAMPP), then open the XAMPP folder and run XAMP Control.app. Click the Start buttons in the control panel to start the servers. If you need to stop the servers (e.g., so you can shut down your computer), you can stop them by clicking the Stop buttons.
Linux
Open a shell and enter the command
/opt/lampp/lampp start
If you need to stop the servers (e.g., so you can shut down your computer), open a shell and enter the command
/opt/lampp/lampp stop
17.6.3. Testing Your Setup
Once you’ve started the servers, you can open any web browser on your computer and enter the address
http://localhost/
to confirm that the web server is up and running. If it is, you’ll see a web page similar to the one in Fig. 17.4. You’re now ready to go!
Fig. 17.4. default XAMPP webpage displayed on Windows.
17.6.4. Running the Examples Using Apache HTTP Server
Now that the Apache HTTP Server is running on your computer, you can copy the book’s examples into XAMPP’s htdocs folder. Assuming you copy the entire examples folder into the htdocs folder, you can run the examples in Chapters 2–16 and 19 with URLs of the form
http://localhost/examples/chapter/figure/filename
where chapter is one of the chapter folders (e.g., ch03), figure is a folder for a particular example (e.g., fig03_01) and filename is the page to load (e.g., NewFormInputTypes.html). So, you can run the first example in Chapter 3 with
http://localhost/examples/ch03/fig03_01/NewFormInputTypes.html
[Note: The ch02 examples folder does not contain any subfolders.]
17.7. Microsoft IIS Express and WebMatrix
Microsoft Internet Information Services Express (IIS Express) is a web server that can be installed on computers running Microsoft Windows. Once it’s running, you can use it to test web pages and web applications on your local computer. A key benefit of IIS Express is that it can be installed without administrator privileges on all versions of Windows XP, Windows Vista, Windows 7 and Windows Server 2008. IIS Express can be downloaded and installed by itself, or you can install it in a bundle with Microsoft’s WebMatrix—a free development tool for building PHP and ASP.NET web apps. We provide links for each below. When you use IIS Express without administrator privileges, it can serve documents only to web browsers installed on your local computer.
17.7.1. Installing and Running IIS Express
If you simply want to test your web pages on IIS Express, you can install it from:
www.microsoft.com/web/gallery/install.aspx?appid=IISExpress
We recommend using the default installation options. Once you’ve installed IIS Express you can learn more about using it at:
learn.iis.net/page.aspx/860/iis-express/
17.7.2. Installing and Running WebMatrix
You can install the WebMatrix and IIS Express bundle from:
www.microsoft.com/web/gallery/install.aspx?appid=IISExpress
Again, we recommend using the default installation options. You can run WebMatrix by opening the Start menu and selecting All Programs > Microsoft WebMatrix > Microsoft WebMatrix. This will also start IIS Express. Microsoft provides tutorials on how to use WebMatrix at:
www.microsoft.com/web/post/web-development-101-using-webmatrix
17.7.3. Running the Client-Side Examples Using IIS Express
Once you have IIS Express installed, you can use it to test the examples in Chapters 2–16. When you start IIS Express, you can specify the folder on your computer that contains the documents you’d like to serve. To execute IIS Express, open a Command Prompt window and change directories to the IIS Express folder. On 32-bit Windows versions, use the command
cd "c:Program FilesIIS Express"
On 64-bit Windows versions, use the command
cd "c:Program Files (x86)IIS Express"
Launching IIS Express
If the book’s examples are in a folder named c:examples, you can use the command
iisexpress /path:c:examples
to start IIS. You can stop the server simply by typing Q in the Command Prompt window.
Testing a Client-Side Example
You can now run your examples with URLs of the form
http://localhost:8080/chapter/figure/filename
where chapter is one of the chapter folders (e.g., ch03), figure is a folder for a particular example (e.g., fig03_01) and filename is the page to load (e.g., NewFormInputTypes.html). So, you can run the first example in Chapter 3 with
http://localhost:8080/ch03/fig03_01/NewFormInputTypes.html
[Note: The ch02 examples folder does not contain any subfolders.]
17.7.4. Running the PHP Examples Using IIS Express
The easiest way to test Chapter 19’s PHP examples is to use WebMatrix to enable PHP for the ch19 folder in the book’s examples. To do so, perform the following steps.
1. Run WebMatrix by opening the Start menu and selecting All Programs > Microsoft WebMatrix > Microsoft WebMatrix.
2. In the Quick Start - Microsoft WebMatrix window, select Site From Folder.
3. Locate and select the ch19 folder in the Select Folder window, then click the Select Folder button.
This opens the ch19 folder as a website in WebMatrix (Fig. 17.5).
Fig. 17.5. The ch19 examples folder in WebMatrix.
Enabling PHP
To enable PHP, perform the following steps:
1. Click the Site option in the bottom-left corner of the window.
2. Click Settings and ensure that Enable PHP is checked (Fig. 17.6). [Note: The first time you do this, WebMatrix will ask you for permission to install PHP. You must do this to test the PHP examples.]
Fig. 17.6. Enabling PHP for the ch19 examples folder in WebMatrix.
Running a PHP Example
You can now run the PHP examples directly from WebMatrix. To do so:
1. Click the Files option in the bottom-left corner of the window.
2. Open the folder for the example you wish to test.
3. Right-click the example’s PHP script file and select Launch in browser.
This opens your default browser and requests the selected PHP script file.