Re: wsa:FaultTo unusable for SOAP mustUnderstand faults

One of the outcomes of the Palo Alto meeting of the Async TF was Tony's
Timeline.  On this timeline, there is a point at which the [fault
endpoint] becomes "known", and faults can be sent there (actually, I
think I'm oversimplifying somewhat here).  Before that, most bets are
off.  For example, if I POST a request to an invalid URL, I'll get back
a 4xx response before anything even has a chance to look at the [fault
endpoint].  If I fire-and-forget a message to a bogus address, the
transport layer may or may not be able to tell me I did this.

The upshot is that we only know for sure that the [fault endpoint] MUST
be used in the case where a well-formed and properly addressed message
arrives and the receiver produces a fault based on this.  This would
certainly include, say, sending a negative number to a "real square
root" operation.  It might or might not include a complaint brought on
by an invalid refparam or some other bad header.

Your analysis shows that it /cannot /include errors with mustUnderstand
headers, putting them in the same class as transport errors, malformed
SOAP envelopes and such.  This may not be desirable, but it seems to be
a consistent reading of what we have.

Hugo Haas wrote:

>[ I realize that the LC period for Core+SOAP is over, but I believe
>  that the issue below is substantive and needs to be addressed. ]
>
>wsa:FaultTo has been designed for sending faults to a particular
>recipient.
>
>However, it seems that this mechanism doesn't work for SOAP
>mustUnderstand faults.
>
>Here is an example:
>
>  <S:Envelope>
>   <S:Header>
>     <wsa:To>
>      http://destination.example/
>     </wsa:To>
>     <wsa:Action>
>      http://action.example/
>     </wsa:Action>
>     <wsa:FaultTo>
>      <address>
>       mailto:faults@example.com
>      </address>
>     </wsa:FaultTo>
>     <x:YouDontKnowThisHeader mustUnderstand="true"/>
>   <S:Header>
>   <S:Body>
>     <b:foo/>
>   </S:Body>
>  </S:Envelope>
>
>I am making the hypothesis that the SOAP receiver will not understand
>x:YouDontKnowThisHeader, and will therefore fault with a
>mustUnderstand fault.
>
>The SOAP 1.2 processing rules state:
>
>[[
>
>  2.4 Understanding SOAP Header Blocks
>
>[...]
>
>   A SOAP header block MAY carry a mustUnderstand attribute information item (see 5.2.3
>   SOAP mustUnderstand Attribute). When the value of such an attribute information item
>   is "true", the SOAP header block is said to be mandatory.
>
>   Mandatory SOAP header blocks are presumed to somehow modify the semantics of other
>   SOAP header blocks or SOAP body elements. Therefore, for every mandatory SOAP header
>   block targeted to a node, that node MUST either process the header block or not
>   process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP
>   Messages and 5.4 SOAP Fault). Tagging SOAP header blocks as mandatory thus assures
>   that such modifications will not be silently (and, presumably, erroneously) ignored by
>   a SOAP node to which the header block is targeted.
>
>]]
>
>and further:
>
>[[
>
>  2.6 Processing SOAP Messages
>
>   This section sets out the rules by which SOAP messages are processed. Nothing in this
>   specification prevents the use of optimistic concurrency, roll back, or other
>   techniques that might provide increased flexibility in processing order. Unless
>   otherwise stated, processing of all generated SOAP messages, SOAP faults and
>   application-level side effects MUST be semantically equivalent to performing the
>   following steps separately, and in the order given.
>
>    1. Determine the set of roles in which the node is to act. The contents of the SOAP
>       envelope, including any SOAP header blocks and the SOAP body, MAY be inspected in
>       making such determination.
>
>    2. Identify all header blocks targeted at the node that are mandatory.
>
>    3. If one or more of the SOAP header blocks identified in the preceding step are not
>       understood by the node then generate a single SOAP fault with the Value of Code
>       set to "env:MustUnderstand" (see 5.4.8 SOAP mustUnderstand Faults). If such a
>       fault is generated, any further processing MUST NOT be done. Faults relating to
>       the contents of the SOAP body MUST NOT be generated in this step.
>
>[...]
>
>]]
>
>Based on this, as the SOAP receiver realizes in step 3 above that it
>does not understand x:YouDontKnowThisHeader which is a mandatory
>header block, the message will not be processed at all, which includes
>all WS-Addressing SOAP Header Blocks, and therefore wsa:FaultTo will
>*not* be used to send the fault to mailto:faults@example.com.
>
>I believe that marking wsa:FaultTo as mandatory and trying to modify
>the SOAP processing rules in our spec as part of understanding it to
>make sure a WS-Addressing knowledgeable processor will act on
>wsa:FaultTo whatever happens is likely not to work, as the processing
>won't go past step 3 if there's an ununderstandable header around.
>
>One work-around *might* be to present the wsa:FaultTo (as well as
>other WS-Addressing headers, namely wsa:ReplyTo, wsa:MessageId,
>wsa:Action) as metadata which is populated in a way which falls out of
>the processing of SOAP header blocks.
>
>In a way, our spec is half-way there by not using the word processing:
>
>[[
>
>   When receiving a message, the abstract properties are populated from their
>   corresponding element information items in the message.
>
>]]
>
>However, I believe that it is close to abusing the SOAP specification
>as it's hard to argue that reading the metadata which can be found in
>SOAP header block and changing the processor's behavior based on it
>does not mean processing the SOAP header blocks.
>
>At this point, I'm afraid that I don't have a concrete proposal for
>how to use wsa:FaultTo with mustUnderstand faults while following the
>SOAP processing model to the letter.
>
>In any case, we need to:
>- talk about processing of headers in our SOAP binding document to
>  clarify how our spec fits into the SOAP processing model; in
>  particular, clarify what happens in case of a mustUnderstand fault:
>  is a wsa:FaultTo;
>- add the above example message to the test suite with the appropriate
>  reference to our spec.
>
>Cheers,
>
>Hugo
>
>  
>