Re: SOAP 1.1 One-way HTTP Binding doc

I'm not sure how much actual disagreement there is here, as opposed to
differences in perspective and terminology, but here's my understanding:

Under HTTP rules, there is a semantic difference between
200-with-something (e.g. 200-with-SOAP-envelope) and
202-with-something.  IIUC, the difference is the difference between "I
got your request, here's your response." and "I got your request.  Stay
tuned for further details." optionally together with "Here's some status
information."

The question at hand is how (or whether) to bring this through to the
SOAP request-response MEP, keeping in mind that protocols other than
HTTP may view the world differently.

The status quo SOAP request-response MEP normally exchanges two SOAP
envelopes: a request and a response (no great surprise there).  The
response may be a reply or a fault.  In keeping with local customs, the
(1.2) HTTP binding uses 200 for a reply and 4xx/5xx for a fault.  As far
as I can tell this is for the benefit of the HTTP infrastructure.  The
SOAP level does not distinguish between "SOAP envelope with success
code" and "SOAP envelope with fault code".  The fault code, if any, is
in the SOAP envelope.  For my money, this convention risks confusion
between faults ("I got your request, I don't like it, here's why") and
failures ("There's no one here by that name, the server was too busy to
answer  the phone, etc.).

We had been trying to expand the SOAP request-response MEP just slightly
to allow the server, instead of sending back a SOAP envelope (or
failing), simply to inform the client that the request was received
successfully.  We went ahead with this /on the assumption that people
were already doing essentially this and therefore breakage would be
minor./  I believe that 202 was picked on the same basis.

Now, if an envelope comes back along with that 202 code, what should a
SOAP processor do with it?

   1. Say to itself "Hmm, interesting, that envelope came back with a
      202 code." and then pass the SOAP envelope up the stack like
      anything else
   2. Pass the SOAP envelope up the stack with an indication that it
      came with a 202 code
   3. Complain
   4. Ignore the envelope
   5. Pass the envelope to some processor /other than/ the application
      layer (i.e. WS-RX), and send the application layer an ack.
   6. Something else entirely

Option 1 seems like the most direct migration path, but in that case the
202 is effectively ignored (and why not use an empty 200 as an ack).  I
could certainly imagine 3 and 4 happening in real stacks.  Option 2 is
more in keeping with HTTP semantics, but is anyone expecting this, and
how does it generalize beyond HTTP?  Option 5 seems more like what we'd
need for the use case of piggybacking WS-RX acknowledgments.

That there are at least 5 plausible options indicates to me there is
potential for breakage.

Mark Baker wrote:

>On 1/31/06, David Hull <dmh@tibco.com> wrote:
>  
>
>> We've been pretty clear for a while that empty 202 means "ack".  I'm
>>hearing that non-empty 202 is meant for things like WS-RX acks, but I'm not
>>sure this is nailed down.  There seems to be some possibility that a 202
>>with a SOAP envelope could also be a real response.
>>    
>>
>
>It's still a response, just not the result of processing the request.
>
>So if you took a SOAP envelope and sent it as an HTTP response with a
>202 code, it would mean something entirely different than if sent back
>with a 200 code... in the same way that a SOAP fault sent with 200
>means something entirely different than a SOAP fault
>
>  
>
>> If 202 can be a real response, then one would have to use something besides
>>202 to figure out what's really going on (e.g., whether the message consists
>>only of WS-RX headers and similar).  In this case 202 isn't really carrying
>>any information and why bother allowing for it?  On the other hand, if 202
>>means something in particular, then what exactly does it mean?
>>    
>>
>
>Just what it says in the HTTP spec.
>
>  
>
>> As far as I can tell, the value in non-empty 202 is telling the SOAP stack
>>"Hey, this is just infrastructure stuff.  Don't pass it along to the
>>application."  We can't say that here, but we could (probably) say it
>>elsewhere.
>>    
>>
>
>202, like 200, is a symbol with application layer semantics, and as
>such, it should be exposed to the application (plus the SOAP 1.2 HTTP
>binding is a *transfer* binding).  In the case of 202, the application
>needs to know that no subsequent message which includes "the results
>of processing" of the initial request, is necessarily forthcoming (and
>won't be without additional agreement).
>
>BTW, I just noticed this part of the 202 spec which should probably be
>highlighted;
>
>  "The entity returned with this
>   response SHOULD include an indication of the request's current status
>   and either a pointer to a status monitor or some estimate of when the
>   user can expect the request to be fulfilled."
>
>Which suggests that a URI could be returned upon which the application
>could invoke GET to determine the state of the processing of the
>request (anybody remember CORBA "Futures"?).
>
>Mark.
>
>  
>