HTTP Headers and SOAP

Two types of headers are available in HTTP: request headers and response headers. When you are using your Web browser to surf the Internet, each time you navigate to a new URL the Web browser will create a request and send it to the Web server. These requests are written in plain text; each has headers in a standard format. When creating SOAP messages, you will be adding additional information to these standard formats. HTTP servers generate a response message upon receiving the client request. This message contains a status line and response headers. Let's look at the two headers in more detail.

Request Headers

A typical HTTP message in a SOAP request being passed to a Web server looks like this:

  POST /Order HTTP/1.1
  Host: www.northwindtraders.com
  Content-Type: text/xml
  Content-Length: nnnn
  SOAPAction: "urn:northwindtraders.com:PO#UpdatePO"
  Information being sent would be located here.

The first line of the message contains three separate components: the request method, the request URI, and the protocol version. In this case, the request method is POST; the request URI is /Order; and the version number is HTTP/1.1. The Internet Engineering Task Force (IETF) has standardized the request methods. The GET method is commonly used to retrieve information on the Web. The POST method is used to pass information from the client to the server. The information passed by the POST method is then used by applications on the server. Only certain types of information can be sent using GET; any type of data can be sent using POST. SOAP also supports sending messages using M-POST. We'll discuss this method in detail later in this chapter. When working with the POST method in a SOAP package, the request URI actually contains the name of the method to be invoked.

The second line is the URL of the server that the request is being sent to. The request URL is implementation specific-that is, each server defines how it will interpret the request URL. In the case of a SOAP package, the request URL usually represents the name of the object that contains the method being called.

The third line contains the content type, text/xml, which indicates that the payload is XML in plain text format. The payload refers to the essential data being carried to the destination. The payload information could be used by a server or a firewall to validate the incoming message. A SOAP request must use the text/xml as its content type. The fourth line specifies the size of the payload in bytes. The content type and content length are required with a payload.

The SOAPAction header field must be used in a SOAP request to specify the intent of the SOAP HTTP request. The fifth line of the message, SOAPAction: "urn: northwindtraders.com:PO#UpdatePO", is a namespace followed by the method name. By combining this namespace with the request URL, our example calls the UpdatePO method of the Order object and is scoped by the urn:northwindtraders.com:PO namespace URI. The following are also valid SOAPAction header field values:

  SOAPAction: "UpdatePO"
  SOAPAction: ""

The header field value of the empty string means that the HTTP request URI provides the intent of the SOAP message. A header field without a specified value indicates that the intent of the SOAP message isn't available.

Notice that there is a single blank line between the fifth line and the payload request. When you are working with message headers, the carriage-return/line-feed sequence delimits the headers and an extra carriage-return/line-feed sequence is used to signify that the header information is complete and that what follows is the payload.

Response Headers

A typical response message that contains the response headers is shown here:

  200 OK
  Content-Type: text/plain
  Content-Length: nnnn
  Content goes here.

The first line of this message contains a status code and a message associated with that status code. In this case, the status code is 200 and the message is OK, meaning that the request was successfully decoded and that an appropriate response was returned. If an error had occurred, the following headers might have been returned:

  400 Bad Request
  Content-Type: text/plain
  Content-Length: 0

In this case, the status code is 400 and the message is Bad Request, meaning that the request cannot be decoded by the server because of incorrect syntax. You can find other standard status codes in RFC 2616.