RE: An analysis of mustUnderstand and related issues

Hello,

From Noah's long note:

<snip>

> A proposal for next steps
> -------------------------
> 
> The first question, of course, is whether I have correctly understood
> Henrik's position and proposal, and have correctly interpreted the SOAP
> specification.  If not, we have to store that out.
> 
> If so I would reword Henrik's summary as suggesting that "all
> mustUnderstand failures are noticed before any processing is attempted".  I
> think that is what he intends, and I believe it would solve Glen's problem.
> I am concerned, however, that such a rule makes streaming extremely
> difficult.  I think this says that you cannot safely do any processing
> until you encounter at least the start of the Body.  I suppose if we expect
> headers, collectively, to be short, that is not a big problem.  It
> certainly changes my reading of the specification.
> 
> So, step 2 is to decide whether the requirement to inspect all headers
> before doing any processing is indeed practical.  I think this is a
> question that should be discussed with soapbuilders.
> 
</snip>

Regarding step 2, isn't it true that we don't know if a header has 
been "understood" until processing has been attempted?

The spec says that not only must the semantics of the header be 
obeyed, but also that processing must be successful [1]. If not, a 
SOAP-ENV:MustUnderstand fault must be generated.

This would make it impossible to "notice any mustUnderstand 
failures before any processing is attempted", without changing 
Section 4.2.3 of the spec.

From an implemention standpoint, until the header handler has 
returned "success" for a header, one is never sure that it has been 
"understood". The SOAP processor certainly knows nothing of the 
semantics of the header, only the responsible handler.

Given the current state of the spec, there seems to be no escape;
until a header has been processed, you don't know if it is 
"understood". But by then it's too late... other headers may have 
already been processed, and state changed somewhere.

RC

[1] http://www.w3.org/TR/SOAP/#_Toc478383500

Received on Friday, 25 May 2001 12:13:25 UTC