SOAP faults in HTTP [RE: AJAX vs. Xforms]

Jasper,

This is way off the subject here...but since you insist!


> The client has made the error in trying to add a customer that already
> exists. The server is not erring in not letting you add the customer; it
> is doing exactly what it is supposed to do. Therefore 4xx is correct.

I said you can argue it both ways, and you think you can only argue it one
way. I think the fact that you don't think it's ambiguous appears to be
because you are seeing HTTP status codes as having their HTTP meaning, when
in SOAP they don't.

The HTTP error codes are being used to signal SOAP faults, not HTTP faults.
So 500 does *not* mean "Internal Server Error" in any meaningful sense.

For example, if the client ('Sender') sends an envelope to the server
('Receiver') that contains an element tagged with @mustUnderstand, and the
server actually does not understand that element, then the correct response
is a 500, with a fault message that contains:

  <env:Value>env:MustUnderstand</env:Value>

in the envelope body. Similarly, if the server is unable to process the
message for some reason, a 500 is also generated, and this time env:Value is
set to env:Sender.

These are the faults at the level of SOAP, and the next step is to transport
those via HTTP. Interestingly enough, the status code used is 500 for
everything *except* a client-originated fault. And it would be perfectly
legitimate to reply to a request to add a customer that already exists with
a 'BadArgument' fault.

Indeed the SOAP 1.2 Primer gives an example of indicating a problem with
credit card details using exactly that approach:

  HTTP/1.1 500 Internal Server Error
  Content-Type: application/soap+xml; charset="utf-8"
  Content-Length: nnnn

  <?xml version='1.0' ?>
  <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
    <env:Body>
      <env:Fault>
        <env:Code>
          <env:Value>env:Sender</env:Value>
          <env:Subcode>
            <env:Value>rpc:BadArguments</env:Value>
          </env:Subcode>
        </env:Code>
        <env:Reason>
          <env:Text xml:lang="en-US">Processing error</env:Text>
          <env:Text xml:lang="cs">Chyba zpracování</env:Text>
        </env:Reason>
        <env:Detail>
          <e:myFaultDetails 
           xmlns:e="http://travelcompany.example.org/faults" >
            <e:message>Name does not match card number</e:message>
            <e:errorcode>999</e:errorcode>
          </e:myFaultDetails>
        </env:Detail>
      </env:Fault>
    </env:Body>
  </env:Envelope>


For more on this, take a look at the mapping of SOAP faults to HTTP status
codes:

  <http://www.w3.org/TR/soap12-part2/#tabresstatereccodes>


> Going down for maintenance (503) was just an example.

I'm not with you though...an example of what? It doesn't have the same
meaning in SOAP, as hopefully my explanation shows. That doesn't mean you
can't use 503, but all it can indicate *to a SOAP processor* is one of four
types of SOAP fault (the fifth type being signaled with 4xx codes).

Regards,

Mark


Mark Birbeck

Received on Wednesday, 26 October 2005 23:59:18 UTC