Re: Reliable HTTP comments by Dan Weinreb

The payload error indicator was put at the end of the payload because
the agent that is sending a message could be implemented using a wide
variety of possible persistent storage mechanisms, and during the
building of a batch of messages into a single payload, this storage
mechanism could fail in a variety of ways.

For example, suppose a database is providing the persistent storage.  The
messages could be stored as rows in a table, and the messaging agent
could build a batch by selecting from that table rows that are not marked
as in doubt (sent but not acknowledged).  As the agent fetches each
message, it is sent out on the wire.  One such select may not result in a
suitably large batch, in the agent's estimation, so it waits briefly and
tries again.  Suppose that this second select returns with some error at
some point, indicating that the database system has crashed.  The
transaction including those selects and the corresponding updates
(marking the messages as in doubt) will be rolled back by the database
system during its recovery.  The messages already sent to the receiving
agent will, when the rollback occurs, no longer be marked as in doubt.
The receiving agent must not, therefore, accept that batch.  Putting
abort in the terminator clearly marks for the receiver that the payload
must be discarded at its end.  It's also nicer, in terms of
documentation, than simply cutting off the payload prematurely, since it
lets the receiving agent know that the problem is at the sending side
rather than in the network.

The encoding section is, admittedly, sketchy.  It is also, along with
the other MessageContext headers, of use to the applications that are
exchanging the messages, not to HTTPR itself.  The reason for including
them was that they were felt to be of such common interest that most
applications (including, for example, our own demonstration programs)
were likely to be wanting to exchange information along these lines.
Rather than have them each make up their own headers, it was thought it
would be convenient to reserve these headers assign agreeable meanings to
them.

There are a variety of reasons for building HTTPR on top of HTTP.  The
one regarding firewalls does, on the face of it, seem a bit artificial.
But I don't think HTTPR is doing anything all that different from what
HTTP is being asked to do.  With HTTP we get "approximately once
messaging".  (I know that we get a variety of other things as well, and
that there are any number of other ways of looking at what we get from
HTTP, but let's not get bogged down in that before I at least get this
story out.)  What goes on at either end of the wire as the result of the
messages being exchanged is determined by the administrators of the web
servers and the implementers of the web clients; the firewall
administrators don't really care.  There are other security concerns, but
for HTTPR versus HTTP I'd like to suggest that they are identical; what
is changed from one to the other is "approximately once" versus "exactly
once".  It therefore seems reasonable to me to put HTTP and HTTPR in the
same security classification at the firewall.  If you really don't like
that approach, you are always free to not have an HTTPR servlet in your
server configuration for the server that listens to port 80, but for
those server administrators who have little or no leverage with their
firewall administrators to get another hole drilled through, this seems
like a workable solution.

Other reasons, mentioned only briefly in passing in the spec, relate to
the convenience of using the features in HTTP and the existing
implementations of it.  For example, we can let SSL take care of
encryption and authentication rather than redefining it and
reimplementing it.  It's already there in the servers, along with all of
the other mechanisms for doing the approximately once communication and
thread management and all of those other things that full-blown web
servers do.

I don't think I've exhausted the possible reasons for wanting to layer
HTTPR on top of HTTP, but they're the ones I can think of at the moment.

Richard.

Received on Friday, 20 July 2001 16:59:09 UTC