Re: ISSUE: Where do faults go?

Exactly my point.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

David Hull <dmh@tibco.com> wrote on 03/13/2006 01:26:15 PM:

> If a wsa: header arrives mU=true, and I don't understand WSA, then, 
> well, I don't understand WSA.
> 
> So the question is what if I see a foo:SomeHeader mU=true, I don't 
> understand that, but I do understand WSA and there's a valid 
wsa:FaultTo?
> 
> In such a case, 2.4 of the SOAP 1.2 Messaging Framework says:
> Therefore, for every mandatory SOAP header block targeted to a node,
> that node MUST either process the header block or not process the 
> SOAP message at all, and instead generate a fault (see 2.6 
> Processing SOAP Messages and 5.4 SOAP Fault).
> From this I believe we have concluded that we can't use WSA 
> information -- as that would mean processing the SOAP message -- and
> instead have to rely on whatever the binding would do without WSA. 
> For a SOAP request-response MEP (regardless of how we got there), 
> that would generally mean use the response channel.  This is the 
> same thing we would get by defaulting to anonymous in WSA-land, but 
> we get there differently.  In a fire-and-forget case, this might 
> generally mean dropping the fault on the floor (or logging it, or 
> whatever, but generally not putting it on the wire).
> 
> To do anything different, it seems we would have to make a specific 
> exception to the usual SOAP processing model.  Presumably the usual 
> model is there for a reason.  For example, the not-understood foo: 
> header might say something important about disposition of faults in 
general.
> 
> At this point, it's probably more appropriate to look at this in the
> context of the SOAP "one-way MEP".  The behavior in the request-
> response case seems reasonable, and there's not much we can change 
> here at this point anyway.
> 
> Christopher B Ferris wrote: 
> 
> Dave, 
> 
> CIL below. 
> 
> Cheers, 
> 
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295 
> 
> public-ws-addressing-request@w3.org wrote on 03/13/2006 12:51:36 PM:
> 
> > How we handle faults, according to the current Editor's draft (I 
> > double-checked :-): 
> > SOAP processing failures (e.g. mU), are out of scope as always. 
> 
> por que? I can certainly appreciate that WS-A would not contradict SOAP 
> but why do you claim that this is out of scope? I would have expected 
that 
> the spec would be explicit in describing exactly how it composes with 
the 
> SOAP processing model. 
> 
> > If there are no SOAP processing failures, then 
> > If wsa:Action is absent, we don't say what happens.  (We only state 
> > the converse).  If WSA isn't engaged, disposition is out of scope. 
> > If it is, for whatever reason, see below. 
> > If wsa:Action is present, even if it's mangled, or multiply present,
> > or whatever, WSA is engaged. 
> > If WSA is engaged 
> > If wsa:FaultTo is absent, multiply present, or present but invalid, 
> > [fault endpoint] will be empty.  Otherwise it will have the given 
> > value.  I'm inferring this, but I don't see what else one could 
> > infer.  Perhaps we should state more sharply that getting two of 
> > something you can only have one of leaves it undefined. 
> > Likewise for wsa:ReplyTo. 
> > And the rules in 3.4 of the core apply.  If [fault endpoint] is 
> > empty, as it would be in Glen's case, we revert to [reply endpoint].
> > If wsa:ReplyTo had been missing, [reply endpoint] would be anon.  If
> > wsa:ReplyTo is also erroneous, [reply endpoint] is empty and 
> > behavior is undefined. 
> > IMHO, this is good enough.  If both wsa:FaultTo and wsa:ReplyTo are 
> > present and mucked up, we can't really guarantee your safety.  In 
> > any case, the spec as it stands seems unambiguous, given that 
> > duplicating wsa:FaultTo leaves [fault endpoint] undefined.  I can 
> > see cases where the left hand might add one wsa:FaultTo and the 
> > right hand add another, but this seems like a fairly basic failure 
> > in implementation that shouldn't make its way into production. 
> > Famous last words.
> > 
> > Working from a clean slate, I might want to handle this differently,
> > but at this stage I think we've done what we can.  As with other 
> > cases, we might want to make a few editorial changes to clarify 
> > what's going on.
> > 
> > 
> > Christopher B Ferris wrote: 
> > 
> > Glen, 
> > 
> > I would put this in the same class as "where do SOAP mU faults get 
> > delivered". I believe that that 
> > should be a function of the binding, not of WS-A because it is 
> > pretty clear to me that in the face 
> > of a SOAP mU (or VersionMismatch) fault, that WS-A processing cannot
> > be presumed to have 
> > been performed (per the SOAP1.2 spec anyway). 
> > 
> > Thus, I think that an endpoint that includes a non-anonymous [fault 
> > to] endpoint SHOULD expect 
> > that it MAY receive SOAP faults in a manner defined as the default 
> > for the relevant SOAP 
> > binding. In the case of the SOAP Req/Resp MEP and SOAP HTTP binding,
> > that would be 
> > the anonymous endpoint. 
> > 
> > IMO, if a SOAP message contains WS-A headers that are inconsistent 
> > with the spec in any way 
> > that the generated fault SHOULD be sent to the endpoint identified 
> > by the relevant SOAP 
> > MEP/binding. 
> > 
> > Cheers, 
> > 
> > Christopher Ferris
> > STSM, Software Group Standards Strategy
> > email: chrisfer@us.ibm.com
> > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> > phone: +1 508 377 9295 
> > 
> > public-ws-addressing-request@w3.org wrote on 03/13/2006 10:51:09 AM:
> > 
> > > 
> > > Hi folks:
> > > 
> > > Sorry for the last-minute issue, but this just came up as a result 
of
> > > testing....
> > > 
> > > In the test suite, we have a test [1] for generating a fault when a
> > > request message contains 2 <wsa:FaultTo> headers.  Imagine a message
> > > like:
> > > 
> > > <soap:Header>
> > >  <wsa:FaultTo>
> > > 
> > > 
<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address
> > > >
> > >  </wsa:FaultTo>
> > >  <wsa:FaultTo>
> > >   <wsa:Address>http://some-other-address</wsa:Address>
> > >  </wsa:FaultTo>
> > >  ...
> > > </soap:Header>
> > > 
> > > The question is - where should the InvalidAddressingHeader fault go? 
 I
> > > see three possible choices:
> > > 
> > > 1) to the first <FaultTo>
> > > 2) to the second <FaultTo>
> > > 3) to the default (anonymous? see below)
> > > 
> > > The test assumes that the fault will be delivered via the HTTP
> > > backchannel, i.e. to anonymous.  But I can't find anything in the 
spec
> > > that would constrain an implementation to do so - in other words, it
> > > might be just as valid to try to send it to 
http://some-other-address.
> > > Therefore either the test is wrong to make the assumption, or the 
spec
> > > should be clarified.
> > > 
> > > I do think that in the case where we cannot correctly convert SOAP
> > > headers into an appropriate MAP, the value for that MAP should not 
be
> > > set (and in this case would therefore default to anonymous) - 
perhaps
> > > this is the intent, but we should really be explicit about this if
> > > that's what we mean.
> > > 
> > > Another question also arises - in the case where we have a problem
> > > generating the [FaultTo] MAP from the headers, should the generated
> > > fault be delivered to the [ReplyTo] address if there is one, or 
always
> > > to anonymous?  I'd guess the former, but again we should make sure 
we're
> > > clear and explicit about it.
> > > 
> > > I'd propose we fix this by adding something like the following at 
the
> > > end of the last paragraph in section 3.2: "In that case, any 
duplicated
> > > headers MUST NOT be used to populate the appropriate MAPs - the MAPs
> > > should be interpreted as if no such headers were present."  I 
*think*
> > > this should do it, and since we're already clear about the lack of 
an
> > > explicit FaultTo causing faults to go to ReplyTo, I think we're 
covered
> > > there.
> > > 
> > > I'd also like to add, for clarity, section headings for the last two
> > > paragraphs of section 3.2:
> > > 
> > > 3.2.1 Sending Messages
> > > 
> > > 3.2.2 Receiving Messages
> > > 
> > > Thanks,
> > > --Glen
> > > 
> > > [1] http://www.w3.org/2002/ws/addr/testsuite/testcases/#test1242
> > >