Re: 202 in current implementation

Anish Karamarkar writes:

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

Oops, you're right.  I was busy thinking that it should not be a 202, on 
which we seem to agree, and didn't remember that for errors we use the 
http error status codes.

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

Good, we agree.  Thanks!

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

As you say, I don't think this belongs in our spec, at least for this MEP. 
 If someday someone wants to talk about conversational MEPS, we could, but 
I'm not in favor of doing so now.  There are in principle lots of places 
where someone may come upon a SOAP envelope and need for it to be 
processed as SOAP.  We only "own" the spec for that when it's part of an 
MEP.  In this case, I think the right way to do it is for us to say that 
the envelope may be delivered, and for the WSRM folks to write a SOAP 
binding that says basically:  "The SOAP Request/Response MEP and 
associated HTTP binding allow for delivery of an optional SOAP envelope 
with an HTTP status code 202, but neither calls for processing of such a 
response with the SOAP processing model.  WSRM does begin its processing 
of such messages by processing them with the SOAP processing model.  Note 
that if such processing results in a fault, the fault is to be {(sent in a 
request message back to node XXX), (made available locally but not 
transmitted to another node)} , or whatever WSRM actually wants.  In 
short, we deliver the message; they specifiy the SOAP processing.  I don't 
think this needs to be in an MEP, because it's not directly supported by 
bindings.  It's a convention layered on Request/Response.

Noah

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