RE: SOAP 1.1 One-way HTTP Binding doc

For quite some time (multiple revisions) the UDDI V3 specification used a SOAP fault with an error code of E_SUCCESS (= 0) to indicate success for those APIs which had no natural return data (eg: delete calls). This was changed just before we took UDDI V3 to standard because JAX-RPC had trouble distinguishing between a "real" fault with HTTP code 5xx and a success "fault" with HTTP code 2xx - apparently it didn't look at the HTTP error code, but merely at the data structure in the SOAP envelope (and got confused by there being a SOAP fault structure in the both cases). In the end we opted to return an empty body (the success content was essentially meaningless, anyway).
 
So the answer is NO, not all systems distinguish between SOAP envelopes on the basis of the HTTP error code. 
 
While I can understand this, and it does qualify as "separation of layers", I'm not completely convinced...
 
Tony

________________________________

From: public-ws-addressing-request@w3.org on behalf of Mark Baker
Sent: Tue 31-Jan-06 10:38
To: David Hull
Cc: David Orchard; Anish Karmarkar; Christopher B Ferris; WS-Addressing
Subject: Re: SOAP 1.1 One-way HTTP Binding doc




Oops, forgot to finish my thought

On 1/31/06, Mark Baker <distobj@acm.org> wrote:
> On 1/31/06, David Hull <dmh@tibco.com> wrote:
> >  We've been pretty clear for a while that empty 202 means "ack".  I'm
> > hearing that non-empty 202 is meant for things like WS-RX acks, but I'm not
> > sure this is nailed down.  There seems to be some possibility that a 202
> > with a SOAP envelope could also be a real response.
>
> It's still a response, just not the result of processing the request.
>
> So if you took a SOAP envelope and sent it as an HTTP response with a
> 202 code, it would mean something entirely different than if sent back
> with a 200 code... in the same way that a SOAP fault sent with 200
> means something entirely different than a SOAP fault

... sent with a 400 or 500 response code.

Mark.