- From: Mark Little <mark.little@jboss.com>
- Date: Thu, 16 Mar 2006 08:41:56 +0000
- To: Glen Daniels <gdaniels@sonicsoftware.com>
- CC: paul.downey@bt.com, public-ws-addressing-tests@w3.org
I agree that we need to test for this and I also think the specification should be more explicit on how to deal with errors during the processing of the WSA header information. What I'm still unclear about is what algorithm to use in this case. There appear to be only two: (i) it does make sense to say (as the last WG minutes indicate) that if you encounter an error at any point in the processing, then don't trust anything at all in the WSA header and send a fault back to the sender (anonymous). or (ii) if an error happens after processing part of WSA we could try and use that information to send back fault information (assuming we've parsed wsa:ReplyTo or wsa:FaultTo). The problem with (i) is that the receiver may not be expecting to get error messages on that channel. The advantage is that it's simple to reason about and can be tested by everyone. The problem with (ii) is that we can't tell if the information we've already parsed is valid and we also can't guarantee that WSA header information is sent and parsed in the same way by all senders or receivers. This makes a deterministic test impossible to achieve. The advantage is that we MAY be able to send back errors to an endpoint that can actually deal with them. I think we're all agreed that this is an edge case situation, so we probably shouldn't optimise the specification (or our tests) for it. As such, I'm more in favour of (i) than (ii) because of its simplicity. Mark. Glen Daniels wrote: >>> One way or another we should definitely add some tests. >>> >> feel free to submit test cases, I think the format is fairly >> clear. At this stage I think they'd be 'OPTIONAL' or 'INFORMATIONAL' >> unless they're aimed specifically at WSDL CR. >> > > Er... I think we should perhaps gather opinions on this. > > The problem is that the results for WSO2 -> just-about-everyone are > actually (assuming our interpretation is correct) logs demonstrating > IMPROPER behaviour according to our current spec. If I get a message > with no FaultTo, a ReplyTo of "none", and a duplicate To header, we > should NOT be getting a fault back on the HTTP backchannel. > > So, we should really probably fix the test assertions (by adding > something like "(no ReplyTo) OR (ReplyTo == anonymous)") for a bunch of > these tests, and also add the new one I described (I'll submit that in > the correct format). I don't think this should be OPTIONAL or > INFORMATIONAL. > > I don't want to hold things up, but nor do I want a test suite that > doesn't match our spec. > > --Glen >
Received on Thursday, 16 March 2006 08:40:48 UTC