On 2/7/07, noah_mendelsohn@... <noah_mendelsohn@...> wrote:
."
>
> Furthermore, and this is crucial, while SOAP itself mandates no fixed
> order when processing, headers can be defined to control the order [1]:
>
> "The processing of one or more SOAP header blocks MAY control or determine
> the order of processing for other SOAP header blocks and/or the SOAP body.
> For example, one could create a SOAP header block to force processing of
> other SOAP header blocks in lexical order. In the absence of such a
> controlling SOAP header block, the order of header and body processing is
> at the discretion of the SOAP node. Header blocks MAY be processed in
> arbitrary order. Header block processing MAY precede, MAY be interleaved
> with, or MAY follow processing of the SOAP body. For example, processing
> of a "begin transaction" header block would typically precede body
> processing, a "logging" function might run concurrently with body
> processing and a "commit transaction" header block might be honored
> following completion of all other work."
>
> This is not an accident. It's why we require that all mustUnderstand
> checking be done before any other work. That's what ensures you that if
> you have an mU header that says "do the headers in reverse order" or
> "alphabetical order" or more likely "do signatures first" then that
> header or those headers will necessarily be checked in time to determine
> an order.
>

aah. Soap1.2. Soap 1.1 says nothing about where the headers are
validated, only that they must be validated

"A env:mustUnderstand value of "true" means that the SOAP node must
process the header with the semantics described in that header's
specification, or else generate a SOAP fault. Processing the header
appropriately may include removing the header from any generated SOAP
message, reinserting the header with the same or altered value, or
inserting a new header. The inability to process a mandatory header
requires that all further processing of the SOAP message cease, and a
SOAP fault be generated. The message is not forwarded any further."

This is why the release of Axis (1.0?) that didnt do mU checking until
after the message had been handled was within the spirit of the spec,
and not the law.

SOAP1.2 implies that I must check all mu headers before having any
side effect at all. hmm. My current stack lets you declare handlers in
a chain, as axis has done forever, and sun's stack has done since last
week:

AddressedEchoEndpoint extends AlpineEndpoint {
name "wsa-echo";
handlers [
LogCurrentMessageHandler:classname,
AddressHandler:classname,
MustUnderstandChecker:classname,
EchoHandler:classname,
LogCurrentMessageHandler:classname
];
}

There's no way with this chain-of-resposibility design to do advance
checking of handling, or guarantee that there are no side effects (I
log the message -is that a side effect?), before the message is handed
for processing.

I suppose I could modify the handler interface to add an extra method
in which every handler indicates if it will process a specific mU
header. But if every handler is empowered to transform the incoming
message during its work phase, things get complex. You need to create
a provisionally transformed doc (transform, without side effects) just
to make sure the mu headers get processed right.

Or I ignore that part of the spec on the grounds that its pretty much
impossible for interop tests to catch and retain my existing
SOAP1.1-compatible mU processing algorithm.

> Furthermore, and this is the part I really wish had been highlighted a bit
> more, nothing says these must be separate headers. So, IMO, if you want
> to say >in the specification for wsa:To< "if there are multiple wsa:To
> headers, here's the rule for how to process them all in the presence of
> the others", you can do so. If they are marked mU then you can be sure
> that, at least per the SOAP spec, their specifications can conspire to
> determine an order.
>

well, its a shame they dont.

-steve