- From: <paul.downey@bt.com>
- Date: Tue, 31 Jan 2006 21:48:07 -0000
- 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 UTC