Re: Issue 192; HTTP binding looks ok

 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.
 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? (I'm not sure about the second, 
please clarify if that's an error or OK.)
 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.)
 Best regards,

                   Jacek Kopecky

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



On Tue, 19 Mar 2002, Mark Baker wrote:

 > Henrik,
 > 
 > > IMO, the resolution of this issue [1][2] seems to be very clear on the
 > > relationship between a SOAP fault and HTTP status codes so I am I not
 > > sure I understand the discussion about which is a hint and which is not.
 > 
 > As this thread intended to show, I now agree.  Another look at the HTTP
 > binding showed that it appears to be consistent with my views of how
 > faults should be recognized, which is also consistent with the
 > resolution of the issues you cited.
 > 
 > Adding the resolution text from those issues should also help make this
 > issue clearer to its audience, but it would still be nice to
 > specifically say "SOAP faults received as part of an HTTP response with
 > a non-4xx or 5xx status code, should not be treated as faults".  I could
 > see this one *easily* being missed by implementors.  I wonder how many
 > SOAP 1.1 implementations get it right?
 > 
 > Certainly something to add to our conformance tests too.
 > 
 > So, issue 192 appears to be down to just my first proposal, to add a
 > blurb to the binding framework saying that, at the very least, binding
 > designers should be aware of this issue (what I proposed for 192 was
 > more specific, but I could live with this).
 > 
 > MB
 >

Received on Tuesday, 19 March 2002 14:29:19 UTC