Re: Issue 192; HTTP binding looks ok

 Mark, it was never my understanding that we agreed that faults 
could sometimes not be faults.
 My view is based mostly on namespacing - we define the structure 
of the SOAP Envelope namespace (in which Fault lies) and we 
define the meaning of the elements. The meaning of Fault is that 
it is a SOAP fault.
 If a message containing an env:Fault element is to be treated as 
an application-specific result, the application has to define 
what env:Fault means to it. How can it redefine something in our 
namespace?
 Anyway,

 > Two bindings anyone? 8-(
 > MB

 +1 here, it would be *so* much cleaner.

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/


On Tue, 19 Mar 2002, Mark Baker wrote:

 > Jacek,
 > 
 > >  Mark,
 > >  if by saying "faults received with 200 OK should not be treated
 > > as faults" you mean "they should be treated as an OK response", 
 > > I object to your proposal.
 > 
 > Yes, that's what I mean.  It's also what we've agreed to in order to
 > resolve issues (as Henrik pointed out), and what is in the current
 > version of the spec.
 > 
 > >  My proposal (and understanding) is that the two following HTTP
 > > responses should be treated as transport errors:
 > > 
 > > HTTP/1.1 200 OK
 > > ...necessary HTTP headers...
 > > 
 > > <env:Envelope ...necessary namespaces and stuff...>
 > >   <env:Body>
 > >     <env:Fault>
 > >       <faultcode><value>env:Receiver</value></faultcode>
 > >       <faultstring>foo</faultstring>
 > >     </env:Fault>
 > >   </env:Body>
 > > </env:Envelope>
 > > 
 > > 
 > > HTTP/1.1 500 server error
 > > ...necessary HTTP headers...
 > > 
 > > <env:Envelope ...necessary namespaces and stuff...>
 > >   <env:Body>
 > >     <m:MyFault>
 > >       <code>15</code>
 > >     </m:MyFault>
 > >   </env:Body>
 > > </env:Envelope>
 > > 
 > >  If I understand your position correctly, you would see the first 
 > > example as perfectly OK, right?
 > 
 > Right.
 > 
 > > (I'm not sure about the second, 
 > > please clarify if that's an error or OK.)
 > 
 > That's an error too.  But it's good you raise this, because I don't
 > recall us saying what a processor needs to do if it doesn't receive a
 > fault in a 4xx or 5xx response (other than what is specified in the
 > state transition model).
 > 
 > >  I think REST principles can be OK with my proposal, on the other
 > > hand tunneling principles are completely blown away with your
 > > proposal. (Just like REST principles are completely forgotten if
 > > we transmit faults with only 200 OK, whereas tunneling principles
 > > can live with 5xx and 4xx for faults.)
 > >  If I'm confusing REST with something else here, please do point 
 > > it out, I want to grok REST to be able to argue with you soundly 
 > > (if I'm not converted in the process.)
 > 
 > Nope, I think you've got it exactly right.  I hadn't considered that
 > this would "blow away" the tunneling use of SOAP, but I guess you're
 > right.
 >

Received on Tuesday, 19 March 2002 14:54:21 UTC