Re: WSO2 -> Axis issues (PLEASE READ, SPEC/TEST ISSUES)

Hi Glen. Comments inline.

Glen Daniels wrote:
> Hi folks:
>
> Some issues with these results... I'd like to get things all green if
> possible, so would like to get these sorted.
>
> 1) Most of the failures are being caused by WSO2 sending <ReplyTo> of
> "none" in the problem header tests (1140-1244 and 1146,1246,1247).
> Aside from the "duplicate FaultTo" tests (1142,1242), I believe Axis is
> behaving entirely reasonably according to the spec - we are generating a
> fault (for instance, "duplicate To header") and then sending it to the
> FaultTo address, which defaults to the ReplyTo address if no <FaultTo>
> is present.  In this case, it goes nowhere because of the "none"
> ReplyTo.  We clarified this behavior on the WSA call this week.
>
> As it stands, everyone else is "passing" this test, and I think here we
> have an issue.  Nothing in the spec says, for example, "ignore ReplyTo
> in the case of duplicate To headers".  I could see an interpretation
> that "if any WSA processing fails, ignore all WSA stuff" (though the
> spec certainly doesn't say that), but that doesn't seem to be what's
> happening here either, since we're checking for WSA stuff in the
> responses....  So basically, right now everyone else seems to be
> assuming that faults should go to anonymous regardless of <ReplyTo> in
> the case of WSA header issues.  If we want that, we should make the spec
> say that - otherwise we should correct the current behavior.
>   

I agree, and the current text in the spec would seem to imply that 
ignoring ReplyTo in the absence of FaultTo in the case of any fault is 
wrong.

"Otherwise, if the reply is a fault message and the related message's 
[fault endpoint] message addressing property is not empty, select the 
EPR from that property. If the [fault endpoint] property is empty, 
select the EPR from the related message's [reply endpoint] message 
addressing property. Otherwise, if the [reply endpoint] property is 
empty, the behavior of the recipient of the related message is 
unconstrained by this specification."

I would have thought that if any WSA processing fails and the ReplyTo 
(or even FaultTo) attributes are valid, we should be sending an 
appropriate fault back. Failing silently is a bad idea IMO.
> I'd suggest a new test which has a problem header (dup Tos, say), no
> <FaultTo>, and a <ReplyTo> of none - then we assert no response content.
> Also, we could add a check for "(no ReplyTo) OR (ReplyTo =! 'none')" on
> the appropriate tests.
>
> Alternately we could make the spec actually specify "always send to
> anonymous for WSA problems", but I think that's a bigger change for WSA.
>   

That doesn't seem to be the path of least resistance ;-)
> 2) WSO2 is doing the same thing Microsoft is doing on test 1170, using a
> value of "true" for SOAP 1.1 mustUnderstand when in fact the only valid
> values are "1" and "0".  This should get fixed at MS/WSO2, as it's
> either a test client problem or a SOAP infrastructure problem on the
> client side.
>
> 3) test1138 was a problem with the client message... what's up with this
> (it actually looks OK to me), and if they're sending the same message to
> everyone why isn't this assertion failing for everyone?  Jonathan /
> Paul?
>
> Thoughts appreciated.
>   

Mark.

> Thanks,
> --Glen
>
>

Received on Wednesday, 15 March 2006 13:51:57 UTC