Re: Reliable HTTP

Mark (Baker, that is),

The following is just a copy of the remarks I made on the
www.ibm.com/developerworks/webservices/library/ws-phtt discussion forum:

Perhaps a paragraph that disappeared during the editing of our
specification should be restored:

"An alternative approach would have been to use the framework for
extending HTTP commands to expose HTTPR-specific fields.  This would
have exposed the protocol detail to web servers, proxies and firewalls
in the web, possibly requiring special versions of this software to be
deployed to handle HTTPR.  To avoid this exposure, and because it is
anticipated that HTTPR will be a minority web protocol, this approach
was not taken."

To respond more specifically to your comments, let me add that HTTPR is
using HTTP's POST strictly as just that, to deliver a payload to a
server, because that was the surest way to get the HTTPR request all the
way from the client to the server through any possible, pre-existing
proxy without interference.  The same applies, I believe even more
strongly, to burying get-responder-info inside the payload instead of
overloading the meaning of HTTP's GET, since get-responder-info does
more than request information; it also establishes an HTTPR session,
which may persist for some time.

At the heart of it is, perhaps, a conflict between the stateless nature
of HTTP and stateful nature of reliable message transfer.  Rather than
shoehorn into HTTP ways of expressing and exchanging state information
and thereby make HTTP a stateful protocol, it seemed preferable to use
HTTP as the transport mechanism for expression of reliable messaging at
a higher level.

HTTP certainly stands for Hypertext Transfer Protocol, and the contents
of POST payloads and their responses under HTTPR are certainly not HTML.
Still, when looked at dispassionately, there is nothing in HTTP that
precludes transmission of any other kind of data, including, we like to
think, HTTPR.

Richard.

Received on Wednesday, 18 July 2001 10:19:21 UTC