Re: SOAP 1.1 One-way HTTP Binding doc

Marc Hadley wrote:
> On Feb 1, 2006, at 1:18 AM, Anish Karmarkar wrote:
> 
>>
>>>> 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.
>>
>>
>> +1
>>
> That's one alternative.
> 
>> Or In the WSRX case, I might send back a 202 with a WSRX ack after  
>> processing all the WSRX headers and storing the messages in a DB,  but 
>> before processing other non-WSRX headers.
>>
> That idea trouble me a bit, the SOAP processing model is all or  
> nothing, allowing some headers to be processed and others to be  ignored 
> (at least for mU processing) diverges from the spec as I read  it.
> 

I was not suggesting that the receiver not follow the SOAP processing 
model. The non-WSRX headers in the example above are indeed processed, 
but they are processed after 202 is sent back. The SOAP processing model 
does not impose any header processing order. There are several ways the 
receiver can process the message while staying within the processing 
model. HTTP 202 status code is intentionally non-committal. The question 
I think we should consider is: do we want to restrict when the 202 gets 
sent. Some examples/scenarios of when 202 could be sent:

1) receiver sends 202 after all the bytes are received correctly (with 
the right HTTP headers/media type), >>but before the SOAP message is 
processed at all<<. The message gets stored in some message store. Batch 
processing of all messages is done once per day. If there is a fault 
that is generated it is sent to wsa:FaultTo. If there is reply to be 
sent, it is sent to wsa:ReplyTo. Both wsa:FaultTo and wsa:ReplyTo are 
non-anonymous.

2) receiver sends 202 after all the bytes are received correctly (with 
the right HTTP headers/media type), >>and after all the MU processing 
(check to ensure that all MU=1 headers are understood, else generating 
MU fault) is done, but before the headers and body are processed<<. The 
message gets stored in some message store. Batch processing of all 
messages is done once per day. If there is a fault that is generated it 
is sent to wsa:FaultTo. If there is reply to be sent, it is sent to 
wsa:ReplyTo. Both wsa:FaultTo and wsa:ReplyTo are non-anonymous.

3) receiver sends 202 after all the bytes are received correctly (with 
the right HTTP headers/media type), >>and after all the MU processing 
(check to ensure that all MU=1 headers are understood, else generate MU 
fault) is done and after the headers are processed<<. The message (with 
only soap body and no headers) gets stored in some message store. Batch 
processing of all messages is done once per day. If there is fault that 
is generated that is sent to wsa:FaultTo. If there is reply to be sent, 
it is sent to wsa:ReplyTo. Both wsa:FaultTo and wsa:ReplyTo are 
non-anonymous.

4) receiver sends 202 after all the bytes are received correctly (with 
the right HTTP headers/media type), >>and after all the MU processing 
(check to ensure that all MU=1 headers are understood, else generate MU 
fault) is done and after the headers and body are processed<<.

Are you suggesting that only (2), (3) and (4) should be allowed but not 
(1)? The way I see it, I don't see why (1) should not be allowed -- we 
are after all trying to do a "one-way" over HTTP and 202 is 
intentionally non-committal (wrt the processing of the received 
message). IOW, what can the sender assume when it gets back a 202? I 
would say: not much other than the fact that the bytes were correctly 
transmitted/transfered.

Comments?

-Anish
--

Received on Wednesday, 1 February 2006 23:09:43 UTC