Learning PHP, MySQL, JavaScript, and CSS, 2nd Edition

HTTP and HTML: Berners-Lee’s Basics

HTTP is a communication standard governing the requests and responses that take place between the browser running on the end user’s computer and the web server. The server’s job is to accept a request from the client and attempt to reply to it in a meaningful way, usually by serving up a requested web page—that’s why the term server is used. The natural counterpart to a server is a client, so that term is applied both to the web browser and the computer on which it’s running.

Between the client and the server there can be several other devices, such as routers, proxies, gateways, and so on. They serve different roles in ensuring that the requests and responses are correctly transferred between the client and server. Typically, they use the Internet to send this information.

A web server can usually handle multiple simultaneous connections and—when not communicating with a client—spends its time listening for an incoming connection request. When one arrives, the server sends back a response to confirm its receipt.

The Request/Response Procedure

At its most basic level, the request/response process consists of a web browser asking the web server to send it a web page and the server sending back the page. The browser then takes care of displaying the page (see Figure 1-1).

Figure 1-1. The basic client/server request/response sequence

These are the steps in the request and response sequence:

1. You enter http://server.com into your browser’s address bar.

2. Your browser looks up the IP address for server.com.

3. Your browser issues a request for the home page at server.com.

4. The request crosses the Internet and arrives at the server.com web server.

5. The web server, having received the request, looks for the web page on its hard disk.

6. The server retrieves the web page and returns it to the browser.

7. Your browser displays the web page.

For an average web page, this process takes place once for each object within the page: a graphic, an embedded video or Flash file, and even a CSS template.

In step 2, notice that the browser looked up the IP address of server.com. Every machine attached to the Internet has an IP address—your computer included. But we generally access web servers by name, such as http://www.google.com. As you probably know, the browser consults an additional Internet service called the Domain Name Service (DNS) to find the server’s associated IP address and then uses that to communicate with the computer.

For dynamic web pages, the procedure is a little more involved, because it may bring both PHP and MySQL into the mix (see Figure 1-2).

Figure 1-2. A dynamic client/server request/response sequence

Here are the steps:

1. You enter http://server.com into your browser’s address bar.

2. Your browser looks up the IP address for server.com.

3. Your browser issues a request to that address for the web server’s home page.

4. The request crosses the Internet and arrives at the server.com web server.

5. The web server, having received the request, fetches the home page from its hard disk.

6. With the home page now in memory, the web server notices that it is a file incorporating PHP scripting and passes the page to the PHP interpreter.

7. The PHP interpreter executes the PHP code.

8. Some of the PHP contains MySQL statements, which the PHP interpreter now passes to the MySQL database engine.

9. The MySQL database returns the results of the statements back to the PHP interpreter.

10. The PHP interpreter returns the results of the executed PHP code, along with the results from the MySQL database, to the web server.

11. The web server returns the page to the requesting client, which displays it.

Although it’s helpful to be aware of this process so that you know how the three elements work together, in practice you don’t really need to concern yourself with these details, because it all happens automatically.

HTML pages returned to the browser in each example may well contain JavaScript, which will be interpreted locally by the client, and which could initiate another request—the same way embedded objects such as images would.