Re: Comments on SOAP 1.2 Part 1

Hi Anne.

I think that I can shed some light on one of your comments:

* Anne Thomas Manes <atm@systinet.com> [2002-07-18 13:01-0400]
> 2.4 Understanding SOAP Headers. Question.
> Is it true that if a "mustUnderstand" header is targeted at a specific role,
> but the message is never routed through a node that assumes that role, then
> the header is never processed, and the Ultimate Receiver can simply ignore
> it?

This is correct. As section 2.4 says[1]:

|   The mustUnderstand attribute information item is not intended as a
|   mechanism for detecting errors in routing, misidentification of nodes,
|   failure of a node to serve in its intended role(s), etc. Any of these
|   conditions can result in a failure to even attempt processing of a
|   given SOAP header block from a SOAP envelope. This specification
|   therefore does not require any fault to be generated based on the
|   presence or value of the mustUnderstand attribute information item on
|   a SOAP header block not targeted at the current processing node. In
|   particular, it is not an error for an ultimate SOAP receiver to
|   receive a message containing a mandatory header block that is targeted
|   at a role other than the ones assumed by the ultimate SOAP receiver.
|   This is the case, for example, when a header block has survived
|   erroneously due to a routing or targeting error at a preceding
|   intermediary.

The processing model[2] is clear. Paraphrasing it:
- identify the blocks that are targeted at you.
- process mandatory blocks in this set or fail.
- process or not the rest of those blocks.

> Is there a way to specify that a message must not be processed if
> certain headers have not been processed (i.e., a true "mandatory" header)?

One could define a simple SOAP extension, targeted at the ultimate
receiver, marked as mandatory, and whose semantic would be: if there
is any mandatory block in this SOAP message that are not targeted at
you, the ultimate destination, then fail.

> Or is this left as an undefined extension feature or a proprietary SOAP
> server feature?

Actually, I think that the specification leaves it open:

|    This specification therefore does not require any fault to be
|    generated based on the presence or value of the mustUnderstand
|    attribute information item on a SOAP header block not targeted at
|    the current processing node.

So according to this sentence, a processor could choose to treat this
as a fault, but the processing model doesn't say anything about it. It
does not require a SOAP processor to do it, but doesn't rule it out
either.

I would go for asking the XML Protocol Working Group to clarify this
in order to have sections 2.4 and 2.6 in sync about that.

My preference would be to just not permit the server to optionally
take the decision to do this check: if the first SOAP intermediary my
message goes through does such an overzealous check, my message may
never go further than this first node. I think that this is an
interoperability risk.

Regards,

Hugo

  1. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#muprocessing
  2. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#procsoapmsgs
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

Received on Friday, 19 July 2002 09:17:33 UTC