The HTTP protocol is currently an evolving standard. Because it is still evolving, the HTTP protocol differs from the other int library protocols, such as FTP, which enjoy a certain maturity and stability. For this reason, the HTTP client implementation in the int library differs architecturally as well.
Unlike the protocol methods declared in other protocol client classes which parallel actions defined by the protocol specification, the HTTP client class contains an execute() method. The execute() method is passed as a reference to one of the derived classes of RWIHttpMethod, such as RWIHttpGet, RWIHttpHead, and RWIHttpPost. These derived classes define specific HTTP commands for GET, HEAD, and POST respectively. A derived class is used in conjunction with the RWIHttpVersion derived class, which specifies an HTTP version, to formulate correct request information for a method (command) of the specific version. The structure of these classes is shown in Figure 25 and Figure 26:
The method and version classes provide an extensible framework for supporting future versions of the HTTP standard. For example, adding support for HTTP/1.1 would entail writing Options, Put, Delete, and Trace method classes, and a Version 1.1 class.
The HTTP client class requires an RWIHttpVersion instance to be passed upon construction. The versions currently supported are 0.9 and 1.0. These version classes are used to filter requests to ensure compliance with their respective versions. For example, in version 0.9 of HTTP, only GET requests are supported and are formatted simply as GET <path>. The same request in version 1.0 of HTTP would be formatted as GET <path> HTTP/1.0, and would require an extra carriage return to signal the server that it has reached the end of data. Also in version 1.0, header fields can be supplied and additional command types, such POST and HEAD, are supported.
Due to these differences between HTTP versions, it is important to pass a correct version object to an HTTP client. Most of the time you should use version 1.0. The only time it would be advantageous to use the older version is when accessing a server that supports only version 0.9.
This scalable architecture supports the ongoing evolution of the HTTP protocol. When version 1.1 servers become widely available, an RWIHttpVersion_1_1 can be written to handle extra formatting that may be required for the new protocol.
©Copyright 2000, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.