Apache: The Definitive Guide, 3rd Edition

How HTTP Clients Work

Once the server is set up, we can get down to business. The client has the easy end: it wants web action on a particular site, and it sends a request with a URL that begins with http to indicate what service it wants (other common services are ftp for File Transfer Protocolor https for HTTP with Secure Sockets Layer — SSL) and continues with these possible parts:

 //<user>:<password>@<host>:<port>/<url-path>

RFC 1738 says:

Some or all of the parts “<user>:<password>@”, “:<password>”,":<port>”, and “/<url-path>” may be omitted. The scheme specific data start with a double slash “//” to indicate that it complies with the common Internet scheme syntax.

In real life, URLs look more like: http://www.apache.org/ — that is, there is no user and password pair, and there is no port. What happens?

The browser observes that the URL starts with http: and deduces that it should be using the HTTP protocol. The client then contacts a name server, which uses DNS to resolve www.apache.org to an IP address. At the time of writing, this was 63.251.56.142. One way to check the validity of a hostname is to go to the operating-system prompt^[8] and type:

             ping www.apache.org

If that host is connected to the Internet, a response is returned:

Pinging www.apache.org [63.251.56.142] with 32 bytes of data: Reply from 63.251.56.142: bytes=32 time=278ms TTL=49 Reply from 63.251.56.142: bytes=32 time=620ms TTL=49 Reply from 63.251.56.142: bytes=32 time=285ms TTL=49 Reply from 63.251.56.142: ...