Re: Reliable HTTP

Hi John,

Generally, I question the choice of HTTP as a base for reliable
messaging. You seem to spend a fair amount of effort avoiding HTTP
mechanisms (by defining a separate set of headers, your own chunking
mechanism, etc.), while not really getting too many benefits from it.
BEEP seems like a much more natural choice in this respect.

HTTPR seems to define a protocol-as-a-content-type that's designed
only to be useful in the context of HTTP. This sets a confusing
stage, to say the least; there are several points in the document
where I'm not sure if you're talking about HTTP messages, HTTPR
messages or payload (e.g., SOAP) messages.

I'd think that serious consideration should be given to other options
first (in rough order of prefernce):

1) define a BEEP reliable messaging profile
2) define a SOAP reliable messaging module
3) define HTTP extensions (methods, headers and status codes) for reliable
   messaging
	

Some more specific comments;

From the primer:

  Reliable HTTP (HTTPR) is a new protocol that offers the reliable
  delivery of HTTP packets between the server and client.

NIT: the basic unit of HTTP is a message, not a 'packet'.

  To this end we recommend that a protocol layer be added to HTTP
  that we call HTTPR and similarly to HTTPS that we call HTTPSR.

Most HTTP implementations (e.g., intermediaries) won't know how to
dispatch these new protocol schemes. If the protocol conforms to the
requirements of HTTP, I'd suggest keeping HTTP and signalling the
presence of reliability semantics through another mechanism (perhaps
content-type?). Also, IIRC it's not permissable to have two protocol
schemes (HTTP and HTTPR) that both use the same default port (80).

What is the HTTP content-type of these messages?

From the spec;

  In one transmission of a batch of messages from one agent to
  another over httpr, the sink agent will indeed see the messages
  arrive in the same order as the source agent sent them because they
  are flowing over a single TCP/IP connection and are therefore
  reliably ordered.

If you're speaking about HTTP messages, this assumption cannot be
made; HTTP intermediaries are allowed to use multiple upstream
connections and keep one downstream connection open. Additionally,
those multiple upstream connections may be to different parent
proxies.

HTTP is explicitly a stateless protocol; you cannot make any
assumptions about the ordering of messages on the wire.



On Mon, Jul 16, 2001 at 04:39:21PM +0100, John Ibbotson wrote:
> A recent thread on this list commented on the need for reliable
> delivery of messages via HTTP. IBM has just released a first draft
> specification to support reliability over HTTP. Together with a
> primer, it is available from
> www.ibm.com/developerworks/webservices. We welcome any comments and
> feedback on this specification. John
> 
> XML Technology and Messaging,
> IBM UK Ltd, Hursley Park,
> Winchester, SO21 2JN
> 
> Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
> Fax: +44 (0)1962 816898
> Notes Id: John Ibbotson/UK/IBM
> email: john_ibbotson@uk.ibm.com
> 
> 

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Monday, 16 July 2001 18:01:06 UTC