Share via


HTTP Request and Response Messages

I've talked about the request-reply message exchange pattern that HTTP uses, but we've never looked at what those messages translate into during transmission. Unlike TCP, which is sometimes used with the request-reply style but is inherently uncorrelated, the idea of requests and responses is built into HTTP.

After a connection is made to the server, the basic request message looks like

 VERB URL VERSION
HEADERS

BODY

The verb is the action that is being requested. The most common HTTP verb is GET, which simply retrieves the resource at the location specified by the URL. The version describes the message format being used and has a format of HTTP/1.0, where the first digit '1' is the major version number and the second digit '0' is the minor version number.

The headers and body specify data for the request. Headers consist of a name, followed by a colon, and then a value. A carriage-return line-feed pair terminates each header and the list of headers ends with a blank line. You can make up your own headers and the ones that the other side doesn't understand will just be ignored. The body is then totally arbitrary data.

Here's an example of a request I tried out when connected to port 80 of www.microsoft.com.

 GET / HTTP/1.1
Accept: text/*
Host: www.microsoft.com

The verb is GET, the location is the root of the server, the HTTP version is 1.1, and I've specified two headers with no body. In response, I got

 HTTP/1.1 200 OK
Date: Thu, 01 Jun 2006 06:34:41 GMT
Server: Microsoft-IIS/6.0
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 30430

followed by a whole bunch of text for the response body. The format of a response message is

 VERSION STATUS REASON
HEADERS

BODY

The status is a machine-readable code that explains how the server is reacting in response to the request while the reason is a human-readable version of the same information. I'll talk about the parts of an HTTP message and how they relate to WCF more in the future, but for now I need to wrap up some of the other series that I have going.

Next time: Inside the Standard Bindings: WSHttp