SOAP issue - mustUnderstand Fault

[I'm not sure if this has been brought up before on this list, but there was
some discussion of this quite a while ago on the SOAP list, which I don't
believe was adequately resolved.]

The SOAP spec indicates that a processor must return a MustUnderstand fault
if it does not understand any headers marked mustUnderstand="1".  However,
it does not go into any further detail about the structure or content of the
fault information, except for stating that the "detail" element may NOT be
used to convey information about header-related faults.

My issue with this involves the fact that I would really like to be able to
build implementations that can intelligently "fall back" to simpler messages
when particular extensions are not understood.  For example (namespaces
elided for clarity):

<envelope>
 <header>
  <myNS:encryptBody mustUnderstand="1" />
  <otherNS:receiptRequested mustUnderstand="1">
   <deliverTo>http://my.com/receipts</deliverTo>
  </otherNS:receiptRequested>
 </header>
 <body>
  dk9f3nmv9jgjdf83hr83yt5iedosodkfjioej
 </body>
</envelope>

If this message generates a MustUnderstand fault, I have no way of knowing
in any standard fashion what combination of the two mustUnderstand headers
was the cause of the problem.  It's certainly possible to send back this
information encoded in the <faultcode> (i.e.
"MustUnderstand.myNS:encryptBody" or the like), but a) that's kind of a
hack, and b) most engines aren't going to support this by default.

If I *could* get this information, and know that the "encryptBody" header
was the problem, I might for instance ask a human whether it's OK to send
this particular request unencrypted, and then continue if so.  As is, all I
can tell is that the request failed.

I'd like to raise this is as a potential issue that I don't see on the
issues list at present.

--Glen

Received on Saturday, 14 April 2001 18:55:56 UTC