Loading ...
Sorry, an error occurred while loading the content.

10760Re: [soapbuilders] Multiple WS-Addresses in multiple namespaces

Expand Messages
  • noah_mendelsohn@us.ibm.com
    Feb 8, 2007
      Steve Loughran writes:

      > 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

      Well, my reading of the ws-i basic profile is that it says the same thing
      regarding SOAP 1.1 [1]:

      "R1025 A RECEIVER MUST handle messages in such a way that it appears
      that all checking of mandatory header blocks is performed before any
      actual processing. "

      Like so much in the basic profile, it takes the SOAP 1.2 refinements to
      the processing model, and mandates their use with SOAP 1.1.

      > > "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:

      Well, I'm not sure what to say. The spec is clear that you must inspect
      the headers first, and I think there are defensible reasons for that. I
      believe most of the commercial implementations (not speaking for my
      employer, IBM here) are moving toward a model in which headers are
      buffered so that mU checking can be done and header processing
      appropriately ordered, but the body is not necessarily parsed and
      processed in advance. Thus, the body can be streamed, but not the

      > 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.

      To be precise, headers are empowered to change the interpretation of other
      parts of the message, or to affect whether you can "understand" other
      headers in the message, but NOT to transform the message. In particular,
      I don't see anything that says a header can cause parts of the message to
      be decrypted or decompressed in a manner that would lead to the appearance
      of new headers that were processed as if they were there from the start.

      What I do think is there implicitly for such cases is for the
      specification of a header to say: when I am present, the SOAP processing
      model is to be rerun from the start on a new infoset constructed in the
      following way (e.g. by decrypting parts of the current.) In a given
      single use of the SOAP processing model, the input envelope infoset is
      invariant, but the interpretations of the headers present may interact.
      Indeed, it's crucial that they do. Surely a digital signature header
      affects the semantics of that which is signed, in the sense that if the
      dsig doesn't check, you may want to act as if none of the other headers
      are there (since they may be the result of tampering.) SOAP is designed
      to enable such scenarios, as long as the specification for the header (in
      this case a dsig header) is written properly.

      > 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.

      Whether you wish your implementation to expose that full power is up to
      you. HOWEVER, if you do not, then the only conforming response is for you
      to act as if you do not in fact "understand" any headers that might
      conceivably have such interacting semantics that you can't handle. So,
      unless you know that a header doesn't affect others, then if it's mU
      you'll either have to mU fault or be nonconforming to ws-i basic profile
      and/or SOAP 1.2.

      > > 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.

      Yes, well, I have many concerns about how the higher level WS* specs were
      written, and whether they took sufficient care to use SOAP's details
      properly. I'm sorry that's in fact causing you trouble.

      > -steve



      Noah Mendelsohn
      IBM Corporation
      One Rogers Street
      Cambridge, MA 02142
    • Show all 14 messages in this topic