RE: 202 in current implementation

On Fri, 31 Mar 2006, 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:

Well, if the processor doesn't do that, then the output is not a reply as 
in "SOAP request reply with optional envelope", but more one way.

It is still possible ton consider this as being a underlying protocol gateway
(ie: not linked to the SOAP processing) from HTTP to JMS for example.

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

So to summarize "if you get a 202, you can't conclude anything unless you 
know the state machine of the targeted service"
Also a fault should be returned using a 4xx or 5xx.

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

Well, it seems to stretch a bit the definition or RoR, but as we will not 
produce a pure one way for HTTP, that might be the most pragmatic 
solution, especially as there are already implementations around.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Monday, 3 April 2006 13:18:12 UTC