An interesting pre-draft RFC for an "application protocol for reliable transmission of messages using HTTP."
From the introduction:
This document describes an application protocol for guaranteed once and only once transmission of messages using HTTP, something that HTTP alone does not guarantee. It describes a means for both downloading and uploading of messages. It is not concerned with endpoint availability, robustness of components, or details of persistent storage. It is not concerned with message order. A characteristic of distributed systems is that senders and receivers of messages can't know with certainty what went wrong in the event of failure, and without catering for agreement, they might not know if anything did go wrong with a transmission. Our primary concern for failure is dealing with partial failure. Partial failure is where one component in the system fails while the others continue to function. The HTTP client-server model has three failing parts, the Client, the Network, and the Server. For example, if the Network fails mid-transmission, a request might be arrive to the Server but not a response to the Client. Or if the Server's firewall rules are mis-configured, Client requests might be rejected out of hand. The techniques described here provides a measure of reliability within the client server model of HTTP. Reliable variants of HTTP or protocols layered upon HTTP often require a peer to peer model, where both communicators are HTTP servers.
There are some interesting ideas there...
—Michael A. Cleverly
Wednesday, May 18, 2005 at 07:42