Re: SOAP 1.1 One-way HTTP Binding doc

David Orchard wrote:
> I'm a little confused by Anish's message because he went from " 
> 
>>>>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 "
> 
> 

Not sure what was confusing about that.
Were you confused/concerned that the example did not state that all the 
MU checking would be done before the WSRX headers are processed?

What I meant in my example (would that be 0th example?) was:
"... I might send back a 202 with a WSRX ack after >>doing the MU 
check<<, processing all the WSRX headers and storing the messages 
 >>which consists of SOAP body and all the non-WSRX headers<< in a DB, 
but before processing other non-WSRX headers."

Does that make it clearer?

> To 4 examples that more clearly show that the 202 could be sent back
> before any SOAP processing or after all mU=True have been checked for.  
> 
> However, pressing onwards.  I think 1-4 are all valid and I'd roughly
> expect #1 to be the most common.  There's nothing in either the SOAP
> spec or the HTTP spec that constrains a receiver to choose a subset of
> those.  
> 
> Not knowing how an receiver might respond would make a sender probably
> want to put a non-anon FaultTo so it would get the fault in all 4 cases.
> 
> 
> This obviously relates to the anon AcksTo problem in WS-RX.  The RX node
> could pick #1 and the Acks would be lost.
> 
> Cheers,
> Dave
> 
> 
>>-----Original Message-----
>>From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
>>Sent: Wednesday, February 01, 2006 3:09 PM
>>To: Marc Hadley
>>Cc: paul.downey@bt.com; chrisfer@us.ibm.com; distobj@acm.org;
>>dmh@tibco.com; David Orchard; public-ws-addressing@w3.org; public-ws-
>>addressing-request@w3.org
>>Subject: 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 Monday, 6 February 2006 19:59:37 UTC