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

RE: SOAP 1.1 One-way HTTP Binding doc

From: <paul.downey@bt.com>
Date: Tue, 31 Jan 2006 21:48:07 -0000
Message-ID: <2A7793353757DB4392DF4DFBBC9522550276F2B0@I2KM11-UKBR.domain1.systemhost.net>
To: <chrisfer@us.ibm.com>, <Marc.Hadley@Sun.COM>
Cc: <Anish.Karmarkar@oracle.com>, <distobj@acm.org>, <dmh@tibco.com>, <dorchard@bea.com>, <public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>


> Given that a 202 response is not related to the *processing* of the 
> request message, one could conclude that any SOAP envelope carried 
> in the 202 Accepted response might not necessarily
> have a relationship with the request message at all. 

So RFC2616 says "202 Accepted:"
 
  "The entity returned with this
   response SHOULD include an indication of the *request*'s current 
   status and either a pointer to a status monitor or some estimate 
   of when the user can expect the *request* to be fulfilled."

// my emphasis

> 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.

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
Received on Tuesday, 31 January 2006 21:48:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:11 GMT