RE: Handling mustUnderstand Headers

From: Kevin Jones <>
Date: Thu, 9 Oct 2003 23:20:36 +0100


I'm convinced. It seems to me that there is no way for the RI to know
whether an MU=1 handler has been properly processed, so the best call it
to assume it is properly processed so long as I have a handler chain
registered for it. Unless the SOAP spec is clearer on this (and I
haven't looked at 1.2 closely enough to know), there's not much else
that can be done.

> Hmmm... that may be the version, or maybe just which tool was used. I
> was using jwsdp-1.2 and generating server code with wscompile and
> received an error. If you didn't even get a warning, that may
> be a place
> we should add in some kind of message. I'll look into it some more.

I'll also check again. I'm using the current release (1.2), and I'm sure
this was the behaviour I was seeing.

Thanks again Bobby,

Kevin Jones

> -----Original Message-----
> From: Bobby Bissett - Javasoft []
> Sent: 09 October 2003 18:40
> To:
> Subject: Re: Handling mustUnderstand Headers
> >
> >>It
> >>just may be that there are cases where doing the wrong thing in a
> >>handler (leaving "actor" header elements in the message)
> doesn't cause
> >>problems.
> >
> > Sure - seems like a bug in the RI though - it should be
> consistent. I
> > either need to detach headers or I don't.
> The short answer: you always need to detach headers, except when you
> don't <grin>. That's basically the contract of an intermediary and a
> header processed by it.
> I think the RI is consistent, though it just might be my way
> of looking
> at it. If a header comes in to a chain that should be understood but
> isn't, you get a fault. If a header comes in to a chain that
> either is
> understood or can be ignored, you don't get a fault. It works
> the same
> way with the endpoint, whether the message came through a
> chain first or
> not.
> Here's another way to view this idea of having the implementation do
> some checking: imagine you have a handler that declares that it
> understands a certain header, but the handleRequest() method simply
> returns true and does nothing else. Is that an error? It will be if
> there's no "contract" with someone else down the line to handle it,
> otherwise it won't be. There's no way for the runtime to know
> this kind
> of thing without adding another layer of complexity to a
> situation that
> I don't think needs it (you *do* get an error from the
> runtime -- it's
> the MustUnderstand fault from the endpoint in our original case).
> I can see that it would be nice to have some way to tell the
> users that
> they forgot to detach the node, as that's a small point in
> the SOAP spec
> and is something that I think everyone will forget to do at
> least once
> (I've done it), but I just don't see an easy way to produce a
> DidntDetachNodeException instead of the MU fault that can
> result instead.
> >
> > [...] it
> > should then say, did something process this (by detaching
> the header).
> Processing a header does not necessarily imply detaching it,
> since you
> can leave in a "similar" header according to the SOAP spec. So the
> concept of checking to see if headers were removed doesn't solve the
> problem. (Also, checking the messages headers after each
> handler would
> be some more overhead.)
> > It may be, for example, that the handler understood the
> header element
> > and not the details, it can't throw an exception because
> the actor is
> > registered for a chain *not* a single handler, so something
> further down
> > may understand this header. If nothing removes the header
> then throw and
> > exception and process the response chain.
> I know I'm repeating myself, but I didn't want to leave out
> your example
> here. Just as a small point, a handler can throw an exception
> any time
> it likes, so there may be cases where you declare that you
> understand a
> header element but then don't understand the data. Anyway, per your
> example, handler1 may not understand the header but can just
> ignore it
> as it goes by, and then handler2 can process it and detach
> it. But there
> may be cases where you don't want to detach it, primarily if
> there's a
> contract with the endpoint to put in a "similar header." So
> if the impl
> did a check and threw an exception for you, it would limit
> things that
> you ought to be able to do (and therefore be noncompliant
> with the SOAP
> spec). If your handler does the wrong thing, the error you get is the
> fault from the endpoint.
> >
> > Again we may be talking at cross-purposes but messages with
> MU=1 and an
> > actor are *not* passed to a handler chain if the chain has not
> > registered interest in those handlers (through getHeaders)
> Yep -- if the chain says that it plays the role of the actor
> in question
> but it can't do what the message wants it to do, then a fault
> is thrown
> and no further processing occurs. Same thing with endpoint.
> >
> > That's not what I'm seeing. If I have two chains defined in
> > jaxrpc-ri.xml, like this:
> Cheers,
> Bobby
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail: