RE: SOAP 1.1 One-way HTTP Binding doc

Tony,

>From the WS-I Basic Profile:

3.3 SOAP Faults
3.3.1 Identifying SOAP Faults
Some consumer implementations erroneously use only the HTTP status code to 
determine the presence of a Fault. Because there are situations where the 
Web infrastructure changes the HTTP status code, and for general 
reliability, the Profile requires that they examine the envelope. A Fault 
is an envelope that has a single child element of the soap:Body element, 
that element being a soap:Fault element.
R1107 A RECEIVER MUST interpret a SOAP message as a Fault when the 
soap:Body of the message has a single soap:Fault child.
3.3.2 SOAP Fault Structure
The Profile restricts the content of the soap:Fault element to those 
elements explicitly described in SOAP 1.1.
R1000 When an ENVELOPE is a Fault, the soap:Fault element MUST NOT have 
element children other than faultcode, faultstring, faultactor and detail
And this later on in the SOAP over HTTP section:

R1126 An INSTANCE MUST return a "500 Internal Server Error" HTTP status 
code if the response envelope is a Fault.

I'm gald to hear that the UDDI TC fixed their abuse of SOAP, but in my 
mind, it couldn't be more clear. In the context of SOAP1.2 [1], 
it is equally clear that a SOAP Fault MUST be accompanied with either a 
500 or 400 HTTP status code.

The reason that JAX-RPC had agita treating a SOAP Fault in the entity body 
of an HTTP
response message with a 200 status as a "success" response is because it 
was correctly implemented, not because
it wasn't keying off of the HTTP response code to interpret what the 
content of the SOAP envelope meant.

The reason for this was that in the pre-WS-I days, many implementations 
were rather inconsistent in their handling
of SOAP faults... some returned an HTTP 200 and others a 500. The WS-I 
Basic Profile, and the SOAP1.2 spec
made it clear that a SOAP Fault is always a SOAP Fault, period. The also 
then clarified that a SOAP Fault
MUST be accompanied by an HTTP 500 so as to be consistent with the HTTP 
specification and so as to
eliminate the interoperability issues by clarifying the ambiguity in the 
SOAP1.1 specification.

IMO, the above does not preclude us from defining a binding that says that 
an HTTP response carrying a SOAP envelope that is
NOT related to the processing of the SOAP envelope in the HTTP request 
message (e.g. a WS-RM SeqAck) is accompanied
by an HTTP 202.

It is then up to the implementations to treat the message in accordance 
with the semantics that we specify, which just happen
to be consistent with the application semantics defined by the HTTP 
specification (what a coinkidink).

[1] 
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#tabresstatereccodes

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

"Rogers, Tony" <Tony.Rogers@ca.com> wrote on 01/31/2006 12:11:21 AM:

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