RE: 202 in current implementation

Yves Lafon suggests:

> "If a mU fault has to be sent as part of the initial processing of the 
> request, it should be sent back to the originator instead of 
> using a HTTP 
> 202 return code."

>From the definition for 202 [1] 

"The request has been accepted for processing, but the processing has not 
been completed.  The request might or might not eventually be acted upon, 
as it might be disallowed when processing actually takes place."

So, I think we want to be careful not to commit the processor to having 
done mU checking before sending a 202.  I think we might therefore say:

"In conformance with the HTTP specification, a 202 response allows for the 
possibilities that any or all of the SOAP processing, or else no SOAP 
processing, might have been done at the time the response is sent.  If 
SOAP processing has been done, and if such processing has resulted in a 
fault (including mustUnderstand faults), that fault SHOULD be returned 
with a status code of 200, not 202.  If SOAP processing is deferred until 
after a 202 response has been sent, then the disposition of any resulting 
SOAP faults is beyond the scope of this specification. "

Maybe the wording could be tightened, but I think this makes clearer that 
a 202 does not commit the receiver to having done any processing.  If WSDL 
or WSA bindings to SOAP wish to mandate that mU checking be done before 
deciding on the status code, then those specs may so specify.   I don't 
think SOAP should preclude any options allowed by HTTP.

Noah

[1] http://www.faqs.org/rfcs/rfc2616.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Friday, 31 March 2006 23:14:43 UTC