Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
HTTP Headers: A Simple Overview
Although a complete discussion of HTTP and headers is outside the scope of this article, it’s important that you understand the basics of how HTTP works with data contained in headers. In this section, I’ll briefly discuss the communication between HTTP clients and servers. (If you’re already familiar with HTTP, you can skip to the next section.)
In an HTTP conversation, the client sends requests to the web server, which answers with responses. Requests and responses can include additional information in the form of headers. The info can be a simple code or a complete document, file, or whatever was requested.
Listing 2 shows a simple HTTP exchange between a Telnet client and a remote server. The client text (the request) is shown in bold.
Listing 2 A sample HTTP session with headers.
GET /helloworld.html HTTP/1.1 Accept: text/plain,text/html Host: webserver User-Agent: Telnet Connection: Close HTTP/1.1 200 OK Date: Thu, 27 Jul 2006 01:21:00 GMT Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2 Last-Modified: Thu, 27 Jul 2006 01:16:36 GMT ETag: "19b49b-91-44c813f4" Accept-Ranges: bytes Content-Length: 145 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <body> <p>Hello world!</p> </body> </html>
Notice that the client uses the GET command to make its request, annotating the request with additional headers to specify information such as client type (User-Agent) and types of encoding that the client can receive (text or html). The request ends with a blank line, signaling the server that the client has finished providing information.
The server replies with a response code (in this case, 200 OK) a handful of informational headers of its own, and in this case the requested document, helloworld.html. In this particular example, because the client requested in its Connection header that the session be closed after the transaction, the server closes the connection after sending the entire response.
Using the same technique on the Netgear wireless access point I mentioned earlier nets a different result, due to the access point’s protection via HTTP-Auth. Listing 3 shows the results of a non-authenticated request.
Listing 3 A sample HTTP-Auth session without appropriate authentication.
GET / HTTP/1.1 Accept: text/plain,text/html Host: accesspoint User-Agent: Telnet Connection: Close HTTP/1.1 401 Authorization Required Date: Thu, 27 Jul 2006 02:13:26 GMT Server: Apache/2.0.54 (Debian GNU/Linux) PHP/4.3.10-16 WWW-Authenticate: Basic realm="MediaWiki" Vary: accept-language,accept-charset Accept-Ranges: bytes Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 Content-Language: en <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <title>Authentication required!</title> </head> <body> <h1>Authentication required!</h1> <p> This server could not verify that you are authorized to access this resource. </p><p> You either supplied the wrong credentials (e.g., bad password), or your browser doesn’t understand how to supply the credentials required. </p> </body> </html>
Notice that the response headers and HTML document returned are defined by the server’s configuration and can vary significantly between web servers. However, the response code, "HTTP/1.1 401 Authorization Required," is uniform and will be returned by any HTTP-compliant server when the required authorization is missing from the request.