RE: SOAP 1.1 One-way HTTP Binding doc

Hey folks:

Brief comments below....

> > > 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. 
> 
> I think that this is making some dangerous assumptions, that 
> the wsa:ReplyTo 
> and wsa:FaultTo are non-anonymous. Wouldn't it be required to 
> KNOW that with 
> some certainty? e.g. wouldn't the SOAP processing, at least 
> as far as inspecting 
> the message to ENSURE that were the case, need to be 
> performed? What if the 
> wsa:ReplyTo and/or wsa:FaultTo *were* anonymous? (oops). For 
> that matter, 
> what if they had been omitted altogether (after all, they are 
> not required). 
> 
> Shouldn't the message at least be scanned to ensure that it 
> is in fact 
> the correct version of SOAP? 
> 
> > > 
> > > 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. 
> 
> Again, see above. This gets a little closer to what I would 
> expect. Whether 
> the headers are *processed* or just inspected (e.g. for mU 
> purposes as well 
> as to ensure that the wsa:ReplyTo and/or wsa:FaultTo are 
> non-anonymous). Clearly, 
> if they are anonymous or omitted (which I believe means that 
> they default to 
> anonymous) then the message would need to be *processed* rather than 
> stored for subsequent batch processing. 
> 
> > > 
> > > 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. 
> 
> I tend to agree with Marc. Something part way between (2) and 
> (3) is warranted. 
> I don't think (1) is valid. Certainly, (1) is making some 
> pretty dangerous assumptions. 

Perhaps it would make sense to use more specific status code definitions
here?

202 = Message accepted, nothing more can be assumed (i.e. it's not
really "OK")
210 = Message accepted, MU processing OK (i.e. if there's a faultTo you
can probably assume you'll get any faults there)

...or something similar.

I tend to agree that an "OK" response SHOULD mean that at least minimal
SOAP processing has occurred (version check, MU check), but I can see
the utility to the batching use-case as well.  Alternately, we could
explicitly disallow "raw" batching and indicate that the 202 MUST only
be sent after at least MU processing.

--Glen

Received on Friday, 3 February 2006 17:54:17 UTC