- From: David Hull <dmh@tibco.com>
- Date: Thu, 09 Jun 2005 16:30:09 +0200
- To: public-ws-async-tf@w3.org
- Message-id: <42A85271.3090206@tibco.com>
In most of our discussion, we've been assuming that an HTTP server should return some form of 2xx message without a SOAP body in cases where the actual response is being sent elsewhere. I believe this will work much of the time, but I'm now more convinced it won't work in all cases. For the sake of concreteness, assume the MEP in question is robust in-only and the [fault endpoint] has an anonymous [address] component. Then a 2xx message is insufficient if * Traffic is meant to be secured. In this case, the empty 2xx marker reveals information (namely that there was no fault), while an encrypted SOAP message response doesn't. * A reliability mechanism is in use. In this case, the response needs to carry the usual sequence number headers. It's a little difficult defining the exact circumstances where this matters, but it would generally be in the context of a series of operations done in a single reliability context. I believe the cases to distinguish are 1. The server fell over before sending back the marker message. 2. The server thinks it sent back a marker message, but the back-channel was cut off before it could arrive. * (previously mentioned) The underlying transport provides a back channel but no mechanism for correlation (and the client cares about correlation). In this case, the client needs to know which request the marker message pertains to. * (maybe) The [fault endpoint] had a non empty [reference parameters] along with the anonymous [address]. There is actually a modeling question here, namely whether the marker message is coming back on the transport's back-channel, or whether it is addressed to the [fault endpoint]. This can be argued either way. Hopefully we can decide based on other factors. This doesn't mean we can't use 2xx responses in the common case. We just have to define that as a transport-level optimization of a SOAP marker message with no special headers.
Received on Thursday, 9 June 2005 14:30:18 UTC