202

I think we might want to be a little careful in how we describe the use
of a 202 ack, particularly if we require the message to contain an empty
SOAP body.

Suppose, for example, that I'm using some sort of reliability mechanism
to ensure that a series of one-way messages arrives safely.  Why would I
be using that with HTTP, which sits on top of TCP?  The series of
one-way messages spans any particular connection.  Even TCP can drop a
connection, and the receiver might have successfully received a message
but been unable to return any kind of response.  In such a case, it
could well be useful to acknowledge that message on receipt of the next
message, hoping to avoid a needless retransmit.

Or, suppose that the receiver wants to send a one-way message to the
sender, possibly for some unrelated reason.  The response channel is
there.  Why not use the bandwidth?  This could be particularly important
in situations where connections are relatively expensive, perhaps in
mobile applications.

I've argued elsewhere that, for other reasons, an acknowledgment message
might want to contain WSA headers, but I forget whether that would only
apply to asynchronous bidirectional transports.

In any case, it seems fine to make a general rule -- independent of any
particular concept of a MEP -- that when the receiver of an HTTP
response has nothing else to send back, it should send back a 202
(rather than, say, simply dropping the connection).  This seems pretty
well in line with the intent of 202.  But it may well be too restrictive
to mandate that the receiver MUST send back a 202 with an empty SOAP
body in cases where it is effectively receiving a one-way message.

Received on Friday, 4 November 2005 05:23:41 UTC