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

Having caught up on my email backlog it seems that we need to tighten up the specification in terms of what it says about errors that occur during the processing of the WSA header. It does appear from the discussion in the WG that the consensus is that faults must be dealt with as though WSA was not being used at all. I missed that part of the meeting on Monday, so was there anything else said that isn't covered in the minutes?

Mark.


Mark Little wrote:
>
> 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
>>
>>   
>
>