When debugging web applications, most adminstrators will review the HTTP request and response headers for errors. This information can be retrieved with Firefox’s HTTP Live headers plugin, ethereal, or with curl’s “-v” (make the operation more talkative) option:
$ curl -v http://www.google.com
About to connect() to www.google.com port 80
Trying 64.233.187.99... connected
Connected to www.google.com (64.233.187.99) port 80
> GET / HTTP/1.1
User-Agent: curl/7.13.1 (powerpc-apple-darwin8.0) libcurl/7.13.1
OpenSSL/0.9.7g zlib/1.2.3
Host: www.google.com
Pragma: no-cache
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: text/html
< Set-Cookie: PREF=ID=12; expires=Sun, 17-Jan-2038 19:14:07 GMT;
path=/; domain=.google.com
< Server: GWS/2.1
< Transfer-Encoding: chunked
< Date: Tue, 18 Oct 2005 03:52:08TGMT:00-04:00
The “>” and “<” characters are used to indicate the direction the requests are sent and received. The curl(1) manual page indicates that the “-i” (Include protocol headers in the output) option should print protocol headers, but for some reason it only prints the HTTP response headers:
$ curl -i http://www.google.com
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html
Set-Cookie: PREF=ID=3eb84ab15b6724e3:TM=12; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Server: GWS/2.1
Transfer-Encoding: chunked
Date: Tue, 18 Oct 2005 03:54:38TGMT:00-04:00
When I get more time, I will have to go wandering through the curl source code to see why.