- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Mon, 13 Mar 2006 10:51:09 -0500
- To: <public-ws-addressing@w3.org>
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
Received on Monday, 13 March 2006 15:52:41 UTC