Re: 202 in current implementation

noah_mendelsohn@us.ibm.com wrote:
> 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.

The status code in case of fault should be 4xx or 5xx not 200.

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

+1
I certainly would not want to prevent the batching case.

There is one usecase (which has been discussed before) where sending a 
202 with an envelope in the response requires MU processing (though I'm 
not sure it needs to be reflected in our spec):

The receiver receives the message and sends a WS-ReliableMessaging ack 
(which requires a SOAP env in the HTTP entity body of the response) back 
to the sender. Per the WS-ReliableMessaging spec, to generate an ack (or 
to even know that the envelope in the request was a Reliable message), 
the receiver (or RMD in WS-RM parlance) must figure out the ID of the 
WS-RM Sequence. This requires that the RMD process the wsrm:Sequence 
SOAP header. And per the SOAP processing model, this would require that 
the RMD perform the MU check. This of course does not require that the 
receiver process other SOAP header or the SOAP body.

-Anish
--

>  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 Wednesday, 5 April 2006 08:09:40 UTC