- From: <paul.downey@bt.com>
- Date: Sat, 5 Nov 2005 13:35:41 -0000
- To: <dmh@tibco.com>, <public-ws-addressing@w3.org>
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