- From: Mark Little <mark.little@jboss.com>
- Date: Thu, 16 Mar 2006 09:26:24 +0000
- To: Glen Daniels <gdaniels@sonicsoftware.com>
- CC: paul.downey@bt.com, public-ws-addressing-tests@w3.org
Mark Little wrote: > 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. Scratch that. As Kevin just reminded me, the sender should expect errors during transmission for things like MU anyway. > 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 09:25:40 UTC