RE: 202

David 

> 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.

I don't think I fully understand this paragraph: is it saying that a TCP 
connection may fail after the reciever has received the complete HTTP 
request, but before sending an HTTP ACK? 

In which case both sender and receiver are aware that the connection has 
broken and without the HTTP ACK and the TCP shutdown three-way handshake 
the sender must assume that the message hasn't been 'secured', let alone 
processed. I'm not sure how this relates to HTTP 202 though.

> 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.

You want to treat a HTTP conversation as a bi-directional pipe? 
Out of  interest, which SOAP specifications do this, and do we want
to consider existing or potential specs which abuse HTTP in this way?

> 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.

Sorry, but I need some more context here than 'elsewhere' to understand
this sentence!

> 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.  

I'm not sure about the 'general rule', but I believe that's what we 
have documented in the Test Suite:

http://www.w3.org/2002/ws/addr/testsuite/exchanges/

> 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.

Er, AIUI RFC2616 encourages a 202 to contain stuff such as estimates 
of how long the *request* can be completed, status information for the 
*request* and  a link to where the status of the *request* can be 
monitored. 

Anything else wonders back into HTTP abuse territory.

Paul

Received on Saturday, 5 November 2005 13:35:49 UTC