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

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

Expand Messages
  • John Kemp (Nokia-NRC/Williamstown)
    Hi Steve, ... Looking at this practically - if the correct WSA (and other) headers are present (and in the SAME namespace), then it seems possible that the
    Message 1 of 14 , Jan 29, 2007
    • 0 Attachment
      Hi Steve,

      ext Steve Loughran wrote:
      >
      >
      > I know having more than <wsa:To> or wsa:MessageID header in your Soap
      > message is a nono, for any binding of wsa: to the various draft and
      > final WS-A releases.
      >
      > But what happens if someone sends your stack a message with multiple
      > wsa headers in different xml namespaces?
      >
      > <wsa2005:To />
      > <wsa2003:To />
      > <wsa2004:To />

      Looking at this practically - if the correct WSA (and other) headers are
      present (and in the SAME namespace), then it seems possible that the
      SOAP receiver can attempt a response. In other words, if the receiver
      gets a wsa:To header it understands, it might attempt to otherwise
      process the other headers, and message.

      If my implementation received such a message (with mismatched WSA
      namespaces, or multiple WSA headers from different namespaces), I'd have
      to say that I would imagine that either a) there is a bug in the SOAP
      sender's code or b) someone is sending me garbage in order to DoS my
      system. So, it's quite possible that I would choose to either reject the
      message, with an mU fault on the header (or headers) that my stack
      didn't understand, or simply drop the message.

      I think all of those are actually valid responses (success, because you
      got what you need, but extra headers you didn't need, or failure with
      explicit indication or not).

      In all of the above cases, I consider this a bug in the sender's code,
      in which case, the sender should expect varied behaviour from various
      stacks.

      Or do you think there are ever valid reasons for including multiple
      wsa:To (or other WSA in different namespaces) headers in a message?

      Regards,

      - John
    • Steve Loughran
      ... Yes, I am thinking of how best to handle the situation on my end. I currently work back from newest to oldest namespaces looking for a match, and ignore
      Message 2 of 14 , Jan 29, 2007
      • 0 Attachment
        On 1/29/07, John Kemp (Nokia-NRC/Williamstown) <John.Kemp@...> wrote:
        > Hi Steve,
        >
        > ext Steve Loughran wrote:
        > >
        > >
        > > I know having more than <wsa:To> or wsa:MessageID header in your Soap
        > > message is a nono, for any binding of wsa: to the various draft and
        > > final WS-A releases.
        > >
        > > But what happens if someone sends your stack a message with multiple
        > > wsa headers in different xml namespaces?
        > >
        > > <wsa2005:To />
        > > <wsa2003:To />
        > > <wsa2004:To />
        >
        > Looking at this practically - if the correct WSA (and other) headers are
        > present (and in the SAME namespace), then it seems possible that the
        > SOAP receiver can attempt a response. In other words, if the receiver
        > gets a wsa:To header it understands, it might attempt to otherwise
        > process the other headers, and message.
        >
        > If my implementation received such a message (with mismatched WSA
        > namespaces, or multiple WSA headers from different namespaces), I'd have
        > to say that I would imagine that either a) there is a bug in the SOAP
        > sender's code or b) someone is sending me garbage in order to DoS my
        > system. So, it's quite possible that I would choose to either reject the
        > message, with an mU fault on the header (or headers) that my stack
        > didn't understand, or simply drop the message.

        Yes, I am thinking of how best to handle the situation on my end. I
        currently work back from newest to oldest namespaces looking for a
        match, and ignore any others, leaving it up to the mU processing to
        handle To or messageID headers marked mU=true that arent being picked
        up.

        But I'm thinking of catching the explicit problem and rejecting it.

        > I think all of those are actually valid responses (success, because you
        > got what you need, but extra headers you didn't need, or failure with
        > explicit indication or not).
        >
        > In all of the above cases, I consider this a bug in the sender's code,
        > in which case, the sender should expect varied behaviour from various
        > stacks.
        >
        > Or do you think there are ever valid reasons for including multiple
        > wsa:To (or other WSA in different namespaces) headers in a message?

        Well, there was some stuff in the early specs for relay related stuff,
        but that stuff was pulled.

        However, there is always the problem of talking to a remote endpoint
        whose up-to-dateness is unknown. In that world I could start at
        2003/03 or 2004/04, or I could send all three addresses in
        triplicate, all headers marked mU=false, secure in the knowledge that
        one of them will be picked up.

        -steve
      • John Kemp (Nokia-NRC/Williamstown)
        ... That seems reasonable... ... That seems reasonable too ;) ... Right. I just don t think you should feel too secure about sending all three together. It
        Message 3 of 14 , Jan 29, 2007
        • 0 Attachment
          ext Steve Loughran wrote:

          >>
          >> If my implementation received such a message (with mismatched WSA
          >> namespaces, or multiple WSA headers from different namespaces), I'd have
          >> to say that I would imagine that either a) there is a bug in the SOAP
          >> sender's code or b) someone is sending me garbage in order to DoS my
          >> system. So, it's quite possible that I would choose to either reject the
          >> message, with an mU fault on the header (or headers) that my stack
          >> didn't understand, or simply drop the message.
          >
          > Yes, I am thinking of how best to handle the situation on my end. I
          > currently work back from newest to oldest namespaces looking for a
          > match, and ignore any others, leaving it up to the mU processing to
          > handle To or messageID headers marked mU=true that arent being picked
          > up.

          That seems reasonable...

          >
          > But I'm thinking of catching the explicit problem and rejecting it.

          That seems reasonable too ;)

          >
          >> I think all of those are actually valid responses (success, because you
          >> got what you need, but extra headers you didn't need, or failure with
          >> explicit indication or not).
          >>
          >> In all of the above cases, I consider this a bug in the sender's code,
          >> in which case, the sender should expect varied behaviour from various
          >> stacks.
          >>
          >> Or do you think there are ever valid reasons for including multiple
          >> wsa:To (or other WSA in different namespaces) headers in a message?
          >
          > Well, there was some stuff in the early specs for relay related stuff,
          > but that stuff was pulled.
          >
          > However, there is always the problem of talking to a remote endpoint
          > whose up-to-dateness is unknown. In that world I could start at
          > 2003/03 or 2004/04, or I could send all three addresses in
          > triplicate, all headers marked mU=false, secure in the knowledge that
          > one of them will be picked up.

          Right. I just don't think you should feel too secure about sending all
          three together. It might work, it might not, and I do think it's
          reasonable for a receiver to fail your request, even if otherwise valid.

          I'm not very knowledgeable about WSDL, but perhaps it would be helpful
          if the wsaw:UsingAddressing element (of the WS-A WSDL binding) helped a
          sender determine the specific /version(s)/ of WS-A in use by a remote
          endpoint, rather than being an empty element?

          - John
        • illsleydc
          Steve, The WS-A implementations I have knowledge of both take the (c) approach and only process one namespace. This means that when mustUnderstand processing
          Message 4 of 14 , Jan 29, 2007
          • 0 Attachment
            Steve,
            The WS-A implementations I have knowledge of both take the (c)
            approach and only process one namespace. This means that when
            mustUnderstand processing is done, the headers from the namespace(s)
            which weren't chosen will cause a mU fault.

            I've debated this a few times and I think this is a resonable
            compromise between strictness (when the client mandates it) and
            allowing clients to send ignorable xml if they have a cunning plan.

            David.

            P.S. When ws-security for any ws-a headers is used, the choice for (c)
            should only be from headers which were secured.

            --- In soapbuilders@yahoogroups.com, "Steve Loughran"
            <steve.loughran.soapbuilders@...> wrote:
            >
            > I know having more than <wsa:To> or wsa:MessageID header in your Soap
            > message is a nono, for any binding of wsa: to the various draft and
            > final WS-A releases.
            >
            > But what happens if someone sends your stack a message with multiple
            > wsa headers in different xml namespaces?
            >
            > <wsa2005:To />
            > <wsa2003:To />
            > <wsa2004:To />
            >
            > Do stacks
            > (a) reject it as something explicitly forbidden in WS-A
            > (b) reject it as something users shouldnt be doing
            > (c) pick one of the addresses at random and use it
            > (d) verify that the addresses are all consistent
            >
            > The spec says "A message MUST NOT contain more than one wsa:To,
            > wsa:ReplyTo, wsa:FaultTo, wsa:Action, or wsa:MessageID header targeted
            > at a recipient" but it also declares wsa to be mapped to
            > http://www.w3.org/2005/08/addressing, and pretends that none of the
            > drafts ever got implementing in shipping code.
            >
            > I suspect that outcome (c) is the default one, but I am not convinced
            > it is the right one...
            >
            > -Steve
            >
          • Paul Downey
            Hi Steve ... I raised this very issue in my position paper [1] to the W3C Workshop on Enterprise computing, and see it as a fundamental consequence of SOAP not
            Message 5 of 14 , Jan 30, 2007
            • 0 Attachment
              Hi Steve
              > But what happens if someone sends your stack a message with multiple
              > wsa headers in different xml namespaces?
              >
              > <wsa2005:To />
              > <wsa2003:To />
              > <wsa2004:To />
              I raised this very issue in my position paper [1] to the W3C Workshop
              on Enterprise computing, and see it as a fundamental consequence
              of SOAP not having a "stack", but a "bag" (actually a graph with WSS)
              which requires meta-data such as the much trumpeted WS-Policy to
              unravel.

              I guess you could send all three to handle versioning in the recipient,
              but mostly it's going to spell doom, especially if

              wsa2004:Action says "getCustomerInfo",
              wsa2005:Action says "fireNuclearMissiles",

              and your XML Gateway and Service are out of sync .. boom!

              It gets worse if you consider the old Action could have been
              signed and the new one does the deed.

              The order of SOAP headers should have been made significant IMO.

              Paul
              --
              http://blog.whatfettle.com

              [1] http://www.w3.org/2007/01/wos-papers/bt


              --
              http://blog.whatfettle.com
            • Glen Daniels
              Hi Paul! ... While I don t necessarily disagree with this (and believe me, the discussion as to processing order was a big one back in the early days of XMLP),
              Message 6 of 14 , Jan 30, 2007
              • 0 Attachment
                Hi Paul!

                You wrote:
                > Hi Steve
                > > But what happens if someone sends your stack a message with multiple
                > > wsa headers in different xml namespaces?
                > >
                > > <wsa2005:To />
                > > <wsa2003:To />
                > > <wsa2004:To />
                > I raised this very issue in my position paper [1] to the W3C Workshop
                > on Enterprise computing, and see it as a fundamental consequence
                > of SOAP not having a "stack", but a "bag" (actually a graph with WSS)
                > which requires meta-data such as the much trumpeted WS-Policy to
                > unravel.
                > [...]
                > The order of SOAP headers should have been made significant IMO.

                While I don't necessarily disagree with this (and believe me, the
                discussion as to processing order was a big one back in the early days
                of XMLP), I'm also not sure how having a processing order would save you
                here.

                There are two cases when you have two headers. Either you understand
                them both (i.e. have both versions installed) or you only understand
                one. Assuming nothing is marked MU=true here, the second case is simple
                in that you'll only process one and therefore order doesn't matter.

                In the first case, which is the interesting one, you'd still have an
                issue even if SOAP said "process in lexical order". The problem is that
                the WSA specs would need to say something like "if you support both this
                and previous versions, you MUST NOT process the earlier version's
                headers if you see them". Otherwise you'd still just process the first
                WSA header then you'd process the second one, since you understand both.
                The SOAP spec itself can't (and arguably shouldn't) handle this kind
                of thing itself.

                Lexical ordering, or hierarchical headers, can help with things like
                "encrypt then compress" vs "compress then encrypt", but not really with
                versioning, as far as I can tell.

                Thanks,
                --Glen
              • Steve Loughran
                ... or you understand none, which again, is unimportant. ... Well, then -why didnt WS-A to have some guidelines for the problem. Given that the WS-RF 1.0 spec
                Message 7 of 14 , Jan 30, 2007
                • 0 Attachment
                  On 1/30/07, Glen Daniels <glen@...> wrote:
                  > There are two cases when you have two headers. Either you understand
                  > them both (i.e. have both versions installed) or you only understand
                  > one. Assuming nothing is marked MU=true here, the second case is simple
                  > in that you'll only process one and therefore order doesn't matter.
                  >

                  or you understand none, which again, is unimportant.

                  > In the first case, which is the interesting one, you'd still have an
                  > issue even if SOAP said "process in lexical order". The problem is that
                  > the WSA specs would need to say something like "if you support both this
                  > and previous versions, you MUST NOT process the earlier version's
                  > headers if you see them". Otherwise you'd still just process the first
                  > WSA header then you'd process the second one, since you understand both.
                  > The SOAP spec itself can't (and arguably shouldn't) handle this kind
                  > of thing itself.

                  Well, then -why didnt WS-A to have some guidelines for the problem.

                  Given that the WS-RF 1.0 spec depends on two different drafts of WS-A,
                  surely it should have been obvious that there were going to be legacy
                  addresses out there.

                  Life is so much simpler with URLs. You cannot post a request to three
                  different URLs, and if you use the element in the message body to
                  select your action, its inherently impossible to hae duplicate
                  payloads.

                  -steve
                • Glen Daniels
                  Hi Steve: ... I agree, and I would suggest that feedback/errata be offered to the WSA working group. I haven t had time to scan the archives, but I m sure
                  Message 8 of 14 , Feb 1, 2007
                  • 0 Attachment
                    Hi Steve:

                    Steve Loughran wrote:
                    > > The SOAP spec itself can't (and arguably shouldn't) handle this kind
                    > > of thing itself.
                    >
                    > Well, then -why didnt WS-A to have some guidelines for the problem.
                    >
                    > Given that the WS-RF 1.0 spec depends on two different drafts of WS-A,
                    > surely it should have been obvious that there were going to be legacy
                    > addresses out there.

                    I agree, and I would suggest that feedback/errata be offered to the WSA
                    working group. I haven't had time to scan the archives, but I'm sure
                    this came up during the course of the WG discussions (not that you'd
                    know it by reading the specs). It would be nice to see some mention of
                    how to deal with multiple versions in there.

                    > Life is so much simpler with URLs. You cannot post a request to three
                    > different URLs, and if you use the element in the message body to
                    > select your action, its inherently impossible to hae duplicate
                    > payloads.

                    I don't think this is a particularly valid comparison. It would be more
                    like adding multiple versioned HTTP headers rather than posting to
                    different URLs. The point of SOAP headers is that they modify, not
                    replace, the (potentially non-extensible) content of a message.

                    --Glen
                  • Steve Loughran
                    ... well, I shall modify my servlet engine to support multiple Host fields in the get request to make its http layer more consistent :)
                    Message 9 of 14 , Feb 1, 2007
                    • 0 Attachment
                      On 2/1/07, Glen Daniels <glen@...> wrote:
                      >
                      > > Life is so much simpler with URLs. You cannot post a request to three
                      > > different URLs, and if you use the element in the message body to
                      > > select your action, its inherently impossible to hae duplicate
                      > > payloads.
                      >
                      > I don't think this is a particularly valid comparison. It would be more
                      > like adding multiple versioned HTTP headers rather than posting to
                      > different URLs. The point of SOAP headers is that they modify, not
                      > replace, the (potentially non-extensible) content of a message.
                      >

                      well, I shall modify my servlet engine to support multiple Host fields
                      in the get request to make its http layer more consistent :)
                    • noah_mendelsohn@us.ibm.com
                      ... One of my great regrets about the SOAP Recommendation is that it does not make crystal clear an aspect of the design that I considered to be very
                      Message 10 of 14 , Feb 6, 2007
                      • 0 Attachment
                        Paul Downey writes:

                        > I raised this very issue in my position paper [1] to the W3C Workshop
                        > on Enterprise computing, and see it as a fundamental consequence
                        > of SOAP not having a "stack", but a "bag" (actually a graph with WSS)
                        > which requires meta-data such as the much trumpeted WS-Policy to
                        > unravel.

                        One of my great regrets about the SOAP Recommendation is that it does not
                        make crystal clear an aspect of the design that I considered to be very
                        important. Still, the crucial function is there IMO:

                        First of all, it's not true that what SOAP has is a "bag"; the header
                        elements are siblings in an envelope Infoset, and the Infoset is ordered.
                        Also, headers may have interacting semantics [1] :

                        "Mandatory SOAP header blocks are presumed to somehow modify the semantics
                        of other SOAP header blocks or SOAP body elements."

                        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.

                        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.

                        In fact, what I really wanted to see in the recommendation would be a
                        statement along the lines of: "The specifications for headers that may
                        coexist in a SOAP message must collectively describe the correct
                        interpretation of the headers in combination as well as in isolation.
                        Thus, specifications may be written for families of headers designed to be
                        used together, to determine operation in the case where multiple instances
                        of the same header appear etc. Such specifications may call for a given
                        header to be "understood" only when accompanied or only if not accompanied
                        by certain other headers. etc."

                        I think that is in fact implicit in what is there, but obviously many
                        users have missed it. Whether the typical stacks out there provide much
                        help in supporting such combined interpretation and ordering is a
                        different question, but the spec definitely anticipates it IMO.

                        Noah

                        [1] http://www.w3.org/TR/soap12-part1/#muprocessing
                        [2] http://www.w3.org/TR/soap12-part1/#procsoapmsgs
                        --------------------------------------
                        Noah Mendelsohn
                        IBM Corporation
                        One Rogers Street
                        Cambridge, MA 02142
                        1-617-693-4036
                        --------------------------------------
                      • Steve Loughran
                        On 2/7/07, noah_mendelsohn@us.ibm.com wrote: . ... aah. Soap1.2. Soap 1.1 says nothing about where the headers are validated,
                        Message 11 of 14 , Feb 8, 2007
                        • 0 Attachment
                          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
                        • noah_mendelsohn@us.ibm.com
                          ... 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
                          Message 12 of 14 , Feb 8, 2007
                          • 0 Attachment
                            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
                            headers.

                            > 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

                            [1]
                            http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16468312



                            --------------------------------------
                            Noah Mendelsohn
                            IBM Corporation
                            One Rogers Street
                            Cambridge, MA 02142
                            1-617-693-4036
                            --------------------------------------
                          • Steve Loughran
                            ... Sometimes I suspect complexity is the underlying problem. Like WSDL. Its almost impossible for humans to write, so what you get is a mess, compared to,
                            Message 13 of 14 , Feb 8, 2007
                            • 0 Attachment
                              On 2/8/07, noah_mendelsohn@... <noah_mendelsohn@...> wrote:
                              > Steve Loughran writes:
                              >
                              > > On 2/7/07, noah_mendelsohn@...
                              > > <noah_mendelsohn@...> wrote: ."
                              >
                              >
                              > > > 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.
                              >

                              Sometimes I suspect complexity is the underlying problem. Like WSDL.
                              Its almost impossible for humans to write, so what you get is a mess,
                              compared to, say, COM IDL interfaces.

                              As for the higher order specs, well, I relish their inconsistency,
                              epecially WSRF, that has explicit dependencies on two different draft
                              WSA versions, and punts on the whole problem of whether not bulk
                              attribute read/write operations are atomic or not.

                              But that's an OASIS problem so I won't be giving my local TAG
                              representative a hard time, about it, or you. Liked your W3C
                              submission to the web of enterprisey services; interesting contrast to
                              the IBM 'we want a single stack' story.

                              -steve
                            Your message has been successfully submitted and would be delivered to recipients shortly.