Let's step back from our example, and take an overhead view of what's going on with our web page between writing it and viewing it. When we installed PHP in Chapter 1, the installation was broken down into stages because we installed several different pieces of software.

One of these pieces of software was the web server, which makes your web pages available to all and sundry. Another job of the web server is to provide an area (typically in a directory or folder structure) in which to organize and store your web pages or whole web site. There are many commercial and freeware web servers available, but two companies' web servers predominate and take up over 70% of the market. The two products are Apache's web server and Microsoft's Internet Information Server. We will assume that you are using one of these two web servers to perform the task of making your web pages available.

When you use the Web to view a web page, you will automatically be making contact with a web server. The process of submitting your URL is called as making a request to the server. The server interprets the URL, locates the corresponding page, and sends back the page as part of what is called the response to the browser. The browser then takes the code it has received from the web server and compiles a viewable page from it. The browser is referred to as a client in this interaction, and the whole interaction as a client-server relationship.

Client-Server

This term describes effectively the workings of the web by outlining the distribution of tasks. The server (the web server) stores, interprets, and distributes data, and the client (browser) accesses the server to get at the data. From now on whenever we use the term client, we are just referring to the browser. As you'll come to see in later chapters, the term client-server is an oversimplification of the process - it's quite an abstract description of a physical process. To understand what is going on in greater detail, we need to briefly discuss the workings of the Internet itself.

Internet Protocols

We won't go through the entire history of the Internet here; the important point is that it is a network of interconnected nodes. The Internet is designed to carry information from one place to another. It uses a suite of networking protocols (known as TCP/IP) to transfer information around the.

A networking protocol is simply a method of describing information packets so that they can be sent down your telephone-, cable-, or T1-line from node to node, until they reach their intended destination.

One advantage of the TCP/IP protocol is that it can re-route information very quickly if a particular node or route is broken or slow. When the user tells the browser to fetch a web page, the browser parcels up this instruction using a protocol called the Transmission Control Protocol (or TCP). TCP is a transport protocol, which provides a reliable transmission format for the instruction. It ensures that the entire message is packaged up correctly for transmission (and also that it is correctly unpacked and put back together after it reaches its destination). The networking protocol TCP/IP is a method of describing your information packets so that they can be sent down a telephone line, cable, or T1-line from node to node.

Before the parcels of data are sent out across the network, they need to be addressed. So a second protocol called HyperText Transfer Protocol (or HTTP) puts an address label on it, so that TCP/IP knows where to direct the information. HTTP is the protocol used by the World Wide Web in the transfer of information from one machine to another - when you see a URL prefixed with http://, you know that the internet protocol being used is HTTP. You can think of TCP/IP as the postal service that does the routing and transfer, while HTTP is the stamp and address on the letter (data) to ensure it gets there.

The message passed from the browser to the web server is known as an HTTP request. When the web server receives this request, it checks its stores to find the appropriate page. If the web server finds the page, it parcels up the HTML contained within (using TCP), addresses these parcels to the browser (using HTTP), and sends them back across the network. If the web server cannot find the requested page, it issues a page containing an error message (in this case, the dreaded Error 404: Page Not Found) - and it parcels up and dispatches that page to the browser. The message sent from the web server to the browser is called the HTTP response.

Here's an illustration of the process as we understand it so far:

There is still quite a lot of technical detail missing here, so let's dig further down and look more closely at exactly how HTTP works. When a request for a web page is sent to the server, this request contains more than just the desired URL. There is a lot of extra information that is sent as part of the request. This is also true of the response - the server sends extra information back to the browser. It's these different types of information that we'll look at in this next section.

A lot of the information that is passed within the HTTP message is generated automatically, and the user doesn't have to deal with it directly, so you don't need to worry about transmitting such information yourself. While you don't have to worry about creating this information yourself, you should be aware that this extra information is being passed between machines as part of the HTTP request and HTTP response - because the PHP script that we write can allow us to have a direct effect on the exact content of this information.

Every HTTP message assumes the same format (whether it's a client request or a server response). We can break this format down into three sections: the request/response line, the HTTP header, and the HTTP body. The content of these three sections is dependent on whether the message is an HTTP request or HTTP response - so we'll take these two cases separately.

Let's just pause and illustrate our understanding of the process now: