Re: Finding Faults in headers

Hello,

This topic was discussed some time ago on the DM list. [1]

The short answer was:

Headers (the body is semantically a header with 
mustUnderstand="1" and targeted at the "default actor") are 
orthogonal in their purpose. Respecting this principle, it would be 
bad for the Fault to carry "detail" info about *header* faults... this 
properly belongs in a header element that is contained in the same 
SOAP envelope in which the "Fault" is contained. In this way the 
responsible header handler code will have a chance to see it. This 
fault header element would be a component of the overall "module". 
For instance, WSDL supports explicit declaration of 
"soap:headerfault" elements to support this approach.

For instance, in the digest authentication scheme used here by 
SOAP based apps, an expired authentication token presented by a 
client (in a header entry) results in a Fault message. Since the 
auth scheme is implemented as a header based "module", the 
Fault message contains no details. Rather, the Fault message 
envelope contains header entries whose content represents the 
"details" of the fault, such as the error code and the new challenge 
token needed to compute another authentication token.

Since the fault details are contained in headers, the component 
responsible for processing the header entries which support the 
"module" (including special "fault" headers), has the opportunity to 
process them. Besides the design principle of "orgthogonality", in 
practice I find that this is the best approach since the code that 
processes header entries is different from that which processes the 
body, at least in our implemention design.

I write in haste, does this make sense?

RC

[1] 
http://discuss.develop.com/archives/wa.exe?A2=ind0006&L=SOAP
&D=0&P=82252
[2] http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:header

> I'd like to understand *why* Fault/detail cannot carry information about
> headers?  The spec also doesn't say what *should* be done.  I know
> that's an open issue, and browsing the email archive I didn't see any
> followup to Glenn's original post that caused the issue to be added.
> 
> At any rate, knowing *why* would help figure out what should be done. 
> For now, I'm included to add descripting text to the Fault/faultstring,
> and perhaps define a header that re-uses faultcode and detail.  I'll go
> ask for ideas about that on the soapbuilders list.
> 	/r$

Received on Tuesday, 22 May 2001 11:21:04 UTC