W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2006

Re: SOAP 1.1 One-way HTTP Binding doc

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Wed, 01 Feb 2006 09:42:58 -0500
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Cc: paul.downey@bt.com, chrisfer@us.ibm.com, distobj@acm.org, dmh@tibco.com, dorchard@bea.com, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-id: <D98592DF-4725-4A25-8BE2-95C4612BD0E9@Sun.COM>
On Feb 1, 2006, at 1:18 AM, Anish Karmarkar wrote:
>>> However, given what Mark observed, I suspect
>>> that we might do well to specify that at a minimum, the SOAP  
>>> processing w/r/t SOAP headers MUST be performed before any  
>>> response is generated, so as to ensure that if a mU fault is  
>>> generated, it can be transmitted on the HTTP response (with a 500).
>> Except I might legitimately send back a 202 Accepted following  
>> securing the message in a database or putting it onto a reliable  
>> message queue, well before any SOAP processing has taken place.
> +1
That's one alternative.

> Or In the WSRX case, I might send back a 202 with a WSRX ack after  
> processing all the WSRX headers and storing the messages in a DB,  
> but before processing other non-WSRX headers.
That idea trouble me a bit, the SOAP processing model is all or  
nothing, allowing some headers to be processed and others to be  
ignored (at least for mU processing) diverges from the spec as I read  


>> For my money the ability to send a RX ACK in a 202 is interesting
>> and falls well within RFC2616's 202, but presumably would require  
>> SOAP processing generating MU faults etc, so would require more RX  
>> specific instruction in such a note building upon Dave's one-way  
>> note.
>> Paul

Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.

Received on Wednesday, 1 February 2006 14:43:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:12 UTC