HyperWrite - Consultancy and Training 

Help Systems, Structured Authoring, DITA, Hypertext, Documentation Technologies

HyperWrite Logo
Skip Navigation LinksHome > Articles > This Article
Skip Navigation Links

Reliable HTTP - A New Protocol


By now, we have been thoroughly exposed to the acronym HTTP. It stands for Hypertext Transfer Protocol, and is one of the underlying technologies of the World Wide Web. A Web page is delivered from a server to a browser through HTTP. An HTTP Request is the instruction sent from the browser to the server. An HTTP Response is the result of the request, sent by the server to the browser. A Web page is delivered within the HTTP Response.

There is a variant of HTTP that we may also have encountered: HTTPS. This protocol is the secure version of HTTP, where the request and response are encrypted before transmission. Secure HTTP is used for most Web applications where personal, financial or sensitive information is being sent from browser to server or vice versa. A Web server must have a server certificate, acquired from a third party certifying body, for it provide an HTTPS service.

Another new variant of HTTP is HTTPR - for Reliable HTTP. This new protocol is being developed by IBM for adoption as a standard by the Internet Engineering Task Force (IETF). In a nutshell, HTTPR aims to ensure that a Web transmission gets delivered to its destination only once, or gets reported as undeliverable. HTTPR is geared toward business-to-business communications over the Web, such as paying a bill or processing a purchase order, where a request must be delivered once and only once to its intended receiver.

To understand more about how HTTPR works, we need to know a bit more about HTTP.

The Principle of  HTTP

Accessing pages on the Web is an easy concept. You simply type a URL into your browser, click Go, and the requested page displays. In the background, however, a flurry of computer and network activity makes the simple process work. Your browser has to format your Web page request into an HTTP Request. It has to work out the Internet IP address of the server that you are requesting the page from. A number of computers on the Internet must then pass your HTTP Request from machine to machine until it reaches the Web server. The Web server must then interpret the request, fetch the requested resource, and start sending the multiple elements of the page back to you across the Internet as HTTP Responses. Lots of things can go wrong. For example, if the page you requested does not exist, the Web server will send an HTTP Error 404. Sometimes, some elements of the page may be delivered successfully, but other parts are not delivered successfully. For this reason, HTTP is not all that reliable. Pages don't always get delivered, and neither the browser nor the server can be sure that a request or response made it to its destination.

When informational content is being requested and delivered, this unreliability of HTTP doesn't present too many problems. If the page doesn't display, you might try again, or try again later. It may be annoying, but it isn't critical.

However, where the Request/Response is transactional, as is the case for most Web applications, this unreliability becomes a problem. For example, you just clicked the Transfer button in your Internet Banking application, and your browser page seems to be 'hung'. Did your funds transfer go through? Should you try again and risk sending the money twice? Did your funds go to the correct account, as you didn't receive the acknowledgement you expected? In such cases, the unreliability of HTTP is a big problem. And as more and more Web activity becomes transactional as Web applications become the norm, HTTP's limitations will become critical.


HTTPR (or Reliable HTTP) is designed to ensure the delivery of Requests and Responses from one system to another. Rather than replace HTTP, HTTPR is layered on top of HTTP. HTTPR requests and responses are packaged as the 'payload' of an HTTP transmission. HTTPR has three operational modes: sessionless, simple sessions, and pipelined sessions.

Reliable HTTP enables transmission failures to be reported more accurately. If a Web server is unavailable or rejects a particular request, then the browser will know that the request failed. This ability to report a message failure is a key features of HTTPR.

HTTPR ensures that a transmission reaches its destination, and further ensures that each parcel of information is delivered only once. In our funds transfer example above, you need to be confident that the transfer is processed only once. So if for some reason a request hits the server twice, the server needs to understand that the second request was a duplicate.

HTTP is often described as 'sessionless', in that each request is treated by the server as a unique event unconnected to any other request. The server therefore doesn't know that the request is just received is from the same browser that made another request 30 seconds ago. HTTP doesn't maintain a 'persistent connection' between browser and server. However, HTTPR does allow persistence, and this persistence leads to reliability. A persistence mechanism retains the previous messages in a storage system.

When Will We See It Being Used?

Version 1.1 of HTTPR is currently (December 2002) released, and version 2.0 is in draft form. IBM has published the standard for public comment and feedback. It has not yet been adopted by IETF. IBM's WebServices Toolkit (a Web application software development kit) already provides support for HTTPR, but we probably won't see widespread use of HTTPR 'in the wild' for at least one year.

More Information


Collected links

Bookmark and Share


Created with DITA

Valid XHTML 1.0 Transitional Valid CSS!


HyperWrite provides training in a number of authoring software tools, and in structured authoring, technical writing and Help authoring techniques. Find out more...