RE: SOAP 1.1 One-way HTTP Binding doc

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 "

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 Thursday, 2 February 2006 02:05:20 UTC